Puhuttaessa modernista tietovarastoinnista ja sen arkkitehtuureista ei voi olla törmäämättä erilaisten tietojärvien ja tietovarastojen käsitteisiin. Tässä blogikirjoituksessa käsitellään tietoalustojen evoluutiota perinteisestä tietoalustasta ja tietovarastoinnista kohti Lakehouse-tietoarkkitehtuuria, erityisesti tarkastellen Lakehousea ja sen mahdollistavaa Delta Lakea -teknologiaa.   

Kuvataan Lakehouse- ja Mitaliarkkitehtuuri Microsoftin Fabric SaaS-palvelun ratkaisuna. Microsoft Fabric on kattava analytiikan ja tietovarastoinnin ratkaisu, joka sisältää tärkeimmät modernit työkalut tietojenkäsittelyyn, tallentamiseen ja analysointiin reaaliajassa.

Miksi Lakehouse ja Delta Lake

Perinteiset tietoalustat ja tietovarastot ovat keskeisessä roolissa organisaatioiden datanhallinnassa. Kuitenkin teknologisen kehityksen myötä tarve entistä joustavammille ja monipuolisemmille ratkaisuille on kasvanut. Tässä evoluutiossa Lakehouse edustaa innovatiivista askelta, joka yhdistää perinteisen tietovaraston (Data Warehouse) luotettavuuden ja rakenteisen datan käsittelyn tietojärven (Data Lake) joustavuuteen ja monimuotoisuuteen erilaisten tietojen hallinnassa ja käsittelyssä.

Delta Lake puolestaan on avainasemassa tämän kehityksen toteuttamisessa, tarjoten avoimen lähdekoodin tallennuskerroksen, joka tuo ACID-transaktiot (Atomicity, Consistency, Isolation, and Durability), metadatan hallinnan ja luotettavuuden tietojärven ympäristöön. Delta Lake -teknologia antaa tiedon varastoinnille joustavuutta  ja tehokkuutta. Lakehouse-tietoarkkitehtuurin, erityisesti Delta Laken, merkitys korostuu jatkossakin datavetoisten yritysten keskuudessa.

Tietovarastot ja tietojärvet ovat vakiintuneita tietoalustoja, joita käytetään yhdessä tai erikseen riippuen datan volyymista ja käyttötarkoituksista. Molemmilla on vahvuutensa ja haasteensa, ja seuraavassa käsitellään näitä näkökohtia sekä pohditaan, miksi Lakehouse-tietoarkkitehtuuri on luonnollinen kehitysaskel tietovarastoratkaisuna.

Perinteisen ja modernin tietoalustan haasteita jotka Lakehouse pyrkii ratkomaan

Perinteiset tietovarastot mahdollistavat historiallisten datajoukkojen järjestämisen analytiikan ja Business Intelligencen (BI) tarpeisiin. Datamäärien kasvaessa perinteiset tietovarastot voivat muuttua kustannustehottomiksi laskentaresurssien ja tallennustilan yhdistetyn käytön vuoksi. Lisäksi ne eivät sovellu optimaalisesti reaaliaikaisen suoratoistodatan käsittelyyn, ja eräajoprosessit voivat olla haasteellisia sopeutumaan nopeasti muuttuviin datavirtoihin. Rakenteellisen datan (Structured) hallinta on perinteisen tietovaraston vahvuus, mutta ne kohtaavat vaikeuksia puolirakenteellisen (Semi-structured) ja rakenteettoman (Unstructured) datan käsittelyssä.

Perinteisen tietovaraston haasteiden monimutkaisuuden ratkaisemiseksi rinnalle on otettu käyttöön tietojärviä. Tietojärvet tarjoavat alhaisen tallennuskustannuksen ja kyvyn käsitellä dataa eri formaateissa. Niiden monipuolisuus tekee niistä sovellettavia eri käyttötarkoituksiin, kuten edistyneeseen analytiikkaan ja koneoppimiseen.

Yksinkertaistettuna modernissa pilvipohjaisessa tietoalustaratkaisussa rakenteellinen data luetaan tietovarastoon ja sen rinnalla toimii tietojärvi puolirakenteellisen ja rakenteettoman datan säilömiseen. Tietojärveä voidaan käyttää myös datan syöttökerroksena tietovarastolle.

Tietojärvillä on kuitenkin myös rajoituksensa. Tiedostomuodossa tallentaminen ilman määriteltyä rakennetta tekee kriittisen tietojenhallinnan vaikeaksi, mikä vaikeuttaa ETL-transaktioiden suorittamista ja johtaa haasteisiin datan eheyden ja yhdenmukaisuuden hallinnassa. Delta Lake ja Lakehouse-tietoarkkitehtuuri pyrkivät ratkomaan yllä mainittuja haasteita.

Alla oleva kuva kuvaa evoluutiota perinteisestä tietoalustasta moderniin pilvipohjaiseen tietoalustaan ja siitä aina Lakehouse-tietoarkkitehtuuriin. Katsotaan seuraavassa kappaleessa tarkemmin Delta Lakea ja Lakehouse-tietoarkkitehtuuria.

Delta Lake Lakehouse-tietoarkkitehtuurin mahdollistaja

Delta Lake mahdollistaa Lakehouse-tietoarkkitehtuurin käyttöönoton tarjoamalla vahvan perustan tiedon tallennuskerroksena. Lakehouse-tietoarkkitehtuuri taas pyrkii jatkuvaan ja yksinkertaistettuun tapaan järjestää tietoa hyödyntäen Delta Laken tuomia etuja.

Yhdellä tietoalustalla toimiminen poistaa siiloja ja yksinkertaistaa prosesseja. Data tallennetaan Delta Lakeen delta-formaatissa parquet-tiedostoiksi. Tämä pienentää datan varastoinnin kustannuksia ja parantaa kyselysuorituskykyä. Tehokkaan datan varastoinnin ja nopean kyselysuorituskykynsä ansiosta Delta Lake tukee erinomaisesti suoratoisto ja eräajoprosessointia, mikä tekee siitä monipuolisen ratkaisun erilaisten tietokäsittelytarpeiden täyttämiseksi.

Lisäksi Delta Lake käyttää JSON-metadatatiedostoja, jotka sisältävät tiedot tauluista, tiedostojen sijainneista ja määritellyistä rakenteista. JSON-metadatat mahdollistavat tietojen hallinnan ja käsittelyn, mikä on keskeistä tietoalustan tehokkaassa toiminnassa. Metadata mahdollistaa aikamatkustamisen (time travel). Aikamatkustuksen avulla voi palauttaa tietyn hetken tilanteen aiempiin versioihin, eli tiettyyn ajanhetkeen, ja tämä kyky perustuu tarkkaan metadatatiedostojen hallintaan. Aikamatkustamisessa on rajoituksensa: se rajoittuu niihin versioihin, jotka on tallennettu Delta Lakeen, ja määrityksiin historiatietojen säilytysajoista.

Lakehouse-tietoarkkitehtuuri Microsoft Fabric

Mitaliarkkitehtuuri – Kuinka Organisoida Data Lakehousessa?

Käydään läpi Lakehouse-tietoarkkitehtuuria tarkemmin Microsoftin Fabric SaaS-palvelun ratkaisuna. Esimerkin avulla saamme käytännönläheisemmän kuvan.  Alla olevaan kuvaan olen piirtänyt yksinkertaistetun Lakehouse-ratkaisun, jossa tietoalustaan luetaan useasta eri tietolähteestä tai lähdejärjestelmästä tietoa, joko reaaliajassa tai eräajoin eli tiettyinä ennakkoon määriteltyinä hetkinä.

Data luetaan tietoalustaan integraatiotyökalulla, tässä tapauksessa Azure Data Factory, joko suoraan tai hyödyntäen väliaikaista laskeutumisalustaa (valinnainen, ei kuvattu ratkaisussa), ja tallennetaan Lakehouseen. Fabric mahdollistaa myös olemassa olevien tietojärvien nopean hyödyntämisen shortcut-toiminnolla. Fabricissa tiedot tallennetaan parquet-tiedostomuodossa One Lake -tietoalustaan riippumatta siitä, onko kyseessä Lakehouse vai Warehouse -tietovarasto. One Lake perustuu Delta Lake -teknologiaan. Olipa kyseessä T-SQL-datavarastointi, Spark tai KQL-suoratoisto, jokainen Fabricin työkuorma toimii delta-taulukoiden kanssa.

Lakehouse-tietoarkkitehtuuri rakennetaan usein Databricksin kehittämää mitaliarkkitehtuuria hyödyntäen. Mitaliarkkitehtuurissa ja kuvan esimerkissä on kolme kerrosta tiedon säilyttämiseen, muokkaamiseen, prosessointiin ja jakamiseen. Esimerkkiarkkitehtuurissa hyödynnetään muistikirjoja (Notebook) tiedon muokkaamiseen, rikastamiseen ja siirtämiseen kerrokselta toiselle. Muistikirjat voidaan ajastaa ja orkestroida Azure Data Factoryn putkilla (Pipeline). Muistikirjojen ajastamiseen ja ajamiseen voidaan hyödyntää myös muita tekniikoita.

Mitaliarkkitehtuurin tavoite on organisoida dataa loogisesti Lakehousen sisällä eri kerrosten välillä. Kerrokset on nimetty mitalien mukaan pronssi, hopea ja kulta. Mitalin kirkkaampi väri viittaa datan laatuun eli tavoitteena on prosessoida, yhdistää ja parantaa datanlaatua kerroksittain aina loppukäyttäjälle asti. On hyvä tunnistaa, että mitaliarkkitehtuurin kolmekerroksinen tietovarastointimetodi on hyvin samankaltainen perinteisempien source, staging ja curated ratkaisujen kanssa.

Mitaliarkkitehtuurin etuja ovat:  

• Yksinkertainen ja looginen rakenne.
• Mahdollistaa inkrementaalisen kehittämisen.
• Tukee erilaisia työmääriä ja soveltuu erilaisiin käyttötarkoituksiin.
• Hopeakerros voidaan toteuttaa erilaisilla tietomalleilla tarpeen mukaan, kuten esimerkiksi Data Vault tai malleilla, jotka ovat lähellä kolmannen normaalimuodon rakennetta.
• Arkkitehtuuri tukee joustavuutta analytiikassa ja datankäsittelyssä. Data tieteilijät ja analyytikot voivat työskennellä viimeisimpien saatavilla olevien tietojen kanssa ja edistää nopeampaa päätöksentekoa ja analytiikkaa.
• Mitaliarkkitehtuurin modulaarinen luonne edistää yhteensopivuutta eri komponenttien ja järjestelmien välillä. Tämä on erityisen arvokasta heterogeenisissä dataympäristöissä, joissa käytetään erilaisia työkaluja ja alustoja.
• Taulukkojen uudelleen rakentaminen raakatiedoista milloin tahansa.
• ACID-tapahtumat ja Time Travel -toiminnallisuudet

Mitaliarkkitehtuurin kerrosten tehtävät:

• Pronssikerros (Bronze)
  • Yleisesti pronssikerrokseen tiedot tallennetaan raakamuodossa eli kopiona lähdejärjestelmästä ilman muuntoja:
    • Pronssikerroksessa dataa ei muunneta alkuperäisestä muodostaan, jotta alkuperäinen tieto säilyy ja on saatavilla sellaisenaan tulevia tarpeita varten.
  • Data on pronssikerroksessa vain lukumuodossa:
    • Dataa voidaan lukea ja käyttää, mutta siihen ei tehdä muutoksia.
  • Tietoja voidaan säilöä eri tietomuodoissa, esimerkiksi erilaisina tiedostoina (Parquet, JSON tai CSV) tai delta-tauluina:
    • Pronssikerroksessa tarjotaan joustavuutta tallennettavan datan muodossa. Se voi sisältää eri tietomuotoja, mikä mahdollistaa erilaisten tietojen tehokkaan käsittelyn.
  • Pronssikerroksen data voidaan syöttää kokonaisuudessaan aina uudelleen lähdejärjestelmästä (Full load) tai lisätä ainoastaan muuttuneet tiedot olemassa olevan datan jatkoksi inkrementaalisesti (Delta load).
  • Sallii lähteeksi transaktiopohjaisen tai reaaliaikaisen prosessoinnin:
    • Pronssikerros tarjoaa joustavuutta datan keräämisessä, ja se voi käsitellä tietoa sekä transaktiopohjaisesti että reaaliaikaisesti lähteen luonteesta riippuen.

• Hopeakerros (Silver)
  • Pääasiallinen tiedonsäilytyskerros:
    • Hopeakerros toimii pääsäilytysalueena, jossa dataa pidetään ensisijaisesti lähdejärjestelmästä tuotuna. Tämä varmistaa, että alkuperäinen data säilyy turvallisesti ja eheänä.
  • Järjestetään, siivotaan ja yhdistetään pronssikerroksen data yhtenäiseen tietomalliin:
    • Hopeakerroksessa toteutetaan toimet, kuten tietojen järjestely, puhdistaminen ja yhdistäminen yhtenäiseen rakenteeseen. Näin varmistetaan, että data on valmiina siirrettäväksi seuraavaan kehitysvaiheeseen.
  • Luodaan historiointikäytännöt ja historioidaan dataa:
    • Hopeakerroksessa implementoidaan historiointikäytännöt, jotka mahdollistavat datan historian seuraamisen ajan myötä. Tämä tarjoaa kattavan näkymän datan kehityksestä ja muutoksista.
  • Yhtenäistetään tietomuoto:
    • Microsoft Fabric tallentaa datan yhtenäisessä muodossa parquet-tiedostoformaatissa One Lake -tietoalustaan. Tämä varmistaa, että dataa voidaan käsitellä yhdenmukaisesti ja tehokkaasti.

• Kultakerros (Gold)
  • Data on järjestetty valmiiksi ja käytettävissä raportoinnille ja loppukäyttäjille:
    • Kultakerros tarjoaa valmiiksi järjestetyn datan, joka on helposti käytettävissä raportoinnissa ja loppukäyttäjien tarpeisiin. Tämä edistää nopeaa ja tehokasta päätöksentekoa.
  • Data mallinnetaan yleensä tähtimalliin faktoiksi ja dimensioiksi:
    • Kultakerroksessa suoritetaan tietomallinnus, yleensä tähtimalliin, jotta data voidaan tehokkaasti kuvata faktoiksi ja dimensioiksi. Tämä parantaa tiedon käsiteltävyyttä ja ymmärrettävyyttä.
  • Voidaan organisoida projektikohtaisiin tai liiketoimintakohtaisiin kokonaisuuksiin:
    • Kultakerroksessa dataa voidaan organisoitua projektikohtaisesti tai liiketoimintakohtaisesti tarpeiden mukaan. Tämä mahdollistaa joustavan käytön eri liiketoiminta-alueilla.
  • Sovelletaan liiketoimintasääntöjä ja tehdään monimutkaisia transformaatioita sekä laskentaa:
    • Kultakerroksessa toteutetaan liiketoimintasääntöjä ja suoritetaan monimutkaisia transformaatioita ja laskentaa. Tämä varmistaa, että data vastaa tarkasti liiketoiminnan tarpeita.
  • Kokonaisuus edustaa datatuotetta:
    • Kultakerroksen lopputulos muodostaa laadukkaan datatuotteen, joka vastaa liiketoiminnan tarpeisiin. Datatuote tarjoaa vahvan perustan tehokkaalle päätöksenteolle ja liiketoiminnan kehittämiselle.

Mitaliarkkitehtuurin kultakerros on hyödynnettävissä raportoinnille. Data on jalostettu valmiiksi ja hyödynnettävissä liiketoiminta-alueittain kokonaisuuksina tai osina. Power BI mahdollistaa datan visualisoinnin ja mahdollisten uusien mittareiden luomisen kultakerroksen datasta.

Kultakerrosta voidaan hyödyntää myös Data Science ja AI pohjaisten ratkaisujen rakentamiseen. Data Science ja AI ratkaisut käyttävät usein mallien kouluttamiseen dataa mahdollisimman läheltä lähdettä joten Lakehouse-tietoarkkitehtuuri mahdollistaa datan hyödyntämisen Data Science ja AI ratkaisuihin myös pronssi- ja hopeakerroksesta, joskin pronssikerrosta hyödyntäessä datan laatu saattaa olla riittämätön.

Yhteenveto

Lakehouse-tietoarkkitehtuuri luo tehokkaan skaalautuvan tietoalustan, jossa tietoa järjestetään ja muokataan asteittain kerrosten välillä. Lakehouse soveltuu erinomaisesti edistyneelle analytiikalle ja vaativille hybridiratkaisuille, joissa tietoa luetaan eri lähteistä, joko reaaliajassa tai eräajoin.

On hyvä huomioida, että modernit ratkaisut, kuten Microsoft Fabricin Delta Lake-pohjaisen yhtenäisen tiedonvarastoinnin (One Lake) menetelmien avulla mahdollistetaan Lakehouse ja Warehouse ratkaisujen sujuva yhteensopivuus. Tämä taas antaa lähes rajattomat mahdollisuudet luoda hybridiratkaisuja, jotka vastaavat monimutkaisiin liiketoiminta- ja teknisiin vaatimuksiin.

Perinteisille ratkaisulle on yhä paikkansa erilaisissa käyttötapauksissa. Aina pilvimigraatioissa ja tietovarastoinnin uudistushankkeissa on tärkeää tehdä kattava analyysi eri vaihtoehdoista uudeksi tietoalustaksi ja datastrategiasta.

Liikkeelle Datastrategiasta Tietoalusta-ratkaisua valittaessa

Tietoalustan arkkitehtuuria valittaessa tulee aina tehdä tarkat strategiset linjaukset:

• Käyttötapausanalyysi
  • Mihin kerättävää dataa käytetään ja hyödynnetään.
  • Data ja liiketoimintastrategian yhtenäisyys.
• Missä muodossa ja mistä lähdedata on saatavissa
  • Rakenteellinen, puolirakenteellinen ja ei-rakenteellinen data.
  • Reaaliaikainen vai eräajo.
  • Sisäinen vai ulkoinen data.
  • Minkälaisia integraatioita tarvitaan.
• Millä syklillä dataa tietoalustaan tallennetaan.
• Arkkitehtuuri, työkalut ja komponentit
• Tiedonhallinta.
• Tietoturva ja käyttäjähallinta.

Me DB Pro Servicellä teemme kattavia datastrategiakonsultaatioita. Voit lukea tarkemmin datastrategiasta blogeissamme: Kuinka määritellä datastrategian suunta 

DB Pro Services tarjoaa kattavia ratkaisuja ja asiantuntijapalveluita tekoälyn käyttöönottoon liittyviin haasteisiin. Tarjontamme kattaa muun muassa datastrategian, modernien data-alustojen sekä edistyneen analytiikan kokonaisuudet. Ota yhteyttä, niin autamme sinua ja organisaatiotasi hyödyntämään tietoa tehokkaasti ja menestymään kilpailussa!

Robin Aro

Lead Data Engineer

robin.aro@dbproservices.fiDB Pro Services Oy

Microsoft teki ison muutoksen kumppaniohjelmaansa syksyllä 2022. Vanha Microsoft Partner Network -ohjelma Gold- ja Silver -tasoisine sertifiointeineen jäi historiaan ja tilalle tuli MCPP-ohjelma (Welcome to the Microsoft AI Cloud Partner Program).

MCPP tulee sanoista Microsoft Cloud Partner Program, jonka alla yritys voi suorittaa kaikkiaan kuusi eri painopistealuetta. DB Pro Services Oy suoritti Microsoftin MCPP Data ja AI Designation -painopistealueen elokuussa 2023.

”Vahvasti Microsoft-datateknologioihin keskittyvänä yrityksenä halusimme luonnollisesti olla mukana tässä muutoksessa. Olemme nyt saavuttaneet Solution Partner -statuksen Data- ja AI -painopistealueella. Tämä vaati merkittävää panostusta mm. asiantuntijoiden sertifiointeihin. Suurkiitos kaikille, jotka ovat omalla panostuksellaan mahdollistaneet tämän etapin. Ohjelman vaatimukset täytettiin täysillä pisteillä (100/100), joten asiakkaamme ja kumppanimme voivat olla varmoja, että meidän kauttamme on saatavissa sertifioituja huippuosaajia vaativiin tietoalusta- ja tekoälypohjaisiin projekteihin.”, yrityksen perustaja ja toimitusjohtaja Jani K. Savolainen täsmentää.

Haluatko tietää lisää vaativista tietoalusta- ja tekoälypohjaisista ratkaisuista? Ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy

“Suutarin lapsella on kengät” – Netvisor-integraatio

Olin tässä taannoin asiakkaan luona konsultoimassa Azure Data Platformin mahdollisuuksista ja hyvin menneen session päätteeksi joku asiakkaista kysäisi pilke silmäkulmassa “Mites teidän omat tiedonhallintaratkaisut? Onko meihin liittyvät projektidatat tallessa ja turvassa? Onkos suutarin lapsella kenkiä?”. Ja tähän pienen alkuhämmennyksen jälkeen vastasin “Toki! Mekin käytämme Azure Data Platformia ja sen palveluita”. Ja tämä on totta. Suutarin lapsella on sittenkin kengät! Ja miksipä en kertoisi tarkemmin miten me käytämme Azure-ratkaisuja ja mikä meidän suunnitelma on niiden osalta tulevaisuudessa. Tässä ensimmäisessä osassa käyn läpi yleisarkkitehtuurin ja avaan Netvisor-integraatiota, jonka kautta saamme ajantasaista tietoa kassavirta- ja talousraportointiin.

Azure Data Platform -arkkitehtuuri

Arkkitehtuurikuva (kuva 1.) kertoo pääpirteissään mistä on kysymys. Ratkaisumme koostuu useasta eri Azure-palvelusta, joita sitten hallinnoidaan Azure Data Factoryn kautta. Tiedon lataamiseen data lähteistä käytössä on Azure Logic Appsia ja Power BI Data Flowta. Tiedot tallennetaan Azure Data Lakeen (Blob storage ja Data Lake Gen2), jossa niitä käsitellään ja täydennetään Azure Databricksin scripteillä. Valmis data viedään storagesta Azure SQL:ään ja edelleen Azure Analysis Services -kuutioon. Kuution ja dynaamisen securityn käyttö tosin odottaa asiakasraportoinnin valmistumista ja toistaiseksi raportoimme Power BI:llä suoraan Azure SQL:stä.

Integraatio-ratkaisuista Azure Logic Apps on erinomainen työkalu kun dataa haetaan API-rajapinnoista. API-rajapintojen tyypilliset hakurajoitukset kuten sivutukset, on helppo toteuttaa Logic Appsin iteraatiotoiminnoilla. Lisäksi Logic Appsin toimintaa voidaan helposti laajentaa Azure Functionien kautta. Power BI Dataflows on taas täysin ilmainen (jos Power BI -lisenssit on kunnossa) ja valmiit datasetit pystytään tallentamaan Data Lake Gen2:seen. Tosin tässä on 10GB rajoitus per käyttäjä (Premium-lisenssillä 100GB), joka meille riittää hyvin.

Netvisor -integraatio

Olemme toteuttaneet integraatiot meillä käytössä oleviin Visma Severaan (toiminnanohjausjärjestelmä), Visma Netvisoriin (taloushallinto ja laskutus), Hubspot CRM sekä muutamiin muihin meille keskeisiin työkaluihin. Käyn tässä blogissa läpi Netvisor-integraation toteutuksen pääpiirteissään. Netvisor-integraation tavoitteena on hakea datat liittyen tulos- ja taseraportointiin sekä kassavirtalaskelmaan. Nykyiset Netvisorin tarjoamat omat raportit eivät riitä vaan tarve olisi pysytä porautumaan raportilla aina tositeriville asti. Ensimmäisessä vaiheessa pärjäämme GeneralLedger- ja AccountList- tiedoilla.

Azure Logic Apps ja Azure Function

Netvisorin API -rajapinnan käyttö vaatii ns. MAC-koodin laskemisen lähtöparametrien perusteella. Tästä syystä Azure Logic Appsilla toteutettuun ratkaisuun on lisätty Azure Function -kutsuja MAC-koodin laskemista varten. Azure Function-sovellus on c#-koodia ja sen rajapinta on http post -kutsu. Azure Functionin palauttamaa mac-koodia käytetään kussakin Netvisor-rajapintahaussa yhtenä parametrinä. Rajapinta palauttaa hakutulokset XML-formaatissa ja ne tallennetaan sellaisenaan Azure Blob Storageen.

Tutkin pitkään, miten XML:n saisi jo Logic Apps-sovelluksessa muutettua geneerisemmäksi JSON:ksi, mutta päädyin ratkaisuun, jossa muunnos tehdään Azure Databricksin kautta.  Logic Appsissa on mahdollista tehdä muunnos käyttäen funktiokutsua json(xml(<content>)), mutta huomasin että tässä on bugi, eikä listatyyppisen datan konversio tuottanut oikeaa json-formaattia. Toinen vaihtoehto on käyttää Transform XML tai Liquid -toiminnallisuuksia, mutta ne vaativat Azure Integration Accountin käyttöottoa ja sen kustannus on aivan liian kallis tässä kohtaa (lue useita satoja euroja per kk).

Azure Databricks – xml:stä jsoniin

Databricksiä käytetään Netvisor-integraatiossa pelkästään XML:n muuttamisessa JSON-formaattiin. XML luetaan ensin dataframeen josta se kirjoitetaan json-formaatissa takaisin blob storageen. Azure Databricks workspaceen pitää tuoda spark-xml -parseri joka löytyy Maven-repositorystä ja sen tarkempi dokumentaatio githubista löytyy täältä https://github.com/databricks/spark-xml . Kuvassa 3. näkyy myös Pythonkoodi millä tiedosto saadaan nimettyä halutun nimiseksi (tässä tapauksessa generalledger.json).

UTF-16 -konversio

Tässä kohtaa luulin, että data on valmiina ladattavaksi Azure SQL-kantaan suoraan Azure Blob-storagesta, mutta eteen tulikin merkistöongelma. Yllättäen ääkköset eli skandit eivät näkyneet oikein. UTF8-formaatti pitää saada muutettua UTF 16-formaattiin ja tähän löytyikin helppo ratkaisu Azure Data Factoryn kautta. Tehdään Copy-activity, jossa sink-datasetin encoding -arvo asetetaan UTF-16. Samalla kopioidaan tiedosto Azure Blob -storagessa stage-alueelle.

Azure SQL ja external table

Seuraava vaihe on saada data Azure SQL:ään. Otimme muuten käyttöön Azure SQL:n serverless-version (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-serverless ), jolloin ei tarvitse maksaa kannan ”staattisesta” käytöstä. Tietokannan kustannus on merkittävästi edullisempi näin. Kuvan 5.  sql -stored proseduurilla data luetaan ja parsitaan suoraan Azure Storagesta external-data sourcen kautta sql-tauluun. Huomaa että openrowset:ssa pitää käyttää single_nclob, jotta UTF-16 formaatissa oleva data saadaan luettua oikein skandien kera.

Latausten hallinta – Azure Data Factory

Lopuksi kun palaset on saatu kohdilleen, niin luodaan Azure Data Factory Pipelinet ajojen hallintaan. Tarvitaan kaksi pipelinea:

1. 01_Logic Apps -pipeline. Käynnistää Netvisor-intgraation Logic Apps -toteuksen web-rajapinnan kautta.
2. 02_Netvisor-pipeline. Käynnistää ensin Databricks -notebookin ja klusterin (klusteri sammuu automaattisesti 10min kuluttua). Seuraava steppi on tehdä UTF-16 konversio ja lopuksi kutsuu Azure SQL:n stored prosedurea.

Näitä ajoketjuja ei voi yhdistää samaan koska ensimmäinen käynnistetään web-rajapinnan kautta eikä pipeline tiedä koska Logic apps -työ on tehty loppuun (näyttää valmista jo 1-2 sekunnin kuluttua). Tässä kohtaa tämä ei kuitenkaan ole iso ongelma. Ajot kestävät vain muutaman minuutin ja ne on helppo ajastaan niin että ensimmäinen on varmasti valmis ennen kuin toinen lähtee liikkeelle.

Power BI -raportti

Kun data on saatu Azure SQL -kantaan siitä onkin helppo toteuttaa meidän Power BI Talousraportointi -pohjalla porautuva tulos- ja taseraportti. Mutta siitä tarkemmin seuraavassa blogissa 😉 .

Kaipaatko tukea Azure Data Platform ratkaisujen käyttöönotossa tai hyödyntämisessä? Ota yhteyttä ja keskustellaan, kuinka voimme auttaa!

DB Pro Services

Marko Somppi, CEO, Partner