• Productivity Leap

Uuden sukupolven tietovaraston synty

PEKKA STIGELL

pekka.stigell@productivityleap.com


Tietovarastojen kehitys alkoi muutama vuosikymmen sitten. Vuosien saatossa on syntynyt erilaisia näkökantoja tietovarastojen suunnitteluun ja käyttötarkoituksiin. Suunnittelussa on perinteisesti jakauduttu kimballilaisiin tai inmonlaisiin ja käyttötarkoitukset vaihtelevat organisaation laajuisista keskitetyistä tiedon integraatioratkaisuista järjestelmäkohtaisiin raportointikantoihin.

Perinteiset tietovarastot


Kimballin arkkitehtuurissa suunnittelu lähtee siitä että tietovarasto koostuu datamarteista. Datamartit mallinnetaan yleensä tähtimallisiksi kantarakenteiksi, jotta ne tukisivat mahdollisimman hyvin raportointivälineitä. Tähtimallien kokoelmasta käytetään joskus nimitystä lumihiutalemalli, jossa eri tähdet yhdistyvät toisiinsa yhteisillä dimensioilla. Tähtimallisten datamartien alle rakennetaan helposti monimutkaiseksi rönsyilevä latausalue, jossa eri lähteiden tietoa yhdistetään raportoitavaan muotoon sopivaksi (Kuva 1). Tällöin tiedon varastointi ja historiointi jää datamartien varaan.


Kuva 1. Kimballin arkkitehtuuri

Inmonlaiset varastot ovat yleensä kolmannen normaalimuodon kantoja jotka noudattelevat pitkälti rakenteeltaan lähdejärjestelmien tietokantarakenteita. Tällöin tietojen yhdistäminen tietovarastossa ja latausketjujen (data pipeline) suunnittelu voivat olla hankalia, koska taulujen väliset suhteet määrittelevät tietojen latausjärjestyksen. Inmonlaisen lähestymistavan perusajatus on, ettei tietovarasto ole ensisijaisesti raportointikanta, vaan tiedon integrointi ja säilytyspaikka (Kuva 2). Tämän takia raportointia varten tehdään tietovaraston päälle oma kerros näkymistä tai tietokantatauluista.


Kuva 2. Inmonlainen arkkitehtuuri.

Uuden sukupolven tietovarasto


Kumpikin perinteisistä arkkitehtuureista oli lähtökohta uusimpaan ja ainoaan alunperin pelkästään tietovarastointa varten tarkoitettuun suunnittelumenetelmään. Tarkoitus oli kerätä aiemmista arkkitehtuureista hyvät puolet, hylätä huonot puolet ja samalla luoda uusi suunnittelumenetelmä. Menetelmällä eri lähdejärjestelmien tietoa on helppo integroida, varastoa voi rakentaa iteratiivisesti eikä olemassa oleviin rakenteisiin tarvitse tehdä muutoksia. Tieto pysyy sellaisena kuin se varastoon ladattiin, tiedon jäljitettävyys säilyy ja tieto on helppo ladata useista eri lähdejärjestelmistä yhtä aikaa, ilman että latausjärjestystä tarvitsee erikseen miettiä. Näistä asioista koostuu Dan Linstedtin Data Vault ja sen uusin versio 2.0.

Data Vault on siis suunnittelumenetelmä, joka koostuu joukosta sääntöjä. Tärkein sääntö suunnittelussa on tunnistaa liiketoiminnan avaimet, jotta päästään mallintamaan Data Vaultin tärkeintä taulutyyppiä eli hubeja. Kun hubeja mallinnetaan, lähtökohtana kannattaa käyttää käsitemallia. Tällöin toki vaaditaan käsitemallin olemassaoloa, mutta mikäli käsitemallinnus on tehty hyvin, voidaan sen pohjalta muodostaa Data Vault -kannan taulut pitkälti automaattisesti (nykyaikaisilla ETL -välineillä). Muita Data Vaultin taulutyyppejä ovat linkkitaulut, satelliittitaulut ja referenssitaulut. Linkkitaulut kuvaavat hubien, eli liiketoiminnan avainten välisiä suhteita ja satelliittitaulut sisältävät kaiken attribuuttitiedon ja tiedon historioinnin (Kuva 3). Referenssitaulut sisältävät nimensä mukaisesti referenssityyppistä tietoa kuten esim. koodistoja.


Kuva 3. Data Vault 2.0 -arkkitehtuuri.

Data Vaultin myötä tietovarastointi on mennyt yleisesti Inmonlaiseen suuntaan, jossa tietovarastokerros rakennetaan Data Vaultilla ja sen päälle rakennetaan datamartit, joista tietoa hyödynnetään. Samalla on ETL:stä (extract, transform, load) tullut ELT:tä (extract, load, transform). Kirjainyhdistelmien ero tarkoittaa sitä, että ETL:ssä haetaan ensin tiedot, muunnetaan ne sopivaan muotoon ja ladataan vasta sitten tietovarastoon. ELT:ssä taas tiedon muunnosta yritetään välttää mahdollisimman pitkälle kun tieto tuodaan lähdejärjestelmistä tietovarastoon ja tiedon muunnos tehdään vasta tietovarastosta eteenpäin vietäessä, esim. Data Vaultin kyseessä ollessa Business Data Vaultiin tai datamarteihin.


Uuden sukupolven tietovaraston rakentaminen


Perinteisillä menetelmillä tehdyillä tietovarastoprojekteilla on syystäkin huono maine. Usein ne venyvät pitkiksi ja saattaa jopa käydä niin ettei kehitysprojekti pääse koskaan tuotantoon, tai jos pääseekin, tietovarasto jää pienelle käytölle. Onneksi tietovarastoinnin evoluutio on Data Vaultin ja ELT-automatisoinnin myötä vihdoin siinä pisteessä että tietovarastoinnin yhteydessä voidaan puhua ketteryydestä, skaalautuvuudesta ja pitkälle viedystä automatisoinnista.


Data Vault sopii täydellisesti tietovarastojen mallinnukseen ja myös tiedon vieminen tietovarastoon on yksinkertaisempaa kuin perinteisillä menetelmillä suunnitelluissa tietovarastoissa. Usein suurin osa tietovarasto- ja tiedolla johtamisen projektien kaikesta työstä on ETL-työtä, joka johtuu siitä että lähes kaiken joutuu tekemään käsin. Toki Data Vault -kannan tapauksessa tuon työn osuutta on jo ainakin teoriassa ollut mahdollista pienentää ELT-töiden toisteisuuden ansiosta. Modernilla ELT-välineellä mekaanisen työn voi automatisoida, jolloin ELT-työn osuus projektin kokonaistyömäärästä tippuu helposti useamman kymmenen prosenttia, puhumattakaan ylläpito- ja jatkokehityskustannuksista.


Samaan aikaan myös projektityömenetelmät ovat kehittyneet ja nykyään ketterät menetelmät ovat onnistuneen projektin kulmakiviä. Sinänsä valitulla ketterällä menetelmällä ei ole merkitystä, kunhan ollaan ketteriä. Käytännössä otetaan riittävän pieniä toteutuskokonaisuuksia työn alle ja jos huomataan jonkin menneen pieleen, peruutetaan ja korjataan (Kuva 4). “Epäonnistu nopeasti” saattaa olla hyvinkin paikkaansa pitävä toteutusvaiheen yleisohje.


Kuva 4. Uuden sukupolven tietovaraston kehitysprosessi.

Miksi tietovarastot kannattaa suunnitella ja toteuttaa uuden sukupolven menetelmällä? Jos pitää valita yksi asia, niin se on läpimenoajat ja niiden nopeus. Tästä käytännön jatkokehitysesimerkki vastaavalla arkkitehtuurilla toteutetusta tietovarastosta:


Asiakkaan olemassa olevasta modernista tietovarastosta puuttui raportoinnin tarvitsemaa tietoa. Tieto oli olemassa tiedon lähteessä, joten tiedon saaminen raportointirajapintaan vaati tiedon haun lähdejärjestelmästä (olemassa olevasta rajapinnasta), viennin Data Vault -kantaan ja sieltä datamartiin.


Työvaiheet lyhyesti:

1. Uusien kenttien lisääminen lähdejärjestelmän rajapinnan hakuun

2. Kenttien mäppääminen olemassa olevaan loogiseen malliin

3. Staging arean ja Data Vaultin automaattinen generointi olemassa olevien Data Vault -konversiosääntöjen pohjalta

4. Tarvittavien muutosten lisääminen datamart -tauluihin ja ajoihin

5. Muutokset sisältävien ELT-ajojen testaus ja ajaminen, jotta tiedot saadaan raportoinnin nähtäville


Tähän meni kokonaisuudessaan työaikaa kaikkine huolimattomuusvirheineen ja niiden korjauksineen alle 2 tuntia, jonka jälkeen tieto oli raportointivälineen käytettävissä.


Käytännössä kaikki muutokset ja lisäykset tietovarastoon menevät samalla kaavalla kuin yllä olevassa esimerkissä. Arkkitehtuurista hyötyvät sekä tekniset henkilöt (manuaaliset työvaiheet minimoidaan ja testaamisen tarve vähenee) että organisaation johto ja muut tiedon hyödyntäjät (organisaation operatiivisten järjestelmien tuottama tieto saadaan nopeammin hyödynnettäväksi). Tämä johtaa vääjäämättä kustannussäästöihin pitkällä aikavälillä.

© Productivity Leap 2019

Privacy Policy

We're Social...
  • White Facebook Icon
  • White Twitter Icon
  • White LinkedIn Icon
  • White Instagram Icon
Contact Us
Logo.png