Data Vault – een overzicht

Data Vault is een innovatieve gegevensmodelleringsmethode voor grootschalige datawarehouseplatforms. Data Vault is uitgevonden door Dan Linstedt en is ontworpen om een Enterprise Data Warehouse te leveren terwijl het de nadelen van de genormaliseerde (3e normale vorm) en dimensionale modelleringstechnieken aanpakt. Het combineert de gecentraliseerde ruwe gegevens opslagplaats van de Inmon aanpak met de incrementele opbouw voordelen van Kimball.

Dit artikel geeft een samenvatting van de nadelen van de 3NF en Dimensional Design aanpak en somt de voor- en nadelen op van de Data Vault aanpak. Ten slotte bevat het links naar nuttige achtergrondinformatie en is het bedoeld als antwoord op de volgende vragen:

Moet ik Data Vault gebruiken voor mijn Data Warehouse-project?

Welk probleem probeert Data Vault op te lossen?

Voordat wordt ingegaan op de uitdagingen die Data Vault probeert op te lossen, is het de moeite waard te kijken naar de alternatieve aanpak van gegevensmodellering en de bijbehorende gegevensarchitectuur. Het onderstaande diagram toont een mogelijke Enterprise Data Architecture.

Enterprise Data Warehouse

Bij de EDW-benadering worden gegevens geladen in een transient Landing Area, waarna een reeks ETL-processen wordt gebruikt om gegevens te laden in een enterprise data warehouse met een derde normale vorm. De gegevens worden vervolgens geëxtraheerd in dimensionale data marts voor analyse en rapportage.

De belangrijkste nadelen van deze aanpak zijn:

1. Time to Market: Het Enterprise Data Warehouse moet eerst gegevens uit elk van de bronsystemen integreren in een centrale gegevensopslagplaats voordat ze beschikbaar zijn voor rapportage, wat tijd en moeite toevoegt aan het project.
2. Complexiteit en vaardigheid: Een datawarehouse moet mogelijk gegevens uit honderd bronnen integreren, en het ontwerpen van een bedrijfsbreed datamodel ter ondersteuning van een complexe bedrijfsomgeving is een aanzienlijke uitdaging die zeer bekwame datamodelleringsdeskundigen vereist.
3. Gebrek aan flexibiliteit: Een model met de derde normale vorm heeft de neiging de bestaande gegevensrelaties te modelleren, wat een betrekkelijk inflexibele oplossing kan opleveren die aanzienlijk moet worden aangepast als extra bronnen worden toegevoegd. Erger nog, overijverige deskundigen op het gebied van gegevensmodellering proberen dit vaak te ondervangen door te complexe generieke modellen te leveren die bijna onmogelijk te begrijpen zijn.

Dimensionale ontwerpbenadering

Het onderstaande diagram illustreert een potentiële gegevensarchitectuur voor een klassiek dimensioneel datawarehouseontwerp.

De bovenstaande aanpak maakt het EDW overbodig om snel resultaten te kunnen leveren aan eindgebruikers. Ik heb deze techniek in 2008 gebruikt bij een Londense tier one Investment bank om kredietrisico-evaluaties te leveren aan zakelijke gebruikers binnen enkele weken na de start van het project. Als we hadden gewacht met het bouwen van een traditioneel datawarehouse, waren we failliet gegaan voordat we iets nuttigs hadden opgeleverd.

In eerste instantie waren de zakelijke gebruikers enthousiast over de snelheid van leveren; na verloop van tijd vonden we echter veel uitdagingen die steeds pijnlijker werden om mee om te gaan. Deze omvatten:

1. Toenemende complexiteit van de code: De ETL-code (Extract, Transform, and Load) werd zo ingewikkeld dat het niet langer beheersbaar was. Het vervangen van de ETL-tool (Informatica) door Oracle-scripts hielp, (omdat we de oplossing al doende vereenvoudigden), maar dat was niet de kern van het probleem. We probeerden de inkomende data te herstructureren, te ontdubbelen, de data op te schonen en te conformeren, en veranderende business rules toe te passen in de tijd. Het was erg moeilijk om al deze stappen in een enkele codebase uit te voeren.

2. Gebrek aan ruwe gegevens: Aangezien het landingsgebied louter van voorbijgaande aard was (elke keer verwijderd en opnieuw geladen), hadden we geen historisch overzicht van ruwe gegevens. Dit maakte het voor analisten moeilijk om waardevolle nieuwe gegevensrelaties te ontdekken, en het toenemende belang van Data Science, dat (vooral) ruwe gegevens nodig heeft, werd eenvoudigweg genegeerd.

3. Beheer van geschiedenis: Aangezien we geen geschiedenis van ruwe gegevens hadden en alleen de attributen laadden die nodig waren voor analyse, werd het moeilijk om aanvullende gegevensfeeds te back-populeren.

4. Lineage was een uitdaging: Omdat zowel de technische als de bedrijfslogica in steeds meer afzettingslagen van broncode was geïmplementeerd, was het bijna onmogelijk om de herkomst van een gegevensitem uit het rapport terug te traceren naar het bronsysteem.

De business was dol op de aanvankelijke snelheid van levering. Naarmate de tijd verstreek, werd het echter steeds moeilijker om het tempo vast te houden, omdat de oplossing steeds complexer werd en de bedrijfsregels in de loop der tijd veranderden.

Data Vault-architectuur

Het onderstaande diagram toont een potentiële gegevensarchitectuur die wordt gebruikt door de Data Vault-methodologie.

Hoewel deze op het eerste gezicht erg lijkt op de Enterprise Data Warehouse-architectuur hierboven, heeft deze een paar belangrijke verschillen en overeenkomsten, waaronder:

• Gegevens laden: Wanneer de gegevens van de Landing Area in de Raw Data Vault worden geladen, is het proces uitsluitend gericht op het herstructureren van het formaat (en niet zozeer van de inhoud) van de gegevens. De brongegevens worden noch opgeschoond, noch gewijzigd, en kunnen zonder probleem volledig worden gereconstrueerd.
• Scheiding van Verantwoordelijkheid: De Raw Vault bevat de ongewijzigde ruwe gegevens, en de enige verwerking is volledig technisch, om de gegevens fysiek te herstructureren. De bedrijfsregels leveren aanvullende tabellen en rijen om de Raw Vault uit te breiden met een Business Vault. Dit betekent dat de bedrijfsregels zowel afgeleid zijn van als opgeslagen worden los van de ruwe gegevens. Deze scheiding van verantwoordelijkheid maakt het eenvoudiger om veranderingen in de bedrijfsregels in de loop van de tijd te beheren en vermindert de algehele complexiteit van het systeem.
• Bedrijfsregels: De resultaten van bedrijfsregels, inclusief ontdubbeling, conforme resultaten en zelfs berekeningen, worden centraal opgeslagen in de Business Vault. Dit helpt dubbele berekeningen en potentiële inconsistenties te voorkomen wanneer resultaten voor twee of meer datamarts worden berekend.
• Data Marts: In tegenstelling tot de Kimball-methode waarbij berekende resultaten worden opgeslagen in Fact- en Dimension-tabellen in de Data Marts, zijn bij de Data Vault-benadering de Data Marts vaak efemeer, en kunnen ze worden geïmplementeerd als views direct over de Business en Raw Vault. Dit betekent dat zij in de loop van de tijd gemakkelijker kunnen worden gewijzigd en dat het risico van inconsistente resultaten wordt vermeden. Als views niet het vereiste prestatieniveau bieden, bestaat de mogelijkheid de resultaten in een tabel op te slaan.

De voordelen van Data Vault

Data Vault adresseert de moeilijkheden die inherent zijn aan zowel het 3rd Normal Form Enterprise Data Warehouse als de Dimensional Design-benadering, door de beste aspecten van beide in één hybride benadering te combineren. De voordelen zijn:

1. Incrementele levering: Hoewel het verstandig is om elk Data Warehouse op te bouwen binnen de context van een algemeen bedrijfsmodel, ondersteunt Data Vault een volledig incrementele oplevering. Net als bij Kimball’s Dimensional Design-aanpak kunt u klein beginnen en in de loop der tijd incrementeel extra bronnen toevoegen.

2. Flexibiliteit: In tegenstelling tot de 3rd Normal Form-modelleringsaanpak, die inflexibel kan zijn, vereist Data Vault geen herbewerking bij het toevoegen van extra bronnen. Omdat Data Vault de ruwe gegevens en de bedrijfsafgeleide gegevens afzonderlijk opslaat, ondersteunt het gemakkelijk wijzigingen in bedrijfsregels.

3. Verminderde complexiteit: Omdat Data Vault in twee stappen is opgebouwd, scheidt het de technische herstructurering van de gegevens van de toepassing van bedrijfsregels, wat helpt deze potentieel complexe fasen te isoleren. Ook het opschonen van gegevens wordt beschouwd als een bedrijfsregel en kan onafhankelijk van het laden van de eerste gegevens worden beheerd.

4. Inclusief ruwe gegevens: Het opnemen van de ruwe gegevens in Data Vault betekent dat het mogelijk is om het presentatiegebied te back-populeren met historische attributen die in eerste instantie niet beschikbaar werden gesteld. Als de Data Marts zijn geïmplementeerd als views, kan dit zo eenvoudig zijn als het toevoegen van een extra kolom aan een bestaande view.

5. Ondersteunt op elegante wijze verandering in de tijd: Vergelijkbaar met de langzaam veranderende dimensie in de Kimball-aanpak, ondersteunt Data Vault op elegante wijze veranderingen in de tijd. In tegenstelling tot het zuivere dimensionale ontwerp scheidt Data Vault echter de ruwe en de bedrijfsafgeleide gegevens en ondersteunt het wijzigingen die voortvloeien uit zowel het bronsysteem als de bedrijfsregels.

6. Lineage en audit: Omdat Data Vault metadata bevat waarmee de bronsystemen kunnen worden geïdentificeerd, wordt het eenvoudiger om de lineage van gegevens te ondersteunen. In tegenstelling tot de Dimensional Design-benadering, waarbij gegevens worden opgeschoond voordat ze worden geladen, zijn wijzigingen in Data Vault altijd incrementeel en gaan resultaten nooit verloren, wat een automatische audit trail oplevert.

7. High-Performance Parallel Loads: Met de introductie van Hash Keys in Data Vault 2.0 zijn de afhankelijkheden van het laden van gegevens geëlimineerd, wat betekent dat het bijna real-time laden van gegevens mogelijk is, naast het parallel laden van terabytes tot petabytes aan gegevens.

8. Automatiseerbaar: Terwijl zowel Entity Relationship Modelling als Dimensional Design tijd en ervaring vereisen om vaardigheden op te bouwen, heeft Data Vault de neiging om gemakkelijker te automatiseren, en er zijn verschillende tools (hieronder vermeld) om te helpen de oplossing te leveren.

De nadelen van Data Vault

Data Vault is niet de perfecte one size fits all-oplossing voor elk datawarehouse, en het heeft wel een paar nadelen die moeten worden overwogen. Deze omvatten:

1. De leercurve: Net zoals 3rd Normal Form, Entity Relationship Modelling, en Dimensional Design specifieke vaardigheden zijn die tijd kosten om onder de knie te krijgen, is er een leercurve met Data Vault. Het starten van een Data Warehouse-transformatieproject brengt aanzienlijke risico’s met zich mee, en het toevoegen van Data Vault kan het risico vergroten, vooral als het team geen ervaring heeft met Data Vault. Zorg voor deskundig advies en ondersteuning, naast training voor belangrijke personen.

2. Veel Joins: Een slecht ontworpen Data Vault-ontwerp zal een enorm aantal van het bronsysteem afgeleide tabellen opleveren, maar zelfs een goed ontworpen oplossing vermenigvuldigt het aantal brontabellen met een factor 2 of 3. Het aantal tabellen en dus joins kan onhandelbaar lijken en leiden tot complexe join condities. Dit kan echter worden aangepakt met het juiste gebruik van overbruggingstabellen in de Business Vault, en zoals bij elke oplossing is het een afweging van schijnbare complexiteit en flexibiliteit.

Waar kan Data Vault worden gebruikt?

Data Vault vereist enige nauwgezetheid in het leveren van een goed ontwerp en het vasthouden aan de Data Vault 2.0 principes. Net als het Enterprise Data Warehouse is het ontworpen om gegevens uit verschillende gegevensbronnen te integreren en daarom kan het in sommige situaties overkill zijn.

Samengevat: als u een kleine tot middelgrote analytics-behoefte hebt, met een klein (minder dan 10) team van architecten, ontwerpers en ingenieurs die een oplossing leveren met gegevens die afkomstig zijn uit een paar systemen, dan kan Data Vault ongeschikt zijn voor uw behoeften.

Als u echter een groot project hebt met 30 of meer bronsystemen die tot een enorme uitdaging op het gebied van data-integratie leiden en u bereid bent de vaardigheden en rigueur van een nieuwe methodologie op u te nemen, dan kan Data Vault potentieel een enorme waarde aan het project toevoegen.

Andere bronnen en hulpmiddelen

De volgende bronnen kunnen helpen bij het evalueren en begrijpen van de Data Vault-methode:

• Kent Graziano (gecertificeerd Data Vault Master) heeft een lezenswaardige samenvatting van Data Vault.
• De Genesee Academy (Training) biedt een goede introductie tot de belangrijkste principes van Data Vault.
• UK Consultancy Data Vault biedt een informatieve samenvatting van Frequently Asked Questions die veel van de directe zorgen behandelen.
• Dan Linstedt heeft een enorm aantal diepgaande artikelen over de details rond Data Vault.
• Building a Scalable Data Warehouse with Data Vault 2.0 – is het referentieboek van Dan Linstedt.
• The Elephant in the Fridge – is een toegankelijke inleiding tot Data Vault.

Hoewel deze op geen enkele wijze als aanbeveling mogen worden beschouwd, volgt hier een shortlist van de tools die kunnen helpen bij het automatiseren van de levering van Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – A lightweight open source automation framework

Conclusie

Naarmate on-premise data warehouse projecten naar de cloud worden verplaatst, heroverweegt een toenemend aantal bedrijven hoe het Data Warehouse is opgezet. De overstap van meerdere onafhankelijke on-premise gegevenssilo’s naar een moderne cloud-gebaseerde oplossing is een unieke kans om gegevens uit de hele onderneming te integreren in een enkele, consistente opslagplaats.

Als dat de uitdaging is waarvoor u staat, dan kan Data Vault u helpen de oplossing te leveren.

Als u dit artikel nuttig vond, bent u wellicht geïnteresseerd in mijn persoonlijke blogsite (absoluut geen reclame), op www.Analytics.Today.

Disclaimer: De meningen die in mijn artikelen worden geuit, zijn mijn eigen meningen en weerspiegelen niet noodzakelijk die van mijn werkgever (in heden of verleden) of van enige klant met wie ik heb samengewerkt.