Data Vault: meer dan modellering | 42 Versions of the Truth

Over mij

Ik ben Lidwine van As, sinds 1994 werkzaam in de IT, en actief als zelfstandig consultant op gebied van informatiemanagement en -architectuur.
Op "42 versions" schrijf ik over onderwerpen in mijn vakgebied die mijn aandacht trekken.

Contact

Volg dit weblog via ...

Categorieën

Apr 21

Data Vault: meer dan modellering

in architectuur, datawarehousing

Momenteel ben ik betrokken bij een datawarehouseproject waarbij gewerkt wordt volgens de Data Vault methodiek. Hoewel bepaald nog geen gemeengoed in de datawarehouse community, krijgt Data Vault langzamerhand meer bekendheid; zo zijn er inmiddels diverse artikelen over het onderwerp verschenen in DB/M. Belangrijkste bron van informatie zijn de whitepapers van Dan Linstedt, de founding father van Data Vault.

Wat in die publicaties echter onderbelicht blijft, is dat Data Vault veel meer is dan “alleen maar” datamodellering. Het geeft je niet alleen een uitstekend gereedschap in handen om je centrale datawarehouse te modelleren: het is ook een architectonische visie op de rol van het data warehouse in de overall BI-omgeving.

Eigenlijk is het eigenaardig dat die andere kant van Data Vault tot dusver in het openbaar wat op de achtergrond is gebleven. Want juist die andere kant biedt een radicaal andere visie op datawarehousing dan momenteel gangbaar is - één die naar mijn mening een hoop meerwaarde voor het vakgebied zou kunnen bieden.
(”In het openbaar”, want de visie van Linstedt komt uitvoerig aan de orde tijdens de Data Vault certificatiecursus. Wie de cursus niet gevolgd heeft, moet het doen met Linstedts blog, waarin hij zijn kijk op de veranderende rol van het datawarehouse beschrijft.)

System of fact

In de Data Vault visie verschuift de rol van het datawarehouse van gegevensintegrator naar “system of record”, of, in de terminologie waar Linstedt de voorkeur aan geeft, “system of fact”. Uitgangspunt is dat alle data altijd geladen wordt: “100% of the data 100% of the time”. Er vindt geen cleansing plaats, geen uitval vanwege gebrekkige kwaliteit, geen toepassing van business rules, geen data-integratie.
(Overigens vindt wel datamodelintegratie plaats: d.w.z. entiteiten uit onderliggende bronsysteemmodellen worden tot één Data Vault entiteit samengevoegd als ze qua grain overeenkomen, maar er vindt geen inhoudelijke merge plaats).

De toepassing van business rules, en alle activiteiten ten behoeve van cleansing, merging en integratie van data worden in de Data Vault aanpak gepositioneerd tussen het datawarehouse en de datamarts. Argumentatie daarbij is dat de gebruikers uiteindelijk eigenaar zijn van de gegevens, niet IT; en dat het dus de gebruiker is die bepaalt hoe je van data informatie maakt, niet de IT-afdeling.
Op zichzelf is dat geen sterk argument: immers, ook als de gebruikers de regels bepalen, is het nog steeds prima denkbaar dat die regels direct al bij binnenkomst van de data worden toegepast. In het licht van de veranderlijkheid van requirements en business rules, is het echter wel verstandig om je bij het inrichten van je datawarehouse niet te laten leiden door het laatste inzicht van de gebruikers t.a.v. de relevante bedrijfsbegrippen: het datawarehouse is idealiter proces- en requirementsonafhankelijk. Linstedt bereikt dit door simpelweg de gegevens (de facts) vast te leggen zoals ze binnengekomen zijn, zonder al bij vastlegging een poging te doen tot interpretatie ervan; want die interpretatie is per definitie gedreven door de inzichten van vandaag, en daar wil je het system of record niet op inrichten.

Compliance

Deze tolerante, proces-agnostische houding ten opzichte van de binnengekomen data is volgens Linstedt onontbeerlijk, wil het datawarehouse compliance met initiatieven als Sarbanes-Oxley, Basel-II etc. kunnen ondersteunen. Dit vereist o.a. dat gerapporteerde gegevens auditable zijn; met andere woorden, van een gerapporteerd gegeven moet nagegaan kunnen worden, hoe het tot stand is gekomen. Bronsystemen houden zelf meestal geen historie bij, dus het datawarehouse is de enige historische opslagplaats voor alle brongegevens. Worden de gegevens bij binnenkomst bewerkt op basis van business rules, dan wordt de audit trail naar het oorspronkelijke brongegeven doorbroken. Compliance vereist dus vastlegging zonder interpretatie.

Parallelle werkelijkheden

Doordat de integratie van gegevens en de toepassing van business rules niet meer in het datawarehouse verankerd zijn, maar pas onderweg naar de datamarts plaatsvinden (áls dat al gebeurt), representeert het datawarehouse niet langer “one version of the truth”, maar eerder “one version of the facts”. Dat geeft ruimte om meerdere parallelle “versions of the truth” af te leiden, ieder geheel toegesneden op de wensen van zijn gebruikers. De Data Vault aanpak sluit daarmee aan bij de (steeds luider wordende) tegengeluiden tegen de heilige graal van de “single version of the truth”: het is bepaald geen sinecure om een single version of the truth neer te zetten, en bovendien is het nog maar de vraag of onze gebruikers daar eigenlijk wel zo goed mee geholpen worden.

New kid on the block

Al met al wijkt de Data Vault aanpak dus aanzienlijk af van hoe we tot dusver onze datawarehouses ingericht hebben. Van Kimball hebben we geleerd om “one version of the truth” te creëren met behulp van conformed dimensions; en ook Inmon gaat uit van een geünificeerde kijk op geïntegreerde gegevens. (Het is in dat verband interessant om op te merken dat Inmon weliswaar zijn goedkeuring uitspreekt voor Data Vault als “the optimal choice for modeling” voor zijn DW 2.0, maar dat het DW 2.0-concept nog steeds voorziet in een integrated sector die data bevat die “[...] is used and understood universally across the corporation”.)

Na zelf jarenlang gewerkt te hebben in traditionele datawarehouse-omgevingen, geeft mijn huidige opdracht me een mooie gelegenheid om de Data Vault aanpak zelf te beproeven en te vergelijken met de gangbare praktijk.
De “system-of-record”-invalshoek om het datawarehouse zo proces- en requirementsonafhankelijk mogelijk te maken, is zeker nader onderzoek waard; maar het ontbreken van afgedwongen gegevensintegratie vormt een behoorlijke beheersuitdaging. “Multiple versions of the truth” kunnen gemakkelijk ontaarden in een onoverzichtelijke, onbeheersbare wirwar van losse data-silootjes - net als in het pré-datawarehousetijdperk. (Is een datawarehouse dat op afroep iedere gewenste realiteit kan produceren, eigenlijk wel compliant?)

Kortom, het belooft een interessant project te worden.

Trackback URI: http://blog.grey-matter.nl/data-vault-meer-dan-modellering/trackback/

Back to home page
« Tags als instrument voor business... Actuele informatie: niet zo simpel... »

2 Responses to “Data Vault: meer dan modellering”

In de documentatie van Dan Linstedt ervan uitgaat dat data warehouse die op dit moment gebouwd worden genormaliseerd zijn in de derde normaal vorm. Dat is een illusie. Op dit moment worden er al data warehouses gebouwd waar zeker ook historie in aanwezig is.

Een andere illusie van Data Vault is dat er geen gebruik wordt gemaakt van Business Rules, Cleansing en data integratie. Dat is nu juist de kracht van het concept van data warehousing en ETL processen. Je wilt niet dat er in je data warehouse van allerlei rommel in terecht komt.

Een derde waanidee van Dan Linstedt is dat hij met zijn data vault altijd wil kunnen achterhalen waar de data vandaan kwam. Alsof dat met de huidige database en ETL tools niet mogelijk is.

Een vierde waangedachte is dat er wordt bij te vermelden dat wanneer alles wordt opgeslagen met de elementen van Data Vault, namelijk hubjes en linkjes, dat er een enorme spagetti aan het onstaan is van tabellen en dus entiteiten. Wat heb je daar dan voor nodig enorme snelle servers en enorme grote harddisks.

[edit by blog owner - dit is geen soapbox voor belastingdienst-bashing, daarvoor kun je bij de Telegraaf terecht]

Dutch Albatros wrote on October 21st, 2008 at 14:12

Beste Dutch Albatros,

Uit uw reactie blijkt dat je er niets van begrepen hebt. Dan toont aan dat een data warehouse gebouwd in derde normaalvorm helemaal niet flexibel is en dus niet snel kan reageren op veranderde business rules. Dan beweert niet dat er geen historie in opgeslagen is, tuurlijk is dat wel het geval. Data Vault is zelf een set van genormaliseerde tabellen, maar met dit verschil dat er geen business rules in het model zelf zijn opgenomen. Dit geeft dat de Data Vault dus heel flexibel en heel snel kan aangepast worden. Je kent het wel, een merge tussen twee bedrijven en men wil even snel de data warehouse aanpassen om alle data van het overgenomen bedrijf er bij in te pompen. Maar je weet ook hoe “snel” dit gaat Met de Data Vault is er geen sprake van reengineering, maar gewoon enkele componenten eraan toe te voegen.

Uw tweede stelling die je maakt is ook achterhaald. De Data Vault is gebouwd voor Enterprise Data Warehousing. Dit wil zeggen dat alle data moet opgenomen worden in de warehouse, zowel de juiste en goede data als “bad data”. Hoe ga je anders verklaren aan die auditor die langskomt waar de records zijn gebleven die hij in het source systeem heeft gevonden maar niet klopten? De Data Vault staat voor auditibiliteit en traceability. Als er quality issues zijn in de bronsystemen is het aan de business process owner om ervoor te zorgen dat die problemen opgelost raken. Zoals Dan het zo mooi zegt, het is niet de bedoeling dat men jou als architect om 2AM uit je bed belt om te zeggen dat een flow vastliep omdat er data issues waren.

Uw derde opmerking is lachwekkend. In een perfecte wereld zijn er geen data issues en loopt alles zoals gepland. Maar spijtig genoeg is onze wereled niet zo perfect. Weeral, Data Vault staat voor auditibiliteit en traceability. Alles wordt “recorded” en is dus perfect te tracen naar de bron toe. Met Data Vault is het zelfs mogelijk om één op één de bronsystemen terug volledig te restoren. Kan jij met jouw data warehouse uw bronsystemen opnieuw exackt zoals ze waren terug opbouwen?

Uw vierde opmerking maakt volledig duidelijk dat je er niets van begrepen hebt. Deze hubs, links en satelieten maken inderdaad dat er veel tabellen zijn, maar vergeleken met een systeem in derde normaal vorm valt dit nog goed mee. Maar een Data Vault is net ontworpen voor heel hoge performantie. Door het ontzettend kleine aantal kolommen per tabel, de ETL die voor 80% bestaat uit inserts en maar 20% uit updates (ik moet je niet vertellen dat inserts snel gaan en updates heel traag) zorgt ervoor dat het loadproces ontzettend snel gaat (en zelfs real-time applicaties ondersteunt!).

Beste Albatros, ik stel voor dat je het Data Vault seminarie zelf eens volgt (wat momenteel ook in Nederland word ingericht!). Als het je lukt de Data Vault principes te kunnen weerleggen, hoedje af. Maar ik ben er confident in, eens je het volledige concept ziet met alle argumentaties (want je vind natuurlijk niet alles op het internet), dan zul je wel inzien dat het misschien toch niet zo’n slecht concept is.

In ieder geval, ik ga blij zijn dat ik voor Data Vault gekozen heb het moment dat er referentiële dataproblemen zijn in die inflow die om middernacht opgestart wordt…

Koen VW

Koen VW wrote on November 1st, 2008 at 22:48