Freitag, 11. Dezember 2015

Data Vault 2.0

Seit vielen Jahren schon war ich in unterschiedlichen BI / Data Warehouse Projekten engagiert. Gemäß Ralph Kimballs Methodik des dimensionalen Modellierens haben wir versucht, so gut wie möglich die Anforderungen zu ermitteln, dimensionale Modelle mit Fakten- und Dimensionstabellen zu bauen und mit beeindruckenden ETL Prozessen zu beladen. Gelegentlich begegnete ich dem geheimnisvollen Stichwort "Data Vault", aber abgesehen von ein paar Schlagworten konnte ich lange Zeit nichts damit verbinden. Es fehlte nach meiner Einschätzung auch nichts in unseren Projekten - die Ergebnisse waren meistens ganz zufriedenstellend.

Mit den ersten Projekten, die Data Vault einsetzen, hat sich mein Blickwinkel auf BI Projekte jedoch gründlich verändert. Tatsächlich lassen sich damit einige grundlegende Probleme sehr effizient lösen.

Was ist denn nun dieses Data Vault?


Das dimensionale Standard Data Warehouse nach Kimball geht von einer zweistufigen Architektur aus, wie sie die nachfolgende Grafik zeigt:
Zweistufige Architektur nach Kimball
Mit Data Vault kommt eine weitere Stufe zwischen Staging Area und dem dimensionalen Data Warehouse hinzu.
Dreistufige Architektur mit Data Vault
 Diese Schicht, gelegentlich auch Enterprise Data Warehouse genannt, hat zwei Aufgaben:
  • Integrieren der Daten aus unterschiedlichen Quellen
  • Aufbau der Historie aller Daten, die diese Quellen liefern
Dabei handelt es sich um eine Datenbank, in der drei Typen von Tabellen modelliert sind:
  • Hubs - enthalten nur Business Keys eines Typs von Geschäftsobjekt
    (z.B. Kunde, Vertrag, Tarif)
  • Links - verbinden Hubs
    (z.B. ein Kunde schließt einen Vertrag)
  • Satelliten - enthalten ergänzende Daten zu Hubs
    (z.B. Vertragsart, Anfangsdatum, Vertragsdauer)
In diesen Tabellen werden die Daten weitestgehend so abgelegt, wie sie aus den Quellen kommen - inklusive aller Änderungen über die Zeit. Erst beim Beladen der obersten Schicht, des dimensionalen Data Warehouse, kommen Geschäftsregeln zur Anwendung, welche die Daten interpretieren und in Informationen umwandeln. Beispielsweise wenn zu einem Kunden aus zwei unterschiedlichen Quellen zwei unterschiedliche Adressen geliefert werden, entscheidet eine Geschäftsregel darüber, welche die vertrauenswürdige Quelle ist.

Der Vorteil dieser Trennung offenbart sich spätestens, wenn eine Geschäftsregel sich ändert: Bei der zweistufigen Lösung hat die Interpretation der Daten bereits beim Laden von der Staging Area in das dimensionale DWH stattgefunden. Ändern diese sich, wird es schwierig: oft ist die Historie der Daten nicht oder nur schwer aus der Staging Area zu rekonstruieren. Mit Data Vault ist das Problem wesentlich kleiner, denn im Data Vault liegen die originalen Quelldaten mitsamt ihrer gesamten Historie - das dimensionale DWH kann jederzeit mit neuen Geschäftsregeln neu beladen werden.

Darüber hinaus bietet die standardisierte Tabellenstruktur im Data Vault die Möglichkeit, das Laden der Tabellen weitgehend zu automatisieren. Auch Erweiterungen wie das Hinzufügen neuer Datenquellen und neuer Attribute erfolgen ganz geradlinig, weil die bestehenden Ladeprozeduren nicht modifiziert und auch nicht erneut getestet werden müssen. Kein Wunder, dass agiles Vorgehen in BI Projekten erst mit Data Vault so richtig gut funktioniert.

Brauchen nun alle BI Projekte einen Data Vault?


Data Vault ersetzt also keineswegs das dimensionale Data Warehouse und die Kimball Methodik, sondern fügt der BI Architektur eine weitere Schicht hinzu. Wann lohnt sich dieser zusätzliche Aufwand?

Bei kleinen und mittleren BI Lösungen, die nicht auditiert werden müssen, ist eine zweistufige Architektur oft völlig ausreichend: Eine Staging Area in der ersten Stufe und ein dimensionales Data Warehouse in der zweiten Stufe.

Wird mit Data Vault alles einfacher?


Durch Hinzufügen der Data Vault Schicht wird zunächst einmal der initiale Aufwand größer. Und vor allem braucht das Team Erfahrung und Anleitung bei der Data Vault Modellierung. Nur wenn die Konzepte durchgängig umgesetzt werden, liefert Data Vault die erwarteten Vorteile. Aber mit wachsender Größe eines DWH Projekts und mit jeder Quelle, die im Lauf der Lebensdauer einer BI Lösung hinzukommt, treten auch die Vorteile stärker in den Vordergrund.

Die Antwort auf die Frage ist also, wie so oft, ein qualifiziertes "Ja, aber". Mein Vorschlag: Machen Sie sich mit dem Thema vertraut, zum Beispiel über die unten aufgeführten Links. Ein DWH Architekt sollte auf jeden Fall Data Vault in seinem Methodenkoffer haben um das in der jeweiligen Situation am besten Passende daraus anzuwenden. Jetzt ist ein perfekter Zeitpunkt sich ernsthaft mit diesem Thema auseinanderzusetzen, denn in seinem gerade erschienen Buch "Building a Scalable Data Warehouse with Data Vault 2.0" stellt Dan Linstedt seine umfassende Methodik und eine ausgereifte Modellierungstechnik anhand vieler Beispiele vor. Alle BI Spezialisten, die wie ich den Microsoft SQL Server als Schwerpunkt haben, wird es freuen, dass viele Beispiele in diesem Buch mit SSIS und T-SQL umgesetzt sind.

Dan Linstedts Blog
Roelant Vos Blog
datavaultmodeling.de

Happy vaulting!