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

Johdanto

Tietoon perustuva päätöksenteko on nykypäivän liiketoiminnassa yhä tärkeämpää. Se auttaa yrityksiä tekemään parempia päätöksiä, optimoimaan toimintaa ja saavuttamaan kilpailuetua. Tiedon jalostamisen peruspilareina toimivat tietovarastointi ja raportointi. Tässä blogikirjoituksessa käsitellään näitä kahta keskeistä osa-aluetta ja selitetään, miksi ne ovat niin tärkeitä liiketoiminnalle.

Mitä on tietovarastointi?

Tietovarastointi tarkoittaa yläkäsitteenä prosessia, jossa yrityksen eri toiminnoista kerätty data tallennetaan keskitettyyn paikkaan yhtenäistetysti. Tämä tietovarasto on suunniteltu niin, että dataa on helppo käsitellä, jakaa ja tutkia erilaisten raporttien ja analyysien muodossa. Tietovarastoinnilla ei tarkoiteta pelkästään datan säilyttämistä, vaan se kattaa myös muita datan elinkaareen kuuluvia asioita. Tietovarasto parantaa operatiivisten järjestelmien suorituskykyä ja saatavuutta, koska raportointia ei tarvitse tehdä enää niiden päältä, vaan raportoinnin työkuormat ohjataan kulkemaan tietovaraston kautta. Myös raporttien teko tietovarastosta on helpompaa kuin vastaavan tiedon onkiminen operatiivisista järjestelmistä. Käydään seuraavaksi läpi laadukkaan tietovarastoinnin ominaisuuksia.

Tietoturva

Datan turvallisuus on erityisen tärkeää nykypäivän digitaalisessa ympäristössä, jossa tietomurrot ja -vuodot ovat yleistyneet. Laadukkaat tietovarastot ovat suunniteltu noudattamaan tietoturvan parhaita käytäntöjä, kuten laadukkaan salauksen ja pääsynhallinnan. Monet tietovarastot hyödyntävät monitasoista autentikointia (MFA) ja roolipohjaista pääsynhallintaa varmistaakseen, että vain oikeutetut henkilöt pääsevät käsiksi arkaluontoiseen tietoon. Lisäksi ne voivat sisältää erilaisia valvontamekanismeja, jotka ilmoittavat epäilyttävästä toiminnasta, jotta mahdollisiin tietoturvariskeihin voidaan puuttua välittömästi.

Tietoturva ei ole vain tekninen vaatimus, vaan myös liiketoiminnallinen tarve. Se on olennainen osa yrityksen mainetta ja luottamusta, ja sen laiminlyönti voi johtaa paitsi taloudellisiin tappioihin, myös vahinkoon yrityksen brändille.

Lähdeintegraatiot

Lähdeintegraatiolla tarkoitetaan tietovarastoinnin prosessia, jossa eri datalähteistä kerätty tieto yhdistetään yhteen keskitettyyn tietovarastoon. Tämä ei ole pelkästään datan siirtämistä paikasta toiseen, vaan se sisältää usein myös datan muuntamista, puhdistamista ja rikastamista, jotta se on sisällöltään eheää ja yhdenmukaista, ymmärrettävässä muodossa raportointia ja analytiikkaa varten, sekä yhteismitallista muiden lähteiden kanssa.

Laadunhallinta

Datan laadunhallinta on olennainen osa tietovarastoinnin prosessia. Huonolaatuinen tai virheellinen data voi johtaa väärään analyysiin ja päätöksentekoon, mikä voi olla kallista yritykselle. Siksi tietovarastointiin sisältyy useita vaiheita datan laadun varmistamiseksi. Esimerkiksi datan puhdistaminen tarkoittaa virheellisen tai puuttuvan tiedon korjaamista, normalisointi puolestaan tarkoittaa datan muuttamista yhteensopivaan ja vertailukelpoiseen muotoon. Validointi taas on prosessi, jossa varmistetaan, että data on luotettavaa ja täyttää ennalta määritellyt laatuvaatimukset.

Nämä toimenpiteet eivät ole yksittäisiä tehtäviä, vaan ne ovat osa jatkuvaa laadunhallintaprosessia, joka alkaa datan keräämisestä ja jatkuu läpi koko sen elinkaaren. Tämä takaa tietovarastosta saadun tiedon olevan aina mahdollisimman tarkkaa, ajantasaista ja luotettavaa, mikä on välttämätöntä tehokkaalle päätöksenteolle.

Saatavuus

Laadukaskaan tieto ei tuota lisäarvoa, mikäli se ei ole kenenkään saatavilla. Datan saatavuus on kriittinen tekijä tietovarastoinnin onnistumisessa ja vaikuttaa suoraan yrityksen kykyyn tehdä informoituja päätöksiä. Laadukas tietovarasto on suunniteltu niin, että se mahdollistaa datan helpon ja nopean jakamisen eri osastojen, tiimien ja jopa ulkoisten sidosryhmien, kuten asiakkaiden tai kumppaneiden, kesken. Tämä poistaa pullonkauloja ja tehostaa päätöksentekoprosessia.

Nykyteknologian ansiosta tietovarastot tarjoavat dataa reaaliaikaisesti ja eri laitteille – mukaan lukien mobiililaitteet. Tämä mahdollistaa joustavuuden ja liikkuvuuden, mikä on erityisen tärkeää etätyöympäristöissä ja globaaleissa organisaatioissa.

Lisäksi hyvin suunniteltu tietovarasto tukee erilaisia käyttöoikeusasetuksia, jolloin voidaan varmistaa, että henkilöt pääsevät käsiksi vain heille relevanttiin tietoon. Tämä ei ainoastaan paranna tietoturvaa, vaan myös tekee datan hyödyntämisestä tehokkaampaa, kun jokainen tiimi tai osasto voi keskittyä juuri siihen dataan, joka on heille olennaista.

Arkistointi ja varmuuskopiointi

Datan pitkäaikainen säilyttäminen ja varmuuskopiointi ovat keskeisiä tietovarastoinnin elementtejä, jotka toimivat yrityksen datan turvaverkkona. Ne eivät ainoastaan suojaa arvokasta dataa, vaan myös mahdollistavat sen palauttamisen odottamattomissa tilanteissa, kuten tietojärjestelmäongelmissa. Tämä sisältää säännölliset varmuuskopiot ja datan elinkaaren hallinnan kattaen myös arkistoinnin ja versionhallinnan. Nämä toimet yhdessä varmistavat datan eheyden ja saatavuuden – myös kriisitilanteissa.

Mitä on raportointi?

Raportointi on keskeinen osa yrityksen tiedonhallintaa ja päätöksentekoprosessia, joka linkittyy vahvasti tietovarastointiin. Se tarkoittaa prosessia, jossa kerätty ja tietovarastossa säilytetty data muunnetaan merkitykselliseksi tiedoksi erilaisten raporttien ja analyysien avulla. Raportit voivat olla monimuotoisia, kattaen kaiken yksinkertaisista myyntitilastoista aina johdon mittaristoihin, monimutkaisiin ennakoiviin analyyseihin ja algoritmeihin, jotka ennustavat yrityksen tulevaisuuden suuntaviivoja. Käydään seuraavaksi läpi raportoinnin keskeisimpiä elementtejä.

Laadukas raportointijärjestelmä

Laadukas raportointijärjestelmä on joustava, skaalautuva ja helppokäyttöinen. Se mahdollistaa datan nopean ja tehokkaan analysoinnin, ja sen tulokset ovat helposti jaettavissa eri sidosryhmille. Nykyaikaiset raportointityökalut, kuten Microsoft Power BI, tarjoavat mahdollisuuden reaaliaikaiseen seurantaan, automatisoituun raportointiin ja monipuolisiin visualisointeihin, jotka tiivistävät tiedosta helpommin ymmärrettävää ja hyödynnettävää.

Visualisointi

Raportoinnin yksi keskeisistä elementeistä on datan visualisointi, joka tarkoittaa tiedon esittämistä graafisessa muodossa, kuten kuvaajina ja taulukoina. Hyvä visualisointi auttaa tekemään monimutkaisesta datasta helpommin ymmärrettävää ja saavutettavaa, ja se voi tuoda esiin näkemyksiä, jotka jäisivät helposti huomaamatta pelkästään raakadatan tarkastelussa. Visualisointien esittämisen tulee olla selkeää ja ytimekästä, keskittyen olennaisiin tietoihin ja mahdollistaen nopeat ja informoidut päätökset.

Laadukas visualisointi helpottaa tiedon esittämistä. Huomataan helposti tuotteen 2 poikkeava käytös päivinä 15–20.

Käyttäjäystävällisyys

Raporttien tulee olla helposti saatavilla ja ymmärrettäviä kaikille niille, joille ne on tarkoitettu. Tämä tarkoittaa, että raporttien tulisi olla selkeitä, visuaalisesti houkuttelevia ja helppolukuisia. Nykyaikaiset raportointityökalut mahdollistavat usein interaktiivisen raportoinnin, jossa käyttäjät voivat tutkia dataa itsenäisesti ja porautua yksityiskohtiin tarpeen mukaan.

Reaaliaikaisuus

Yhä useammin raportoinnin odotetaan olevan reaaliaikaista tai lähes reaaliaikaista, jotta päätöksentekijät voivat reagoida nopeasti muuttuviin tilanteisiin ja hyödyntää mahdollisuuksia ajoissa. Reaaliaikainen raportointi voi auttaa organisaatioita pysymään kilpailukykyisinä dynaamisessa liiketoimintaympäristössä, ja se voi tukea proaktiivista, dataohjattua, päätöksentekoa. Tämä edellyttää vahvaa teknologista infrastruktuuria ja kykyä käsitellä ja analysoida suuria datamääriä tehokkaasti ja luotettavasti.

Kuinka tietovarastointi ja raportointi liittyvät toisiinsa?

Tietovarastointi ja raportointi ovat syvästi kytkeytyneitä prosesseja, jotka yhdessä mahdollistavat informaation muuntamisen merkityksellisiksi oivalluksiksi ja päätöksenteon tueksi. Tietovarastointi kattaa datan keräämisen, integroinnin, pitkäaikaisen säilyttämisen sekä hallinnan, ja luo näin vankan perustan, jolle raportointi rakentuu. Raportointi puolestaan keskittyy datan analysointiin, visualisointiin ja jakamiseen. Näin organisaation jäsenille luodaan mahdollisuus ymmärtää ja hyödyntää dataa tehokkaasti.

Kun nämä kaksi elementtiä – tietovarastointi ja raportointi – toimivat saumattomasti yhdessä, mahdollistavat ne yrityksille kyvyn navigoida datavetoisessa maailmassa, tehdä informoituja päätöksiä ja luoda strategioita, jotka ovat linjassa yrityksen tavoitteiden ja markkinatilanteen kanssa. Tämä yhdistelmä on erityisen voimakas, kun se integroidaan osaksi yrityksen kulttuuria ja päätöksentekoprosesseja, mahdollistaen aidosti datavetoisen organisaation.

Esimerkkitapaus: Sirpaloituneesta datasta laadukkaaksi tietovarastoksi

Sirpaloituneen datan ongelma

Yrityksissä dataa syntyy monista eri lähteistä, kuten myynnistä, markkinoinnista, tuotannosta ja asiakaspalvelusta. Tämä data on usein tallennettu erillisiin järjestelmiin, jotka eivät välttämättä ole yhteensopivia keskenään. Tämä johtaa sirpaloituneeseen dataympäristöön, joka tekee tiedon hallinnasta ja analysoinnista haastavaa.

Ratkaisuna keskitetty tietovarastointi

Ensimmäinen askel sirpaloituneen datan kokoamisessa on dataintegraatio. Tässä vaiheessa eri lähteistä tuleva data tuodaan yhteen, keskitettyyn, sijaintiin. Nykyään raakadata tuodaan yleensä pilvessä toimivaan tietoaltaaseen (data lake). Raakadata jatkaa matkaansa tietoaltaasta tietomalliltaan strukturoituun tietovarastoon, josta se on saatavilla eri raportointi- ja analytiikkatyökalujen käyttöön. Etenkin taulukkomuotoisen datan tietovarastona käytetään usein SQL-tietokantoja.

Dataintegraatio ELT-prosessilla

Yksi yleisimmin käytetty menetelmä datan integroimiseksi on ELT-prosessi, joka on lyhenne sanoista Extract, Load ja Transform (kerää, lataa, muunna). ELT:llä tarkoitetaan kolmiosaista prosessia, jossa data ensin kerätään lähdejärjestelmistä, ladataan tietoaltaaseen ja lopulta muokataan yhdenmuotoiseksi tietovarastoon.

Lopputuloksena keskitetty tietovarasto

Lopputuloksena saatu tietovarasto suunnitellaan niin, että sieltä on helppo hakea, käsitellä ja analysoida dataa. Se toimii yrityksen keskeisenä tietopankkina, josta eri osastot ja johdon edustajat voivat helposti saada tarvitsemansa tiedot.

Tämä keskitetty lähestymistapa ratkaisee monia sirpaloituneen datan aiheuttamia ongelmia, kuten tiedon eheyden ja saatavuuden haasteet. Se mahdollistaa myös tehokkaan, konsolidoidun raportoinnin ja analyysin, jotka ovat keskeisiä tiedolla johtamisessa.

Kokonaisuudessaan keskitetty tietovarastointi ei ole vain tekninen toimenpide, vaan strateginen investointi yrityksen tulevaisuuteen. Se luo perustan, jolle voidaan rakentaa tehokas tiedolla johtamisen ekosysteemi.

Lopuksi

Datavetoinen päätöksenteko on enemmän kuin vain numeroiden tuijottamista; se on kokonaisvaltainen lähestymistapa, joka yhdistää tietovarastoinnin ja raportoinnin voiman. Joten, jos haluat tehdä parempia päätöksiä, optimoida toimintaasi ja saada kilpailuetua, on aika panostaa peruspilareihin: tietovarastointiin ja raportointiin.

Tiedolla johtaminen vaatii oikeanlaista osaamista ja työkaluja. Me DB Pro Servicellä ymmärrämme nämä haasteet ja olemme erikoistuneet auttamaan yrityksiä rakentamaan tehokkaita tietovarastointi- ja raportointiratkaisuja. Tarjoamme kattavia palveluita, jotka kattavat koko tiedolla johtamisen elinkaaren – lähtien datan keräämisestä ja integroinnista aina edistyneeseen analytiikkaan ja raportointiin.

Olemme työskennelleet monenlaisten yritysten ja toimialojen parissa, ja meillä on laaja kokemus erilaisten dataympäristöjen hallinnasta. Käytämme alan parhaita käytäntöjä ja uusimpia teknologioita varmistaaksemme, että saat parhaan mahdollisen hyödyn datastasi.

Ota yhteyttä meihin, jos olet kiinnostunut viemään datasi seuraavalle tasolle. Asiantuntijamme ovat valmiita auttamaan sinua löytämään juuri sinun yrityksellesi sopivan ratkaisun. Katsotaan yhdessä, kuinka voimme auttaa sinua saavuttamaan tavoitteesi datan avulla.

DB Pro Services asiantuntijatiimi

Tietoalustojen ja pilviteknologioiden kehityksen myötä yritykset panostavat tietoon perustuvaan päätöksentekoon. Tietoa käsitellään ja säilötään kasvavissa määrin erilaisten järjestelmien ja tietovarastojen sisällä. Tietojen käsittelyä tapahtuu useissa eri järjestelmissä, kuten erilaisissa toiminnanohjaus- (ERP), laskutus- ja asiakkuudenhallintajärjestelmissä (CRM). Näillä järjestelmillä on jatkuvasti yhtäaikaisia käyttäjiä, jotka samanaikaisesti muokkaavat ja päivittävät tietoa. Lisäksi tiedot ja tietojenkäsittely ulottuvat usein yli organisaatiorajojen, mikä voi johtaa tiedon tuplaantumiseen, vanhentumiseen tai pirstaloitumiseen. Tällaiset tiedon laadulliset ongelmat aiheuttavat epätarkkuuksia tärkeissä analyyseissa ja raporteissa. Vastaukset liiketoiminnalle tärkeisiin kysymyksiin esimerkiksi asiakassegmenteistä tai tuotteiden varastomääristä vääristyvät.  Tämä on myrkkyä liiketoiminnalle ja tietoon pohjautuvalle päätöksenteolle.

Vasta-aineena ydintietojen eli Master Datan määrittely ja Master Datan hallinta

Yllä mainittua ongelmaa on hyvä lähestyä tiedonhallinnallisesti ja tarkkaan laaditulla data strategialla. Ensin tulee määritellä ja erottaa yrityksen tietokokonaisuudesta ydintietoelementit eli Master Data.

Perinteisesti Master Datan katsotaan sisältävän yrityksen kriittisiä tietokokonaisuuksia, kuten asiakas-, tuote-, toimittaja- ja työntekijätietoja, joita käytetään johdonmukaisesti eri liiketoimintaprosesseissa ja sovelluksissa. Kaikkia näitä tietoja yhdistää se, että tähän dataan kohdistuu harvoin muutoksia ja tieto on luonteeltaan pysyvää pitkäaikaista tietoa.

Master Datan määrittelemiseen ja tunnistamiseen on hyvä käyttää käsitemallinuksen metodeja. Käsitemallilla tarkoitetaan geneeristä liiketoimintalähtöistä tietomallia, jota käytetään tietoalueen tietojen kuvailemiseen ja niiden suhteiden syvälliseen ymmärtämiseen. Käsitemallinnuksella saadaan eroteltua ja tunnistettua Master Data ja tapahtumatyyppinen data toisistaan. Mallin avulla luot perustan yrityksen yhteiselle kielelle, kun puhutaan datasta ja tietoelementeistä.

Master Dataa ei tule kuitenkaan sekoittaa referenssidataan, jolla tarkoitetaan myös luonteeltaan pysyvää tietoa. Yleisesti referenssidatalla tarkoitetaan ulkoisia standardoituja koodistoja, kuten maa-, kunta- tai muita vastaavia koodistoja, joita yleensä hyödynnetään tietovarastossa tietokokonaisuuksien laajentamiseen.   

Kuinka edetä, kun Master Data on määritelty

Master Datan hallinnalla (MDM) tarkoitetaan erilaisia prosesseja ja työkaluja, joilla varmistetaan Master Datan hallinta ja koordinointi koko yrityksessä. MDM-arkkitehtuuri tuleekin suunnitella vastaamaan organisaation erityistarpeita, jotta ydintiedot ovat tarkkoja ja käytettävissä kaikkialla yrityksessä.

Käytännössä suunnitellaan keskitetty tietovarasto Master Datan hallintaan ja tallennetaan Master Data tähän yhteen keskitettyyn tietovarastoon. MDM-tietovarasto integroituu kaikkiin tietolähteisiin, jotka hyödyntävät ydintietoja. Tietolähdejärjestelmät lukevat ja kirjoittavat Master Datan MDM-tietovarastosta. Hyvin suunniteltu ja toteutettu MDM-arkkitehtuuri auttaa yritystä saavuttamaan tiedonhallintatavoitteensa ja edistämään liiketoiminnan tuloksia.

Alla oleva kuva havainnollistaa Master Datan hallinnan ja Master Datan tärkeyttä Business Intelligence (BI) tietovarastoinnin yhteydessä.

• Käyttäjät kirjaavat, päivittävät ja poistavat tietoja erilaisissa järjestelmissä. Tiedot tallentuvat näiden operatiivisten järjestelmien tietokantoihin.
  • Käyttäjä saattaa olla esimerkiksi verkkosivustolla asioiva asiakas, yrityksen työntekijä tai automaattisesti rajapintaa käyttäen päivittyvä rekisteri tai laskutieto.
• Keskitetty Master Datan tietovarasto integroituu erilaisten API-rajapintojen avulla operatiivisten järjestelmien tietokantoihin.
  Master Dataksi tunnistetut tiedot luetaan ja ylläpidetään operatiivisista järjestelmistä keskitetyssä Master Datan tietovarastossa muiden sovellusten ja BI-tietovaraston hyödynnettäväksi. Tällä tavalla varmistetaan, että jokaisella järjestelmällä on käytössään yksi ja ajantasainen ydintietojen kokonaisuus.
• Operatiivisista tietokannoista muut liiketoiminnalle tärkeät tiedot luetaan keskitettyyn BI- tietovarastoon erilaisten Extract Transform and Load (ETL) -menetelmien avulla suoraan lähdejärjestelmien tietokannoista.
• Master data luetaan BI-tietovarastoon keskitetystä Master Datan hallinnan tietovarastosta. Näin taataan, että raportoinnin ja analytiikan käytössä olevat ydintiedot ovat yksi todellisuus, joka on aina ajan tasalla ja tärkeimmät mittarit antavat oikeita ja tarkkoja arvoja.
• Viimeiseksi Master Data on yhdistettävissä muuhun yrityksen tietoon BI-tietovarastosta. BI-tietovarastosta tiedot ovat hyödynnettävissä erilaisille hyödyntäjille, kuten edistyneelle analytiikalle tai raportoinnille.  

Yhteenveto

Toimivan Master Data ja MDM-strategian toteuttaminen osana BI-arkkitehtuuria tuottaa lukuisia etuja yritykselle. Alla listattuna vielä tärkeimpiä Master Datan ja MDM:n tuottamia etuja:

• Tiedon laatu (Data Quality):
  • Master Data toimii perustana tiedon laadulle tarjoamalla tarkkoja ja johdonmukaisia tietoelementtejä.
  • MDM-prosessit varmistavat, että Master Data pysyy laadukkaana, tiedon laatuun liittyviä ongelmia tunnistetaan ja ne ratkaistaan.
  • Master Datan hallinnan avulla yrityksen Master Datan laatu on yhtenäistä ja käytössä yhtenä totuutena koko yrityksessä.
• Erilaiset raportit ja edistynyt analytiikka sisältää usein monimutkaisia kyselyitä ja analyyseja, joille tarkka ja johdonmukainen Master Data antaa vahvan perustan.  
• Tietojen hallinta (Data Governance):
  • MDM-prosessit tarjoavat tarvittavan hallintokehyksen Master Datan tehokkaaseen hallintaan ja tiedon laadun ylläpitämiseen koko tiedon elinkaaren ajan.
  • Master Datan määrittelyllä luodaan perusta yrityksen tietojen hallinnalle. Master Datan määrittelyn jälkeen yrityksellä on vankka pohja siirtyä muiden tietoelementtien määrittelemiseen.
  • Tietojen hallinnalla varmistetaan liiketoiminnan yhtenäinen kieli yrityksen tietoelementeistä keskusteltaessa.

Me DB Pro Servicellä tarjoamme laadukkaita tietovarastoinnin ja tiedon mallintamisen asiantuntijapalveluita.  Pidämme huolta, että ratkaisumme ovat kestävästi, turvallisesti ja kustannustehokkaasti toteutettuja. Ota yhteyttä ja kysy lisätietoja tarjoamistamme pilvipohjaisista moderneista tietoalusta -ratkaisuista.

Yhteistyöterveisin,
Robin Aro
Lead Data Engineer
robin.aro@dbproservices.fi
DB Pro Services Oy

Lue myös intro tietomallinnukseen

Kun organisaatio käynnistelee tiedolla johtamista, datan varastoksi käsitetään usein operatiiviset järjestelmät. 

Jos kuitenkin tarkastelemme tällaisen operatiivisen tietovaraston (OLTP), kuten esimerkiksi CRM tai ERP, oliorakennetta, huomaamme nopeasti, ettei siitä helposti eikä selkeästi saada kuvaa mihin liiketoiminnan alueeseen mikäkin taulu tai tietokenttä liittyy. 

Kuva muuttuu sitä hämyisemmäksi mitä isompia operatiivisia kokonaisuuksia katsellaan. Tietorakenne on monimutkainen ja ihmissilmälle sopimaton. Tietokenttien nimeämiseen ja sisältöön on käytetty usein lyhenteitä ja muita tulkinnanvaraisia ilmaisumuotoja.

Esimerkki operatiivisesta tietomallista. (monimutkaisuus, transaktionaalisuus, atomisuus)

Harmillisinta lienee kuitenkin se, että jos kovalla työllä saadaan selvitettyä yrityksen operatiivinen järjestelmän tuottama data, huomataan ettei järjestelmä säilytä lukuja yleensä yhtä päivää kauempaa. Pitää nopeasti ottaa Exceliin kopio päivän tilanteesta ennen kuin järjestelmä pyyhkii sen pois.

Usein myös päädytään virittelemään aputauluja tai –tietokantoja, joihin dumpataan edellisten päivien tiedot haettavaan muotoon (snapshot). Tämä ei poista kuitenkaan kerätyn tiedon vaikeaselkoisuutta ja tekee edelleen tiedon historiallisesta hyödyntämisestä raportoinnin ja analysoinnin tarkoituksiin työlästä ja virhealtista puuhaa.

Operatiiviset järjestelmät on suunniteltu transaktiokeskeisiksi (OLTP), mikä tarkoittaa, että ne soveltuvat parhaiten pistemäisten tietojen tallentamiseen ja näyttämiseen eikä niiden suorituskyky skaalaudu raportointi- ja analysointitarpeisiin.

Tämä on todella ongelmallista esimerkiksi ad hoc-raportoinnin yhteydessä sekä palveluaikana tehtävän raportoinnin osalta, koska tällaiset kyselyt vievät helposti koko OLTP-palvelimen käytettävissä olevat fyysiset resurssit ja näin ollen hidastavat sekä vaarantavat operatiivisen järjestelmän koko toimintakyvyn.

Vielä haasteellisemmaksi raportointi ja tiedolla johtaminen muuttuu operatiivisessa ympäristössä, kun aletaan vertailemaan (konsolidointi) eri järjestelmien välistä tietoa keskenään eri näkökulmista. Ongelmaksi muodostuu mm. se, että tieto on esitetty eri tavalla eri järjestelmissä eikä näin näkymiä kyetä yhdistämään.

Kaiken tämän seurauksena päätöksenteon tueksi tarkoitettuun tietoon ei kyetä luottamaan, kokonaiskuva liiketoiminnasta jää saamatta eikä päätöksiä kyetä tekemään kyllin nopeasti. Liiketoiminnasta vastuussa olevat henkilöt eivät saa tietoja siinä muodossa kuin he ymmärtävät sen, eivätkä tiedä milloin tai miten operatiivinen järjestelmä on korjannut datan muotovirheet (jos ollenkaan) tai että milloin ylipäätään saadaan ajantasaista tietoa yrityksen tilanteesta.

Tarvitaan ratkaisu, joka kykenee taklaamaan operatiivisen raportoinnin tuomat haasteet tiedolla johtamiselle.

Tietovaraston käyttö ja käyttäjät

DW eli tietovarasto on se paikka mihin yrityksen avaintieto keskitetään. Koska tämä tieto on keskitetty, se on helppo löytää. Ja koska tiedon oikeellisuus on tarkastettu, sitä voidaan tarjota esim. virallisiin raportteihin ja tietoon voidaan luottaa.

Eri järjestelmien välinen yhteismitallinen tieto on konformoitu jolloin strateginen päätöksenteko helpottuu, kun on oikeanlaista ja ajantasaista tietoa saatavilla organisaation kaikilla tasoilla.

Tietojäsenet on esitetty selkeässä ja ymmärrettävässä muodossa ja niihin liittyvä metatieto (kuvaus) on esitetty selkeästi. DW-järjestelmän tietomalli on helppo ymmärtää ja se on erittäin suorituskykyinen datamassojen lataamisessa sekä niiden raportoinnissa ja analysoinnissa eikä häiritse operatiivisten järjestelmien performanssia.

Yrityksen ylin johto saa tarvitsemansa mittarit halutulla summatasolla ja kaikkien organisaatioyksiköiden luvut rinnakkain. Strategisessa kuvassa tarvitaan paljon tietoa, jotta voidaan ennustaa tulevaa menneestä, eli laskemaan ns. prediktiivinen analyysi.

HR voi tarvittaessa vilkaista koko henkilöstön poissaoloja ja muuta jaksamista. Projektipäälliköt voivat vertailla omia ja muiden projekteja, josko näin saataisiin tsemppiä lisää omaan tekemiseen. Muu henkilöstö käyttää pääsääntöisesti self service-raportteja. Lisäksi viranomaistahot haluavat tietynmuotoisia raportteja aika ajoin, joita voidaan laskea valmiiksi tietovarastoon.

Esimerkki tietovaraston tietomallista. (yksinkertaisuus, historiointi, suorituskyky)

Monet eri tahot siis käyttävät tietovarastoa sitten kun sellainen on olemassa. Voidaankin sanoa, että DW on eräänlainen yrityksen virallinen totuus.

Tietovaraston suunnittelu ja toteutus

Liiketoiminnasta vastaavat henkilöt tarvitsevat erilaista näkyvyyttä tietoihin: Yksi hoitaa taloutta ja toinen vastaa materiaaleista. Kummallakin henkilöllä on oman alueensa termistö parhaiten hallussa ja kriittiset mittarit tarkkaan laskettuna. Näitä molempia tarvitaan tietovaraston määrittelyvaiheessa.

Huomattavaa kuitenkin on, että tietovaraston mukana organisaatioon tulee uusia rooleja ja vastuita. Ensinnäkin jokainen substanssiosaaja tarvitaan määritysvaiheessa, mutta myös myöhemmin joku ottaa vastuun omasta osa-alueestaan tietovarastossa. Lisäksi liiketoimintakriittiselle tiedolle tarvitaan ns. “raporttivastaava”, joka valvoo raportoitavan tiedon oikeellisuutta. DW:tä suunnitellessa olisi hyvä jakaa roolit oikein.

Millä tavalla tietovarasto sitten pystytetään, riippuu muutamasta asiasta, kuten:

• Onko data hajanaista?
• Mikä on tiedon laatu operatiivisissa järjestelmissä?
• Tehdäänkö koko tietovarasto loppuun asti kerralla?
• Riittääkö pienemmät tietomallit, esimerkiksi liiketoiminnan osa-alueiden mukaan?
• Reaaliaikaisuustarpeet
• Millainen tietovarastoarkkitehtuuri sopii parhaiten ympäristöön
  • Erilliset datamartit
  • Conformed Data Warehouse BUS
  • Data Vault
  • jne
• Push / Pull (kyselläänkö vai tarjoillaanko datat tietolähteistä)
• On-premise vs. pilviratkaisu, hybridi?

Mallintaja

Hyvin keskeinen osa tietovarastoprojektia on tietomallinnus. Tässä on selkeää hyötyä siitä, jos mallintaja tuntee kyseistä liiketoiminta-aluetta ennestään mutta taitava mallintaja kykenee luomaan bisneskäsitteistä ymmärrettävät ylätason tietomallit liiketoiminta-alueesta riippumatta yhdessä asiakkaan kanssa, jonka pohjalta sitten fyysinen tietokantamallinnus voidaan helposti toteuttaa. Fyysisen tietokantamallinnuksen voi tehdä myös hieman teknisempi mallintaja mutta tavallisesti tämän työn tekee DBA, jotta yllätyksiltä vältytään tietomallin toteuttamisvaiheessa.

Toteuttajaroolit tietovarastoprojektissa

Mallintajan lisäksi muita keskeisiä tietovarastoprojektin rooleja ovat:

• DBA / tietokantakehittäjä, joka vastaa tietokannan fyysisen skeeman suunnittelusta ja toteutuksesta sekä tietokantakyselyistä
• ETL-kehittäjä, joka vastaa tiedon lataamisesta operatiivisista järjestelmistä tietovarastoon
• BI-kehittäjä, joka kykenee toteuttamaan erilaisia raportteja, analyysejä, mittaristoja ja ennusteita liiketoiminnan tueksi, sekä tarpeen mukaan:
• Data scientist, joka soveltaa matematiikkaa ja tilastotiedettä bisnesongelman ratkaisemiseksi hyödyntäen mm. koneoppimista

Kun ulkopuolinen konsultti tulee tekemään yritykseen tietovarastoprojektia, hän ei aluksi välttämättä tiedä kovinkaan syvällisesti mitä yrityksen tieto itsessään pitää sisällään. Tämä ei kuitenkaan ole ongelma niin kauan kuin yrityksen omat vastuuhenkilöt tietävät. Projektin edetessä konsultti kyllä tulee tutuksi yrityksen tärkeistä asioista. Usein pienemmissä tietovarastohankkeissa kokenut konsultti voi toimia kaikissa toteuttajarooleissa.

DBA-roolin tärkeys

Mitä suurempi määrä dataa operatiivisista järjestelmistä kerätään, mitä vaihtelevammat datan historiointi- ja reaaliaikaisuusvasteet ja mitä monisäikeisempi tietomalli ovat, sen keskeisemmäksi nousee tietovarastoinnissa DBA:n rooli. Hyvän DBA:n käsissä laitteisto- / tietokantaympäristökustannukset tipahtavat murto-osaan verrattuna peruskoodariin. Tämä johtuu siitä, että kokeneen DBA:n suunnittelema tietomalli on hyvin skaalautuva ja tietokanta suorituskykyinen. Kun kaikkiin näihin osa-alueisiin kiinnitetään riittävästi huomiota, saavutetaan merkittäviä säästöjä niin suoritinmäärissä (CPU), levyvaatimuksissa (IO) kuin datan prosessointiajoissakin.

ETL eli tiedon keruu ja jalostaminen

Kun vaatimusmäärittelyt, mallintaminen ja DW-kanta on tehty, aletaan keräämään dataa. Päivittäinen, miltei reaaliaikainenkin data kootaan lastausalueelle (Staging) sellaisenaan, josta se sitten tarkastetaan ja jalostetaan eteenpäin ihmisellekin sopivaan muotoon.

Kun kaikki lähdedatan siistiminen on tehty, aletaan tietoa kokoamaan raporteille sopivaksi. Tässä vaiheessa liiketoiminnan eri osa-alueiden käsitteelliset siilot yleensä kaadetaan ja tieto summataan, jalostetaan ja konformoidaan koko organisaatiotason termistöön.

Datan keruuprosessit (ETL) kehitetään kerran, jonka jälkeen niihin ei tyypillisesti tule suuria muutoksia. Toki uusia tarpeita tulee ja niihin tehdään prosessit, mutta kaiken kaikkiaan ETL pyörii automaattisesti hiljaa taustalla.

ETL-on siis automatisoitu prosessi, jolla haetaan operatiivisista tietojärjestelmistä tai niiden lastausalueilta dataa tyypillisesti kerran vuorokaudessa palveluajan ulkopuolella siten, etteivät operatiiviset järjestelmät haitallisesti kuormitu. ETL-ajot on mahdollista toteuttaa myös miltei reaaliaikaisena.

ETL on tietovarastokokonaisuuden kannalta erittäin keskeinen osa-alue ja vaikka tätä prosessia pystytäänkin pitkälle automatisoimaan (ETL design patterns), isojen datamassojen kanssa on usein tarvetta latausajojen syväosaamiseen ja performanssioptimointiin, etenkin ETL-valmisohjelmistojen kanssa.

Summa summarum

Tietovarasto elää ja hengittää luotettavan tiedon kautta. Tämä tarkoittaa sitä, että jokaisen tuotantoon oton yhteydessä tiedon oikeellisuuden tarkastaminen on kaiken muun testaamisen ohella kriittinen vaihe projektin onnistumisen kannalta. Raportoitavaa tieto on saatava päätöksenteon tueksi oikeaan aikaan, oikeassa muodossa ja oikeille tahoille. Mikäli yksikin osa-alue lipsuu, liiketoiminta kärsii.

DB Pro Services:in kokeneilla konsulteilla on keskimäärin yli 15 vuoden kokemus DW-projektien määrityksestä, toteutuksesta sekä ylläpidosta. Olemme toteuttaneet lukuisia tietovarastoja keskisuurille ja suuryrityksille sekä kansainvälisille ohjelmistotaloille useilla eri toimialoilla.

Liittyvätpä tarpeesi mihin tahansa osa-alueeseen organisaatiosi tietoalustassa, meiltä löydät huippuasiantuntijat liiketoimintasi tueksi. Sovellamme alamme parhaita käytäntöjä sekä uusimpia Microsoft -teknologioita asiakkaidemme kulloiseenkin tarpeeseen, olipa kyseessä sitten on-premises-, hybridi-, tai Azure-pohjainen ratkaisu.

Jani K. Savolainen

Founder & Chairman

Joonas Lönnmark

Partner, Senior BI Consultant

DB Pro Services Oy 2021

Lue myös intro tietomallinnuksesta sekä tietovarastointi ja raportointi päätöksenteon tukena

Power BI Dataflows – enemmän aikaa tiedon analysointiin

Power BI on mitä mainioin itsepalvelu-BI-työkalu. Se sisältää monipuoliset tietolähdeyhteydet, ETL-työkalun, tehokkaan muistinvaraisen kuution sekä raportointityökalut samassa paketissa. Itse asiassa niin tiiviissä paketissa, että kertaalleen tehdyn ratkaisun uudelleenkäyttö järkevästi on ollut lähes mahdotonta. 

Power BI -raportin kuution pystyy toki siirtämään Azure Analysis Services -kuutioksi pienen kikkailun jälkeen, mutta ETL-työkalulla eli Power Queryllä toteutettuja datasettejä ei ole voinut uudelleenkäyttää muuten kuin kopioimalla M-koodi raportista toiseen. Power BI Dataflows poistaa tämän tuskan! Sillä toteutettu Power Query -datasetti on helposti liitettävissä toisiin Power BI -raportteihin sekä myös muihin Azure Data Platform -tuotteisiin. Väitän, että tällä ratkaisulla pystytään säästämään melkoinen määrä aikaa ja rahaa yrityksissä, joissa Power BI on laajasti käytössä. Aikaa jää enemmän tiedon analysointiin, kun data on valmiiksi pureskeltu ja jaettu Dataflow:n kautta.

Kuinka Power BI DataFlows otetaan käyttöön?

Teknisestä näkökulmasta Power BI Dataflows on irrallinen Power Query -prosessi, joka toimii Power BI -palvelussa. Yksi Dataflow voi koostua useammasta erillisestä tai linkitetystä tietojoukosta. Näitä tietojoukkoja voi ottaa helposti käyttöön Power BI -raportissa Power BI Dataflows -datalähteen kautta. Preview-vaiheessa ollut datalähde on nyt virallisesti saatavilla Power BI Desktopin April 2019 -julkaisussa (ks. kuva)

Oletusasetuksilla Dataflow tallentaa tiedot Power BI:n sisäiseen storageen ja siihen ei ole pääsyä muuten kuin Dataflow:n kautta. Tämä on kuitenkin mahdollista muuttaa niin että data tallennetaan organisaation Azure Data Lake Storage Gen2:een, mikä taas avaa ovet datan käyttämiseen myös muilla Azuren työkaluilla. Data Laken käyttö vaatii tietysti voimassaolevan Azure-tilauksen. Hyvät ohjeet ADLS Gen2:n liittämiseen löytyy täältä.  Kun ADLS Gen2 on luotu, asetettu tarvittavat oikeudet Power BI Service, Power BI Premium ja Power Query -tunnuksille sekä Power BI admin -portaalin kautta liitetty Data Lake käyttäjän Power BI -tenanttiin, näyttää lopputulos tältä:

Power BI Dataflow ADLS Gen2:ssa

Miten data sitten tallentuu ADLS Gen2:een? Testasin tätä yksinkertaisella esimerkillä ja siirsin Power BI -raportista Calendar-taulun Dataflow-datasetiksi.

Power Query -editori on lähes samanlainen kuin Power BI Desktop -työkalussa. Helppo tapa siirtää koodi desktopista on käyttää Power Queryn advanced-editoria. Ohessa kuva Calendar-taulun editointinäkymästä siirron jälkeen.

Kun datasetti on valmis pitää se tietysti prosessoida ennen kuin data tallentuu Data Lakeen. Prosessointi on lähes identtinen verrattuna Power BI -datasetin vastaavaan. Prosessoinnin voi tehdä kertaluonteisesti tai sitten ajastaa.

Microsoftin dokumentaation mukaan data tallentuu ADSL Gen2:een CDM (Common Data Model) -rakenteeseen. Model.json sisältää datan metatiedot ja kukin datasetti on omassa kansiossa csv-tiedostoina (ks. kuva alla).

Calendar-demossa datarakenne ja hakemistot näkyvät alla. Huomattava on että model.json:lla on oma hakemisto josta löytyy tiedoston versiohistoria (model.json.snapshots).

Calendar-data on tallennettu hakemistoon Calendar.csv.snapshots. Datasta tallentuu useita eri versioista. Eli jokainen datan päivitys luo uuden version, ja model.json-tiedostossa on partitions-kohdassa viittaus viimeisimpään versioon.  Nykyisestä Dataflow:n versiosta tähän ei löydy mitään konfigurointivaihtoehtoja eikä Microsoftin dokumentaatiossa ole näistä vielä mitään mainintaa. Ehkä “snapshottien” määrää ja muita vastaavia voi säätää Dataflow:n tulevissa päivityksissä.

Power BI Dataflow -lisensointi

Power BI Dataflow tuntuu olevan jo kohtalaisen valmis kokonaisuus, ja suosittelen ehdottomasti sen testaamista. Huomattava on kuitenkin, että kaikki samat datalähteet mitä löytyy Power BI Desktopista eivät vielä ole tuettuna Dataflow:ssa. Lista tällä hetkellä tuetuista lähteistä löytyy täältä. Lisäksi Dataflow toimii Power BI Pro -lisenssillä, mutta jos käytössä on Power BI Premium, pääsee nauttimaan sen kaikista ominaisuuksista.

Oheisessa taulukossa on tällä hetkellä tiedossa olevat erot ominaisuuksissa lisenssin mukaan:

Dataflow Capability	Pro	Premium
Connectivity	All connectors to all sources	All connectors to all sources
Storage	10 GB per user	100 TB for P1 or greater nodes
Data ingestion	Serial ingestion of entities, making data refresh longer	Parallel ingestion of entities
Incremental updates	Not available	Available
References to entities in the same workspace	Not available	Available, allowing the creation of complex data prep processes using multiple dataflows
References to entities across workspaces	Not available	Available, allowing full data consistency across the whole data estate
Calculation engine	Not available, since entities cannot refer to other entities, computed entities cannot be created	Available, allowing computed entities for complex data prep projects with multiple cleansing and enrichment steps
Refresh rates	Up to 8 times a day	Up to 48 times a day
Automated Machine Learning (preview)	Not available	Available
Cognitive Services (preview)	Not available	Available

Milloin hyödyt Power BI Dataflow:n käytöstä?

Loppuun vielä ajatuksia siitä missä tilanteissa Dataflow:ta kannattaisi käyttää:

• Geneeristen datasettien, kuten dimensioiden toteuttaminen. Esim. aikadimensiot, organisaatiorakenteet, kustannuspaikat, tilihierarkiat, jne.
• Excel-tiedostot, jotka on tallennettu esim. Teamsiin tai Sharepoint-onlineen. Monesti näitä tarvitsevat myös muut ja on paljon helpompaa ottaa datasetti käyttöön suoraan Dataflow:sta.
• Tilanteet, joissa alkuperäiseen datasettiin ei ole mahdollista päästää useita käyttäjiä tekemään raskaita kyselyitä samanaikaisesti.
• Tilanteet, joissa Power BI -raporttien toteuttajilla ei ole riittävää osaamista eivätkä he tunne datalähteen liiketoimintalogiikkaa.
• Silloin, kun halutaan varmistaa, että mitään ylimääräistä ja tietoturvan kannalta riskialtista dataa ei päädy raporteille ja analyyseihin. Näissä tilanteissa tarjotaan valmiiksi käsitellyt datasetit Dataflow:n kautta raporteille.

Kaipaatko tukea Power BI:n käyttöönotossa tai hyödyntämisessä? Ota yhteyttä ja keskustellaan, kuinka voimme auttaa!

DB Pro Services

Marko Somppi, CEO, Partner