Nyt kun kesälomakausi lähestyy, ajattelin käydä läpi kokemuksia ja omia ajatuksiani matkan varrelta Microsoft Fabricilla tehtyjen hankkeiden kautta. Tämä ei missään nimessä ole kirjoitus Fabricin ylivertaisuudesta, ylistystä sen salamannopeasta suorituskyvystä, saatikka sen tarjoamista mahdollisuuksista luoda käyttäjäorganistaatiostaan markkinajohtaja, joka puristaa uusimmat mehut AI:sta. Tämä on lyhyt kirjoitus asioista, joita mielestäni on hyvä ottaa huomioon aloittaessa tietoalustan tekemistä Fabricilla. Ihan kuten millä tahansa teknologialla, suunnittelu on kaiken A ja O. Uuden hankkeen ollessa käsillä, on oikeasti hyvä pysähtyä hetkeksi pohtimaan, mitä oikeastaan halutaan saavuttaa. Vasta sen jälkeen vastataan kysymykseen, miten.
Parhaita käytänteitä ja kultaisia arkkitehtuureja löytyy jokaiselta järjestelmätoimittajalta ja alan toimijalta, ja usein ne kaikki toistavat samaa kaavaa: tehdään mitaliarkkitehtuuri ja tallennetaan kaikki saatavissa oleva data. Tässä arkkitehtuurissa ei ole mitään vikaa, päinvastoin; data-alustan rakenne on hyvä hajottaa eri kerroksiin datan jalostusasteen mukaan. Se mihin tämä usein johtaa, on, että kaikki lähdejärjestelmädata ladataan ja tallennetaan data-alustalle päivittäin kokonaisuudessaan. Huolimatta siitä, miten data säilyy lähdejärjestelmässä, ajetaan datan kopiointitoimet päivittäin ja tallennetaan päivätason kansiorakenteen mukaisesti.
Mutta onko näin aina pakko tehdä? Ei mielestäni. Vaikka tämä toimintatapa on helppo perustella sillä, että tallentamalla datan tilanne joka päivä, siihen voidaan tarvittaessa palata, ei se ole välttämätöntä. Jos data säilyy lähdejärjestelmässä, voidaan ihan hyvillä mielin lukea vain uudet ja päivittyneet rivit, ja jatkaa siitä eteenpäin data-alustalla. Vaikka pilvitallennustila on suhteellisen edullista, päivittäin kasvava tallennusmäärä kumuloi pitkässä juoksussa kustannuksia ja joskus merkittävänkin määrän.
Vaikka kaiken datan päivittäinen lataaminen on aina tehty ja firman legendaarisin arkkitehti teki aina Azure Data Factory:llä päivätason kopioinnit data lakeen, Fabricissa kannattaa hyödyntää Mirroring-toiminnallisuutta ja lukea suoraan lähdettä kopioimatta dataa ajastetusti. Anna järjestelmän tehdä se automaattisesti, mihin muuten pitäisi tuhlata aikaa.
Se, onko Bronze-kerros puhtaasti tiedosto-osio Silver-lakehousessa lähdejärjestelmien rajoitteiden tai päätetyn arkkitehtuurin seurauksena, vai onko Bronze täysin oma lakehouse, ei mielestäni ole niin merkityksellistä, kuin se, miten data luetaan näiden kerrosten välillä. Jos Bronze-kerros on vain kokoelma tiedostoja eri formaateissa Silver-lakehousessa, voi näiden päälle tehdä external-taulut, jolloin niitä on helppo kysellä käyttäen myös Spark SQL:ää. Jos päädytään siihen, että Bronze-kerros on oma lakehouse, kannattaa Silver-kerroksessa hyödyntää shortcut-ominaisuutta, jolloin data on luettaessa tuoretta, eikä tällä hetkellä Fabricia riivaava SQL endpointin viive vaikuta käsiteltävän datan tuoreuteen.
Seuraava kohta koskee Lakehouseja ja niiden prosessointia. Käytä notebookeja aina, kun mahdollista. Ne tarjoavat joustavan tavan lukea, prosessoida ja tallentaa dataa usealla eri koodikielellä. Älä kuitenkaan tee yhtä isoa notebookia, joka tekee kaiken; huolimatta siitä, että notebookissa on erinomaiset dokumentointiominaisuudet, vaan tee useampi notebook, yksi jokaista käsiteltävää entiteettiä kohden. Säästät aikaa tulevaisuudessa, mikäli sinun pitää tehdä muutoksia tai korjata virheitä. Notebookit on hyvä prosessoida käyttäen notebookutils:n runmultiple-toiminnallisuutta, jolloin voit itse määritellä mm. ajettavien notebookien riippuvuussuhteet ja ajojärjestyksen. Näin voit myös säästää resursseja, kun voit hyödyntää samaa Spark-sessiota, ilman että jokainen notebook käynnistää oman session ja kuluttaa resursseja usein turhaan. Uuden session käynnistäminen myös tarvitsee aikaa, joten jakamalla session, voit säästää merkittävänkin määrän aikaa joutokäynnistä.
Hyödynnä versionhallintaa. Vie vähintään kehitystyötilasi koodit GIT:iin, niin säästyt monelta harmilta myöhemmin. Ihan ongelmatonta tämäkään ei välttämättä ole, mutta tee se silti. Keväällä 2025 julkaistiin Fabricin työtilojen kansiorakenteen tuki GIT:iin, eli versionhallintaan lisättiin tuki sille kansiorakenteelle, mikä työtilassa on tehty artefaktien järjestelemiseksi. Kansioiden hyödyntäminen on hyvä tapa järjestellä esimerkiksi erityyppiset tai eri kerrosten artefaktit omiin kansioihinsa sen sijaan, että kaikki olisivat samassa pitkässä listassa. Hieno homma; kansiot menevät myös versionhallintaa, mutta samalla kun tämä ominaisuus julkaistiin, hajotti se toisen.
Teimme toteutusta, jossa ajatuksena oli hyödyntää Fabricin SQL tietokantaa konfiguraatioiden ja ohjaustietojen säilytyspaikkana. Tarkoituksena oli sammuttaa Azuren SQL-kanta, joka oli toiminut siinä roolissa siihen saakka. Fabric SQL toimi loistavasti siihen asti, kunnes yllä mainittu GIT:n hakemistotuki julkaistiin. Kun ominaisuudesta kertova ilmoitus ilmestyi Fabricin käyttöliittymään, hajosivat kaikki data pipelinet, joissa viitattiin käytössämme olleeseen Fabric SQL -kantaan. Tästä luonnollisesti seurauksena oli pitkä ja tulokseton viestinvaihto teknisen tuen kanssa, ja muistutus siitä, että Preview-merkinnällä varustettu ominaisuus kannattaa ottaa mukaan harkiten.
Power BI:ssä on kautta historian ollut näitä esikatseluominaisuuksia, ja monia niistä on käytetty ilman mitään ongelmia, joten uskonloikka oli tässäkin tapauksessa perusteltu. Noh, lopputuloksena asia on edelleen jossain päin maailmaa selvityksessä ja konfiguraatiot luetaan Azure SQL:stä. Muutetaan sitten myöhemmin. Vanha vitsi siitä, että Windowsin voi asentaa omalle koneelle, kun SP1 on julkaistu, ei välttämättä ole ihan vailla katetta.
Fabricista näkee ja tuntee monilta eri osin, että se on uusi ja kehittyvä alusta. Verrattuna jo pidempään tarjolla olleisiin kilpailijoihin, jotkin sen puutteet vaikuttavat jopa huvittavilta. Toki nauru on aika lujassa, kun pitää improvisoida ratkaisua, joka kuulostaa ihan palalta sitä isoäidin kuuluisaa mansikkakakkua.
Fabricissa on kuitenkin valtavasti potentiaalia ja sen suorituskyky on osoittautunut erittäin hyväksi. En saattanut uskoa, että kirjoittamani koodi todella suoritettiin kokonaisuudessaan ja kohdetaulu päivitettiin uudella datalla, niin nopeasti sen suoritus meni läpi. Kokonaisuutena Fabricissa on mielestäni vielä kehitettävää, vaikka sinne tulee jatkuvasti uusia ja erittäin hyödyllisiä ominaisuuksia, toivoisin näkeväni myös olemassa olevien haasteiden saavan huomiota. Välillä tuntuu, että markkinan kuumetessa uutta julkaistaan kiihtyvällä tahdilla, mutta olemassa olevat ongelmat eivät saa sitä kiireellisyysluokitusta, mikä niille mielestäni kuuluisi. Tällä en tarkoita sitä, että Fabric olisi huono, vaan sitä, että korjaamalla virheet samalla tarmolla, kuin tuomalla uutta, säästettäisiin kehittäjien aikaa ja mielenterveyttä. Jokainen bugi on kierrettävissä, mutta se johtaa huonoon arkkitehtuuriin ja wtf-hetkiin tulevaisuudessa.
Autamme mielellämme Fabric ja Power BI asioissa. Yhteystietomme löydette täältä.