Data Vault – en oversigt
Data Vault er en innovativ datamodelleringsmetode til store datawarehouse-platforme. Data Vault er opfundet af Dan Linstedt og er designet til at levere et Enterprise Data Warehouse, samtidig med at ulemperne ved de normaliserede (3. normalform) og dimensionelle modelleringsteknikker håndteres. Den kombinerer det centraliserede rådataregister i Inmon-tilgangen med de inkrementelle opbygningsfordele i Kimball.
Denne artikel opsummerer ulemperne ved 3NF- og Dimensional Design-tilgangen og opregner fordele og ulemper ved Data Vault-tilgangen. Endelig indeholder den links til noget nyttig baggrundslæsning og har til formål at besvare spørgsmålet:
Bør jeg bruge Data Vault på mit Data Warehouse-projekt?
Hvilket problem forsøger Data Vault at løse?
Hvor vi opsummerer de udfordringer, som Data Vault forsøger at løse, er det værd at overveje den alternative datamodelleringstilgang og de tilsvarende dataarkitekturer. Nedenstående diagram viser en potentiel Enterprise Data Architecture.
Enterprise Data Warehouse
Med EDW-tilgangen indlæses data i et transient Landing Area, hvorefter der anvendes en række ETL-processer til at indlæse data i et 3rd Normal form enterprise data warehouse. Dataene udtrækkes efterfølgende i dimensionelle datamarts til analyse og rapportering.
De væsentligste ulemper ved denne tilgang omfatter:
- Time to Market: Enterprise Data Warehouse skal først integrere data fra hvert af kildesystemerne i et centralt dataregister, før de er tilgængelige til rapportering, hvilket øger projektets tid og indsats.
- Kompleksitet og færdigheder: Et datawarehouse skal måske integrere data fra hundrede kilder, og design af en virksomhedsdækkende datamodel til understøttelse af et komplekst forretningsmiljø er en betydelig udfordring, der kræver højt kvalificerede datamodelleringseksperter.
- Manglende fleksibilitet: En tredje normalformsmodel har en tendens til at modellere de eksisterende datarelationer, hvilket kan give en relativt ufleksibel løsning, der kræver betydelig omarbejdning, når der tilføjes yderligere kilder. Endnu værre er det, at overivrige datamodelleringseksperter ofte forsøger at overvinde dette ved at levere overkomplekse generiske modeller, som er næsten umulige at forstå.
Dimensionel designtilgang
Diagrammet nedenfor illustrerer en potentiel dataarkitektur for et klassisk dimensionelt datawarehouse-design.
Overstående tilgang gør det muligt at undvære EDW’et for hurtigt at levere resultater til slutbrugerne. Jeg brugte denne teknik i 2008 i en tier one-investeringsbank i London til at levere kreditrisikovurderinger til forretningsbrugere inden for få uger efter projektets start. Hvis vi havde ventet med at bygge et traditionelt datawarehouse, ville vi være gået konkurs, før vi havde leveret noget brugbart.
I første omgang var forretningsbrugerne begejstrede for leveringshastigheden; med tiden fandt vi imidlertid mange udfordringer, som blev stadig mere smertefulde at håndtere. Disse omfattede:
1. Stigende kompleksitet af koden: ETL-koden (Extract, Transform og Load) var ved at blive så kompliceret, at den ikke længere var til at håndtere. Det hjalp at erstatte ETL-værktøjet (Informatica) med Oracle-scripts, (da vi forenklede løsningen undervejs), men det var ikke roden til problemet. Vi forsøgte at omstrukturere de indkomne data, afduplicere, rense og tilpasse dataene og anvende ændrede forretningsregler over tid. Det var meget vanskeligt at udføre alle disse trin i en enkelt kodebase.
2. Mangel på rådata: Da landingsområdet var rent forbigående (slettes og genindlæses hver gang), havde vi ingen historiske optegnelser af rådata. Dette gjorde det vanskeligt for analytikere at opdage værdifulde nye datarelationer, og den stigende betydning af Data Science, som (først og fremmest) har brug for rådata, blev simpelthen ignoreret.
3. Håndtering af historik: Da vi ikke havde nogen historik for rådata og kun indlæste de attributter, der var nødvendige for analysen, blev det vanskeligt at back-populere yderligere datafeeds.
4. Lineage var en udfordring: Da både den tekniske logik og forretningslogikken blev implementeret i stadigt stigende sedimentære lag af kildekode, var det næsten umuligt at spore et dataelement fra rapporten tilbage til kildesystemet.
Forretningen var vild med den indledende leveringshastighed. Men efterhånden som tiden gik, blev det stadig sværere at opretholde tempoet, da løsningen blev mere og mere kompleks, og forretningsreglerne ændrede sig med tiden.
Data Vault-arkitektur
Diagrammet nedenfor viser en potentiel dataarkitektur, der anvendes af Data Vault-metodologien.
Mens den ved første øjekast ligner Enterprise Data Warehouse-arkitekturen ovenfor meget, har den nogle få væsentlige forskelle og ligheder, som omfatter:
- Data Loading: Når dataene indlæses fra landingsområdet til Raw Data Vault, er processen udelukkende en omstrukturering af dataenes format (snarere end deres indhold). Kildedataene er hverken renset eller ændret og kan uden problemer rekonstrueres fuldstændigt.
- Adskillelse af ansvarsområder: Råboksen indeholder de uændrede rådata, og den eneste behandling er udelukkende teknisk med henblik på fysisk omstrukturering af dataene. Forretningsreglerne leverer yderligere tabeller og rækker for at udvide den rå boks med en forretningsboks. Det betyder, at forretningsreglerne både er afledt af og opbevares separat fra de rå data. Denne adskillelse af ansvaret gør det lettere at administrere ændringer af forretningsregler over tid og reducerer den samlede systemkompleksitet.
- Forretningsregler: Resultaterne af forretningsreglerne, herunder deduplikation, konforme resultater og endda beregninger, gemmes centralt i Business Vault. Dette hjælper med at undgå dobbeltberegning og potentielle uoverensstemmelser, når resultaterne beregnes for to eller flere datamarts.
- Data Marts: I modsætning til Kimball-metoden, hvor de beregnede resultater gemmes i fakta- og dimensionstabeller i datamarkederne, er datamarkederne med Data Vault-metoden ofte flygtige, og de kan implementeres som visninger direkte over Business Vault og Raw Vault. Det betyder, at de både er nemmere at ændre over tid, og at man undgår risikoen for inkonsistente resultater. Hvis visninger ikke giver den nødvendige ydeevne, er der mulighed for at gemme resultaterne i en tabel.
Data Vault Fordele
Data Vault løser de vanskeligheder, der er forbundet med både 3rd Normal Form Enterprise Data Warehouse og den dimensionelle designtilgang, ved at kombinere de bedste aspekter af begge i en enkelt hybridtilgang. Fordelene omfatter:
1. Trinvis levering: Selv om det er fornuftigt at opbygge ethvert Data Warehouse inden for rammerne af en overordnet virksomhedsmodel, understøtter Data Vault fuldstændig inkrementel levering. Ligesom Kimballs tilgang til dimensionelt design kan du starte småt og gradvist tilføje yderligere kilder over tid.
2. Fleksibilitet: I modsætning til 3rd Normal Form-modelleringsmetoden, som kan være ufleksibel, kræver Data Vault ingen omarbejdning, når der tilføjes yderligere kilder. Da Data Vault gemmer de rå og forretningsafledte data separat, understøtter den nemt ændringer i forretningsreglerne.
3. Reduceret kompleksitet: Da Data Vault er opbygget i en totrinstilgang, adskiller den den tekniske datarestrukturering fra anvendelsen af forretningsregler, hvilket hjælper med at isolere disse potentielt komplekse faser. På samme måde betragtes datarengøring som en forretningsregel og kan administreres uafhængigt af den indledende dataindlæsningsindsats.
4. Rå data medtaget: Registrering af de rå data i Data Vault betyder, at det er muligt at back-populere præsentationsområdet med historiske attributter, som ikke oprindeligt blev gjort tilgængelige. Hvis Data Marts er implementeret som visninger, kan dette være så simpelt som at tilføje en ekstra kolonne til en eksisterende visning.
5. Understøtter på elegant vis ændringer over tid: I lighed med den langsomt skiftende dimension i Kimball-metoden understøtter Data Vault på elegant vis ændringer over tid. I modsætning til det rene dimensionelle design adskiller Data Vault imidlertid de rå og forretningsafledte data og understøtter ændringer som følge af både kildesystemet og forretningsreglerne.
6. Lineage og revision: Da Data Vault indeholder metadata, der identificerer kildesystemerne, gør det det lettere at understøtte datalinje. I modsætning til Dimensional Design-tilgangen, hvor data renses før indlæsning, er Data Vault-ændringer altid inkrementelle, og resultaterne går aldrig tabt, hvilket giver et automatisk revisionsspor.
7. Parallelle indlæsninger med høj ydeevne: Med indførelsen af Hash Keys i Data Vault 2.0 er dataindlæsningsafhængigheder elimineret, hvilket betyder, at dataindlæsning næsten i realtid er mulig ud over parallelindlæsning af terabytes til petabytes af data.
8. Muligt at automatisere: Mens både Entity Relationship Modelling og Dimensional Design kræver tid og erfaring for at opbygge færdigheder, har Data Vault tendens til at være lettere at automatisere, og der er flere værktøjer (anført nedenfor) til at hjælpe med at levere løsningen.
Ulemperne ved Data Vault
Data Vault er ikke den perfekte one size fits all-løsning til ethvert datawarehouse, og den har et par ulemper, der skal tages i betragtning. Disse omfatter:
1. Indlæringskurven: På nøjagtig samme måde som 3rd Normal Form, Entity Relationship Modelling og Dimensional Design er specifikke færdigheder, som det tager tid at mestre, er der en indlæringskurve med Data Vault. Det er forbundet med betydelige risici at gå i gang med et projekt til transformation af et Data Warehouse, og tilføjelsen af Data Vault kan øge risikoen, især hvis teamet ikke har erfaring med Data Vault. Sørg for, at du har ekspertrådgivning og -support ud over uddannelse af nøglepersoner.
2. Masser af Joins: Et dårligt designet Data Vault-design vil producere et massivt antal afledte tabeller i kildesystemet, men selv en godt designet løsning multiplicerer antallet af kildetabeller med en faktor 2 eller 3. Antallet af tabeller og dermed også antallet af joints kan virke uoverskueligt og føre til komplekse joinbetingelser. Dette kan dog løses med korrekt brug af brotabeller i Business Vault, og som med enhver løsning er det en afvejning af tilsyneladende kompleksitet og fleksibilitet.
Hvor skal Data Vault bruges?
Data Vault kræver en vis stringens i forhold til at levere et godt design og holde sig til Data Vault 2.0-principperne. Ligesom Enterprise Data Warehouse er det designet til at integrere data fra flere datakilder og kan derfor være overkill i nogle situationer.
Sammenfattende kan Data Vault være uegnet til dine behov, hvis du har et lille til mellemstort analysebehov med et lille (under 10) team af arkitekter, designere og ingeniører, der leverer en løsning med data, der stammer fra få systemer.
Hvis du derimod har et stort projekt med 30 eller flere kildesystemer, der fører til en enorm udfordring med dataintegration, og hvis du er parat til at påtage dig de færdigheder og den strenghed, der følger af en ny metodologi, så kan Data Vault potentielt tilføre projektet en massiv værdi.
Andre ressourcer og værktøjer
Følgende ressourcer kan hjælpe med at evaluere og forstå Data Vault-metoden:
- Kent Graziano (certificeret Data Vault Master) har et læseværdigt resumé af Data Vault.
- The Genesee Academy (Training) giver en god introduktion til de vigtigste principper i Data Vault.
- UK Consultancy Data Vault giver et informativt resumé af Frequently Asked Questions, der tager fat på mange af de umiddelbare bekymringer.
- Dan Linstedt har et stort antal dybdegående artikler om detaljerne omkring Data Vault.
- Building a Scalable Data Warehouse with Data Vault 2.0 – er referencebogen af Dan Linstedt.
- The Elephant in the Fridge – er en lettilgængelig introduktion til Data Vault.
Og selv om disse ikke på nogen måde skal betragtes som en anbefaling, er her en kort liste over de værktøjer, der kan hjælpe med at automatisere leveringen af Data Vault.
- dbtvault
- Wherescape
- VaultSpeed
- Data Vault Builder
- Joyn – A lightweight open source automation framework
Konklusion
I takt med at on-premise data warehouse-projekter flyttes til skyen, er et stigende antal virksomheder ved at gentænke, hvordan datawarehouset er arkitektonisk opbygget. Flytningen fra flere uafhængige on-premise datasiloer til en moderne cloud-baseret løsning er en enestående mulighed for at integrere data fra hele virksomheden i et enkelt, konsistent lager.
Hvis det er den udfordring, du står over for, så kan Data Vault meget vel være med til at levere løsningen.
Hvis du fandt denne artikel nyttig, vil du måske være interesseret i mit personlige blogsite (absolut ingen reklamer), på www.Analytics.Today.
Disclaimer: De udtalelser, der kommer til udtryk i mine artikler, er mine egne og afspejler ikke nødvendigvis min arbejdsgivers (tidligere eller nuværende) eller nogen af de kunder, jeg har arbejdet med.
Leave a Reply