Data Vault – yleiskatsaus

Data Vault on innovatiivinen datan mallinnusmenetelmä suuren mittakaavan tietovarastointialustoille. Dan Linstedtin keksimä Data Vault on suunniteltu tuottamaan Enterprise Data Warehouse -tietovarasto ja samalla puuttumaan normalisoidun (3. normaalimuoto) ja dimensiomallinnusmenetelmien haittoihin. Siinä yhdistyvät Inmonin lähestymistavan keskitetty raakatietovarasto ja Kimballin inkrementaalisen rakentamisen edut.

Tässä artikkelissa tehdään yhteenveto 3NF- ja Dimensional Design -lähestymistapojen haittapuolista ja luetellaan Data Vault -lähestymistavan edut ja haitat. Lopuksi se sisältää linkkejä hyödylliseen taustalukemistoon ja pyrkii vastaamaan kysymykseen:

Käytänkö Data Vaultia tietovarastoprojektissani?

Minkä ongelman Data Vault pyrkii ratkaisemaan?

Ennen kuin tiivistämme yhteenvedon niistä haasteista, joihin Data Vault pyrkii vastaamaan, kannattaa pohtia vaihtoehtoisia tietomallinnuslähestymistapoja ja vastaavia tietoarkkitehtuureja. Alla olevassa kaaviossa on esitetty mahdollinen yritystietoarkkitehtuuri.

Yritystietovarasto

EDW-lähestymistavalla tiedot ladataan ohimenevään laskeutumisalueeseen, minkä jälkeen joukko ETL-prosesseja ladataan dataa 3. Normaalinmuotoiseen yritysdatan 3. muotoon. Tämän jälkeen tiedot poimitaan dimensiomuotoisiin tietomarketteihin analysointia ja raportointia varten.

Tämän lähestymistavan merkittävimpiä haittoja ovat:

1. Time to Market:
2. Monimutkaisuus ja osaaminen: Yrityksen tietovaraston on ensin integroitava tiedot kustakin lähdejärjestelmästä keskitettyyn tietovarastoon, ennen kuin ne ovat käytettävissä raportointia varten, mikä lisää aikaa ja vaivaa projektiin.
3. Monimutkaisuus ja osaaminen: Tietovarasto saattaa joutua integroimaan tietoja sadasta lähteestä, ja koko yrityksen laajuisen tietomallin suunnittelu tukemaan monimutkaista liiketoimintaympäristöä on merkittävä haaste, joka edellyttää erittäin taitavia tietomallinnusasiantuntijoita.
4. Joustavuuden puute: Kolmannen normaalimuodon malli pyrkii mallintamaan olemassa olevat tietosuhteet, mikä voi tuottaa suhteellisen joustamattoman ratkaisun, joka vaatii huomattavaa uudelleentyöstämistä, kun uusia lähteitä lisätään. Vielä pahempaa on, että yli-innokkaat tietomallinnusasiantuntijat yrittävät usein ratkaista tämän ongelman tuottamalla liian monimutkaisia geneerisiä malleja, joita on lähes mahdoton ymmärtää.

Dimensionaalisen suunnittelun lähestymistapa

Oheinen kaavio havainnollistaa klassisen dimensional data warehouse -suunnittelun potentiaalista tietoarkkitehtuuria.

Oheinen lähestymistapa luopuu EDW:stä, jotta loppukäyttäjille voidaan toimittaa nopeasti tuloksia. Käytin tätä tekniikkaa vuonna 2008 lontoolaisessa ykkösluokan investointipankissa toimittaakseni luottoriskin arviointeja yrityskäyttäjille muutamassa viikossa projektin aloittamisesta. Jos olisimme odottaneet perinteisen tietovaraston rakentamista, olisimme menneet konkurssiin ennen kuin olisimme toimittaneet mitään käyttökelpoista.

Aluksi liiketoimintakäyttäjät olivat innoissaan toimituksen nopeudesta, mutta ajan mittaan löysimme kuitenkin monia haasteita, joiden käsitteleminen kävi yhä hankalammaksi. Näitä olivat:

1. Koodin lisääntyvä monimutkaisuus: ETL-koodi (Extract, Transform, and Load) oli muuttumassa niin monimutkaiseksi, ettei se ollut enää hallittavissa. ETL-työkalun (Informatica) korvaaminen Oraclen skripteillä auttoi (koska yksinkertaistimme ratkaisua edetessämme), mutta se ei ollut ongelman ydin. Yritimme jäsentää saapuvat tiedot uudelleen, deduplikoida, puhdistaa ja mukauttaa tiedot sekä soveltaa ajan myötä muuttuvia liiketoimintasääntöjä. Kaikkien näiden vaiheiden toteuttaminen yhdessä koodipohjassa oli todella vaikeaa.

2. Raakadatan puute: Koska laskeutumisalue oli puhtaasti väliaikainen (se poistettiin ja ladattiin joka kerta uudelleen), meillä ei ollut historiatietoja raakatiedoista. Tämä vaikeutti analyytikoiden mahdollisuuksia löytää arvokkaita uusia datasuhteita, ja (ennen kaikkea) raakadataa tarvitsevan Data Sciencen kasvava merkitys yksinkertaisesti sivuutettiin.

3. Historian hallinta: Koska meillä ei ollut raakadatahistoriaa ja latasimme vain analyysin kannalta tarpeelliset attribuutit, lisätietosyötteiden back-populaatio kävi vaikeaksi.

4. Lineage oli haastavaa: Koska sekä tekninen että liiketoimintalogiikka oli toteutettu lähdekoodin alati kasvavissa sedimenttikerroksissa, oli lähes mahdotonta jäljittää tietoelementin linjaa raportista takaisin lähdejärjestelmään.

Liiketoiminta rakasti toimituksen alkuperäistä nopeutta. Ajan mittaan tahtia oli kuitenkin yhä vaikeampi ylläpitää, kun ratkaisusta tuli yhä monimutkaisempi ja liiketoimintasäännöt muuttuivat ajan mittaan.

Data Vault -arkkitehtuuri

Alla olevassa kaaviossa on esitetty Data Vault -menetelmän käyttämä mahdollinen tietoarkkitehtuuri.

Näyttää ensi silmäyksellä hyvin samankaltaiselta kuin edellä esitetty Enterprise Data Warehouse -arkkitehtuuri, mutta siinä on kuitenkin muutamia merkittäviä eroja ja yhtäläisyyksiä, joita ovat muun muassa seuraavat:

• Tietojen lataaminen: Kun tiedot ladataan laskeutumisalueelta raakadataholviin, prosessi on puhtaasti tietojen muodon (pikemminkin kuin sisällön) uudelleenjärjestelyä. Lähdetietoja ei puhdisteta eikä muuteta, ja ne voidaan täysin rekonstruoida ilman ongelmia.
• Vastuunjako: Raakaholvissa säilytetään muuttamattomat raakadatat, ja ainoa käsittely on täysin teknistä, tietojen fyysistä uudelleenjärjestelyä. Liiketoimintasäännöt toimittavat lisätaulukoita ja -rivejä, joilla laajennetaan raakaholvia liiketoimintaholvilla. Tämä tarkoittaa, että liiketoimintasäännöt sekä johdetaan raakadatasta että tallennetaan siitä erillään. Tämä vastuun erottaminen helpottaa liiketoimintasääntömuutosten hallintaa ajan myötä ja vähentää järjestelmän kokonaiskompleksisuutta.
• Liiketoimintasäännöt: Liiketoimintasääntöjen tulokset, mukaan lukien deduplikointi, mukautetut tulokset ja jopa laskelmat, tallennetaan keskitetysti Business Holviin. Näin vältytään päällekkäisiltä laskennoilta ja mahdollisilta epäjohdonmukaisuuksilta, kun tuloksia lasketaan kahdelle tai useammalle tietomarkille.
• Tietomarkit: Toisin kuin Kimball-menetelmässä, jossa lasketut tulokset tallennetaan Data Martsin Fact- ja Dimension-taulukoihin, Data Vault -lähestymistapaa käytettäessä Data Marts ovat usein lyhytaikaisia, ja ne voidaan toteuttaa näkyminä suoraan Business- ja Raw Vaultin yli. Näin niitä on helpompi muokata ajan mittaan ja vältetään epäjohdonmukaisten tulosten riski. Jos näkymät eivät tarjoa tarvittavaa suorituskykyä, on olemassa mahdollisuus tallentaa tulokset taulukkoon.

Dataholvin edut

Dataholvissa ratkaistaan sekä 3. normaalimuodon yritystietovarastoon että dimensiosuunnitteluun perustuvaan lähestymistapaan liittyvät ongelmat yhdistämällä molempien parhaat puolet yhdeksi hybridi-lähestymistavaksi. Etuja ovat:

1. Inkrementaalinen toimitus: Vaikka on järkevää rakentaa mikä tahansa tietovarasto yrityksen kokonaismallin puitteissa, Data Vault tukee täysin inkrementaalista toimitusta. Aivan kuten Kimballin Dimensional Design -lähestymistavassa, voit aloittaa pienestä ja lisätä lisälähteitä asteittain ajan myötä.

2. Joustavuus: Toisin kuin 3rd Normal Form -mallinnusmenetelmä, joka voi olla joustamaton, Data Vault ei vaadi uudelleentyöstämistä lisälähteitä lisättäessä. Koska Data Vault tallentaa raakadatan ja liiketoiminnasta johdetun tiedon erikseen, se tukee helposti liiketoimintasääntöihin tehtäviä muutoksia.

3. Vähennetty monimutkaisuus: Koska Data Vault on rakennettu kaksivaiheisesti, se erottaa teknisen tietojen uudelleenjärjestelyn liiketoimintasääntöjen soveltamisesta, mikä auttaa eristämään nämä mahdollisesti monimutkaiset vaiheet. Samoin tietojen puhdistus katsotaan liiketoimintasäännöksi, ja sitä voidaan hallita alkuperäisestä tietojen lataamisesta riippumatta.

4. Raakatiedot mukana: Raakadatan tallentaminen Data Vaultiin tarkoittaa, että esitysalue on mahdollista täyttää uudelleen historiallisilla attribuuteilla, joita ei alun perin asetettu saataville. Jos Data Marts on toteutettu näkyminä, tämä voi olla niinkin yksinkertaista kuin lisäsarakkeen lisääminen olemassa olevaan näkymään.

5. Tukee tyylikkäästi ajan myötä tapahtuvaa muutosta: Samoin kuin Kimballin lähestymistavan hitaasti muuttuva ulottuvuus, Data Vault tukee tyylikkäästi ajan myötä tapahtuvia muutoksia. Toisin kuin puhdas dimensiosuunnittelu, Data Vault kuitenkin erottaa raakadatan ja liiketoiminnasta johdetun tiedon toisistaan ja tukee sekä lähdejärjestelmästä että liiketoimintasäännöistä johtuvia muutoksia.

6. Linjaus ja tarkastus: Koska Data Vault sisältää lähdejärjestelmät yksilöivää metatietoa, se helpottaa tietojen linjaston tukemista. Toisin kuin Dimensional Design -lähestymistavassa, jossa tiedot puhdistetaan ennen lataamista, Data Vaultin muutokset ovat aina inkrementaalisia, eivätkä tulokset koskaan häviä, mikä tarjoaa automaattisen kirjausketjun.

7. Suorituskykyiset rinnakkaiset lataukset: Hash Keysin käyttöönoton myötä Data Vault 2.0:ssa datan latausriippuvuudet poistuvat, mikä tarkoittaa, että lähes reaaliaikainen datan lataaminen on mahdollista teratavuista petatavuihin ulottuvien datamäärien rinnakkaisten latausten lisäksi.

8. Mahdollista automatisoida: Vaikka sekä Entity Relationship Modelling että Dimensional Design vaativat aikaa ja kokemusta taitojen kehittämiseen, Data Vault on yleensä helpompi automatisoida, ja on olemassa useita työkaluja (lueteltu alla), jotka auttavat ratkaisun toteuttamisessa.

Data Vaultin haitat

Data Vault ei ole täydellinen yhden koon ratkaisu jokaiseen tietovarastoon, ja sillä on muutamia haittoja, jotka on otettava huomioon. Näitä ovat:

1. Oppimiskäyrä: Aivan samalla tavalla kuin 3. normaalimuoto, entiteettisuhteiden mallintaminen ja dimensiosuunnittelu ovat erityisiä taitoja, joiden hallitseminen vie aikaa, myös Data Vaultissa on oppimiskäyrä. Tietovaraston muutosprojektiin liittyy merkittäviä riskejä, ja Data Vaultin lisääminen voi lisätä riskiä, varsinkin jos tiimillä ei ole kokemusta Data Vaultista. Varmista, että sinulla on asiantuntijoiden neuvoja ja tukea avainhenkilöiden koulutuksen lisäksi.

2. Paljon Joineja: Huonosti suunniteltu Data Vault -suunnittelu tuottaa valtavan määrän lähdejärjestelmän johdettuja tauluja, mutta jopa hyvin suunniteltu ratkaisu moninkertaistaa lähdetaulujen lukumäärän 2 tai 3-kertaiseksi. Taulukoiden ja siten myös liitosten määrä voi vaikuttaa hankalalta ja johtaa monimutkaisiin liitosehtoihin. Tämä voidaan kuitenkin ratkaista Business Vaultin siltataulujen oikealla käytöllä, ja kuten minkä tahansa ratkaisun kohdalla, kyse on näennäisen monimutkaisuuden ja joustavuuden välisestä kompromissista.

Missä Data Vaultia kannattaa käyttää?

Data Vault vaatii jonkin verran kurinalaisuutta hyvän suunnittelun toteuttamisessa ja Data Vault 2.0 -periaatteiden noudattamisessa. Kuten Enterprise Data Warehouse, se on suunniteltu integroimaan tietoja useista tietolähteistä, joten se voi olla joissakin tilanteissa liikaa.

Yhteenvetona voidaan todeta, että jos sinulla on pieni tai keskisuuri analytiikkavaatimus ja pieni (alle 10 hengen) arkkitehti-, suunnittelija- ja insinööritiimi, joka tuottaa ratkaisun muutamasta järjestelmästä hankituilla tiedoilla, Data Vault saattaa olla tarpeisiisi sopimaton.

Jos sinulla on kuitenkin suuri projekti, jossa on 30 tai enemmän lähdejärjestelmiä, jotka johtavat valtavaan dataintegraatiohaasteeseen, ja olet valmis ottamaan käyttöön uuden menetelmän taidot ja tiukkuuden, Data Vault voi mahdollisesti tuoda valtavasti lisäarvoa projektiin.

Muut resurssit ja työkalut

Seuraavat resurssit voivat auttaa Data Vault -menetelmän arvioinnissa ja ymmärtämisessä:

• Kent Grazianolla (sertifioitu Data Vault -mestari) on lukemisen arvoinen yhteenveto Data Vaultista.
• Genesee Academy (koulutus) tarjoaa hyvän johdannon Data Vault -menetelmän pääperiaatteisiin.
• UK Consultancy Data Vault Provide a informative summary of Frequently Asked Questions that address many of the immediate concerns.
• Dan Linstedtillä on valtava määrä perusteellisia artikkeleita Data Vaultin yksityiskohdista.
• Building a Scalable Data Warehouse with Data Vault 2.0 – on Dan Linstedtin referenssikirja.
• Elefantti jääkaapissa – on helppokäyttöinen johdanto Data Vaultista.

Vaikka näitä ei pidä missään nimessä pitää suosituksena, tässä on lyhyt lista työkaluista, joiden avulla Data Vaultin toimittamista voidaan automatisoida.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – Kevyt avoimeen lähdekoodiin perustuva automaatiokehys

Johtopäätökset

Kun on-premise-tietovarastoprojekteja siirretään pilvipalveluihin, yhä useammat yritykset miettivät uudelleen tietovaraston arkkitehtuuria. Siirtyminen useista itsenäisistä paikallisista datasiiloista nykyaikaiseen pilvipohjaiseen ratkaisuun on ainutkertainen tilaisuus integroida koko yrityksen tiedot yhdeksi yhtenäiseksi tietovarastoksi.

Jos edessäsi on juuri tämä haaste, Data Vault voi hyvinkin auttaa ratkaisun löytämisessä.

Jos löysit tämän artikkelin hyödylliseksi, saatat olla kiinnostunut henkilökohtaisesta blogisivustostani (jossa ei ole lainkaan mainontaa) osoitteessa www.Analytics.Today.

Disclaimer: Artikkeleissani ilmaistut mielipiteet ovat omiani eivätkä välttämättä vastaa työnantajani (entisen tai nykyisen) tai minkään sellaisen asiakkaan mielipiteitä, jonka kanssa olen työskennellyt.