Data Vault 2.0
Teilnehmer unserer Data Vault 2.0-Schulungen fragen uns häufig, worin der Unterschied zwischen dem Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ und unserer aktuellen Beratungspraxis besteht. Um zumindest vorerst eine eindeutige Antwort zu geben, haben wir diesen Artikel verfasst.
Was gibt es Neues in Data Vault?
Dieser Artikel behandelt aktuelle Updates in den Data Vault 2.0-Praktiken seit der Veröffentlichung des Buches „Building a Scalable Data Warehouse with Data Vault 2.0“. Zu den wesentlichen Änderungen gehören die Virtualisierung des Load End Date mithilfe von Window Functions zur Steigerung der Effizienz, die Einführung hybrider Architekturen, die Data Lakes für Staging-Zwecke integrieren, sowie die Verlagerung von Business Timelines in das dimensionale Modell für eine höhere Flexibilität. Darüber hinaus liegt ein Schwerpunkt auf der Verwendung von Snapshot-Date-Zeitstempeln in Business-Vault-Satelliten, um die Entwicklung von Business-Regeln zu vereinfachen. Der Artikel stellt klar, dass diese Updates als Erweiterungen innerhalb des bestehenden Data Vault 2.0-Frameworks betrachtet werden – bezeichnet als „Data Vault 2.0.1“ –, anstatt eine neue Version wie Data Vault 3.0 darzustellen.
Data Vault 3.0?
Vorab: Es gibt kein Data Vault 3.0. Wir bezeichnen die Version von Data Vault, die wir unterrichten und in unserer Beratungspraxis anwenden, gerne als „Data Vault 2.0.1“. Daher gibt es nur geringfügige Unterschiede zu der Version, die wir im Buch verwendet haben. Einige dieser Änderungen wirken groß, ändern jedoch nicht das zugrundeliegende Konzept – und das ist es, worauf es bei Versionsänderungen ankommt. Auf Konzept-Ebene sehen wir also nur geringfügige Anpassungen oder Erweiterungen. Diese können allerdings größere Auswirkungen auf die praktische Implementierung haben, was wiederum rein auf technologische Veränderungen zurückzuführen ist.
Wie man Data Vault 2.0 zwischen zwei Buchdeckeln unterbringt
Neben den geringfügigen Änderungen am Konzept spielt hier noch ein weiterer Faktor eine Rolle: Beim Schreiben des Buches mussten wir den Umfang begrenzen, damit es zwischen die Buchdeckel passte, da der Verlag eine Seitenbegrenzung hatte (die wir tatsächlich leicht überschritten haben). Daher haben wir im Buch nicht alle Data Vault 2.0-Konzepte angewendet: Echtzeit-Konzepte (Real-Time) werden beispielsweise im Buch nicht behandelt, und wir haben in unseren Beispielen weder einen Data Lake noch Cloud Computing verwendet. Stattdessen haben wir diese Konzepte der Vollständigkeit halber nur kurz angeschnitten und uns auf On-Premise-Technologien konzentriert, die damals in realen Projekten häufiger eingesetzt wurden. Im Jahr 2012 war Cloud Computing zwar bereits verfügbar und weit verbreitet, aber es war einfacher, das Buch durch die Verwendung von On-Premise-Technologien auf eine breitere Leserschaft zuzuschneiden.
Was hat sich vor diesem Hintergrund seit dem Erscheinen des Buches verändert?
Entfernung des Load End Date
Die offensichtlichste Änderung ist die Entfernung des Load End Date. In unseren Praxisprojekten entfernen wir es jedoch nicht vollständig aus dem Data Vault 2.0-Modell, sondern virtualisieren es lediglich: Wir entfernen das Load End Date aus der zugrundeliegenden Satellite-Tabelle und berechnen es virtuell in einer View oberhalb der Satellite-Tabelle mithilfe einer Window Function (typischerweise LEAD, aber auch LAG ist möglich). Auf diese Weise können wir auf das Update-Verfahren zur Pflege des Load End Date (den sogenannten End-Dating-Prozess) verzichten, während die Abfragemuster (Query Patterns) nachgelagert erhalten bleiben. Bedenken Sie, dass es beim Laden von PIT-Tabellen oder Satelliten auch effizienter sein kann, die Window Function zu verwenden; daher ist der Query Layer eigentlich nur für Power User gedacht, wenn diese das Data Vault-Modell direkt abfragen.
Das ist eigentlich kein Update: Bereits 2012 (und davor) haben wir diese Ansätze genutzt, aber sie funktionierten nicht unter SQL Server 2014, der im Buch verwendet wurde, da die für diesen Ansatz erforderliche analytische Window Function viel zu langsam war. Dies verbesserte sich jedoch 2016. Um das Load End Date in Szenarien loszuwerden, in denen die Window Function zu langsam ist oder schlicht nicht existiert, hat sich eine neue Lösung etabliert: die Verwendung einer Snapshot-Partition in der PIT-Tabelle. Das „Ende aller Zeiten“ wird in der PIT-Tabelle verwendet, um für den Delta-Check auf das neueste Delta in jedem Satelliten zu verweisen. Sobald die PIT-Tabelle verfügbar ist, kann sie auch zur Erzeugung von SCD Type 1-Dimensionen (ohne Historie) verwendet werden, wodurch der Bedarf an dem Load End Date (oder einem schnellen Ersatz wie oben beschrieben) nur noch beim Laden besteht.
Hybride Architektur
Die nächste offensichtliche Änderung ist die Nutzung einer hybriden Architektur, bei der ein Data Lake für Staging-Zwecke verwendet wird. Im Buch haben wir uns auf den On-Premise Microsoft-SQL-Server-Stack konzentriert, der kein verteiltes Dateisystem enthielt. Wir haben Kunden bereits damals empfohlen, einen Data Lake für Staging-Zwecke zu nutzen – in einer Architektur, die wir als „hybride Architektur“ bezeichneten. Damals folgten nur wenige diesem Rat, aber heute nutzen die meisten Kunden die hybride Architektur für ihr Data Warehouse. Wir betrachten eine relationale Staging-Area mittlerweile als Anti-Pattern und empfehlen sie unseren Kunden (mit wenigen Ausnahmen) nicht mehr.
Multi-Temporal Data Vault 2.0
Das Buch beschreibt einen Temporal PIT (TPIT) für den Aufbau multi-temporaler Lösungen. Während das Pattern nach wie vor gültig und im Vergleich zu anderen Lösungen relativ flexibel ist, verlagern wir heute für maximale Flexibilität die Business Timelines in der Regel in das dimensionale Modell. Dies wird im Kurs „Multi-Temporal Data Vault 2.0“ detaillierter behandelt. TPITs sind weniger flexibel, bieten aber eine höhere Performance.
Snapshot Date
Satelliten im Business Vault verwenden möglicherweise einen Snapshot-Date-Zeitstempel anstelle eines Load-Date-Zeitstempels. Die Idee dahinter ist, dass eine Business-Vault-Entität als allgemeine Praxis immer eine bestehende Granularität wiederverwenden sollte. Dadurch wird die Entwicklung von Business-Vault-Lösungen deutlich einfacher. Mit dem Snapshot Date im Primärschlüssel des Satelliten wird dies für Business-Regeln auf der ausgehenden Informationsgranularität wesentlich einfacher. Dies wird im Kurs „Data Vault 2.0 Information Delivery“ detaillierter behandelt.
Fazit
Und schließlich haben wir auch einige Fehler gemacht. Wir sind bereit (wenn auch nicht begeistert), diese auf unserer Errata-Seite für das Buch zuzugeben – dieser Link stammt direkt aus unserem internen Wiki und wir versprechen, ihn auf dem neuesten Stand zu halten (allerdings haben wir in letzter Zeit keine weiteren Meldungen erhalten).
