Data Vault – en översikt

Angreppssättet ovan gör det möjligt att avstå från EDW för att snabbt kunna leverera resultat till slutanvändarna. Jag använde den här tekniken 2008 på en Londonbaserad tier one Investmentbank för att tillhandahålla kreditriskbedömningar till affärsanvändare inom några veckor efter det att projektet påbörjats. Om vi hade väntat med att bygga ett traditionellt datalager skulle vi ha gått i konkurs innan vi hade levererat något användbart.

Inledningsvis var affärsanvändarna glada över den snabba leveransen, men med tiden fann vi många utmaningar som blev alltmer smärtsamma att hantera. Dessa omfattade:

1. Ökande komplexitet i koden: ETL-koden (Extract, Transform och Load) blev så komplicerad att den inte längre gick att hantera. Att ersätta ETL-verktyget (Informatica) med Oracle-skript hjälpte (eftersom vi förenklade lösningen allt eftersom), men det var inte roten till problemet. Vi försökte omstrukturera de inkommande uppgifterna, avdubbla, rensa och anpassa uppgifterna och tillämpa ändrade affärsregler över tiden. Att göra alla dessa steg i en enda kodbas var verkligen mycket svårt.

2. Brist på rådata: Eftersom landningsområdet var rent övergående (raderas och laddas om varje gång) hade vi inga historiska uppgifter om rådata. Detta gjorde det svårt för analytiker att upptäcka nya värdefulla datarelationer, och den ökande betydelsen av datavetenskap, som (framför allt) behöver rådata, ignorerades helt enkelt.

3. Hantering av historik: Eftersom vi inte hade någon historik över rådata och endast laddade de attribut som behövdes för analysen, blev det svårt att back-populera ytterligare dataflöden.

4. Linjering var en utmaning: Eftersom både den tekniska logiken och affärslogiken implementerades i allt större lager av källkod var det nästan omöjligt att spåra ett dataelement från rapporten tillbaka till källsystemet.

Företaget älskade den initiala leveranshastigheten. Men med tiden blev det allt svårare att hålla tempot eftersom lösningen blev alltmer komplex och affärsreglerna ändrades med tiden.

Data Vault-arkitektur

Diagrammet nedan visar en potentiell dataarkitektur som används av Data Vault-metodiken.

Och även om den vid första anblicken ser mycket likadan ut som Enterprise Data Warehouse-arkitekturen ovan, så finns det några betydande skillnader och likheter, bland annat följande:

• Data Loading: När data laddas från landningsområdet till Raw Data Vault är processen enbart en omstrukturering av dataformatet (snarare än datainnehållet). Källdata är varken rensade eller modifierade och skulle kunna rekonstrueras helt och hållet utan problem.
• Ansvarsfördelning: I Raw Vault finns de oförändrade rådata, och den enda bearbetningen är helt och hållet teknisk, för att fysiskt omstrukturera data. Affärsreglerna ger ytterligare tabeller och rader för att utöka Raw Vault med ett Business Vault. Detta innebär att affärsreglerna både härrör från och lagras separat från rådata. Denna åtskillnad av ansvar gör det lättare att hantera ändringar av affärsregler över tiden och minskar den totala systemkomplexiteten.
• Affärsregler: Resultaten av affärsreglerna, inklusive deduplicering, överensstämmande resultat och till och med beräkningar, lagras centralt i Business Vault. Detta hjälper till att undvika dubbla beräkningar och potentiella inkonsekvenser när resultaten beräknas för två eller flera datamarkörer.
• Datamarkörer: Till skillnad från Kimball-metoden där de beräknade resultaten lagras i Fact- och Dimension-tabeller i datamartserna, är datamartserna med Data Vault-metoden ofta flyktiga och kan implementeras som vyer direkt över Business Vault och Raw Vault. Detta innebär att de både är lättare att ändra med tiden och att man undviker risken för inkonsekventa resultat. Om vyer inte ger den nödvändiga prestandanivån finns alternativet att lagra resultaten i en tabell.

The Data Vault Advantages

Data Vault tar itu med de svårigheter som är inneboende i både 3rd Normal Form Enterprise Data Warehouse och Dimensional Design approach genom att kombinera de bästa aspekterna av båda i en enda hybridmetod. Fördelarna omfattar:

1. Stegvis leverans: Det är förnuftigt att bygga ett datalager inom ramen för en övergripande företagsmodell, men Data Vault stöder helt och hållet stegvis leverans. Precis som i Kimballs dimensionella designmetod kan du börja i liten skala och successivt lägga till ytterligare källor med tiden.

2. Flexibilitet: Till skillnad från modelleringsmetoden 3rd Normal Form, som kan vara oflexibel, kräver Data Vault ingen omarbetning när ytterligare källor läggs till. Eftersom Data Vault lagrar rådata och affärsdata separat stöder den enkelt ändringar av affärsregler.

3. Minskad komplexitet: Eftersom Data Vault byggs upp i två steg separeras den tekniska dataomstruktureringen från tillämpningen av affärsregler, vilket bidrar till att isolera dessa potentiellt komplexa steg. På samma sätt betraktas datarengöring som en affärsregel och kan hanteras oberoende av den första dataladdningen.

4. Rådata ingår: Att registrera rådata i Data Vault innebär att det är möjligt att fylla presentationsområdet med historiska attribut som ursprungligen inte var tillgängliga. Om Data Marts implementeras som vyer kan detta vara så enkelt som att lägga till en extra kolumn i en befintlig vy.

5. Elegant stöd för förändringar över tid: I likhet med den långsamt föränderliga dimensionen i Kimball-metoden stöder Data Vault på ett elegant sätt förändringar över tiden. Till skillnad från den renodlade dimensionella designen skiljer Data Vault dock på rådata och affärsdata och stöder ändringar som beror på både källsystemet och affärsreglerna: Eftersom Data Vault innehåller metadata som identifierar källsystemen blir det lättare att stödja datalinjering. Till skillnad från dimensionell design, där data rensas innan de laddas, är Data Vault-ändringar alltid inkrementella och resultaten går aldrig förlorade, vilket ger en automatisk verifieringskedja.

7. Högpresterande parallella laddningar: Med införandet av hashnycklar i Data Vault 2.0 elimineras beroenden av dataladdning, vilket innebär att dataladdning nästan i realtid är möjlig förutom parallellladdning av terabyte till petabyte av data.

8. Möjligt att automatisera: Medan både Entity Relationship Modelling och Dimensional Design kräver tid och erfarenhet för att bygga upp färdigheter, tenderar Data Vault att vara lättare att automatisera, och det finns flera verktyg (listade nedan) för att hjälpa till att leverera lösningen.

Data Vaults nackdelar

Data Vault är inte den perfekta lösningen som passar alla datalager, och den har några nackdelar som måste beaktas. Dessa inkluderar:

1. Inlärningskurvan: På samma sätt som 3rd Normal Form, Entity Relationship Modelling och Dimensional Design är specifika färdigheter som det tar tid att behärska, finns det en inlärningskurva för Data Vault. Att inleda ett projekt för omvandling av ett datalager är förenat med betydande risker, och att lägga till Data Vault kan öka risken, särskilt om teamet saknar erfarenhet av Data Vault. Se till att du har expertråd och stöd utöver utbildning för nyckelpersoner.

2. Massor av Joins: En dåligt utformad Data Vault-konstruktion kommer att ge upphov till ett stort antal härledda tabeller i källsystemet, men även en väl utformad lösning multiplicerar antalet källtabeller med en faktor 2 eller 3. Antalet tabeller och därmed även antalet sammanfogningar kan verka oöverskådligt och leda till komplexa sammanfogningsvillkor. Detta kan dock åtgärdas med rätt användning av bryggtabeller i Business Vault, och som med alla lösningar är det en avvägning mellan skenbar komplexitet och flexibilitet.

Var ska man använda Data Vault?

Data Vault kräver en viss rigorositet när det gäller att leverera en bra design och hålla sig till Data Vault 2.0-principerna. Liksom Enterprise Data Warehouse är den utformad för att integrera data från flera datakällor och kan därför vara överdriven i vissa situationer.

Sammanfattningsvis kan Data Vault vara olämplig för dina behov om du har ett litet till medelstort analyskrav, med ett litet (mindre än 10) team av arkitekter, konstruktörer och ingenjörer som levererar en lösning med data som kommer från ett fåtal system.

Om du däremot har ett stort projekt med 30 eller fler källsystem som leder till en enorm utmaning i fråga om dataintegration och är beredd att ta på dig de färdigheter och den stränghet som en ny metod innebär, kan Data Vault potentiellt tillföra ett enormt värde till projektet.

Andra resurser och verktyg

Följande resurser kan hjälpa till att utvärdera och förstå Data Vault-metoden:

• Kent Graziano (certifierad Data Vault Master) har en sammanfattning av Data Vault som är värd att läsa.
• The Genesee Academy (Training) ger en bra introduktion till huvudprinciperna i Data Vault.
• UK Consultancy Data Vault tillhandahåller en informativ sammanfattning av Frequently Asked Questions som tar upp många av de omedelbara frågorna.
• Dan Linstedt har ett stort antal djupgående artiklar om detaljerna kring Data Vault.
• Building a Scalable Data Warehouse with Data Vault 2.0 – är Dan Linstedts referensbok.
• The Elephant in the Fridge – är en lättillgänglig introduktion till Data Vault.

Och även om dessa inte på något sätt bör betraktas som en rekommendation, finns här en kort lista över verktyg som kan hjälpa till att automatisera leveransen av Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – ett lättviktigt ramverk för automatisering med öppen källkod

Slutsats

I takt med att datalagringsprojekt på plats flyttas till molnet, …omprövar ett ökande antal företag hur datalagret är uppbyggt. Flytten från flera oberoende datasilos på plats till en modern molnbaserad lösning är en unik möjlighet att integrera data från hela företaget i ett enda, konsekvent arkiv.

Om det är den utmaningen du står inför kan Data Vault mycket väl bidra till att leverera lösningen.

Om du tyckte att den här artikeln var till hjälp kan du vara intresserad av min personliga bloggsida (helt utan reklam), på www.Analytics.Today.

Disclaimer: De åsikter som uttrycks i mina artiklar är mina egna och återspeglar inte nödvändigtvis åsikterna hos min arbetsgivare (tidigare eller nuvarande) eller hos någon kund som jag har arbetat med.