Thema: Teil 13. Inkremente, Snapshots und Verlauf
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2-3 Stunden
Voraussetzungen: Grundlegendes Verständnis von dbt (data build tool) und Datenmodellen
SQL-Kenntnisse auf dem Niveau des Schreibens von Abfragen und des Verständnisses von Fensterfunktionen
Verständnis der Konzepte von Data Warehouses und ETL/ELT-Prozessen
Vertrautheit mit dem Bereich der Bankberichterstattung (Kunden, Zahlungen, Kredite, Einwilligungen)
Grundlegendes Verständnis des Konzepts der Datenreproduzierbarkeit
Lernziele: Die drei Verlaufsmodi von Daten (full refresh, incremental, snapshot) unterscheiden und verstehen, wann welcher anzuwenden ist
Korrekte Spezifikationen für Modelle mit Verlauf formulieren, einschließlich Schlüssel, Ereignisdatum und Wiedergaberichtlinie
Einen Satz von Prüffakten bestimmen, die die Sicherheit der Modellwiedergabe belegen
Anforderungen an verspätet eingehende Daten analysieren und vertragliche Einschränkungen formulieren
Das erworbene Wissen anwenden, um die Verlaufsstrategie im Bankbereich (Kunden, Karten, Kredite, Einwilligungen) auszuwählen
Übersicht: Datenverlauf ist nicht nur ein technisches Detail, sondern ein Vertrag über die Zeit zwischen Quelle und Konsument. In der Bankberichterstattung macht die Unfähigkeit, den gestrigen Zustand einer Tabelle wiederherzustellen, ein Audit unmöglich und untergräbt das Vertrauen in die Modelle. Das Kapitel führt drei Verlaufsmodi (full refresh, incremental, snapshot) als unterschiedliche „Zeitversprechen“ ein, zeigt, was eine korrekte Spezifikation eines Modells mit Verlauf enthalten muss, beschreibt die minimalen Prüffakten und die Wiedergaberichtlinie. Besondere Aufmerksamkeit gilt verspätet eingehenden Daten, die die Reproduzierbarkeit des Ergebnisses verändern und daher vor dem Schreiben von SQL beschrieben werden müssen. Der Leser lernt zu erkennen, wo im produktiven Bereich Verlauf benötigt wird, und explizite Entscheidungen zu formulieren, anstatt sie dem „Ermessen des Agenten“ zu überlassen.
Schlüsselkonzepte: Full refresh: Modus, bei dem die Tabelle bei jeder Ausführung komplett aus den Quellen neu aufgebaut wird. Liefert ein einfaches, immer aktuelles Bild „zum heutigen Tag“, erhält aber nicht den gestrigen Zustand. Geeignet für Lernbeispiele, kleine Tabellen und selten aktualisierte Referenzdaten. Im produktiven Bereich wird es teuer und unsicher, wenn die Tabelle groß ist und von anderen Modellen abhängt.
Incremental model: Modus, bei dem dbt nur geänderte Zeilen anhand eines eindeutigen Schlüssels und Datumsfensters hinzufügt oder aktualisiert. Erfordert eine explizite Strategie (insert, merge, delete+insert), einen eindeutigen Schlüssel und eine Wiedergaberichtlinie. Spart Ressourcen, schafft aber versteckte Verpflichtungen: Was geschieht mit verspäteten Zeilen, wie lange wird das Fenster aufbewahrt, kann die Vergangenheit neu berechnet werden.
Snapshot: Modus, der die Änderung eines Attributs im Zeitverlauf speichert. Jede Version einer Zeile erhält einen Aktivierungszeitstempel (dbt_valid_from, dbt_valid_to), sodass die Frage „was wussten wir gestern“ beantwortet werden kann. Geeignet für Statuswerte, Segmente, Einwilligungen und sich langsam ändernde Dimensionen, bei denen die Audit-Rückverfolgbarkeit wichtig ist.
Eindeutiger Schlüssel (unique key): Attribut oder Attributmenge, die eine Zeile im Modell eindeutig identifiziert. Ohne expliziten Schlüssel sind weder Aktualisierung noch korrekter Snapshot noch Duplikatprüfung möglich. Der Schlüssel muss zeitstabil sein und darf nicht von veränderlichen Geschäftsfeldern abhängen.
Ereignisdatum (event date): Feld, das den Zeitpunkt bestimmt, auf den sich ein Fakt bezieht. Unterscheidet sich vom Ladedatum der Zeile: Eine Operation kann gestern stattfinden und heute im System eintreffen. Das Ereignisdatum ist die Grundlage für Wiedergabefenster, Filter im Inkrementalmodell und die SCD-Logik des Snapshots.
Wiedergaberichtlinie (replay policy): Explizite Beschreibung, ob und für welchen Zeitraum die Vergangenheit neu berechnet werden darf. Ohne sie kann jeder Neustart des Modells historische Aggregate unbemerkt verändern. Die Richtlinie beantwortet: Welche Zeilen dürfen rückwirkend aktualisiert werden, welche erfordern einen PatchSpec und die Bestätigung eines Reviewers.
Verspätet eingehende Daten (late-arriving data): Zeilen, deren Ereignisdatum älter als das letzte Datum im Inkrementalmodell ist. Ihre Behandlung ist die Hauptquelle versteckter semantischer Drift. Entscheidungen (ob sie in Aggregate aufgenommen werden, für welches Fenster, was mit bereits erstellten Berichten geschieht) dürfen nicht innerhalb von is_incremental() belassen werden – dies ist eine vertragliche Angelegenheit.
Patchspec: Formaler Antrag auf Änderung eines bereits fixierten historischen Fakts. Wird verwendet, wenn eine verspätete Korrektur einen Zeitraum betrifft, der über das Wiedergabefenster hinausgeht, und erfordert die Bestätigung eines Reviewers sowie eine explizite Beschreibung der Konsequenzen.
Prüffakten (validation facts): Minimaler Satz von Aussagen, die die Korrektheit des Modellverlaufs belegen: ein erneuter dbt build ändert das Ergebnis nicht ohne Änderung der Rohdaten, der eindeutige Schlüssel wird nicht dupliziert, das Ereignisdatum ist nicht null, das Wiedergabefenster ist beschrieben, ein Reviewer hat die Verlaufsemantik manuell bestätigt.
Reproduzierbarkeit (reproducibility): Eigenschaft eines Modells, bei der sein Ergebnis aus einem fixierten Satz von Eingabedaten und der Spezifikation wiederhergestellt werden kann. Sie wird durch jede implizite Umschreibung der Vergangenheit zerstört, einschließlich eines full refresh einer Tabelle, für die Verlauf erforderlich ist.
Wichtige Termine: Basel-III-Abkommen (2010-2011): Verschärfung der Anforderungen an die Reproduzierbarkeit der Bankberichterstattung, einschließlich Risikoberichterstattung und Kundensegmentierung; erhöht die Bedeutung von Snapshot-Ansätzen
Inkrafttreten der DSGVO (25. Mai 2018): Verstärkte die Anforderungen an die Fixierung und das Audit von Kundeneinwilligungen und machte den Verlauf von Einwilligungen obligatorisch statt wünschenswert
IFRS-9-Standard (seit 2018 schrittweise eingeführt): Erfordert die Verfolgung von Kreditrisikostufen (Stage 1/2/3) und Überfälligkeit im Zeitverlauf, was ohne expliziten Verlauf unmöglich ist
Anforderungen des 152-FZ (in Kraft seit 2014): Russisches Gesetz über personenbezogene Daten, das die Speicherung von Informationen über Verarbeitung und Einwilligungen in historischer Perspektive verpflichtend vorschreibt
Übungsaufgaben: Name: Auswahl der Verlaufsstrategie für eine Quelle
Problem: Sie erhalten die Tabelle raw.transactions mit den Spalten transaction_id, client_id, transaction_date, amount, status, load_dttm. Für 30 Tage enthält die Tabelle etwa 5 Millionen Zeilen, das durchschnittliche Volumen täglicher neuer Operationen beträgt 150 000. Der Status einer Operation kann rückwirkend (z. B. von PENDING auf CONFIRMED oder DECLINED) innerhalb von 14 Tagen ab dem Operationsdatum geändert werden. Bestimmen Sie die geeignete Verlaufsstrategie (full refresh, incremental oder snapshot), notieren Sie den eindeutigen Schlüssel, das Ereignisdatum, die Wiedergaberichtlinie und die Regeln zur Behandlung verspätet eingehender Daten.
Lösung: 1. Wir wählen das incremental model, weil ein full refresh bei 5 Mio. Zeilen zu teuer ist und ein Snapshot überdimensioniert wäre – wir benötigen die aktuellen Status der Operationen, nicht den Verlauf ihrer Änderungen. 2. Der eindeutige Schlüssel ist transaction_id (stabil, unabhängig vom Status). 3. Das Ereignisdatum ist transaction_date, nicht load_dttm. 4. Wiedergaberichtlinie: Aktualisierungen sind für Zeilen zulässig, deren transaction_date in die letzten 14 Tage ab dem aktuellen Datum fällt; für ältere Zeilen ist ein PatchSpec erforderlich. 5. Verspätet eingehende Daten: Wenn load_dttm heute ist und transaction_date älter als 14 Tage, wird die Zeile angenommen, aber Aggregate für diesen Tag werden nicht ohne Reviewer neu berechnet. 6. Inkrementalstrategie: merge nach transaction_id, Filter in is_incremental() nach transaction_date >= current_date - 14. 7. Prüffakten: Ein erneuter dbt build ändert die Ergebnistabelle nicht ohne neue Rohdaten, die Eindeutigkeit von transaction_id ist gewahrt, transaction_date is not null.
Komplexität: intermediate
Name: Erstellung einer Spezifikation für ein Modell mit Verlauf
Problem: Schreiben Sie eine schlechte Formulierung einer Spezifikation in eine gute um. Schlechte Formulierung: „Eine inkrementelle Beladung für das Modell client_segments implementieren“. Zusätzlicher Kontext: Das Modell speichert das Kundensegment (MASSE, VIP, STANDARD, RISK), das Segment wird vierteljährlich überprüft, kann sich aber bei großen Ereignissen (Ausfall, Beschwerde bei der Aufsichtsbehörde) häufiger ändern.
Lösung: Schlechte Formulierung: „Inkrementelle Beladung implementieren“. Gute Formulierung: „Das Modell client_segments verwendet client_id als eindeutigen Schlüssel und segment_effective_date als Ereignisdatum. Das Segment des Kunden wird zu jedem segment_effective_date bestimmt. Änderungen innerhalb des Quartals (Ausfall, Beschwerde bei der Aufsichtsbehörde) können den Datensatz des Kunden rückwirkend aktualisieren, jedoch nur innerhalb des aktuellen Quartals. Änderungen für vergangene Quartale erfordern einen PatchSpec und die Bestätigung eines Reviewers. Für die Auditierung des Segments im Zeitverlauf wird ein Snapshot client_segments_history mit den Feldern dbt_valid_from und dbt_valid_to verwendet, wobei der Snapshot-Schlüssel client_id und die Strategie timestamp ist. Die Verlaufsemantik wird vor dem ersten Release vom Leiter der Risikoberichterstattung bestätigt“.
Komplexität: intermediate
Name: Diagnose eines Verlaufsproblems
Problem: Das Risikoberichterstattungsteam beschwert sich: „Gestern war der Kunde im Dashboard im VIP-Segment, heute ist er es nicht mehr“. Das Modell client_segments arbeitet im Modus full refresh. Was ist passiert? Wie hätte das Modell aufgebaut sein müssen?
Lösung: Was passiert ist: Der full refresh hat die Tabelle neu aufgebaut, und das aktuelle Segment des Kunden hat sich geändert (z. B. erfüllt der Kunde die VIP-Kriterien nicht mehr). Der Verlauf des vorherigen Zustands wurde nicht gespeichert. Das Dashboard zeigt nur den aktuellen Snapshot und kann die Frage „was wussten wir gestern“ nicht beantworten. Lösung: Das Modell client_segments hätte entweder einen Snapshot (mit den Feldern dbt_valid_from, dbt_valid_to und dem Schlüssel client_id) oder einen inkrementellen Modus mit vollständigem Änderungsverlauf haben müssen. Für analytische Segment-Marts ist die richtige Wahl ein Snapshot, da sich das Segment selten ändert, aber jede Änderung für das Audit bedeutsam ist. Das Dashboard muss auf den Mart mit Filter nach dbt_valid_from <= report_date < dbt_valid_to zugreifen, nicht auf die aktuelle Tabelle. Zusätzlich muss in der Spezifikation die Wiedergaberichtlinie beschrieben werden: ob das Segment für vergangene Zeiträume rückwirkend geändert werden kann oder ob dies einen PatchSpec erfordert.
Komplexität: intermediate
Name: Qwen-Abfrage zur Auditierung von Modellen
Problem: Formulieren Sie eine Abfrage an den Assistenten Qwen, die in Ihrem dbt-Projekt alle Modelle findet, in denen Verlauf erforderlich, aber nicht beschrieben ist. Formulieren Sie, was der Assistent für jedes dieser Modelle zurückgeben soll, damit das Ergebnis in Aufgaben umgewandelt werden kann.
Lösung: Abfragetext: „Lies specs und marts. Finde Modelle, in denen Verlauf, eine incremental strategy oder ein Snapshot benötigt wird. Gib für jedes den Schlüssel, das Ereignisdatum, die Wiedergaberichtlinie und offene Fragen zurück. Ändere SQL nicht“. Der Assistent soll eine Tabelle der Form zurückgeben: model_name | unique_key | event_date | history_strategy | replay_window | late_data_policy | open_questions. Beispiel für client_segments: client_id | segment_effective_date | snapshot | N/A (aktuelles Quartal) | Änderungen im aktuellen Quartal – ja, früher – nur über PatchSpec | „Snapshot-Strategie nicht beschrieben“, „kein Prüffakt zur Reproduzierbarkeit“. Basierend auf dieser Antwort wird ein Aufgabenbacklog gebildet: Spezifikation hinzufügen, Snapshot implementieren, Tests auf Schlüssel-Duplikate und nicht-leeres Ereignisdatum schreiben, Richtlinie mit dem Modelleigentümer abstimmen.
Komplexität: beginner
Fallstudien: Name: Verlust des Einwilligungsverlaufs eines Kunden in Open API
Szenario: Eine große russische Bank hat Open API für Partnerservices (Versicherungen, Broker, Marktplätze) eingeführt. Jede Partneranfrage erfordert eine aktive Einwilligung des Kunden zur Datenübermittlung. Einwilligungen werden im Modell consents gespeichert, das im Modus full refresh arbeitet: Bei jeder Ausführung wird die Tabelle komplett neu aufgebaut, und nur der letzte Status (active oder revoked) bleibt erhalten.
Aufgabe: Im Juni 2024 beschwerte sich ein Kunde bei der Zentralbank, dass ein Partner-Broker seine Daten ohne Erlaubnis an eine Versicherung übermittelt habe. Die Bank versuchte, den Verlauf wiederherzustellen: „Welche Einwilligung war am 15. Mai aktiv, als der Partner die Anfrage sendete?“ Es stellte sich heraus, dass die Tabelle consents für den 15. Mai bereits neu aufgebaut war – die aktuelle Version zeigt nur den heutigen Status. Ein Auditprotokoll existiert, ist aber nicht über einen eindeutigen Schlüssel und ein Ereignisdatum mit dem Modell verknüpft. Die Aufsichtsbehörde verlangte die Wiederherstellung des Verlaufs für 6 Monate, aber die Daten sind nicht vorhanden. Parallel entdeckte die Risikoabteilung, dass ein Teil der Operationen im März den Status „Einwilligung aktiv“ hatte, obwohl der Kunde sie tatsächlich im Februar widerrufen hatte – der full refresh ersetzte „revoked“ durch „active“ für alle vergangenen Zeiträume. Die Reproduzierbarkeit der Berichterstattung ist verletzt, ein Audit ist unmöglich.
Lösung: Das Datenteam realisierte innerhalb von 6 Wochen die folgenden Änderungen. 1) Ein Snapshot-Modell consents_history wurde erstellt mit dem eindeutigen Schlüssel (client_id, partner_id, scope) und der timestamp-Strategie auf dem Feld updated_at; die Tabelle speichert nun Paare aus dbt_valid_from / dbt_valid_to. 2) Der aktuelle Mart consents blieb full refresh, erhielt aber die explizite Kennzeichnung „nicht für Audit der Vergangenheit verwenden“. 3) Für jedes Modell mit Verlauf wurde eine Spezifikation geschrieben: Schlüssel, Ereignisdatum (consent_updated_at), Wiedergaberichtlinie (rückwirkende Änderungen innerhalb von 30 Tagen aktiv, danach nur über PatchSpec mit Bestätigung durch Compliance), Regeln zur Behandlung verspätet eingehender Daten (wenn updated_at < 30 Tage – annehmen; wenn älter – in Ausnahmen erfassen, Aggregate nicht neu berechnen). 4) Es wurde ein Test auf Eindeutigkeit des Schlüssels im Snapshot und der Test „ein erneuter dbt build ändert das Ergebnis nicht ohne neue Rohdaten“ eingeführt. 5) Die Wiederherstellung des Verlaufs für 6 Monate erfolgte über das Auditprotokoll mit manuellem Abgleich für 200 zufällige Kunden; die Genauigkeit der Wiederherstellung betrug 99,4 % (Abweichungen in 0,6 % der Fälle wurden erklärt und dokumentiert).
Ergebnis: Die Bank stellte der Aufsichtsbehörde den wiederhergestellten Einwilligungsverlauf und einen detaillierten Bericht über die Speicherarchitektur zur Verfügung. Strafmaßnahmen konnten durch Transparenz und schnelle Reaktion gemildert werden. Nach dem Vorfall fixierte das Team folgende Regelung: „Kein Modell, das einen Kundenstatus oder ein Kundensegment enthält, wird ohne explizite Verlaufsrichtlinie und Prüffakten releast“. Im folgenden Quartal wurde das gleiche Schema auf die Modelle client_segments, credit_risk_stages, card_status angewendet – überall, wo zuvor full refresh mit Verlaufsverlust verwendet wurde. Die durchschnittliche Zeit zur Wiederherstellung des Verlaufs auf Anfrage der Aufsichtsbehörde reduzierte sich von 3 Wochen auf 2 Tage.
Gewonnene Erkenntnisse: Der Modus materialized='incremental' allein löst den Verlauf nicht – er ändert nur die Art des Schreibens. Den Sinn des Verlaufs bestimmen Schlüssel, Ereignisdaten und Wiedergaberichtlinie
Full refresh ist nur für Modelle zulässig, bei denen die Vergangenheit keine Rolle spielt; für alles, was Statuswerte, Einwilligungen und Segmente betrifft, ist ein Snapshot oder ein Inkrementalmodell mit explizitem Verlauf erforderlich
Verspätet eingehende Daten sind ein vertragliches, kein technisches Problem: Ihre Behandlung darf nicht dem „Ermessen von is_incremental()“ überlassen werden, sondern Fenster und Ausnahmen müssen explizit beschrieben werden
Die Reproduzierbarkeit der Berichterstattung ist eine Eigenschaft des Gesamtsystems; selbst wenn einzelne Tabellen korrekt sind, macht der Verlust der zeitlichen Verbindung zwischen ihnen ein Audit unmöglich
Die Spezifikation eines Modells mit Verlauf muss 5 Fragen beantworten: Schlüssel, Ereignisdatum, Möglichkeit der Neuberechnung, Richtlinie für verspätete Daten, Team, das die Sicherheit der Wiedergabe nachweist
Verwandte Konzepte: Snapshot
Incremental model
Verspätet eingehende Daten
Wiedergaberichtlinie
Prüffakten
Spezifikation eines Modells mit Verlauf
Name: Verspätet eingegangene Zahlung und zerstörte Aggregate
Szenario: Eine Retailbank berechnet tägliche Aggregate für Kartenoperationen: Ausgabenvolumen, durchschnittlicher Bon, Ablehnungsquote. Aggregate werden vom Inkrementalmodell daily_card_aggr gebildet, das um 02:00 Uhr alle Operationen vom Vortag nimmt und das entsprechende Aggregat aktualisiert. Der eindeutige Schlüssel ist operation_id, das Ereignisdatum ist operation_date, das Wiedergabefenster beträgt 3 Tage.
Aufgabe: Am Morgen des 10. Juni stellte die Betrugsüberwachung fest, dass im Bericht für den 5. Juni eine große Operation (180 000 ₽) fehlte, die erst am 9. Juni verbucht wurde. Ursache: In der Nacht vom 5. auf den 6. Juni gab das Processing die verzögerte Operation zurück, und der dbt-Build am 6. Juni berechnete das Aggregat für den 5. Juni nicht mehr neu (außerhalb des 3-Tage-Fensters). Die Betrugsüberwachung traf Entscheidungen auf Basis unvollständiger Daten. Parallel entstand eine ähnliche Situation mit einer Operation vom 7. Juni, die am 10. eintraf: Das Aggregat für den 7. wurde aktualisiert, während der 8. und 9. ohne benachbarte Kontextoperationen blieben. Das Team konnte nicht erklären, ob die Aggregate der vergangenen Woche überhaupt „korrekt“ sind.
Lösung: Das Team überarbeitete die Wiedergaberichtlinie. 1) Das Wiedergabefenster wurde für große Operationen (amount > 100 000 ₽) von 3 auf 7 Tage erweitert, und im dbt-Modell wurde eine Verzweigung hinzugefügt: „if amount > threshold, Fenster auf 7 Tage erweitern“. 2) Für alle verspätet eingehenden Operationen außerhalb des Fensters wurde ein eigener Staging-Layer late_operations erstellt, der Aggregate nicht korrigiert, sondern in den Ausnahmenbericht einfließt. 3) Die Modellspezifikation wurde um den Punkt ergänzt: „Operationen mit einem Ereignisdatum älter als 7 Tage können nur über einen PatchSpec mit Angabe des Grundes und Abstimmung mit dem Analysten in das Aggregat aufgenommen werden“. 4) Es wurde ein täglicher Test eingeführt: „Die Summe der Operationen in raw für die letzten 7 Tage entspricht der Summe der Operationen im Aggregat für denselben 7-Tage-Zeitraum“, der Abweichungen erkennt, bevor sie den Konsumenten auffallen. 5) Der Betrugsüberwachung wurde vorrangiger Zugriff auf late_operations gewährt.
Ergebnis: In den folgenden 3 Monaten wurden 47 Fälle verspätet eingehender Operationen älter als 7 Tage registriert. Alle Fälle wurden nach der Regelung behandelt: 38 wurden über PatchSpec in die Aggregate aufgenommen, 9 wurden als Processing-Fehler anerkannt und abgelehnt. Die Betrugsüberwachung hörte auf, sich über „verlorene“ Operationen zu beschweren, und begann, den Berichten zu vertrauen. Die durchschnittliche Reaktionszeit auf große Anomalien reduzierte sich von 24 Stunden auf 6 Stunden. Das Team formulierte das Prinzip: „Das Wiedergabefenster muss mit der maximal sinnvollen Datenverzögerung in der Quelle abgestimmt sein, nicht mit der Bequemlichkeit des dbt-Builds“.
Gewonnene Erkenntnisse: Die Größe des Wiedergabefensters ist eine vertragliche Entscheidung, kein technischer Parameter; sie muss die realen Verzögerungen in den Quellen widerspiegeln, nicht den Wunsch, Build-Zeit zu sparen
Verspätet eingehende Daten dürfen nicht „stillschweigend verworfen“, sondern müssen explizit in einem eigenen Layer erfasst und den Eigentümern der Berichterstattung zugänglich gemacht werden
PatchSpec ist kein „Krücke für Fehler“, sondern ein normaler Mechanismus für rückwirkende Änderungen mit expliziter Verantwortung des Reviewers
Prüffakten müssen Abstimmungen zwischen raw und marts einschließen, nicht nur Tests auf Eindeutigkeit und Nicht-Null-Werte
Die Verlaufsemantik (kann das Aggregat für den vergangenen Tag geändert werden) ist wichtiger als die Schreibweise (merge, insert, snapshot)
Verwandte Konzepte: Incremental model
Verspätet eingehende Daten
Wiedergaberichtlinie
PatchSpec
Prüffakten
Lerntipps: Beginnen Sie mit einer Tabelle der drei Verlaufsmodi (full refresh, incremental, snapshot) und formulieren Sie für jeden Modus das „Zeitversprechen“ in einem Satz – das hilft, die Strategie in der Praxis schnell auszuwählen
Versuchen Sie für jedes Modell in Ihrem Projekt, die 5 Fragen der Spezifikation zu beantworten (Schlüssel, Ereignisdatum, kann die Vergangenheit neu berechnet werden, was mit verspäteten Daten geschieht, welches Team die Sicherheit der Wiedergabe nachweist) – wenn Sie auch nur eine nicht beantworten können, ist der Verlauf nicht beschrieben
Verwechseln Sie das Ereignisdatum nicht mit dem Ladedatum (load_dttm): Das sind zwei verschiedene Größen, und das Inkrementalmodell muss nach dem Ereignisdatum filtern, sonst verlieren Sie verspätet eingehende Daten
Formulieren Sie eine Abfrage an Qwen (oder einen beliebigen LLM-Assistenten) zu Ihrem Projekt nach der Vorlage aus dem Kapitel – das liefert einen schnellen Schnitt der Modelle, in denen der Verlauf nicht beschrieben ist, und verwandelt das abstrakte Thema in ein konkretes Backlog
Erstellen Sie im Projekt ein separates Dokument „Verlaufsrichtlinie“ nach der Vorlage aus dem Kapitel (Kundenattribute, Kartenoperationen, Kredite, Open-API-Einwilligungen, Wiedergabe und verspätete Daten) und aktualisieren Sie es bei jedem Release eines neuen Modells mit Status oder Segment
Schreiben Sie Prüffakten als ausführbare Prüfungen, nicht als Textabsatz: Test auf Eindeutigkeit des Schlüssels, Test „erneuter dbt build == dbt build“, Abgleich der Summen zwischen raw und marts pro Fenster
Denken Sie bei der Wahl zwischen incremental und snapshot nicht an die Tabellengröße, sondern an die Fragen der Konsumenten: Wenn „wie viel jetzt“ gefragt wird – incremental, wenn „was war gestern“ – snapshot
Typische Falle: materialized='incremental' setzen und glauben, der Verlauf sei gelöst. Stellen Sie immer die Frage „Was passiert, wenn in raw eine Aktualisierung einer Zeile aus dem letzten Monat eintrifft?“ – wenn die Antwort nicht beschrieben ist, ist der Verlauf nicht gelöst
Lernen Sie, Spezifikationen kritisch zu lesen: Die Formulierung „inkrementelle Beladung implementieren“ ist eine rote Flagge, die eine Klärung aller 5 Punkte erfordert
Gehen Sie zur Vorbereitung auf die Kontrollfragen jede mit einem realen Beispiel aus Ihrem Projekt durch: incremental vs. snapshot, Fakten zur Sicherheit der Wiedergabe, Vertrag vs. SQL für verspätete Daten
Zusätzliche Ressourcen: dbt-Dokumentation zu Inkrementalmodellen: https://docs.getdbt.com/docs/build/incremental-models – offizielles Handbuch zur Konfiguration von is_incremental(), Strategien merge/insert/delete+insert, Umgang mit eindeutigem Schlüssel und Datumsfenstern
dbt-Dokumentation zu Snapshots: https://docs.getdbt.com/docs/build/snapshots – Handbuch zu SCD Type 2, Strategien timestamp und check, Feldern dbt_valid_from / dbt_valid_to, Abhängigkeitsgraphen von Snapshots
Buch 'fundamentals of data engineering' (joe reis, matt housley): Kapitel zur schrittweisen Beladung und CDC, einschließlich Mustern für verspätet eingehende Daten und Wiedergabefenster
Buch 'data quality: the accuracy dimension' (jack olson): Kapitel zur Reproduzierbarkeit und zum Audit von Daten, anwendbar auf die Bankberichterstattung
IFRS-9-Standard (MSFО 9): https://www.ifrs.org – offizieller Text des Standards, erläutert die Anforderungen an den Verlauf von Kreditrisikostufen und Überfälligkeit
Basel-III-Abkommen: Dokumente des Basler Ausschusses für Bankenaufsicht (BCBS) – Anforderungen an die Reproduzierbarkeit der Risikoberichterstattung
dbt-utils-Paket: https://github.com/dbt-labs/dbt-utils – fertige Tests und Makros, einschließlich surrogate_key, Prüfung auf Nicht-Null-Werte und Abstimmungen zwischen Modellen
Blog dbt labs 'how we structure our dbt projects': Abschnitt zu den Schichten staging / intermediate / marts und Beschreibung der Verträge zwischen den Schichten, einschließlich Verlauf
Zusammenfassung: Datenverlauf ist ein Vertrag über die Zeit, kein technisches Implementierungsdetail. Das Kapitel führt drei Modi (full refresh, incremental, snapshot) als unterschiedliche „Zeitversprechen“ ein: das Aktuelle neu aufbauen, das Geänderte hinzufügen/aktualisieren, die Attributänderung speichern. Die Wahl zwischen ihnen muss vor dem SQL in der Spezifikation festgehalten werden: welcher Schlüssel die Zeile bestimmt, welches Feld das Ereignisdatum ist, ob die Vergangenheit neu berechnet werden darf, was mit verspätet eingehenden Daten geschieht, welches Team die Sicherheit der Wiedergabe nachweist. Verspätet eingehende Daten sind die Hauptquelle versteckter semantischer Drift, und ihre Behandlung gehört in den Vertrag, nicht in is_incremental(). Im Bankbereich ist Verlauf für Kundenattribute und -segmente, Kartenoperationen, Kreditstadien und Open-API-Einwilligungen verpflichtend. Minimale Prüffakten (erneuter dbt build ändert das Ergebnis nicht, Eindeutigkeit des Schlüssels, nicht-leeres Ereignisdatum, beschriebenes Fenster, Bestätigung durch Reviewer) verwandeln den Verlauf von einer Absicht in eine messbare Eigenschaft des Modells. Wichtigste praktische Schlussfolgerung: Das Dokument „Verlaufsrichtlinie“ muss in jedem Projekt existieren und die Strategie für jede Entität explizit fixieren, auch wenn die erste Version ein einfaches full refresh bleibt.