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

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