Was ist neu in Data Vault?

Data Vault 3.0?

Zunächst einmal: 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 in diesem Buch verwendet haben. Einige dieser Änderungen sehen groß aus, aber sie ändern nicht wirklich das zugrunde liegende Konzept, und darauf kommt es bei Versionsänderungen an. Basierend auf dem Konzept sehen wir also nur kleine Änderungen oder Verbesserungen. Sie könnten jedoch größere Auswirkungen auf die tatsächliche Implementierung haben, aber das ist nur auf technologische Änderungen zurückzuführen.

 

Montage von Data Vault 2.0 zwischen zwei Abdeckungen

Zusätzlich zu den geringfügigen Änderungen am Konzept gibt es noch einen weiteren Faktor, der hier eine Rolle spielt: Als wir das Buch schrieben, mussten wir den Umfang des Buches so anpassen, dass es zwischen die Buchdeckel passt, da der Verlag ein Seitenlimit hatte (das wir tatsächlich ein wenig überschritten haben). Daher haben wir nicht alle Data Vault 2.0-Konzepte im Buch angewendet: Echtzeit-Konzepte werden beispielsweise nicht im Buch behandelt, und wir haben in unseren Beispielen weder einen Data Lake noch Cloud Computing verwendet. Stattdessen haben wir diese Konzepte nur kurz und der Vollständigkeit halber behandelt, uns aber auf On-Premise-Technologie konzentriert, die damals in realen Projekten häufiger eingesetzt wurde. Im Jahr 2012 war Cloud Computing bereits verfügbar und weit verbreitet, aber es war einfacher, das Buch durch die Verwendung von On-Premise-Technologien auf mehr Leser zuzuschneiden.

 

Was hat sich seit dem Erscheinen des Buches geändert? 

 

Aufhebung des Lastendatums

 

Die offensichtlichste Änderung ist die Entfernung des Lastenddatums. Nun, in unseren aktuellen Projekten entfernen wir es nicht vollständig aus dem Data Vault 2.0-Modell, wir virtualisieren es nur, indem wir das Lastende aus der zugrunde liegenden Satellitentabelle entfernen und es virtuell in einer Ansicht über der Satellitentabelle unter Verwendung einer Fensterfunktion (typischerweise LEAD, aber LAG ist auch möglich) berechnen. Auf diese Weise können wir die Aktualisierungsprozedur zur Beibehaltung des Ladungsenddatums (den so genannten Enddatierungsprozess) loswerden und gleichzeitig die Abfragemuster nachgelagert beibehalten. Bedenken Sie, dass es auch beim Laden von PIT-Tabellen oder Satelliten effizienter sein kann, die Fensterfunktion zu verwenden, und dass die Abfrageschicht daher eigentlich nur für Power-User gedacht ist, wenn sie das Data Vault-Modell direkt abfragen. 

 

Das ist eigentlich kein Update: Schon 2012 (und davor) haben wir diese Ansätze verwendet, aber sie funktionierten nicht auf SQL Server 2014, der in diesem Buch verwendet wurde, da die für diesen Ansatz erforderliche analytische Fensterfunktion viel zu langsam ist. In 2016 hat sich dies jedoch verbessert. Um in solchen Szenarien, in denen die Window-Funktion zu langsam ist oder einfach nicht existiert, das Load End Date loszuwerden, ist eine neue Lösung entstanden: die Verwendung einer Snapshot-Partition in der PIT-Tabelle. Das Ende aller Zeiten wird in der PIT-Tabelle verwendet, um auf das letzte Delta in jedem Satelliten für die Deltakontrolle zu verweisen. Sobald die PIT-Tabelle verfügbar ist, kann sie auch für die Erstellung von SCD-Typ-1-Dimensionen (ohne Historie) verwendet werden, so dass die Notwendigkeit des Ladungsenddatums (oder eines schnellen Ersatzes wie oben beschrieben) nur beim Laden besteht.

 

Hybride Architektur

 

Die nächste offensichtliche Änderung ist die Verwendung eines hybride Architektur wo ein Data Lake für Staging-Zwecke verwendet wird. In diesem Buch konzentrierten wir uns auf den Microsoft SQL Server-Stack vor Ort, der kein verteiltes Dateisystem enthält. Wir haben unseren Kunden bereits empfohlen, einen Data Lake für Staging-Zwecke zu verwenden, und zwar in einer Architektur, die wir als "hybride Architektur" bezeichnet haben. Damals folgten nur wenige diesem Rat, aber heute nutzen die meisten Kunden die hybride Architektur für ihre data warehouse. Wir betrachten einen relationalen Staging-Bereich eigentlich als Anti-Muster und empfehlen ihn unseren Kunden nicht mehr (mit einigen Ausnahmen). 

 

Multi-Zeitlich Data Vault 2.0

 

Das Buch beschreibt ein temporales PIT (TPIT) für den Aufbau multitemporaler Lösungen. Das Muster ist zwar immer noch gültig und im Vergleich zu anderen Lösungen relativ flexibel, doch werden heutzutage die Geschäftszeitpläne in der Regel in das dimensionale Modell verschoben, um die höchste Flexibilität zu erreichen. Dies wird ausführlicher in dem Abschnitt Multitemporal Data Vault 2.0 Klasse. TPITs sind weniger flexibel, haben aber eine höhere Leistung.

 

Schnappschuss Datum

Satelliten in der Unternehmensdatenbank können einen Snapshot-Datum-Zeitstempel anstelle eines Ladedatum-Zeitstempels verwenden. Der Gedanke dahinter ist, dass eine Business Vault-Entität in der Regel immer eine bestehende Granularität wiederverwenden sollte. Die Entwicklung von Business Vault-Lösungen wird dadurch wesentlich einfacher. Mit dem Snapshot-Datum im Primärschlüssel des Satelliten wird es viel einfacher, Geschäftsregeln für die Granularität der ausgehenden Informationen zu erstellen. Dies wird ausführlicher im Abschnitt Data Vault 2.0 Klasse der Informationslieferung. 

 

Ein Geständnis

 

Und schließlich haben auch wir einige Fehler gemacht. Wir sind bereit (nicht glücklich), sie auf unserer Errata-Seite für das Buch einzugestehen - dieser Link stammt direkt aus unserem internen Wiki und wir versprechen, sie auf dem neuesten Stand zu halten (allerdings haben wir in letzter Zeit keine weiteren Meldungen erhalten).