Data Vault – Ein Überblick
Data Vault ist eine innovative Datenmodellierungsmethode für große Data Warehouse Plattformen. Data Vault wurde von Dan Linstedt entwickelt, um ein Enterprise Data Warehouse bereitzustellen und gleichzeitig die Nachteile der normalisierten (3. Normalform) und dimensionalen Modellierungstechniken zu beheben. Es kombiniert das zentralisierte Rohdaten-Repository des Inmon-Ansatzes mit den Vorteilen des inkrementellen Aufbaus von Kimball.
Dieser Artikel fasst die Nachteile des 3NF- und Dimensional Design-Ansatzes zusammen und listet die Vor- und Nachteile des Data Vault-Ansatzes auf. Schließlich enthält er Links zu nützlicher Hintergrundlektüre und zielt darauf ab, die Frage zu beantworten:
Sollte ich Data Vault für mein Data Warehouse-Projekt verwenden?
Welches Problem versucht Data Vault zu lösen?
Bevor wir die Herausforderungen zusammenfassen, die Data Vault zu lösen versucht, lohnt es sich, den alternativen Datenmodellierungsansatz und die entsprechenden Datenarchitekturen zu betrachten. Das folgende Diagramm zeigt eine mögliche Enterprise Data Architecture.
Enterprise Data Warehouse
Beim EDW-Ansatz werden die Daten in eine transiente Landing Area geladen, woraufhin eine Reihe von ETL-Prozessen zum Laden der Daten in ein Enterprise Data Warehouse der dritten Normalform verwendet wird. Die Daten werden anschließend in dimensionalen Data Marts für Analysen und Berichte extrahiert.
Die wichtigsten Nachteile dieses Ansatzes sind:
- Time to Market: Das Enterprise Data Warehouse muss zunächst Daten aus den einzelnen Quellsystemen in ein zentrales Daten-Repository integrieren, bevor sie für die Berichterstattung zur Verfügung stehen, was das Projekt zeitaufwändig macht.
- Komplexität und Fachwissen: Ein Data Warehouse muss möglicherweise Daten aus hundert Quellen integrieren, und die Entwicklung eines unternehmensweiten Datenmodells zur Unterstützung eines komplexen Geschäftsumfelds ist eine große Herausforderung, die hochqualifizierte Datenmodellierungsexperten erfordert.
- Mangelnde Flexibilität: Ein Modell in dritter Normalform neigt dazu, die bestehenden Datenbeziehungen zu modellieren, was zu einer relativ unflexiblen Lösung führen kann, die erheblich überarbeitet werden muss, wenn zusätzliche Quellen hinzugefügt werden. Schlimmer noch, übereifrige Datenmodellierungsexperten versuchen oft, dies durch die Bereitstellung überkomplexer generischer Modelle zu überwinden, die fast unmöglich zu verstehen sind.
Dimensionaler Designansatz
Das folgende Diagramm zeigt eine mögliche Datenarchitektur für ein klassisches dimensionales Data Warehouse-Design.
Der obige Ansatz verzichtet auf das EDW, um den Endanwendern schnell Ergebnisse zu liefern. Ich habe diese Technik 2008 bei einer Londoner Tier-One-Investmentbank eingesetzt, um den Geschäftsanwendern innerhalb weniger Wochen nach Projektbeginn Kreditrisikobewertungen zu liefern. Hätten wir mit dem Aufbau eines herkömmlichen Data Warehouse gewartet, wären wir bankrott gegangen, bevor wir etwas Nützliches geliefert hätten.
Anfänglich waren die Geschäftsanwender von der schnellen Bereitstellung begeistert, doch im Laufe der Zeit stießen wir auf viele Herausforderungen, die immer schwieriger zu bewältigen waren. Dazu gehörten:
1. Zunehmende Code-Komplexität: Der ETL-Code (Extrahieren, Transformieren und Laden) wurde so kompliziert, dass er nicht mehr zu handhaben war. Das Ersetzen des ETL-Tools (Informatica) durch Oracle-Skripte half zwar (da wir die Lösung nach und nach vereinfachten), aber das war nicht die Ursache des Problems. Wir versuchten, die eingehenden Daten umzustrukturieren, sie zu deduplizieren, zu bereinigen und anzupassen und die sich im Laufe der Zeit ändernden Geschäftsregeln anzuwenden. Die Durchführung all dieser Schritte in einer einzigen Codebasis war in der Tat sehr schwierig.
2. Mangel an Rohdaten: Da der Landebereich rein transient war (jedes Mal gelöscht und neu geladen), hatten wir keine historischen Aufzeichnungen von Rohdaten. Dies machte es für Analysten schwierig, wertvolle neue Datenbeziehungen zu entdecken, und die zunehmende Bedeutung von Data Science, die (vor allem) Rohdaten benötigt, wurde einfach ignoriert.
3. Verwaltung der Historie: Da wir keine Historie der Rohdaten hatten und nur die Attribute luden, die für die Analyse benötigt wurden, wurde es schwierig, zusätzliche Datenfeeds zurückzupflegen.
4. Lineage war eine Herausforderung: Da sowohl die technische als auch die geschäftliche Logik in immer mehr Schichten von Quellcode implementiert war, war es fast unmöglich, die Herkunft eines Datenelements vom Bericht zurück zum Quellsystem zu verfolgen.
Das Unternehmen war von der anfänglichen Schnelligkeit der Bereitstellung begeistert. Im Laufe der Zeit wurde es jedoch immer schwieriger, das Tempo beizubehalten, da die Lösung immer komplexer wurde und sich die Geschäftsregeln im Laufe der Zeit änderten.
Data Vault Architektur
Das folgende Diagramm zeigt eine mögliche Datenarchitektur, die von der Data Vault-Methodik verwendet wird.
Auf den ersten Blick ähnelt sie zwar der obigen Enterprise Data Warehouse-Architektur, weist aber einige signifikante Unterschiede und Ähnlichkeiten auf, darunter:
- Datenladen: Wenn die Daten aus dem Landing Area in den Raw Data Vault geladen werden, handelt es sich um einen reinen Umstrukturierungsprozess des Formats (und nicht des Inhalts) der Daten. Die Quelldaten werden weder bereinigt noch modifiziert und können ohne Probleme vollständig rekonstruiert werden.
- Trennung der Verantwortlichkeiten: Der Raw Vault enthält die unveränderten Rohdaten, und die einzige Verarbeitung ist rein technischer Natur, um die Daten physisch umzustrukturieren. Die Geschäftsregeln liefern zusätzliche Tabellen und Zeilen, um den Raw Vault um einen Business Vault zu erweitern. Das bedeutet, dass die Geschäftsregeln sowohl von den Rohdaten abgeleitet als auch getrennt von diesen gespeichert werden. Diese Trennung der Verantwortlichkeiten erleichtert die Verwaltung von Änderungen der Geschäftsregeln im Laufe der Zeit und verringert die Gesamtkomplexität des Systems.
- Geschäftsregeln: Die Ergebnisse von Geschäftsregeln, einschließlich Deduplizierung, angepasster Ergebnisse und sogar Berechnungen, werden zentral im Business Vault gespeichert. Dadurch werden doppelte Berechnungen und potenzielle Inkonsistenzen vermieden, wenn Ergebnisse für zwei oder mehr Data Marts berechnet werden.
- Data Marts: Im Gegensatz zur Kimball-Methode, bei der berechnete Ergebnisse in Fakten- und Dimensionstabellen in den Data Marts gespeichert werden, sind die Data Marts beim Data Vault-Ansatz oft flüchtig und können als Ansichten direkt über den Business und Raw Vault implementiert werden. Dies bedeutet, dass sie im Laufe der Zeit leichter zu ändern sind und das Risiko inkonsistenter Ergebnisse vermieden wird. Wenn Ansichten nicht das erforderliche Leistungsniveau bieten, besteht die Möglichkeit, die Ergebnisse in einer Tabelle zu speichern.
Die Vorteile von Data Vault
Data Vault geht die Schwierigkeiten an, die sowohl mit dem Enterprise Data Warehouse in der dritten Normalform als auch mit dem Dimensional Design-Ansatz verbunden sind, indem es die besten Aspekte beider Ansätze in einem einzigen hybriden Ansatz kombiniert. Die Vorteile umfassen:
1. Inkrementelle Bereitstellung: Während es sinnvoll ist, jedes Data Warehouse im Kontext eines Gesamtunternehmensmodells aufzubauen, unterstützt Data Vault eine vollständig inkrementelle Bereitstellung. Genau wie beim Dimensional Design-Ansatz von Kimball können Sie klein anfangen und im Laufe der Zeit schrittweise zusätzliche Quellen hinzufügen.
2. Flexibilität: Anders als der 3rd Normal Form Modellierungsansatz, der unflexibel sein kann, erfordert Data Vault keine Nacharbeit, wenn zusätzliche Quellen hinzugefügt werden. Da Data Vault die Rohdaten und die abgeleiteten Geschäftsdaten getrennt speichert, können Änderungen an den Geschäftsregeln problemlos vorgenommen werden.
3. Geringere Komplexität: Da Data Vault in einem zweistufigen Ansatz aufgebaut ist, trennt es die technische Datenumstrukturierung von der Anwendung von Geschäftsregeln, was dazu beiträgt, diese potenziell komplexen Phasen zu isolieren. Ebenso wird die Datenbereinigung als Geschäftsregel betrachtet und kann unabhängig vom anfänglichen Datenladeaufwand verwaltet werden.
4. Einschließlich Rohdaten: Die Aufzeichnung der Rohdaten in Data Vault bedeutet, dass es möglich ist, den Präsentationsbereich mit historischen Attributen zu füllen, die ursprünglich nicht zur Verfügung gestellt wurden. Wenn die Data Marts als Ansichten implementiert sind, kann dies so einfach sein wie das Hinzufügen einer zusätzlichen Spalte zu einer bestehenden Ansicht.
5. Unterstützt auf elegante Weise Veränderungen im Laufe der Zeit: Ähnlich wie die sich langsam verändernde Dimension im Kimball-Ansatz unterstützt Data Vault elegant Änderungen im Laufe der Zeit. Im Gegensatz zum reinen Dimensional Design trennt Data Vault jedoch die Rohdaten von den abgeleiteten Geschäftsdaten und unterstützt Änderungen, die sich sowohl aus dem Quellsystem als auch aus den Geschäftsregeln ergeben.
6. Abstammung und Prüfung: Da Data Vault Metadaten zur Identifizierung der Quellsysteme enthält, ist es einfacher, die Datenabfolge zu unterstützen. Im Gegensatz zum Dimensional Design-Ansatz, bei dem die Daten vor dem Laden bereinigt werden, sind Data Vault-Änderungen immer inkrementell, und die Ergebnisse gehen nie verloren, so dass ein automatischer Prüfpfad entsteht.
7. Leistungsstarke parallele Ladevorgänge: Mit der Einführung von Hash Keys in Data Vault 2.0 werden Abhängigkeiten beim Laden von Daten eliminiert, was bedeutet, dass das Laden von Daten nahezu in Echtzeit möglich ist, zusätzlich zum parallelen Laden von Terabytes bis Petabytes von Daten.
8. Automatisierbar: Während sowohl Entity Relationship Modelling als auch Dimensional Design Zeit und Erfahrung erfordern, um Fähigkeiten aufzubauen, ist Data Vault tendenziell leichter zu automatisieren, und es gibt mehrere Tools (siehe unten), die bei der Bereitstellung der Lösung helfen.
Die Nachteile von Data Vault
Data Vault ist nicht die perfekte Einheitslösung für jedes Data Warehouse, und es gibt einige Nachteile, die berücksichtigt werden müssen. Dazu gehören:
1. Die Lernkurve: Genauso wie 3rd Normal Form, Entity Relationship Modelling und Dimensional Design spezifische Fähigkeiten sind, die zu beherrschen Zeit braucht, gibt es eine Lernkurve mit Data Vault. Der Beginn eines Data Warehouse-Umwandlungsprojekts ist mit erheblichen Risiken verbunden, und das Hinzufügen von Data Vault kann das Risiko erhöhen, insbesondere wenn das Team keine Erfahrung mit Data Vault hat. Vergewissern Sie sich, dass Sie fachkundige Beratung und Unterstützung sowie Schulungen für wichtige Mitarbeiter erhalten.
2. Viele Joins: Ein schlecht konzipierter Data Vault-Entwurf erzeugt eine riesige Anzahl von abgeleiteten Tabellen des Quellsystems, aber auch eine gut konzipierte Lösung vervielfacht die Anzahl der Quelltabellen um den Faktor 2 oder 3. Die Anzahl der Tabellen und damit der Joins kann unübersichtlich erscheinen und zu komplexen Join-Bedingungen führen. Dies kann jedoch durch die korrekte Verwendung von Brückentabellen im Business Vault gelöst werden, und wie bei jeder Lösung handelt es sich um einen Kompromiss aus scheinbarer Komplexität und Flexibilität.
Wo sollte Data Vault eingesetzt werden?
Data Vault erfordert eine gewisse Strenge bei der Bereitstellung eines guten Designs und die Einhaltung der Data Vault 2.0-Prinzipien. Wie das Enterprise Data Warehouse ist auch Data Vault für die Integration von Daten aus verschiedenen Datenquellen konzipiert und kann daher in manchen Situationen überfordert sein.
Zusammenfassend lässt sich sagen, dass Data Vault für kleine bis mittelgroße Analyseanforderungen mit einem kleinen (weniger als 10-köpfigen) Team von Architekten, Designern und Ingenieuren, die eine Lösung mit Daten aus einigen wenigen Systemen bereitstellen, möglicherweise ungeeignet ist.
Wenn Sie jedoch ein großes Projekt mit 30 oder mehr Quellsystemen haben, das zu einer enormen Datenintegrationsherausforderung führt, und bereit sind, die Fähigkeiten und die Strenge einer neuen Methodik auf sich zu nehmen, dann kann Data Vault potenziell einen enormen Mehrwert für das Projekt darstellen.
Weitere Ressourcen und Tools
Die folgenden Ressourcen können helfen, die Data Vault-Methode zu bewerten und zu verstehen:
- Kent Graziano (zertifizierter Data Vault Master) hat eine lesenswerte Zusammenfassung von Data Vault.
- Die Genesee Academy (Training) bietet eine gute Einführung in die wichtigsten Prinzipien von Data Vault.
- UK Consultancy Data Vault Provide a informative summary of Frequently Asked Questions that address many of the immediate concerns.
- Dan Linstedt has a huge number of in-depth articles on the details around Data Vault.
- Building a Scalable Data Warehouse with Data Vault 2.0 – is the reference book by Dan Linstedt.
- The Elephant in the Fridge – is an accessible introduction to Data Vault.
Auch wenn dies in keiner Weise als Empfehlung zu verstehen ist, hier eine kurze Liste von Tools, die bei der Automatisierung der Bereitstellung von Data Vault helfen können.
- dbtvault
- Wherescape
- VaultSpeed
- Data Vault Builder
- Joyn – Ein leichtgewichtiges Open-Source-Automatisierungs-Framework
Fazit
Da On-Premise-Data-Warehouse-Projekte in die Cloud verlagert werden, überdenken immer mehr Unternehmen die Art und Weise, wie das Data Warehouse aufgebaut ist. Der Wechsel von mehreren unabhängigen On-Premise-Datensilos zu einer modernen Cloud-basierten Lösung ist eine einmalige Gelegenheit, Daten aus dem gesamten Unternehmen in ein einziges, konsistentes Repository zu integrieren.
Wenn das die Herausforderung ist, vor der Sie stehen, dann kann Data Vault durchaus helfen, die Lösung zu liefern.
Wenn Sie diesen Artikel hilfreich fanden, interessiert Sie vielleicht meine persönliche Blog-Site (absolut werbefrei) unter www.Analytics.Today.
Haftungsausschluss: Die in meinen Artikeln geäußerten Meinungen sind meine eigenen und spiegeln nicht unbedingt die meines Arbeitgebers (früher oder heute) oder eines Kunden wider, mit dem ich zusammengearbeitet habe.
Leave a Reply