Thema: Teil 1. Einführung: SDD für Daten
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2–3 Stunden (Theorie + Praxis mit lokalem Projekt)
Voraussetzungen: Grundlegende SQL-Kenntnisse (SELECT, JOIN, GROUP BY, Aggregatfunktionen)
Verständnis des Konzepts von Data Warehouses und Marts
Vertrautheit mit der Methodik Spec-Driven Development (SDD) aus dem ersten Band
Grundlegende Kenntnisse von dbt (Modelle, Sources, Tests)
Sicherer Umgang mit Kommandozeile und Git
Lernziele: Den Hauptunterschied zwischen SDD Data und einem traditionellen dbt-Kurs formulieren: Die Arbeitsreihenfolge verläuft von Mission und Spezifikation zum SQL, nicht umgekehrt.
Erklären, warum eine unsichtbare Veränderung der Datenbedeutung (Grain, Metrik, Freshness, PII) gefährlicher ist als ein Fehler im Code einer Webanwendung.
Die Rolle der Datenprodukt-Spezifikation als einziger Quelle der Wahrheit und den Platz von dbt als Ausführer der festgehaltenen Zusage bestimmen.
Drei Grundregeln von SDD Data aufzählen: Die Spezifikation lebt im Repository, der Prüfsachverhalt hat einen Befehl oder einen Reviewer-Schritt, Autor und Reviewer arbeiten in unterschiedlichen Modi.
Einen lokalen Smoke-Test des Lehr-DataLakeHouse auf DuckDB ausführen und den eigenen Lesemodus des Kurses festhalten.
Übersicht: Der erste Teil des Buches führt die Methodik Spec-Driven Development in Bezug auf Datenplattformen ein. Wenn im ersten Band SDD die Features von Webanwendungen vor Agentenfehlern in Routen und UI schützte, schützt es hier die Bedeutung der Daten: Granularität des Marts, Korrektheit der Metriken, Aktualität, Richtlinie zu personenbezogenen Daten und Kompatibilität mit nachgelagerten Konsumenten. Die Hauptthese des Teils: dbt bleibt das wichtigste Transformationswerkzeug, ist aber nicht die Quelle der Bedeutung. Die Bedeutung lebt in den Spezifikationen, und SQL muss die festgehaltene Zusage ausführen, nicht sie nachträglich schaffen.
Das Lehrprojekt — DataLakeHouse der fiktiven Bank „Bank Sewerny Most“. Bis zum Ende des Buches baut der Leser ein lokales dbt-Projekt auf DuckDB, das fünf finale Marts zusammenführt: mart_customer_360, mart_card_turnover_daily, mart_payment_risk_signals, mart_credit_portfolio_quality und mart_open_api_consents. Alle Daten sind synthetisch, und der russische Bankenkontext dient als Satz von Einschränkungen: PII, Zahlungen, Einwilligungen, Risikosignale, regulatorische Berichterstattung. Dies ist eine reproduzierbare Lehrarchitektur, keine juristische Anleitung.
Der Teil legt den Rhythmus des gesamten Bandes fest: Zuerst hält der Leser die Zusage des Datenprodukts fest, macht sie dann über dbt ausführbar, beweist sie anschließend mit Fakten und gibt sie zur unabhängigen Prüfung. Auf Ebene des ersten Kapitels wird vom Leser verlangt, den Lesemodus zu wählen, den Smoke-Test auszuführen und in den Arbeitsnotizen das Verständnis festzuhalten, dass das Buch einen reproduzierbaren Datenproduktprozess aufbaut, nicht „eine Bank im Allgemeinen“.
Schlüsselkonzepte: Sdd data: Ein Entwicklungszyklus, in dem der Agent nicht mit der Implementierung beginnt. Zuerst halten Mensch und Agent die Absicht, Grenzen, Entscheidungen und Prüfsachverhalte fest, dann schreibt der Agent Code oder SQL gemäß den genehmigten Dateien, danach prüft ein separates Review nicht nur das Bestehen der Tests, sondern auch die Übereinstimmung des Ergebnisses mit der Spezifikation. Für Daten sieht der Zyklus so aus: Datenprodukt beschreiben → Vertrag definieren → dbt-Modell implementieren → Prüfsachverhalte ausführen → Auswirkung auf den Vertrag bewerten → Release-Beweise sammeln.
Spezifikation des Datenprodukts: Ein Dokument, das die Zusage an den Konsumenten festhält: welcher Grain zugesagt ist, welche Felder obligatorisch sind, welche verboten sind, welche Prüfungen eine Änderung zulassen, wer Drift oder Breaking Changes bestätigt. Lebt im Repository, nicht im Chat, und dient als einzige Quelle der Wahrheit.
Datenvertrag: Eine formale Vereinbarung zwischen Lieferant und Konsumenten des Marts über dessen Struktur und Semantik. Jede Vertragsänderung muss ausdrücklich festgehalten und genehmigt werden, sonst gilt sie als Breaking Change.
Grain (Granularität) des Marts: Eine semantische Einheit, die beschreibt, was eine Zeile in der Tabelle darstellt (zum Beispiel „ein Kunde“ oder „ein Kunde-Produkt“). Eine Änderung des Grains ist ein typisches Beispiel für eine unsichtbare Breaking Change der Bedeutung.
Unsichtbare Bedeutungsänderung: Ein Defekt, bei dem SQL kompiliert und dbt-Tests bestehen, der nachgelagerte Konsument aber eine andere Bedeutung der Zeilen erhält. In einer Webanwendung ist ein solcher Defekt oft sofort sichtbar, in Daten kann er über eine Woche später in einen Bericht, eine KPI oder ein Risikomodell gelangen.
Prüfsachverhalt: Ein Befehl, eine SQL-Abfrage oder ein manueller Reviewer-Schritt, die beweisen, dass das dbt-Modell die Spezifikation erfüllt hat, nicht nur die Tests bestanden hat. Ohne Prüfsachverhalt ist ein grüner dbt build kein korrekter Mart.
Dbt als Ausführer der Zusage: Die Positionierung von dbt in diesem Buch: ein Transformationswerkzeug, das das Verhalten überprüfbar macht, aber nicht entscheidet, was für das Geschäft wahr sein soll. Analog zu einem Test-Framework in einer normalen Anwendung.
Datalakehouse der Bank „Sewerny Most“: Ein Lehrprojekt auf DuckDB, lokal reproduzierbar. Umfasst fünf Marts: mart_customer_360, mart_card_turnover_daily, mart_payment_risk_signals, mart_credit_portfolio_quality, mart_open_api_consents. Alle Daten sind synthetisch.
Drei Grundregeln von sdd data: (1) Die Spezifikation lebt im Repository, nicht im Chat. (2) Ein Prüfsachverhalt muss einen Befehl, SQL oder einen manuellen Reviewer-Schritt haben. (3) Autor und Reviewer müssen in unterschiedlichen Modi arbeiten, auch wenn es derselbe CLI-Agent nach /clear ist.
Pii und Richtlinie zu personenbezogenen Daten: Eine Klasse von Einschränkungen, für die das Buch die Spezifikation vor SQL einführt. Im DataLakeHouse sind personenbezogene Daten, Einwilligungen und Risikosignale Bereiche, in denen „schnelles SQL“ Entscheidungen trifft, für die es keine Befugnis hat.
Konsumentenkette: Eine Metapher, die das Ausbreiten des Bedeutungsfehlers erklärt: Das Operationsteam entlädt die Quelle, der Data Engineer passt die Typen an, der Analyst baut den Bericht, das Risikoteam betrachtet das Signal, der Manager liest das Aggregat. Ein lokaler SQL-Fehler wird zu einem systemischen Bedeutungsfehler.
Smoke-Test und lokaler Track: Der Befehl bash smoke_all.sh aus book3/examples/bank-lakehouse. Ohne dbt generiert er synthetische Daten und prüft die Struktur, mit dbt führt er ein vollständiges dbt build aus. Dies ist der erste praktische Schritt des ersten Teils.
Vertragsdrift und Breaking Change: Drift ist die allmähliche Verschiebung des tatsächlichen Verhaltens des Marts von der Spezifikation. Breaking Change ist eine Änderung des Grains, der obligatorischen Felder oder der Metriksemantik, die den Vertrag mit den Konsumenten verletzt. Beide erfordern eine ausdrückliche Bestätigung durch den Eigentümer.
Wichtige Termine: Stufe 0: Ausführung von smoke_all.sh: Der erste praktische Schritt: einen lokalen Smoke-Test ausführen und sich vergewissern, dass das DataLakeHouse auf der Maschine des Lesers reproduzierbar ist.
Stufe 1: Festlegung des Lesemodus: Entscheidung, welchem Track der Leser folgt: Lehr-lokal auf DuckDB oder Abgleich mit der Kampf-Umgebung als Referenzschicht.
Stufe 2: Arbeitsnotizen: Festhalten in einer Markdown-Datei: „Erster Durchlauf: Ich baue ein lokales DataLakeHouse der Bank auf dbt-duckdb auf; einen Abgleich mit der Kampf-Umgebung implementiere ich erst nach der praktischen Prüfung“.
Übungsaufgaben: Name: Übung 1. Ausführung des lokalen Smoke-Tests für DataLakeHouse
Problem: Klonen Sie das Buch-Repository, wechseln Sie in das Verzeichnis book3/examples/bank-lakehouse und führen Sie bash smoke_all.sh aus. Zuerst ohne installiertes dbt — vergewissern Sie sich, dass das Skript synthetische Daten generiert und die Struktur prüft. Installieren Sie dann die Abhängigkeiten (dbt-core, dbt-duckdb) und führen Sie das vollständige dbt build aus. Halten Sie in den Notizen die Liste der erstellten Tabellen und die Ausführungszeit fest.
Lösung: Schritt 1: git clone <Buch-Repository> && cd <Buch-Verzeichnis>. Schritt 2: cd book3/examples/bank-lakehouse. Schritt 3: bash smoke_all.sh — ohne dbt sollte das Skript synthetische Parquet/CSV in das Verzeichnis data/ generieren und einen Strukturbericht ausgeben. Schritt 4: pip install dbt-core dbt-duckdb (oder Äquivalent für Ihren Paketmanager). Schritt 5: erneute Ausführung von bash smoke_all.sh — sollte dbt build ausführen und grün abschließen. Schritt 6: Untersuchen Sie die Datei dbt_project.yml und das Verzeichnis models/, finden Sie die fünf finalen Marts. Notieren Sie in den Notizen Beobachtungen zur Build-Zeit und zur Zeilenanzahl in jeder Mart-Tabelle.
Komplexität: beginner
Name: Übung 2. Szenario „Unsichtbare Grain-Änderung“
Problem: Öffnen Sie die Spezifikation (oder Beschreibung) des Marts mart_customer_360 und halten Sie schriftlich dessen Zusage fest: welcher Grain, welche obligatorischen Felder, welche verbotenen Felder, wer ist der Konsument. Fügen Sie dann gedanklich dem SELECT des Agenten das Feld product_code hinzu und beschreiben Sie, wie genau der Vertrag mit dem Konsumenten bricht, der über diesen Mart die Anzahl der aktiven Kunden zählte. Bereiten Sie ein Argument vor: Warum schützt selbst ein grüner dbt build den Bericht nicht.
Lösung: Schritt 1: Halten Sie den Grain fest — „eine Zeile pro customer_id“. Schritt 2: Listen Sie die obligatorischen Felder auf, zum Beispiel: customer_id, full_name, birth_date, segment, opened_at. Schritt 3: Listen Sie die verbotenen Felder auf, zum Beispiel: card_pan, phone, email, Einwilligungen. Schritt 4: Beschreiben Sie den Konsumenten — zum Beispiel den Bericht „Anzahl aktiver Kunden nach Segmenten“, der select segment, count(distinct customer_id) from mart_customer_360 group by segment ausführt. Schritt 5: Nach dem Hinzufügen von product_code beginnt dieselbe Abfrage ohne distinct Kunde-Produkt-Paare zu zählen, und mit distinct berücksichtigt sie nicht mehr, dass ein Kunde mehrere Produkte verschiedener Typen hat. Schritt 6: Argument: dbt-Tests wie not_null und unique auf customer_id bestehen weiterhin, weil customer_id eindeutig bleibt (wenn keine Kundenduplikate in den Daten vorliegen), aber der Bericht zeigt eine überhöhte Zahl an und ändert die Bedeutung.
Komplexität: intermediate
Name: Übung 3. Entwurf eines Prüfsachverhalts
Problem: Schreiben Sie für den Mart mart_card_turnover_daily einen Prüfsachverhalt in Form einer SQL-Abfrage, die beweist, dass die Summe der Umsätze pro Tag im Mart mit der Summe der Umsätze in der Raw-Quelle für denselben Tag übereinstimmt, mit einer Toleranz von ±0,01. Die Abfrage soll in der Datei tests/facts/mart_card_turnover_daily_recon.sql oder einer ähnlichen aufgezeichnet werden. Formulieren Sie im Text, was genau sie beweist und bei welcher Abweichung sie als Breaking Change gilt.
Lösung: Schritt 1: Bestimmen Sie die Quelle — zum Beispiel stg_card_transactions. Schritt 2: Schreiben Sie den Abgleich: with mart_sum as (select transaction_date, sum(amount) as mart_total from {{ ref('mart_card_turnover_daily') }} group by transaction_date), src_sum as (select transaction_date, sum(amount) as src_total from {{ source('core','card_transactions') }} group by transaction_date) select m.transaction_date, m.mart_total, s.src_total, abs(m.mart_total - s.src_total) as diff from mart_sum m join src_sum s using(transaction_date) where abs(m.mart_total - s.src_total) > 0.01. Schritt 3: Leeres Ergebnis — Erfolg. Schritt 4: Im Text festhalten: „Wenn diff > 0,01 für einen beliebigen Tag ist, gilt der Sachverhalt als fehlgeschlagen, das Release wird blockiert, Eigentümer ist das Risikoteam“. Schritt 5: Fügen Sie diese Datei als data_tests zu sources.yml hinzu oder binden Sie sie in CI ein.
Komplexität: intermediate
Name: Übung 4. Identifikation von PII im Mart
Problem: Öffnen Sie das Schema (SQL oder Beschreibung) des Marts mart_open_api_consents. Listen Sie die Felder auf, die Sie als PII oder sensibel klassifizieren würden. Formulieren Sie, welche davon an den Konsumenten weitergegeben werden dürfen, welche maskiert werden müssen, welche vollständig verboten sind. Erstellen Sie eine kurze Liste von Prüfungen, die diesen Mart begleiten müssen.
Lösung: Schritt 1: Schreiben Sie alle Felder auf. Schritt 2: Klassifizieren Sie. Zum Beispiel: client_id — Quasi-Identifikator, zulässig in aggregierten Schnitten; consent_id — zulässig; consent_type, granted_at, expires_at — zulässig; ip_address, user_agent, device_id — verboten oder maskiert; full_name, phone, email — verboten; reason_for_withdrawal — zulässig in Aggregaten. Schritt 3: Beschreiben Sie für jede Klasse die Behandlung. Schritt 4: Formulieren Sie Prüfungen: Test auf Abwesenheit von phone/email, Test auf Vorhandensein der obligatorischen consent_id, Prüfung der Mart-Aktualität (nicht älter als N Stunden), Prüfung des Anteils revoked gegenüber granted. Schritt 5: Fügen Sie die Liste der Eigentümer an: client_id — Dateneigentümer ist der Kundenservice, consent_id — Produkt der offenen APIs.
Komplexität: intermediate
Name: Übung 5. Review in einem anderen Modus
Problem: Stellen Sie sich vor, Sie haben die Spezifikation und das dbt-Modell für mart_payment_risk_signals geschrieben. Simulieren Sie nun ein Review „in einem anderen Modus“: Starten Sie eine CLI-Agentensitzung mit /clear, verbieten Sie sich ausdrücklich, das Modell zu ändern, und bitten Sie nur darum, die Übereinstimmung mit der Spezifikation zu prüfen. Notieren Sie, welche Fragen Sie dem Reviewer stellen würden und welche Beweise Sie verlangen würden.
Lösung: Schritt 1: Beschreiben Sie das zu prüfende Artefakt — Pfad zur Spezifikation, Pfad zum Modell, Pfad zu den Tests. Schritt 2: Halten Sie das Verbot fest — „Bearbeite weder model.sql noch die Spezifikation, analysiere nur“. Schritt 3: Fragenliste für das Review: Stimmt der Grain mit dem zugesagten überein; sind alle obligatorischen Felder vorhanden und nicht null; gibt es im SELECT verbotene Felder; besteht der Prüfsachverhalt; gibt es eine Abweichung von der Raw-Quelle bei Summen/Anzahl. Schritt 4: Erforderliche Beweise — Ausgabe des Prüfsachverhalts, Liste der Tests und deren Status, Diff des dbt-Projekts gegen main, Link zur spec-Datei mit Version. Schritt 5: Halten Sie das Urteil fest — approved / changes_required / blocked.
Komplexität: advanced
Fallstudien: Name: Fall 1. Kunden-Mart „blähte sich auf“ nach dem Hinzufügen eines Produkts
Szenario: Eine mittelgroße Bank, Datenplattform auf dbt + Snowflake. Der Mart mart_customer_360 bedient seit einem halben Jahr das Dashboard „Aktive Kunden nach Segmenten“ und den Bericht für die regulatorische Berichterstattung. Das Analystenteam bat den Data Engineer, dem Mart das Feld product_code hinzuzufügen, um auf BI-Seite nicht das Produktverzeichnis joinen zu müssen.
Aufgabe: Der Data Engineer fügte mit KI-Assistent product_code zum SELECT hinzu, führte dbt build aus, Tests auf not_null und unique für customer_id bestanden (weil ein Kunde zum Stichtag ein Produkt hatte). Das Release ging in die Produktion. Nach einer Woche zeigte der regulatorische Bericht 18% mehr „aktive Kunden“ als die tatsächliche Zahl — bei Kunden mit zwei oder mehr Produkten vervielfachten sich die Zeilen. Das Dashboard nach Segmenten zeigte weiterhin korrekte Zahlen, weil dort manuelles distinct verwendet wurde.
Lösung: Das Team stoppte das Release, machte die Änderung im dbt-Projekt rückgängig, schrieb eine separate analytische Schicht mart_customer_products mit dem Grain „Kunde-Produkt“, und in mart_customer_360 ließ man den Grain „Kunde“. Nach dem Vorfall führte man die SDD-Praxis ein: Für jeden Mart wird im Repository eine YAML-Spezifikation mit Grain, obligatorischen und verbotenen Feldern gespeichert. Jeder PR wird von einem Reviewer in einer separaten Agentensitzung geprüft, der den Diff mit der Spezifikation abgleicht.
Ergebnis: Die Kosten des Vorfalls — drei Tage manuelle Nachberechnung der regulatorischen Berichterstattung und eine Erklärung an die Compliance. Nach der Einführung von SDD Data werden solche Änderungen in der Review-Phase blockiert: Der Reviewer bemerkt, dass das Hinzufügen eines Felds den Grain ändert, und verlangt entweder, es in einen separaten Mart auszulagern, oder die Drift ausdrücklich zu beschreiben und die Unterschrift des Dashboard-Eigentümers einzuholen.
Gewonnene Erkenntnisse: Ein grüner dbt build ist nicht gleichbedeutend mit der Erhaltung des Mart-Vertrags.
Grain ist Teil der Spezifikation, nicht eine Eigenschaft von SQL.
Ein Review „in einem anderen Modus“ (separate Agentensitzung) fängt das, was der Autor kontextbedingt übersieht.
Verwandte Konzepte: Grain (Granularität) des Marts
Unsichtbare Bedeutungsänderung
Spezifikation des Datenprodukts
Vertragsdrift und Breaking Change
Name: Fall 2. PII-Leck über analytischen Mart
Szenario: Ein großes Fintech, dbt + BigQuery. Das Open-API-Team bereitet den Mart mart_open_api_consents für externe Partner über ein BI-Tool vor. Der KI-Assistent nahm auf die Anfrage „baue einen Mart zu Einwilligungen mit maximal vielen Feldern“ die Felder client_email und client_phone in das SELECT auf, da er sie als „nützlich für die Segmentierung“ einstufte.
Aufgabe: Die Partner begannen, im Dashboard E-Mails und Telefone der Kunden zu sehen, obwohl keine Einwilligung zur Übermittlung dieser Daten an die Partner vorlag. Die Rechtsabteilung registrierte einen Vorfall der Verarbeitung personenbezogener Daten, es folgte eine Geldstrafe und die Verpflichtung, die Kunden zu benachrichtigen.
Lösung: Der Mart wurde mit einer Whitelist von Feldern neu aufgebaut, die in der Spezifikation beschrieben ist. In dbt wurde ein Test hinzugefügt, der fehlschlägt, wenn ein neues Feld aus der „roten Liste“ im Schema auftaucht. Im Repository erschien eine YAML-Spezifikation mit den Abschnitten allowed_fields und forbidden_fields. Jeder PR mit Erweiterung des SELECT wird verpflichtend mit der Liste der verbotenen Felder abgeglichen.
Ergebnis: Die Kosten des Vorfalls — regulatorische Geldstrafe, Reputationsverluste, Neuaufbau der Partner-API. Nach der Einführung von SDD Data wird die PII-Policy vor SQL beschrieben, nicht vor Gericht nach dem Release geklärt. Die Spezifikation lebt im Repository, neben dem Modell, und jedes Teammitglied sieht die Grenzen.
Gewonnene Erkenntnisse: „Maximal viele Felder“ ist eine gefährliche Anweisung für einen Agenten ohne Spezifikation.
Ein Verbot in SQL lässt sich leichter prüfen als ein Verbot im Kopf eines Analysten.
PII-Policy ist ein Vertrag, keine Best Practice.
Verwandte Konzepte: PII und Richtlinie zu personenbezogenen Daten
Datenvertrag
Spezifikation des Datenprodukts
Drei Grundregeln von SDD Data
Name: Fall 3. Unmerkliche Freshness-Verschiebung bei Zahlungs-Risikosignalen
Szenario: Risikoplattform einer mittelgroßen Bank, dbt + ClickHouse. Der Mart mart_payment_risk_signals wird alle 15 Minuten aktualisiert. Der Agent änderte beim Refactoring des DAGs den Zeitplan, und die tatsächliche Freshness des Marts stieg von 15 auf 47 Minuten. Die dbt-Tests bestanden weiterhin, weil die Daten absolut gesehen aktuell waren (nicht älter als ein Tag).
Aufgabe: Das Risikoteam entdeckte die Verschiebung erst zwei Wochen später, als das Fraud-Scoring-Modell nächtliche Angriffsspitzen verpasste: Der Mart schaffte es einfach nicht, die letzten Transaktionen nachzuziehen. Einen direkten Vorfall konnte man vermeiden, aber die durchschnittliche Erkennungszeit von Fraud-Signalen stieg.
Lösung: In die Spezifikation von mart_payment_risk_signals wurde ein expliziter Abschnitt freshness mit einer Obergrenze von 20 Minuten aufgenommen. Im dbt-Projekt erschien ein Prüfsachverhalt, der max(updated_at) des Marts mit der aktuellen Zeit vergleicht und fehlschlägt, wenn die Differenz größer als 20 Minuten ist. Dieser Sachverhalt gehört zum obligatorischen Satz der Release-Beweise.
Ergebnis: Die Kosten — zwei Wochen „blinder Fleck“ und Dutzende Stunden Analyse durch Risikoanalysten. Nach der Einführung von SDD Data werden Freshness-Verschiebungen innerhalb eines Releases entdeckt, nicht nach zwei Wochen Betrieb. Freshness ist Teil des Vertrags, keine operative Detailfrage.
Gewonnene Erkenntnisse: Freshness ist ein semantisches Versprechen, kein SLA im ITSM.
Der Test „nicht älter als ein Tag“ schützt geschäftskritische Marts nicht.
Der Freshness-Prüfsachverhalt muss im Repository neben der Spezifikation leben.
Verwandte Konzepte: Prüfsachverhalt
Spezifikation des Datenprodukts
Vertragsdrift und Breaking Change
Konsumentenkette
Lerntipps: Versuchen Sie nicht, DuckDB sofort durch den Kampf-Stack zu ersetzen. Im ersten Durchlauf ist es wichtiger, die Verbindung „Spezifikation → dbt → Prüfsachverhalt“ zu sehen, als eine produktionsreife Infrastruktur aufzubauen.
Halten Sie beim Lesen zwei Dinge offen: den Text des Kapitels und models/ im lokalen Projekt. Prüfen Sie jede Aussage aus der Theorie anhand der entsprechenden Datei im Repository.
Bevor Sie den Agenten bitten, SQL zu schreiben, schreiben Sie selbst 5–10 Zeilen Spezifikation: Grain, obligatorische Felder, verbotene Felder, Konsument, Freshness. Diese Übung zeigt am schnellsten den Unterschied zwischen SDD Data und einem gewöhnlichen dbt-Kurs.
Legen Sie eine separate Datei notes/sdd-data-checks.md an und sammeln Sie dort die Kontrollfragen aus jedem Teil. Vor dem Start des nächsten Kapitels kehren Sie dorthin zurück und versuchen, ohne Hinweise zu antworten.
Öffnen Sie bei der Arbeit mit dem Agenten immer eine neue Sitzung (/clear) für die Rolle des Reviewers. Autor und Reviewer müssen in unterschiedlichen Modi arbeiten — das ist Regel Nr. 3, und sie spart Stunden der Analyse.
Führen Sie bash smoke_all.sh nach jeder Änderung aus. Wenn der Smoke-Test gelb oder rot wird, korrigieren Sie das dbt-Modell nicht „ins Blaue“ — lesen Sie zuerst die Spezifikation und den Prüfsachverhalt erneut.
Lesen Sie den Abschnitt „Das erste Risiko: unsichtbare Bedeutungsänderung“ vor jedem neuen Teil erneut. Dieses Szenario wiederholt sich in verschiedenen Formen, und es ist leicht zu vergessen, wenn man in den Details der Marts versinkt.
Vermischen Sie den Lehr-Track und die Kampf-Umgebung nicht. Wenn Sie ein Arbeits-dbt-Projekt haben, gleichen Sie es als Referenzschicht ab, aber versuchen Sie nicht, SDD Data im ersten Durchlauf auf die Produktion „anzuwenden“.
Zusätzliche Ressourcen: Buch-Repository, Verzeichnis book3/examples/bank-lakehouse: Enthält das dbt-Projekt DataLakeHouse der Bank „Sewerny Most“, synthetische Daten und das Skript smoke_all.sh. Dies ist das wichtigste praktische Artefakt des Kurses.
dbt-Dokumentation (dbt labs): Referenz zu Modellen, Tests, Sources, Exposures und Makros. Verwenden Sie es als Wörterbuch, nicht als Lehrbuch — der konzeptionelle Rahmen wird im Buch gegeben.
Dbt-utils und dbt-expectations: Pakete mit fertigen Tests, nützlich für den Aufbau von Prüfsachverhalten (expect_column_values_to_be_between, recency, Freshness).
Erster Band der Reihe (sdd für Webanwendungen): Quelle der SDD-Methodik. Wenn Sie den ersten Band übersprungen haben, lesen Sie das Einführungskapitel — der Zyklus „beschreiben → spezifizieren → implementieren → prüfen → Review“ ist für beide Bände einheitlich.
Checkliste für die Spezifikation eines Datenprodukts (Vorlage in book3/templates/): YAML/JSON-Vorlage mit den Abschnitten Grain, obligatorische/verbotene Felder, Freshness, Eigentümer, Prüfsachverhalte. Kopieren und an Ihr Projekt anpassen.
Standards der regulatorischen Berichterstattung der Zentralbank der Russischen Föderation (Föderales Gesetz 152, Vorschriften zur Informationssicherheit): Der Kontext, in dem das DataLakeHouse der Bank lebt. Nicht als juristische Anleitung, sondern als Quelle von Einschränkungen, die die Spezifikation obligatorisch machen.
Zusammenfassung: Teil 1 führt die Methodik SDD Data ein und hält deren Schlüsselthese fest: In einer Datenplattform ist die Bedeutung wichtiger als der Code. Ein Agent kann unbemerkt den Grain, die Metrik, die Freshness, die PII-Policy oder die Kompatibilität mit Konsumenten ändern, und ein grüner dbt build fängt das nicht. Deshalb ist die Arbeitsreihenfolge umgekehrt zu einem gewöhnlichen dbt-Kurs: zuerst die Mission der Plattform, dann die Spezifikation des Datenprodukts und der Vertrag, dann raw/staging, dann Marts, dann Prüfsachverhalte und unabhängiges Review. dbt bleibt das wichtigste Transformationswerkzeug, aber die Quelle der Bedeutung ist die Spezifikation, die im Repository lebt. Drei Regeln sind ab dem ersten Kapitel zu merken: Die Spezifikation lebt im Repository, der Prüfsachverhalt hat einen Befehl oder einen Reviewer-Schritt, Autor und Reviewer arbeiten in unterschiedlichen Modi. Das Lehrprojekt — DataLakeHouse der Bank „Sewerny Most“ auf DuckDB, das fünf Marts zusammenführt (mart_customer_360, mart_card_turnover_daily, mart_payment_risk_signals, mart_credit_portfolio_quality, mart_open_api_consents). Das minimale Ergebnis des Teils — den Lesemodus wählen, den lokalen Smoke-Test ausführen und in den Notizen festhalten, dass das Buch einen reproduzierbaren Datenproduktprozess aufbaut, nicht „eine Bank im Allgemeinen“.