Was ist ein Satellit in Data Vault?

Hubs sagen, was existiert. Links sagen, wie die Dinge zusammengehören. Keines von beiden speichert einen Namen, einen Kontostand oder einen Status. Das ist die Aufgabe des Satelliten.

In der Sprache der klassischen Modellierung: Die Attribute einer Entität, ihr Kontext, werden zu einem Satelliten. Wo die Tabelle Customer neben customer_number auch name, address und segment führt, hält der Data Vault die Nummer im Kunden-Hub und die Attribute in einem Satelliten an diesem Hub.

Was ein Satellit ist

Ein Satellit enthält die beschreibenden Attribute eines Hubs und jede Änderung daran im Lauf der Zeit. Zieht ein Kunde um, überschreibt der Satellit die Adresse nicht: Er fügt eine neue Zeile an, und die alte bleibt erhalten. Jede Zeile hält fest, wann sie in den Vault kam und welches System sie geliefert hat. So ist jede Version nachvollziehbar.

Wer die dimensionale Modellierung kennt: Ein Satellit ist eine Slowly Changing Dimension Typ 2, nur ohne dass je ein UPDATE ausgeführt wird. Auf Wunsch lässt sich die Historisierung auch abschalten, das ergibt einen nicht historisierten Satelliten.

Der Aufbau eines Satelliten

Der Primärschlüssel ist der Parent-Hash-Schlüssel plus das Load-Date.

Der Hash-Diff ist eine Option, keine Regel

Data Vault nach Lehrbuch verlangt, für jede Satellitenzeile einen Hash-Diff zu berechnen, um Änderungen zu erkennen. In der Praxis hängt das vom Ladevorgang ab:

• Delta-Loads: Die gespeicherten Zeilen haben ihren Hash bereits, also ist es günstig, nur die eingehenden Zeilen zu hashen. Hier ist der Hash-Diff im Vorteil.
• Full-Loads: Bei jedem Lauf Millionen von Zeilen zu hashen, kostet viel Rechenleistung. Ein direkter Spaltenvergleich (IS DISTINCT FROM) ist auf modernen Datenbanken oft schneller.
• Breite Tabellen: Oft wird behauptet, breite Tabellen profitierten am meisten vom Hashen. Eher trifft das Gegenteil zu: Breitere Zeilen bedeuten längere Zeichenketten, die vor dem Hashen verkettet werden müssen.

Datavault Builder unterstützt den Hash-Diff als Option, nicht als Pflicht. Dem Hash-Diff ist ein eigener Artikel dieser Reihe gewidmet.

Transaktionen erhalten einen eigenen Satelliten

Mengen, Preise und Beträge einer Auftragsposition beschreiben die Transaktion selbst. Mit einem Grain-Hub für die Auftragsposition, wie im Artikel über Links beschrieben, kommen sie in einen gewöhnlichen Satelliten an diesem Grain-Hub und werden dort wie jedes andere Attribut historisiert.

Wie Sie Satelliten aufteilen

• Nach Quellsystem. Daten aus CRM und ERP teilen sich nie einen Raw-Satelliten. Jede Quelle behält ihre eigene Herkunft, unverändert.
• Nach Änderungshäufigkeit. Stehen ein täglicher Kontostand und ein offizieller Name im selben Satelliten, wird der Name jeden Tag in eine neue Zeile kopiert. Schnell und langsam wechselnde Attribute werden getrennt gehalten.
• Nach Schutzbedarf. Personenbezogene Daten wie Name, E-Mail und Geburtsdatum kommen in einen eigenen Satelliten, getrennt von Attributen, die niemanden identifizieren. Für das DSGVO-Reporting gibt es dann eine klare Anlaufstelle, und Zugriffsregeln oder ein Löschantrag betreffen nur diesen Satelliten.
• Nie löschen. Verschwindet ein Datensatz in der Quelle, bleibt seine Historie erhalten. Ein Record-Tracking-Satellit vermerkt, dass der Schlüssel nicht mehr geliefert wird. Die Ausnahme ist eine gesetzliche Pflicht, Informationen zu entfernen, etwa ein Löschantrag nach DSGVO, und genau dort zahlt sich die Aufteilung nach Schutzbedarf aus.

Was sich mit Datavault Builder ändert

Sie ordnen im Modell Quellspalten einem Satelliten zu. Änderungserkennung, Append-only-Ladevorgang und Audit-Spalten werden generiert und laufen nativ auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL. Zwei Situationen, die klassische Lademuster nicht abdecken, sind von Haus aus berücksichtigt:

• Bitemporale Ladevorgänge. Ein Finanzinstitut mit Tagesendverarbeitung hat zwei Zeitachsen: wann etwas für das Geschäft galt und wann das Warehouse es geladen hat. Datavault Builder verarbeitet die Tagesend-Historie und die Lade-Historie gemeinsam und erzeugt bitemporale Satelliten. Wie das funktioniert, lesen Sie im Beitrag zur „Bi-temporale Datenverarbeitung im DWH“. Auch der Bitemporalität ist ein eigener Artikel dieser Reihe gewidmet.
• Mehr als eine Änderung pro Ladevorgang. Ein Data Lake liefert oft mehrere Versionen desselben Datensatzes in einem Batch. Klassische Muster laden eine Änderung pro Schlüssel und Lauf. Damit müssten Sie die Daten in einer Schleife abarbeiten, und jede Version erhielte den Zeitpunkt des Ladevorgangs als Datum. Datavault Builder lädt alle Änderungen in einem Batch und ordnet jeden Datensatz an der Stelle der Zeitachse ein, an der der Data Lake ihn erfasst hat.