Klassinen tietovarastointi

Jani Savolainen

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 Data Engineer & Architect

DB Pro Services Oy 2021

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