Insert Only in Data Vault 2.0
Eine fundierte Modellierung ist entscheidend, um das volle Potenzial von Data Vault 2.0auszuschöpfen. Damit das System in Bezug auf Skalierbarkeit und Performance optimal genutzt werden kann, muss es zudem auf einer vollständig insert-only-basierten Architektur aufbauen. Alle Aktualisierungsvorgänge auf dem Weg in den Data Vault lassen sich dadurch eliminieren – und die Ladeprozesse deutlich vereinfachen.
Die gemeinsame Umsetzung in Data Vault 2.0
In den gängigen Ladeprozessen von Data Vault 2.0spielen zwei technische Zeitstempel eine zentrale Rolle. Der erste ist der Ladezeitstempel (LDTS – Load Date Timestamp). Er stellt kein Geschäftsdatum aus dem Quellsystem dar, sondern gibt an, wann die Daten erstmals ins Data Warehouse geladen wurden, in der Regel in den Staging-Bereich.
Damit unterscheidet er sich grundlegend von fachlich bedeutenden Datumswerten, die aus den Quellsystemen stammen. Aus diesem Grund muss der LDTS einheitlich für einen gesamten Batch-Ladeprozess generiert werden. Geschäftsrelevante Datumsangaben wie z. B. Gültigkeitsdaten werden hingegen in Effectivity Satelliten gespeichert, die meist mit Link-Entitäten verknüpft sind. Diese geben Aufschluss über Beziehungen zwischen Geschäftsobjekten – inklusive Beginn und Ende der jeweiligen Beziehung.
Der zweite technische Zeitstempel ist der Lade-Endzeitstempel (LEDTS – Load End Date Timestamp). Wie der LDTS wird auch der LEDTS vom System generiert und kommt nur in Satelliten vor. Da diese Satelliten delta-gesteuert sind, gibt es immer genau einen Datensatz, der das aktuellste Delta repräsentiert. Der Wert des LEDTS in diesen Datensätzen ist normalerweise "9999-12-31" (End of Time) oder NULL. Die folgende Abbildung zeigt den gesamten Enddatierungsprozess, der mit dem LEDTS-Attribut verbunden ist. Er wird nach Abschluss des Ladeprozesses des Satelliten ausgeführt (nicht während des Ladevorgangs):
Die Abbildung zeigt, dass der Satellit mit einem neuen LEDTS-Wert aktualisiert werden muss, was Performance kostet. Wie bereits eingangs erwähnt, möchten wir LEDTS-Updates vermeiden, um mit einer vollständig Insert-only-basierten Data Vault 2.0-Architektur eine bessere Performance zu erzielen.
An dieser Stelle stellt sich oft die Frage, wie man das aktuellste Delta in einem Satelliten abfragen kann, wenn kein LEDTS mehr vorhanden ist – etwa mit MAX(LDTS)? Ganz sicher nicht.
Der Vorteil von PIT-Tabellen in Data Vault 2.0
Die Lösung ist die Verwendung von Window-Functions zum Laden von Point-in-Time (PIT)-Tabellen. Wir behandelten das Thema PIT-Tabellen an einem Beispiel aus der Versicherungsbranche bereits in unserem Newsletter von Oktober 2018. Der Zweck von PIT-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins vermieden und stattdessen Inner Joins mit equi-join-Bedingungen ermöglicht werden – aus Performancegründen. Wir empfehlen daher ausdrücklich, eine PIT-Tabelle als performantere Alternative zur LEDTS-basierten Lösung zu verwenden. Die PIT-Tabelle wird mithilfe von Window-Functions erstellt, um das aktuellste Delta im Satelliten zu identifizieren. Sobald sie mit Snapshots der aktuellen Daten aufgebaut ist, entfällt die Notwendigkeit, LDTS-Werte mit BETWEEN-Bedingungen abzufragen. Die zeitliche Historie wird als Snapshots gespeichert und kann über equi-join-Bedingungen auf Hash Key und LDTS mit den zugehörigen Satelliten verbunden werden. Da PIT-Tabellen im Laufe der Zeit wachsen, empfiehlt es sich, sie nach dem Snapshot-Datum zu partitionieren. Schließlich lassen sich die Dimensionsdaten im (visualisierten) Information Mart direkt aus der PIT-Tabelle und den zugehörigen Satelliten effizient abfragen.
Durch die Verwendung von Window-Functions mit Partitionierung nach Hash Key und Sortierung nach LDTS lässt sich das aktuellste Delta dynamisch bestimmen. Es gibt mehrere geeignete Window-Functions zur Ermittlung des aktuellste Deltas, die folgende Tabelle zeigt einige Beispiele.
Ein Grund für die Einführung des LEDTS in Data Vault war, dass viele Datenbanksysteme Anfang der 2000er Jahre noch keine Window-Functions unterstützten oder nicht performant genug waren.
Wie bereits im Newsletter vom Oktober 2018 erwähnt, besteht der Hauptzweck von PIT-Tabellen darin, Inner Joins mit equi-join-Bedingungen zu ermöglichen. Sie sind aber auch der Schlüssel zu einer Insert-only-Implementierung von Data Vault 2.0, die effizientere Ladeprozesse ermöglicht.
Fazit
Die Umsetzung einer Insert-only-Architektur in Data Vault 2.0 erhöht die Skalierbarkeit und Performance, da beim Laden der Daten keine Update-Operationen mehr erforderlich sind. Dieser Ansatz vereinfacht die Ladeprozesse und stellt sicher, dass alle Datenänderungen als neue Datensätze erfasst werden – bei gleichzeitigem Erhalt der historischen Nachvollziehbarkeit. Durch den Einsatz von Point-in-Time (PIT)-Tabellen können Organisationen die aktuellsten Daten effizient abfragen, ohne auf Enddatierungslogiken angewiesen zu sein, was die Datenabfrage und Analyse weiter vereinfacht.