Teil 13. Increments, Snapshots und Historie

Die Datenhistorie ist eine der Hauptquellen für versteckte inhaltliche Drift. Eine Tabelle kann „heute" korrekt sein, aber für ein Audit ungeeignet, wenn der gestrige Zustand nicht wiederherstellbar ist. Im Bankkontext ist das besonders wichtig: Berichte, Einwilligungen, Überfälligkeiten und Risiko-Flags müssen reproduzierbar sein.

Drei Historie-Modi

1. Full refresh — alles aus den Quellen neu aufbauen. Gut für ein Lehr-

beispiel, schlecht für große produktive Tabellen.

1. Incremental model — geänderte Zeilen hinzufügen oder aktualisieren. Erfordert

eine Strategie, einen eindeutigen Schlüssel und eine Replay-Richtlinie.

1. Snapshot — Attributänderungen über die Zeit speichern. Nützlich für Status,

Segmente, Einwilligungszustand und sich langsam ändernde Dimensionen.

Im Lehrbeispiel überladen wir nicht alle Modelle mit Incremental-Logik, aber wir müssen verstehen, wo sie im produktiven Kreis erscheinen wird.

Was in die Spezifikation gehört

Für ein Modell mit Historie muss die Spezifikation Folgendes beantworten:

• welcher Schlüssel die Zeile bestimmt;
• welches Feld die Ereignis- oder Änderungszeit definiert;
• ob die Vergangenheit neu berechnet werden kann;
• was bei verspätet eingegangenen Daten zu tun ist;
• welche Anweisung die Sicherheit des Replays belegt.

Schlechte Formulierung:

Eine inkrementelle Ladung durchführen.

Gute:

Das Modell verwendet `transaction_id` als eindeutigen Schlüssel und `transaction_date` als
Ereignisdatum. Verspätete Zeilen innerhalb von 7 Tagen dürfen Aggregate aktualisieren. Ältere
Korrekturen erfordern eine PatchSpec und die Bestätigung durch einen Reviewer.

Prüffakten

Mindestfakten:

• ein wiederholter dbt build ändert das Ergebnis nicht ohne Änderung der Rohdaten;
• der eindeutige Schlüssel wird nicht dupliziert;
• das Ereignisdatum ist nicht null;
• das Replay-Fenster ist beschrieben;
• der Reviewer hat manuell bestätigt, dass sich die Semantik der Historie nicht geändert hat.

Qwen-Abfrage

Lies specs und marts.
Finde Modelle, bei denen Historie, Incremental-Strategie oder Snapshot benötigt werden.
Gib für jedes den Schlüssel, das Ereignisdatum, die Replay-Richtlinie und offene Fragen zurück.
SQL nicht ändern.

Minimale Ausgabe

Nach dem Kapitel erstellen Sie eine Notiz:

# Historie-Richtlinie

## Kundenattribute
## Kartenoperationen
## Kredite
## Open API Consents
## Replay und verspätete Daten

Wenn ein Modell keine Historie hat, schreiben Sie explizit, warum.

Analyse für den Leser

Die Datenhistorie wirkt wie ein technisches Thema, bis die Frage „was wussten wir

zu diesem Zeitpunkt?" aufkommt. Für Berichtswesen und Risiko ist das kritisch. Eine heutige Neuberechnung kann die korrekte aktuelle Tabelle liefern, aber eine falsche historische Antwort. Wenn gestern eine Einwilligung aktiv war und heute widerrufen wird, zerstört ein einfaches Überschreiben des Zustands eine wichtige Tatsache.

Inkrementelles Modell, Snapshot und Full Refresh sind nicht nur Wege, eine Tabelle zu schreiben. Es sind unterschiedliche Versprechen über die Zeit. Full Refresh sagt: Wir bauen den aktuellen Zustand aus der Quelle neu auf. Incremental Model sagt: Wir fügen geänderte Zeilen nach Schlüssel und Replay-Fenster hinzu oder aktualisieren sie. Snapshot sagt: Wir speichern die Attributänderung über die Zeit. Die Wahl zwischen ihnen muss vor der Implementierung dokumentiert werden, sonst wählt der Agent die bequemste Variante.

Besonders gefährlich sind verspätet eingegangene Daten. Wenn eine Transaktion aus der vergangenen Woche heute eingeht, darf man bereits erstellte Aggregate ändern? Wenn ja, für welchen Zeitraum? Wenn nein, wo wird die Ausnahme festgehalten? Solche Fragen darf man nicht nach Inspiration innerhalb von is_incremental() entscheiden. Sie gehören zum Vertrag, weil sie die Reproduzierbarkeit des Ergebnisses verändern.

Das Lehrbeispiel muss nicht alle Historie-Modi implementieren. Aber der Leser muss

lernen zu sehen, wo Historie im produktiven Kreis benötigt wird. Für Kunden sind es Attribute und Segmente. Für Zahlungen — Transaktionszeit und verspätete Eingänge. Für Einwilligungen — Aktivität und Widerruf. Für Kredite — Stage und Überfälligkeit. Eine gute Spezifikation benennt zumindest diese Grenzen, auch wenn die erste Version ein einfacher Full Refresh bleibt.

Übung

Wählen Sie eine Quelle und entscheiden Sie, ob sie Full Refresh, Incremental Model oder Snapshot benötigt. Notieren Sie den Schlüssel, das Ereignisdatum, die Replay-Richtlinie und was mit verspäteten Daten zu tun ist.

Typischer Fehler

Zu denken, dass materialized='incremental' die Historie löst. Das ist nur ein Schreib- modus. Den Sinn der Historie bestimmen Schlüssel, Zeitstempel, Replay-Richtlinie und Reviewer-Fakten.

Kontrollfragen

1. Wie unterscheidet sich Incremental Model von Snapshot?
2. Welche Fakten belegen die Sicherheit des Replays?
3. Warum müssen verspätet eingegangene Daten vor dem SQL beschrieben werden?