Marko Oja
Data-arkkitehti, joka auttaa asiakasta ymmärtämään tekniikan mahdollisuudet ja muuntaa innovatiiviset ideat teknisiksi ratkaisuiksi. Ketterät kehitysmenetelmät ja kehitystyötä tukevat prosessit ovat lähellä Markon sydäntä.
Microsoft Fabric on yksi kuumimmista teknologioista dataskenessa ja ollut sellainen heti julkistamisestaan lähtien. Datan ammattilaiset eri puolilla maailmaa ovat tunnistaneet sen merkittävän potentiaalin. Fabricin deployment-ominaisuudet kehittyvät jatkuvasti ja ne lähestyvät isojen organisaatioiden ratkaisua. Tämän kypsyysasteen myötä monet yritykset pohtivatkin, onko nyt oikea hetki lähteä käyttämään Fabricia varsinaisessa tuotantokäytössä. Jos kuulut näiden onnekkaiden arviointia tekevien joukkoon, saatat olla kiinnostunut tutustumaan toimitusmalleihin ja niihin liittyviin näkökohtiin MS Fabricin osalta. Tämä artikkeli ei missään nimessä ole kokonaisvaltainen lista, vaan tarjoaa nostoja ja esimerkkejä siitä, mitä voit odottaa suunnitellessasi Fabricin arkkitehtuuria ja toteutusmalleja.
Yritystason vähimmäisvaatimukset
Aloitetaan keskittymällä siihen, mitä halutaan saavuttaa. Jos tavoitteena on kevyt konseptin todentaminen tai yksinkertainen itsepalveluanalytiikan ratkaisu, jäljempänä esitellyt ominaisuudet ei välttämättä ole käyttötapaukseen soveltuvia tai tarpeellisia. Mutta, jos ollaan rakentamassa ison organisaation data-alustaa, tulee siinä olla eri ympäristöjä. Tyypillisessä yritysratkaisussa käytetään erillisiä kehitys-, testaus- ja tuotantoympäristöjä, joissa kussakin on omat erityispiirteensä ja vaatimuksensa. Taas konseptin todistamiseksi kaksi erillistä ympäristöä, kuten kehitys ja testaus, ovat riittäviä, ja niissä voidaan datan ja toteutuksen rakenteiden erottaminen todeta.
Fabricissa ympäristöt voi tarkoittaa sitä, että käytämme toimialueita (domains) toteutus kokonaisuuksien erotteluun, mutta vähintään sen pitäisi tarkoittaa ympäristöille omia datasäilöjä (storage account) ja dataputkia. Lisäksi, jos sisällytämme Power BI:n osaksi kokonaisuutta, myös semanttiset mallit ja raportit tulisi olla ympäristökohtaisia. Monien ympäristöjen käytön keskeisin syy on se, ettemme halua vaarantaa tuotannon latauksia tai raportointia ottamalla käyttöön jotakin, joka ei ole toimintavalmista. Juuri tästä syystä kehitämme alustaa kehitysympäristössä, suoritamme integraatio- ja järjestelmätestaukset testiympäristössä ja käytämme sekä ylläpidämme lopullista järjestelmää tuotantoympäristössä.
Kaksi toimitusmallivaihtoehtoa
Fabric tarjoaa kaksi pääasiallista tapaa sovellusten toimittamiseen, jotka mahdollistavat useamman ympäristön. Jos olet perehtynyt Power BI:n toimitusputkiin (deployment pipelines), tunnet jo ensimmäisen näistä tavoista. Toinen toimitusmalli on GIT-integraatio, joka mahdollistaa toteutustesi siirtämisen versionhallintaan sekä muutosten vetämisen versionhallinnasta suoraan työtiloihin (Workspace). Fabric API:t täydentävät näitä kahta menetelmää ja niitä voidaan käyttää tukemaan toimituksiin liittyviä tehtäviä.
Toimitusputkien (deployment pipelines) avulla luot prosessin, joka määrittelee vaiheet, joilla siirrytään yhdestä ympäristöstä toiseen. Oletetaan, että aloitat 'kehitys'-ympäristöstä, siirryt sieltä 'testaus'-ympäristöön ja lopulta 'tuotantoon'. Näiden putkien avulla voit määritellä parametrit toimitettaville objekteille, kuten asettaa parametreja semanttisille malleille ja konfiguroida työkirjojen (notebook) yhteyksiä lakehouse-tietovarastoihin, toimitettaessa muutoksia työtilasta (workspace) toiseen. Käyttämällä näitä putkia voi jo nykyisessä tilassaan rakentaa tehokkaan ja toimivan prosessin Power BI -malleille ja raporteille.
Toinen vaihtoehto käyttöönotolle on GIT-integraatio, mutta tämä menetelmä vaatii hieman luovuutta. Voimme edelleen soveltaa samaa perusperiaatetta, jossa siirrämme toteutusta kehitysympäristöstä testiympäristöön ja siitä edelleen tuotantoon. Erona on, että emme käytä Fabricin toimitusputkia, vaan siirrämme uusimman version GIT-repositorioon Azure DevOpsissa. Käyttämällä vetopyyntöä (pull request) voimme siirtää muutokset kehityshaarasta testi- ja tuotantohaaroihin. Jotta tämä prosessi vaikuttaisi Fabricin puolella, meidän täytyy myös linkittää työtilamme vastaaviin niitä vastaaviin kehityshaaroihin. Kun kehityshaaraa päivitetään Azure DevOpsissa, saadaan työtilassa visuaalisen ilmoitus tulevista muutoksista, minkä jälkeen voidaan yksinkertaisesti päivittää uusin version työtilaan.
Keskeisiä ominaisuuksia tulossa pian
Monet käyttöönottoon liittyvät ominaisuudet ovat jo preview-vaiheessa. Näitä uusia ominaisuuksia ovat, tuki (esimerkiksi) dataputkille ja työkirjoille, GIT-integraatio ja Fabric API.
Uusi Fabric API on avainasemassa mahdollistamassa GIT-pohjaisen toimitusmallin. Tarvitaan keino käynnistää päivitysprosessi versionhallinnasta Fabriciin. Tämän voisi tehdä manuaalisesti, mutta se ei ole kovin käytännöllinen ratkaisu, jos ympäristössä on useita työtiloja, jotka halutaan päivittää yhtenäisenä järjestelmäpäivityksenä.
Fabric API:n avulla voidaan suorittaa päivitykset helposti valitsemallasi koodi- tai skriptikielellä. Tämä prosessi sisältää autentikoinnin OAUTH-tunnistautumisella ja päivityspyynnön tekemisen määritellylle GIT-repositoriolle. Parasta tässä on, että tämän prosessin integroiminen osaksi normaalia DevOps-käyttöönotto-putkea tulee olemaan suhteellisen yksinkertaista, kunhan SPN tuki API:iin tulee tuetuksi.
Toinen huomionarvoinen uusi ominaisuus on SQL-tietokantaprojektien tuki Fabricin varastoille (warehouse). (SQL-projektien tuki varastoille Microsoft Fabricissa.) Tällä hetkellä GIT-integraatiolle tai käyttöönotto-putkille ei ole virallista tukea, mutta ne ovat tulossa. Aiemmin myös kaikki varaston (warehouse) sisäiset rakenteet olivat toimitustapojen ulkopuolella, joten SQL-projektien tuki merkitsee merkittävää edistysaskelta.
Hukassa oleva ongelmalapsi, jolle löytyy toimiva purkka
Viimeisenä, muttei vähäisimpänä, on lakehouse. On ehkä hieman liioiteltua sanoa, että se kuuluu tuettujen käyttöönotettavien objektien joukkoon, sillä GIT-integraatiota taulujen rakenteille ei ole saatavilla. On tosin melko yleistä, että deltataulujen skeeman hallintaa ei tarjota valmiina. Tässä suhteessa Fabricin lakehouse on yhteensopiva muiden ratkaisujen kanssa.
Onneksi on olemassa muutamia keinoja, jotka voivat helpottaa lakehousen käyttöönottoa. Yksi näistä keinoista on suunnitella ja rakentaa prosessiputket niin, että ne luovat tarvittavat taulukot automaattisesti, mikäli niitä ei ole alun perin olemassa. Tämä on yllättävän helppoa, sillä dataputket hoitavat tämän automaattisesti, ja muistikirjoissa voit käyttää seuraavan tyyppistä koodia:
Datan kirjoittaminen suoraan absoluuttiseen polkuun mahdollistaa lisäksi sellaisten työkirjojen luomisen, jotka ovat helposti käyttöönotettavissa ilman erillisiä lakehouse yhteysmäärityksiä toimituksen aikana. Esimerkin työkirja ei edellytä lakehouseyhteyden asettamista. Sen sijaan työkirja hyödyntää työkirjan suorituksen aikaisen työtilan (workspace) oletusarvoja, kuten työtilanne ja lakehousen id:eitä. Näitä tietoja voidaan hakea käyttämällä mssparkutils-paketin funktioita. Jos olet kiinnostunut käyttämään työkirjoja Fabric-ratkaisussasi tai suunnittelet niiden käyttöä, suosittelen tutustumaan tähän pakettiin.
Keskeiset ajatukset
Voimme odottaa useita uusia ominaisuuksia tulevan käyttöön seuraavien kahden neljänneksen aikana. Ennustan, että vuoden 2024 loppuun mennessä deployment-kyvykkyydet saavuttavat aitoa tuotantovalmiutta. Erityisen rohkaisevaa on nähdä, kuinka Microsoft panostaa kehittämään Fabricin käyttöönottomallia; on selvää, että he ymmärtävät näiden kriittisten ominaisuuksien tärkeyden isoille organisaatioille.
Viimeisimpien lisäysten, kuten API-rajapintojen, ansiosta Fabric on ylittänyt merkittävän rajapyykin. Nyt onkin sopiva hetki alkaa harkita Fabricin käyttöä tuotantokriittisissä hankkeissa. Toistaiseksi saatat tarvita suunnitelmallisuutta kuormitusmalliesi kanssa, jotta käyttöönotto sujuisi helpommin. Lisäksi sinun tulee tehdä joitakin toimenpiteitä Azure DevOpsin puolella varmistaaksesi, että kaikki toimii moitteettomasti.
Tällä hetkellä tasapainottelemme yhä täydellisen automaation ja osittain manuaalisen käyttöönoton välillä. Kuitenkin asetelma on kääntymässä, ja tulevaisuuden julkaisuissa odotan näkeväni useita uudistuksia. Toivon, että päivitykset sisältävät muun muassa rajapinnan yhteyksien hallintaan, virallisia DevOps-moduuleja ja laajempaa tukea GIT-integraatiolle.
Odotan innolla, että nykyiset esikatseluominaisuudet tulevat laajasti saataville ja että pääsen näkemään tulevat parannukset lähitulevaisuudessa.