Tietovarastoarkkitehtuuri: Vertailussa Kimball, Inmon ja Data Vault 2.0 arkkitehtuurit

31.03.2021

Tietovarastoarkkitehtuuri: Vertailussa Kimball, Inmon ja Data Vault 2.0 arkkitehtuurit

Kuinka moni tietovarastoa työssään hyödyntävä tai siitä vastuussa oleva tietää, millä arkkitehtuuriperiaatteella kyseinen ratkaisu on toteutettu? Harva toimittaja on antanut asiakkaan tehdä tämän päätöksen tai edes kertonut vaihtoehdoista. Valitettavan usein tekninen ratkaisu jää asiakkaalta täysin pimentoon ja aikaa myöten tietovaraston ylläpitäminen ja sen jatkokehittäminen käy vaivalloiseksi ja hitaaksi tai jopa täysin mahdottomaksi.

Tämä johtuu yleensä useasta eri syystä, mutta useimmiten taustalta löytyy puuttuvat yhteisesti sovitut pelisäännöt (governance) arkkitehtuurin kehittämisestä sekä mahdollisesti kehittäjien vaihtuminen matkan varrella. Jokainen tekijä kutoo verkkonsa omalla parhaimmaksi katsomallaan ja osaamallaan tavalla. Lopputuloksena tästä syntyy arkkitehtuurisesti melkoisia katiskoja ja himmeleitä, joiden setvimiseen tarvitaan mieluummin kourallinen dynamiittia kuin kirurgin veistä.

Perinteiset arkkitehtuurit

Kimballin-ja-Inmonin-arkkitehtuurit
Kimballin-ja-Inmonin-arkkitehtuurit

Tietovarastojen mallinnuksessa on tyypillisesti käytetty joko Kimballin 2-kerros tai Inmonin 3-kerrosarkkitehtuuria. Kimballin arkkitehtuurissa raakadata kopioidaan ensin Staging alueelle, josta se sitten viedään tietovarastokerrokseen dimensiomallisiin Data Marteihin. Tämän arkkitehtuurin etu on sen keveys ja helppo rakentaminen verrattuna muihin arkkitehtuureihin, mutta haittapuolena on esimerkiksi toisen dimensiomallin rakentaminen samasta lähtödatasta, koska tiedot pitää uudelleen ladata Staging alueelta.

Data-Vault-arkkitehtuuri
Data-Vault-arkkitehtuuri

Inmon esitteli puolestaan kolmikerrosarkkitehtuurin, jossa Staging alue on samanlainen kuin Kimballin arkkitehtuurissa eli pitää sisällään kopion lähdejärjestelmän raakadatasta. Data Warehouse -kerros perustuu puolestaan lähdejärjestelmän tauluihin ja näiden päälle rakentuvat dimensionaaliset tietomallit – Data Martit. Tämän arkkitehtuurin merkittävin etu verrattuna Kimballiin on se, että Data Warehouse tasolla data on jo puhdistettua ja integroitua eikä tätä tarvitse tehdä enää rakennettaessa uusia Data Marteja raportointikäyttöön. Viime vuosien aikana erityisen suurta suosiota on saanut Data Vault 2.0 arkkitehtuuri, jossa myös on kolme loogista vaihetta ja kerrosta

Moderni arkkitehtuuri

Raakadata tuodaan ensin Staging alueelle, joka tyypillisesti jakaantuu kahteen: Tiedostopohjaiseen Data Lake ja relaatiomalliseen alueeseen. Varsinainen tietovarasto (EDW) rakennetaan Data Vault  mallinnusmenetelmällä ja tarkoituksena on säilöä kaikki historiadata raakamuodossaan.

Data Vaultissa tärkeä huomioitava seikka on se, että liiketoimintasäännöt, kuten datan puhdistaminen, suodatus ja rikastaminen tapahtuvat vasta tietovarastokerroksen jälkeen toteutettavissa Information (Data) Marteissa, joihin varsinaisilla raportointityövälineillä kytkeydytään. Tästä on se selkeä hyöty, että sääntöjen muuttuessa tai niitä lisättäessä, muutokset tehdään vain yhteen kerrokseen eikä sinne tänne koko tietovarastoarkkitehtuurissa. Myöskään tietoja ei tarvitse uudelleen ladata lähdejärjestelmistä saakka, mikä on yleisesti muiden arkkitehtuurien heikkous.  Lisäksi tietojen jäljitettävyys säilyy, koska EDW tasolla on aina raakadata, joka vastaa lähdejärjestelmissä syntyneitä tietoja.

Esimerkki Data Vault 2.0 kokonaisarkkitehtuurista
Esimerkki Data Vault 2.0 kokonaisarkkitehtuurista

Selkeitä hyötyjä, joita Data Vault arkkitehtuuri mahdollistaa ja jotka puuttuvat perinteisimmistä arkkitehtuureista (Kimball, Inmon) ovat:


Tuulta purjeisiin Bilot DW Core™ kiihdyttimellä
Lue lisää modernin pilvialustan toteuttamisesta.
Tuulta purjeisiin Bilot DW Core™ kiihdyttimellä
Tiedonhallinta ja analytiikka
Tutustu myös tiedonhallinta- ja analytiikkapalveluihimme.
Autamme yrityksiä tiekartan piirtämiseen ja toteuttamiseen kaikissa tilanteissa.

Share
Contact Person

Bloggaaja

Toni Haapakoski

Co-founder, Executive Advisor, Solution Owner