Insert-Only in Data Vault 2.0
Eine kompetente Modellierung ist wichtig, um das volle Potenzial von Data Vault 2.0 auszuschöpfen. Um im Hinblick auf Skalierbarkeit und Performance das Beste aus dem System herauszuholen, muss es zudem auf einer Architektur aufbauen, die vollständig auf Insert-Only ausgelegt ist. Beim Laden in das Data Vault können sämtliche Update-Operationen eliminiert und die Ladeprozesse erheblich vereinfacht werden.
Die gängige Implementierung in Data Vault 2.0
In den gängigen Lademustern gibt es in Data Vault 2.0 zwei wichtige technische Zeitstempel. Der erste ist der Load Date Timestamp (LDTS). Dieser Zeitstempel stellt kein Business-Datum (Business Date) dar, das aus dem Quellsystem stammt. Stattdessen gibt er Auskunft darüber, wann die Daten zum ersten Mal in das Data Warehouse geladen wurden, in der Regel in die Staging Area.
Daher unterscheidet er sich grundlegend von den verschiedenen Business-Daten, die aus den Quellsystemen stammen und eine geschäftliche Bedeutung haben. Aus diesem Grund muss er für einen gesamten Batch-Ladeprozess generiert werden. Business-Daten, wie beispielsweise Gültigkeitsdaten, werden in Effectivity-Satelliten gespeichert, die meist mit Link-Entities verbunden sind. Sie liefern Informationen über die Beziehungen zwischen Geschäftsobjekten sowie das jeweilige Anfangs- und Enddatum.
Der zweite technische Zeitstempel ist der Load End Date Timestamp (LEDTS). Wie der LDTS ist auch der LEDTS systemgeneriert und tritt nur in Satellite-Entities auf. Da diese Satelliten delta-basiert sind, gibt es immer einen Datensatz, der das aktuellste Delta darstellt. Der Wert des LEDTS bei diesen Datensätzen ist üblicherweise „9999-12-31“ (End of Time) oder NULL. Die folgende Abbildung zeigt den gesamten End-Dating-Prozess, der mit der Verwendung des LEDTS-Attributs einhergeht. Dieser wird nach dem Laden des Satelliten ausgeführt (nicht währenddessen):
Die Abbildung verdeutlicht, dass wir den Satelliten mit dem neuen LEDTS-Wert aktualisieren müssen, was zulasten der Performance geht. Wie anfangs erwähnt, möchten wir die LEDTS-Updates eliminieren, um mit einer 100-prozentigen Insert-Only-Architektur in Data Vault 2.0 eine höhere Performance zu erzielen.
An dieser Stelle stellt sich die typische Frage, wie das aktuellste Delta in einem Satelliten abgefragt werden kann, wenn wir keinen LEDTS mehr haben. Mittels max(LDTS)? Sicherlich nicht.
Der Vorteil von PIT-Tabellen in Data Vault 2.0
Die Antwort liegt in der Verwendung von Fensterfunktionen (Window Functions) zum Laden Ihrer Point-in-Time-Tabellen (PIT-Tabellen). Wir haben das Thema PIT-Tabellen bereits mit einem Beispiel aus der Versicherungsbranche in unserem Newsletter vom Oktober 2018 behandelt. 2018. Der Zweck von PIT-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und aus Performancegründen Inner Joins mit Equi-Join-Bedingungen ermöglicht werden. Wir empfehlen dringend, eine PIT-Tabelle als performantere Alternative zum LEDTS aufzubauen. Die PIT-Tabelle wird mithilfe von Fensterfunktionen erstellt, um das aktuellste Delta im Satelliten zu finden. Sobald sie mit Snapshots der aktuellen Daten erstellt wurde, müssen wir den LDTS nicht mehr mit BETWEEN-Bedingungen abfragen. Die zeitliche Historie wird in Form von Snapshots gespeichert und kann mit Equi-Join-Bedingungen auf dem Hash-Key und dem LDTS zu den zugehörigen Satelliten abgefragt werden. Da PIT-Tabellen kontinuierlich wachsen, wird empfohlen, Partitionen auf dem Snapshot-Datum zu erstellen. Schließlich können die (visualisierten) Information-Mart-Dimensionen ganz einfach direkt aus der PIT-Tabelle und den zugehörigen Satelliten abgefragt werden.
Durch die Verwendung von Fensterfunktionen auf dem Hash-Key (Partition) und dem LDTS (Order) können Sie das aktuellste Delta identifizieren, das dynamisch berechnet wird. Es gibt verschiedene Fensterfunktionen, die zur Ermittlung des aktuellsten Deltas verwendet werden können. Die folgende Tabelle zeigt einige Beispiele für diese Fensterfunktionen.
Ein Grund für die Existenz des LEDTS in Data Vault ist, dass viele Datenbanken im frühen 21. Jahrhundert noch keine Fensterfunktionen unterstützten oder dafür nicht schnell genug waren.
Wie bereits im Newsletter vom Oktober 2018 erwähnt, besteht der Zweck von PIT-Tabellen darin, Inner Joins mit Equi-Join-Bedingungen zu ermöglichen. Sie sind jedoch auch der Schlüssel zu einer reinen Insert-Only-Implementierung von Data Vault 2.0, wodurch weitaus effizientere Ladeprozesse ermöglicht werden.
Fazit
Die Implementierung einer Insert-Only-Architektur in Data Vault 2.0 verbessert die Skalierbarkeit und Performance, indem Update-Operationen während des Datenladens eliminiert werden. Dieser Ansatz vereinfacht den Ladeprozess und stellt sicher, dass alle Datenänderungen als neue Datensätze erfasst werden, wodurch die historische Genauigkeit gewahrt bleibt. Durch die Nutzung von Point-in-Time-Tabellen (PIT-Tabellen) können Unternehmen die aktuellsten Daten effizient abfragen, ohne auf End-Dating-Techniken angewiesen zu sein, wodurch der Datenabruf und die Datenanalyse weiter optimiert werden.
