Microsoft Fabricin datatarinassa Power BI -raportti on yleisesti viimeinen luku. Power BI -raportti on lopullinen piste, johon tiedon kerääminen, siistiminen, yhdisteleminen ja käsittely tähtää. Raportin tekemisen jälkeen voidaan todeta, että data on muiden osapuolien saavutettavissa ja helposti käytettävänä.
Fabricin dataa on kuitenkin mahdollista hyödyntää myös Fabricin ulkopuolella, eikä rajoittua sen osalta pelkästään Power BI -raportin tuottamiseen. Datan keräämiseen ja jalostamiseen on käytetty paljon aikaa ja vaivaa, joten datan hyödyntäminen myös muissa ratkaisuissa on järkevää.
Fabricin dataan kytkeytyminen
Fabricissa olevaan dataan on mahdollista päästä käsiksi usealla eri menetelmällä, mutta kaksi yleisintä ja helpoiten käytettävää menetelmää ovat SQL Analytics Endpoint ja GraphQL-rajapinta. Molemmat menetelmät tukevat Microsoft Entran Service Principal:iin perustuvaa tunnistautumista tai Interactive-tilassa tapahtuvaa Entra-tunnistautumista käyttäjien omilla tunnuksilla. Jos termi Service Principal ei ole tuttu, niin yksinkertaistettuna voi ajatella, että se on sovellukselle luotava identiteetti. Identiteetin avulla sovellus voi tunnistautua Fabriciin ja hakea siellä olevaa dataa käyttöoikeuksiensa rajoissa.
SQL Analytics Endpoint
SQL Analytics Endpoint mahdollistaa Fabricin datan lukemisen Fabricin ulkopuolisella sovelluksella samalla tavalla kuin kytkeydyttäisiin SQL-tietokantaan. Tietokantaa vasten on mahdollista tehdä SQL Server -yhteensopivia kyselyjä, joiden suorituskyky on varsin hyvällä tasolla. Mikäli suorituskykyyn liittyvät asiat kiinnostavat enemmän, niin olen kirjoittanut suorityskyvystä erillisen blogikirjoituksen henkilökohtaiseen blogiini. Tämän kirjoituksen löydät tästä linkistä.
Fabricin luonteeseen kuuluu, että sinne ei pusketa dataa, vaan Fabric on aina dataa noutava osapuoli. Näin ollen SQL Analytics Endpoint ei tue datan lisäykseen ja muokkaukseen liittyviä kyselyjä, kuten esimerkiksi INSERT ja UPDATE -käskyjä Lakehouse-tietovarastoa vasten. Warehouse-tietovarastoa vasten myös datan muokkauskäskyt toimivat.
GraphQL
GraphQL on avoimeen ”standardiin” perustuva kyselykieli, joka toimii hieman samalla tavalla kuin REST-rajapinnat. Toisin kuin REST API:t, GraphQL on standartoidumpi menetelmä datan hakemiseen ja muokkaamiseen. Datan hakeminen tapahtuu käyttämällä JSON-tyylisiä kyselyjä, joita lähetetään HTTP-kutsuina Fabriciin. GraphQL tukee samoja tunnistautumismenetelmiä kuin SQL Analytics Endpoint.
GraphQL-rajapinnan kautta on myös mahdollista muokata dataa käyttäen ns. mutation-kyselyjä. Fabricin GraphQL-resurssi luo automaattisesti dataan perustuvia kysely- ja muokkausrakenteita, joita voi kohtuullisen nopeasti hyödyntää sovellusratkaisuissa. GraphQL-rajapinnan käyttämiseen liittyy hieman rajoitteita, jotka on kattavasti listattu Microsoftin dokumentaatiossa. Rajoituksiin on syytä tutustua ennen kuin aloittaa tekemään ensimmäistä toteutusta rajapintaa vasten.
Arkkitehtuuri ja ratkaisukuvaus
Pohditaan seuraavaksi hieman sitä, millainen Fabric-dataa hyödyntävä ratkaisu voisi olla. Perusajatuksena sillä ei ole väliä, hyödynnämmekö SQL Analytics Endpointia tai GraphQL-rajapintaa. Molemmissa on taustalla sama tietoturva (Entra Service Principal) ja samanlainen käyttöoikeushallinta. GraphQL tuo tähän tosin hieman lisävalintaa ja sallii ns. ”Tallennetun käyttäjätilin” käyttämisen, jolloin käyttäjälle voi luvittaa vain API:n. Alla olevaan tietovarastoon ei API-käyttäjää tarvitse tällöin luvitta.
Valintaa menetelmien välillä kannattaa perustella sillä, minkälaista sovellutusta ollaan tekemässä ja minkälaisia kyvykkyyksiä toteuttavasta tiimistä löytyy. Jos tiimissä on paljon SQL-osaamista ja sovelluksesta löytyy hyvä SQL-abstraktio, niin SQL Analytics Endpointin hyödyntäminen Warehouse-tietovarastoa vasten voi olla hyvä valinta. Jos taas osaaminen painottuu API-kutsujen tekemiseen ja tietoon halutaan päästä ilman SQL-kyselyjen kirjoittamista, niin silloin GraphQL voi olla sopivampi valinta.
Mikäli ratkaisussa päädytään GraphQL:n käyttöön, kannattaa pohtia, pitäisikö rajapinnan eteen laittaa jonkinlainen API-hallintatyökalu. Fabric tarjoaa melko heikosti työkaluja API:n hallintaan ja monitorointiin. GraphQL-rajapinnan eteen on mahdollista laittaa Azuren API Management -tuote, joka tukee suoraan GraphQL-tyyppisiä rajapintoja. API Managementin avulla saamme paljon rajapintojen käyttöön, tietoturvaan ja monitorointiin liittyviä työkaluja käyttöön. Tarvittaessa voimme jopa vaihtaa tunnistautumismenetelmän API-avaimeen pohjautuvaksi.
API Management pystyy tarvittaessa suorittamaan Policy-säännön avulla tunnistautumisen käyttäen Service Principal -tunnusta ja näin ollen tarjoamaan esimerkiksi API-avain -pohjaisen tunnistautumisen sovellukselle. Toki, tällöin menetetään käyttäjätason tunnistautuminen, mutta vastaavasti mahdollistetaan esimerkiksi AWS:ssä olevan työkuorman kytkeytyminen GraphQL-rajapintaan.
User Data Functions
Huhtikuun toisena päivänä Fabriciin julkaistiin User Data Function -nimellä kulkeva ominaisuus. Ominaisuuden avulla on mahdollista rakentaa Azure Function -tyylisiä toimintoja, jotka pystyvät kytkeytymään OneLakesta löytyviin tietovarastoihin. Funktiot saavat automaattisesti HTTP-osoitteen, jota on mahdollista kutsua myös Fabricin ulkopuolelta hyödyntäen tuttuja Service Principal- ja Interactive authentication tunnistautumismenetelmiä. Funktioiden avulla on kätevä toteuttaa tietojen validointia, kevyitä ETL-toimintoja ja dataputkissa toistuvia toimintoja helposti jaettavaksi, mutta myös ulkoapäin kutsuttaviksi API-rajapinnoiksi. User Data Functions -ominaisuudella toteutetut funktiot on mahdollista kytkeä osaksi Azuren API Management -tuotetta, ja saada näin lisäkerroksia rajapintojen hallintaan. Ominaisuus on kirjoitushetkellä vielä Preview-tilassa, mutta sinänsä mikään ei estä sen käyttämistä myös tuotantotyökuormissa preview-rajoitukset huomioiden.
Yhteenveto
Fabric on kehittynyt huimasti viimeisen kahden vuoden aikana. Alunperin perinteisestä tietovarastosta yhdistettynä ETL-ominaisuuksiin on päästy jo sovellusalustatasolle. Fabric mahdollistaa dataan liittyvien työkuormien kirjoittamisen usealla eri ohjelmointikielellä ja usealla eri menetelmällä. Dataa on mahdollista julkaista ulospäin Fabricista muille sovelluksille ja sen hyödyntäminen organisaatiossa muussakin kuin raportointikäytössä on varsin helppoa. Suurimmat rajoitukset liittyvät tällä hetkellä rajapintojen heräilyyn käytön jälkeen (cold start) ja ehkä turhan kevyeen hallittavuuteen, jota on toki helppo paikata API-hallintatyökaluilla.
