Microsoft Fabric on Microsoftin uusin tarjooma datan pyörittelyyn. Fabric on ensinäkemältä yksinkertaisesti sateenvarjo, jonka alle on koottu yhteen dataan liittyviä erilaisia palveluita. Ensivaikutelma on siis hyvin samanlainen kuin jo tutuksi tulleessa ja hyväksi todetussa Azure Synapse Analytics -palvelussa. Pinnan alla on kuitenkin myös oikeasti datainsinöörin ja BI-kehittäjän elämää helpottavia uudistuksia.
Tämä on ensimmäinen osa sarjassa blogikirjoituksia, joissa käyn läpi Microsoft Fabric -tuotetta. Tässä kirjoituksessa tarkastelen mitä Microsoft Fabric tarkoittaa organisaatioille, jotka ovat panostaneet esimerkiksi Synapse Analyticsin käyttöön, kuinka Fabricin kustannukset muodostuvat, ja millä tavalla Fabric helpottaa organisaation datan käyttöä kahdessa tavallisessa käyttötapauksessa: johdon raportoinnin kehittämisessä ja IoT-datan käsittelyssä.
Sarjan toisessa osassa syvennyn tarkemmin kuhunkin Fabricin osa-alueeseen teknisestä näkökulmasta ja vertailen Fabricia Microsoftin muihin datatuotteisiin eli lähinnä Azure Synapse Analyticsiin.
Mistä on kyse, ja mitä tapahtuu Synapse Analyticsille?
Microsoftin omien sanojen mukaan Fabric on kaikenkattava, ”all-in-one”-tuote datan siirtoon, datan käsittelyyn, datan reaaliaikaiseen käsittelyyn, business intelligenceen ja tietovarastointiin. Lyhyesti sanottuna Fabric pitää sisällään tutut, aiemmin erillisinä olleet datatuotteet. Microsoft käyttää niistä Fabricin sisällä nimitystä ”experience”, eli suomeksi jotakuinkin ”kokemus”, mutta on ehkä helpompi kutsua niitä osa-alueiksi. Niitä ovat:
- Data Factory
- Data Engineering (vertautuu Azure Databricksiin)
- Data Science (kuten Azure Machine Learning)
- Data Warehouse (kuten aiemmat Microsoftin warehouse-ratkaisut)
- Real-Time Analytics (yhdistelee Azure Event Hubsia ja Azure Stream Analyticsiä)
- Power BI
Toisaalta jo Azure Synapse Analytics sisälsi Data Factoryn ja Data Engineering -osiot ja myös tietovarastointia ja Power BI:tä. Mitä näistä työkaluista organisaatioiden sitten tulisi jatkossa käyttää?
No, ilmeisesti Microsoftin mielestä Fabric on se suunta, mihin asiakkaiden olisi syytä katsoa tästä eteenpäin (tosin tällä hetkellä tuote on preview-tilassa, eikä esimerkiksi asiakastukea siihen saa). Microsoft itse asiassa mainostaa Fabricia Synapse Analyticsin dokumentaation etusivulla. Lisäksi Fabricin dokumentaatiossa on maininta, että vaikka Synapse Analytics, Data Factory ja Data Explorer jatkavat elämää tuotteina, on Fabric niistä seuraava, parempi versio.
Microsoft näkee Fabricin helppokäyttöisenä ja kustannustehokkaana SaaS-ratkaisuna, siinä missä em. vanhat tuotteet ovat enemmänkin PaaS-tuotteita (vaikka eivät nekään vaikeakäyttöisiä tai paljon ylläpitoa vaativia ole). Lisäksi Microsoft sanoo, että em. vanhoille tuotteille olisi tulossa jossain vaiheessa migraatiopolkuja Fabriciin. Voisin siis kuvitella, että jos Fabric vain saa hyvän vastaanoton ja lopulta jalostuu valmiiksi tuotantokelpoiseksi tuotteeksi, on Microsoftin pyrkimys saada asiakkaat siirtymään siihen.
Jos organisaatio on panostanut jo vahvasti esimerkiksi Synapse Analyticsiin, Azure Data Factoryyn tai Databricksiin ja perustanut data laken Azure Data Lake Storage (ADLS) Gen 2:n päälle, voi asia tuntua hieman turhauttavalta. Harmistukseen ei kuitenkaan ole niin paljon aihetta kuin luulisi, sillä Microsoft Fabric sisältää muutamia mukavia ominaisuuksia, joilla vanhojen tekniikoiden käyttöä voi jatkaa yhdessä Fabricin kanssa, ja toisaalta se todellakin tekee kehityskokemuksen sen verran mukavaksi, että siihen siirtymistä (joko em. migraatiopolkujen kautta tai suoraan) kannattaa kyllä harkita.
Tutkin Fabricin uusia ominaisuuksia tarkemmin myöhemmin tässä blogikirjoituksessa kahden tyypillisen käyttötapauksen kautta. Fabric-aiheisten blogikirjoitusten seuraavassa osassa tarkastelen ominaisuuksia vielä tarkemmin teknisestä näkökulmasta. Nyt kuitenkin on aika puhua hetki rahasta!
Lisensointi ja kustannukset
Fabricia voi käyttää myös täysin ilman Azure-tiliä, koska sillä on vahva sidos Power BI -tuotteeseen ja sen käyttämiin lisensseihin. Myös tarvittavan Power BI -lisenssin voi hankkia ilmaiseksi, jos ei sellaisia ole ennestään, ja sillä pääsee tutustumaan myös kaikkiin Fabricin ominaisuuksiin kokeilujakson ajan. Rajoituksia on tällöin kuitenkin Power BI -raporttien jakamisessa muille käyttäjille.
Fabricissa ei Synapsesta poiketen provisioida ja hallinnoida kustannuksia per tuote, vaan Fabricille ostetaan haluttu määrä kapasiteettia, jonka lisäksi maksetaan käytetystä tallennustilasta. Kaikki Fabricin eri osa-alueet käyttävät tätä kapasiteettia. Kapasiteetin seurantaan on Fabricin sisällä saatavilla Power BI -sovellus/raportti, joka vaikuttaakin erittäin kattavalta. Tallennustilan hinnoittelu on Microsoftin mukaan saman suuntainen kuin tavallisella ADLS Gen 2 -data lakella.
Kustannukset koostuvat siis tallennustilasta ja valitusta kapasiteetista. Jos lisäksi tarkoitus on hyödyntää täysillä myös Power BI -ominaisuuksia, tarvitaan myös maksullisia Power BI -lisenssejä. Toisaalta, jos organisaatio käyttää jo nyt Power BI:tä, saattaa tarvittavat lisenssit olla jo olemassa.
Koitan tässä kuvata hyvin yksinkertaisesti, kuinka Fabricin saa käyttöön. Microsoft ei mielestäni ole onnistunut kuvaamaan lisensointia kovin selkeästi. Ylätasolla Fabricin käyttöön vaikuttaa kaksi merkittävää tekijää: a) onko organisaatiossa jo (tietyn tyyppisiä) Power BI -lisenssejä ja b) onko tarkoitus hyödyntää Fabricin Power BI -ominaisuuksia. Jos organisaatio on jo panostanut paljon Power BI:hin niin luultavasti tällöin löytyvät myös vaadittavat lisenssit, joilla Fabricin saa käyttöön ja joilla voi myös tehdä siellä kaikki tarvittavat Power BI -temput.
Power BI -lisensseillä Fabricin käyttöönotossa tulee huomioida seuraavaa:
- Jos organisaatiolla on Power BI Premium -lisenssi, saa sillä Fabricin kaikki ominaisuudet käyttöön ja se sisältää myös dedikoitua kapasiteettia.
- Premium Per User (PPU) -lisenssillä saa käyttöön Fabricista vain Power BI -toiminnallisuudet ja silloin käytetään jaettua kapasiteettia.
Ilman Power BI -lisenssejä Fabricin saa käyttöön Azuresta:
- Kapasiteettia voi ostaa Azuren kautta, eli tähän tarvitaan Azure-tili. Kun tähän lisää ilmaisen käyttäjäkohtaisen Power BI -lisenssin, pystyy luomaan Power BI -sisältöä, mutta sitä ei pysty jakamaan muiden käyttäjien kesken. Muiden tekemää ja jakamaa Power BI -sisältöä pystyy kuitenkin katsomaan (jos niiden tekijöillä on jakamiseen oikeuttava lisenssi).
- Jos halutaan pystyä käyttämään Power BI:tä täysmääräisesti, täytyy hankkia lisäksi myös käyttäjäkohtaisia Power BI Pro -lisenssejä.
Azuresta ostettuna kapasiteettia kulutetaan pay-as-you-go-tyyliin minuuttikohtaisella hinnoittelulla. Kapasiteettia voi skaalata tarpeen mukaan milloin vain ylös ja alas, ja sen voi jopa pistää tauolle tarvittaessa, jolloin ei tule kustannuksia. Jos taas käytetään Power BI Premium -lisenssejä, on käytössä valittu kapasiteettitaso kuukausihinnoittelulla. On kapasiteetti hankittu mistä tahansa, niin jos sitä kulutetaan hetkellisesti enemmän kuin mitä valittu taso sallii, skaalaa Fabric suorituskykyä alaspäin. Kapasiteetti ei siis voi loppua koskaan kesken.
Fabric on käytettävissä kaikkien ominaisuuksien osalta ilmaiseksi näillä näkymin lokakuun 1. päivään asti, kun aktivoi 60 päivän kokeilujakson. Kokeilujakson aktivoimiseen Microsoftilta löytyy kattavat ohjeet täältä: https://learn.microsoft.com/en-us/fabric/get-started/fabric-trial
Kaksi käyttötapausta, joissa Fabricin hyödyt tulevat esiin
Käsittelen tässä kahta erilaista hyvin tuttua dataan liittyvää käyttötapausta siitä näkökulmasta, että kuinka niiden kehittäminen, käyttäminen ja ylläpitäminen on erilaista ja kenties helpompaa Microsoft Fabricilla: johdon raportointi sekä IoT-datan käsittely.
Johdon raportointi
Hyvin tyypillinen dataan liittyvä käyttötapaus on johdon raportointi, jossa yleensä useasta eri tietojärjestelmästä tai tietokannasta/tietovarastosta tuodaan dataa data lakeen, jalostetaan sitä jollain tavalla ja tarjotaan se esimerkiksi Power BI -raportilla tai räätälöidyllä sovelluksella käyttäjille.
Homma on ollut ratkaistavissa Azuren datatyökaluilla jo pitkään:
- Azure Data Factory tuo dataa esimerkiksi ajastetusti tai muuten triggeröitynä yöaikaan eri järjestelmistä eräajotyyppisesti data lakeen ns. raakadata-alueelle.
- Dataa voidaan muotoilla, yhdistellä tai siistiä joko Data Factoryssä tai Azure Databricksillä ja viedä se data lakeen ns. tuotantoalueelle.
- Data voidaan sen jälkeen tuoda Power BI:n käytettäväksi esimerkiksi Azure Synapse Analyticsin Serverless SQL -taulujen kautta, jolloin data pysyy data lakessa (ns. lakehouse -lähestymistapa) tai sitten dataa tuodaan SQL Warehouseen ja Power BI hakee sen sieltä.
- Räätälöidyille sovelluksille data, tai yleensä vain osa siitä, on voitu edelleen viedä vaikkapa tavalliseen Azure SQL-tietokantaan tai CosmosDB-tietokantaan.
Oikeastaan prosessina homma menee Fabricia käyttäen samalla tavalla, mutta käytetyt työkalut ovat hieman erilaisia ja niiden käyttöä helpottamaan Fabricissa on tiettyjä uudistuksia verrattuna vanhaan.
Itse kehittäjänä koen, että isoin muutos kehittäjäkokemuksessa saattaa tulla olemaan täysi Git-versionhallintatuki sekä CI/CD-tuki kaikille Fabricin eri osasille. Tällä hetkellä nämä ominaisuudet ovat vielä erittäin rajoitettuja Fabricissa, mutta pitkällä aikavälillä näen tässä paljon potentiaalia, joka vähentää kehittäjien tuskailua eri työvälineiden, versionhallinnan sekä eri ympäristöjen (kehitys, testi, tuotanto) hallinnassa. Näin voi käydä, jos sekä Data Factoryn pipelinet, eli datan siirtoon tehdyt putket, Spark-notebookit datan muokkaukseen, Data Warehousen skeemat sekä Power BI -raportit ovat jonain päivänä Git-versionhallinnassa ja lisäksi kaikkien näiden palasten kehittäminen ja vienti testiin ja edelleen tuotantoon tapahtuu hallitusti CI/CD:n avulla. Kaikki nämä tekniikat ovat olleet jo pitkään peruskauraa sovelluskehityksessä, mutta dataan liittyvässä kehityksessä homma on ollut hyvin hajanaista ja pirstaloitunutta. Fabric voi hyvinkin tuoda tähän muutoksen, mutta se nähdään vasta jonkin ajan kuluttua.
Fabricin data lake on myös iso parannus aikaisempiin erillisiin ADLS Gen 2 -data lake -ratkaisuihin Azuressa. Tai oikeastaan itse data lake ei ole merkittävästi erilainen, mutta sen integroituminen osaksi kaikkia tässä käyttötapauksessa käytettäviä eri palasia sen sijaan on. Fabricissa sekä Data Factory että notebookit datan muokkaukseen ovat suoraan yhdistettävissä Fabricin sisällä olevaan data lakeen ilman sen kummempia kytkentöjä. Tämä on iso parannus aiempaan, jossa piti luoda yhteys jossain päin Azurea olevaan data lakeen.
Fabricin data lakeen voi myös lisätä muita data lakeja Azuressa tai AWS S3:ssa käyttäen ns. shortcutteja. Tämä voi itse asiassa säästää huomattavan määrän työtä ja rahaa: datan kopiointia ei tarvitse tehdä, jolloin ei tarvitse tehdä datalle pipelineja Data Factoryyn eikä maksaa levytilasta kopioidulle datalle. Tosin se yleisempi tilanne on kyllä se, että data on sellaisissa paikoissa, joista se joudutaan Data Factoryllä hakemaan. Kannattaa toki muistaa sekin, että verkkorajoja ylitettäessä (esimerkiksi Azuren regioonien välillä tai AWS:stä Azureen) täytyy tiedonsiirrosta maksaa jonkin verran dataa lukiessa, vaikka sitä ei suoranaisesti kopioitaisikaan Fabriciin.
Ylläpitoa helpottamaan Fabric sisältää ns. lineage ja impact analysis -työkalut. Niillä pystyy tarkastelemaan datan lähteitä ja datan kulkua Fabricissa ja tekemään päätelmiä siitä, mihin prosessin myöhempiin osiin muutos jossain aiemmassa vaiheessa voi vaikuttaa ja millä tavalla. Ylläpitoa ajatellen myös Data Factoryn monitoroinnin pitäisi Microsoftin mukaan Fabricissa olla parempi kuin aiemmissa toteutuksissa. Tämä jääköön nähtäväksi.
Myös järjestelmän kustannusten seuranta tulee luultavasti olemaan aiempaa helpompaa, koska nyt tarvitsee seurata ainoastaan Microsoft Fabricin kuluttamaa kapasiteettia, eikä eri tuotteiden resurssien käyttöä. Kapasiteetista ja lisensseistä kerrottiin tarkemmin aiemmassa kappaleessa.
IoT-datan käsittely
Toinen yleinen data-aiheinen käyttötapaus on IoT-datan käsittely, johon usein liitetään myös vaatimus lähes reaaliaikaisesta raportoinnista. Jos ajatellaan tällaisen datan varastointia ja tuomista esimerkiksi Power BI -raportille, ovat käytettävät palikat oikeastaan samat kuin edellisessä käyttötapauksessa liittyen johdon raportointiin: data menee jotain kautta Fabricin data lakeen ja se on sieltä suoraan käytettävissä Power BI -raportilla tai räätälöidyssä sovelluksessa. Näihin pätevät siis samat positiiviset havainnot mistä kirjoitin edellisessä kappaleessa. Samoin isot positiiviset odotukset liittyen Git-integraatioon ja CI/CD-työkaluihin pätevät yhtä lailla tähänkin ja itse asiassa kaikkiin Fabricin käyttötapauksiin.
IoT-datan käsittelyssä muutoksia voi lisäksi nähdä siinä, kuinka IoT-data Fabricin data lakeen saadaan. Aiemmin yleinen tapa on ollut käyttää IoT-datan vastaanottoon Azure Event Hubia, josta data on mennyt eteenpäin joko Azure Stream Analyticsiin tai kenties Azure Databricksiin käyttäen Sparkin structured streaming -ominaisuuksia. Sekä Stream Analytics että Databricks voivat kuitenkin olla melko kalliita käyttää ja tämä on huomattu joissain projekteissa myös käytännössä.
Microsoft Fabric sisältää suoraan ns. eventstreamejä, jotka pystyvät ottamaan vastaan dataa joko AMQP-protokollalla tai Microsoftin Event Hubs -protokollalla. Tällöin Azureen ei tarvitse luoda datan vastaanottoa varten mitään. Jos taas käytössä on Azure IoT Hub, voidaan hyödyntää IoT Hubin tarjoamaa Event Hubs -yhteensopivaa rajapintaa ja luoda Fabriciin datalähde, joka osaa lukea viestejä siitä. Eventstreameihin voidaan myös lisätä samantyyppistä viestien käsittelyä, muokkausta ja aggregointia kuin Azure Stream Analyticsissa.
Lyhyesti sanoen, Microsoft Fabricin eventstreamit voivat tuoda kustannussäästöjä ja yksinkertaistaa tällaisten sovellusten rakentamista ja ylläpitoa, mutta asia vaatii vielä tarkempaa tutkimista ja kokeilua.
Yhteenveto
Kuten totesin tämän kirjoituksen alussa, ensimmäinen ajatus Fabricista oli se, että eikös tällainen ole jo olemassa Azure Synapse Analyticsin muodossa. Kun Fabriciin kuitenkin tutustuu tarkemmin, löytyy sieltä paljon todella hyviä ominaisuuksia, joista on varmasti jatkossa hyötyä. Itse olen käyttänyt Fabricista toistaiseksi vasta Data Engineering -osaa ja kirjoittanut liudan notebookkeja datan käsittelyyn, mutta jo siinä huomasi erityisesti sen, kuinka saumatonta Fabricin sisäisen data laken kanssa pelaaminen on.
Toki Microsoft Fabric on vielä preview-vaiheessa, joten tuotantokelpoisia juttuja sillä ei ehkä kannata lähteä tekemään. Sitä paitsi monet osa-alueet ovat vielä erittäin puutteellisia, ehkä erityisesti Data Factory -puoli (tästäkin lisää kirjoitussarjan seuraavassa osassa). Näin ollen kaikkea ei edes pysty vielä Fabricilla tekemään. Fabricin sisäinen data lake sen sijaan vaikuttaa olevan jo hyvässä kunnossa ja samoin Data Engineering -puoli, joten siitä suunnasta Fabricia on ehkä parasta lähteä koestamaan. Kannattaa myös muistaa, että Fabricin sisäinen data lake käyttää jo ADLS Gen 2:sta tuttuja rajapintoja datan käsittelyyn, joten sitä pystyy hyvin hyödyntämään myös esimerkiksi Azure Databricksistä käsin, jos organisaatiossa on se käytössä.
Seuraavassa Fabricia käsittelevässä blogikirjoituksessa käydään Fabricin eri osa-alueita läpi hieman teknisemmästä näkökulmasta. Siinä tarkastellaan osa-aluekohtaisesti, millä tavalla Fabric eroaa aiemmista tuotteista ja erityisesti Azure Synapse Analyticsistä.
Hyödyllisiä linkkejä:
Adafy on näkemyksellinen ohjelmistokumppani, jonka Microsoft-teknologiaosaaminen on tunnustetusti Suomen huipputasoa.
