Teil 1. Einführung: SDD für Daten

In Band 1 wurde SDD auf eine Webanwendung angewendet: Mission, Stack, Roadmap, Feature-Spezifikation, Plan, Überprüfung und Implementierung. In der Datenplattform bleibt die gleiche Logik erhalten, aber das Hauptrisiko ändert sich. In der Anwendung kann der Agent eine Route oder UI falsch machen. In den Daten kann der Agent unbemerkt die Bedeutung einer Metrik, den Grain eines Marts, die Freshness, die PII-Richtlinie oder die Abwärtskompatibilität zu nachgelagerten Konsumenten verändern.

Deshalb beginnt SDD Data nicht mit SQL. Es beginnt mit der Frage: Welches Versprechen gibt das Datenprodukt dem Konsumenten?

Was Sie bauen werden

Das Lernprojekt ist das DataLakeHouse einer fiktiven Bank Bank Nordbrücke. Bis zum Ende des Buches werden Sie ein lokales dbt-Projekt haben, das die finalen Marts baut:

• mart_customer_360;
• mart_card_turnover_daily;
• mart_payment_risk_signals;
• mart_credit_portfolio_quality;
• mart_open_api_consents.

Alle Daten sind synthetisch. Der russische Bankenkontext wird als Satz von Einschränkungen verwendet: PII, Zahlungen, Einwilligungen, Risikosignale, regulatorische Berichterstattung. Dies ist eine Lernarchitektur, keine juristische Anleitung.

Wie sich SDD Data von einem normalen dbt-Kurs unterscheidet

Ein normaler dbt-Kurs beginnt oft mit select * from source. Hier ist die Reihenfolge anders:

1. Zuerst die Mission der Plattform.
2. Dann die Produktspezifikation und der Vertrag.
3. Dann raw/staging.
4. Dann marts.
5. Dann Verifikationsfakten und Reviewer-Bericht.

dbt bleibt das Hauptwerkzeug für Transformationen, wird aber nicht zur Quelle der Bedeutung. Die Bedeutung lebt in den Spezifikationen. SQL soll das fixierte Versprechen ausführen, nicht es nachträglich erzeugen.

Kurze Wiederholung von SDD

SDD ist ein Zyklus, in dem der Agent nicht mit der Implementierung beginnt. Zuerst legen Mensch und Agent Absicht, Grenzen, Entscheidungen und Verifikationsfakten fest. Dann schreibt der Agent Code oder SQL nach den genehmigten Dateien. Nach der Implementierung prüft ein separates Review, nicht nur ob „die Tests bestanden wurden", sondern ob das Ergebnis mit der Spezifikation übereinstimmt.

Für Daten sieht dieser Zyklus so aus:

Datenprodukt beschreiben -> Vertrag definieren -> dbt-Modell implementieren
-> Verifikationsfakten ausführen -> Auswirkung auf den Vertrag bewerten -> Release-Beweise sammeln

Drei Regeln sind ab dem ersten Kapitel zu merken:

• die Spezifikation lebt im Repository, nicht im Chat;
• ein Verifikationsfakt muss einen Befehl, SQL oder manuellen Reviewer-Schritt haben;

• Autor und Reviewer müssen in unterschiedlichen Modi arbeiten, auch wenn es sich um denselben

CLI-Agenten nach /clear handelt.

Das erste Risiko: unsichtbare Bedeutungsänderung

Stellen Sie sich vor, der Agent hat product_code zu mart_customer_360 hinzugefügt. SQL kompiliert, dbt-Tests können bestehen, aber der Grain ist nicht mehr „eine Zeile pro customer_id". Für den nachgelagerten Konsumenten ist dies eine Vertragsbruchänderung: Ein Bericht, der Kunden zählte, beginnt Kunden-Produkt-Paare zu zählen. In einer Webanwendung ist ein solcher Defekt oft sofort sichtbar. In Daten kann er eine Woche später in einen Bericht, KPI oder ein Risikomodell gelangen.

SDD Data ist genau für solche Fälle gedacht. Es erzwingt, vor SQL zu schreiben:

• welcher Grain versprochen ist;
• welche Felder obligatorisch sind;
• welche Felder verboten sind;
• welche Prüfungen eine Änderung zulassen;
• wer Drift oder Bruchänderungen bestätigt.

Aufschlüsselung für den Leser

Beim ersten Lesen ist es leicht, dieses Buch als eine weitere dbt-Route zu betrachten: Adapter installieren, Modelle schreiben, dbt build ausführen, grüne Ausgabe erhalten. Dies ist ein falscher Rahmen. dbt spielt hier dieselbe Rolle wie ein Test-Framework in einer normalen Anwendung: Es macht einen Teil des Verhaltens überprüfbar, entscheidet aber nicht, was genau

für das Geschäft wahr sein muss. Wenn der Leser diese Unterscheidung ab dem ersten Kapitel nicht festhält, werden alle Artefakte danach wie Bürokratie erscheinen.

Es ist nützlich, sich die Lernbank als Organisation vorzustellen, in der eine Tabelle mehrere Hände durchläuft. Das Operationsteam lädt die Quelle. Der Dateningenieur bringt die Typen in Ordnung. Der Analyst baut einen Bericht. Das Risikoteam betrachtet das Signal. Der Leiter liest das Aggregat. Ein Fehler in SQL kann lokal sein, aber ein Fehler in der Bedeutung des Marts breitet sich entlang dieser Kette aus. Deshalb versucht SDD Data, nicht nur den Code zu schützen, sondern auch die Vereinbarung zwischen Menschen: Was eine Zeile bedeutet, welche Felder erlaubt sind, welches Datenalter akzeptabel ist, wer die Änderung bestätigt.

Daraus ergibt sich der Hauptrhythmus des Bandes. Zuerst schreibt der Leser das Versprechen auf, dann macht er es ausführbar, dann beweist er es mit Fakten, dann gibt er es zur unabhängigen Überprüfung weiter. Dies erscheint langsamer, als sofort SQL zu schreiben, aber im Lernprojekt zeigt sich der Unterschied schnell: Sobald PII, Einwilligung oder Risikosignal ins Spiel kommen, beginnt „schnelles SQL", Entscheidungen zu treffen, für die es kein Recht hat. Ein guter Agent beschleunigt die Arbeit nur dann, wenn die Grenzen bereits benannt sind.

Wenn nach diesem Kapitel das Gefühl bleibt, dass alle Worte durch einen einzigen Befehl „baue Mart" ersetzt werden können, sollten Sie innehalten. Ein solcher Befehl fordert den Agent auf, gleichzeitig Analyst, Architekt, Reviewer und Risikoeigentümer zu sein. In Band 1 war dies für ein Feature gefährlich. Bei Daten ist es gefährlicher: Die Ergebnistabelle kann ordentlich aussehen, aber bereits Unwahrheiten erzählen.

Praxis

Öffnen Sie das Beispiel:

cd book3/examples/bank-lakehouse
bash smoke_all.sh

Wenn dbt nicht installiert ist, generiert smoke dennoch synthetische Daten und prüft die Struktur. Nach der Installation der Abhängigkeiten führt es ein vollständiges dbt build aus.

Minimale Ausgabe

Nach diesem Teil sollten Sie einen Lesemodus gewählt haben:

• Lernlokaler Track auf DuckDB;
• Abgleich mit der Produktionsumgebung als Referenzschicht, nicht als obligatorische

Infrastruktur;

• Verständnis, dass das Buch nicht „eine Bank im Allgemeinen", sondern einen reproduzierbaren

Datenproduktprozess aufbaut.

Notieren Sie in Ihren Arbeitsnotizen:

Erster Durchlauf: Ich baue ein lokales DataLakeHouse der Bank auf dbt-duckdb; Abgleich
mit der Produktionsumgebung implementiere ich nicht vor dem praktischen Testat.

Typischer Fehler

Anfänger versuchen sofort, DuckDB durch einen „echten" Stack zu ersetzen. Dies ist verfrüht. Im ersten Durchlauf ist es wichtiger, die Verbindung zwischen Spezifikation und überprüfbarem Mart zu sehen. Wenn die lokale Version Grain, Tests und PII-Richtlinie nicht hält, beschleunigt der Produktionscluster nur den Fehler.

Kontrollfragen

1. Warum kann man in einem Datenprojekt nicht mit SQL beginnen?
2. Was ändert sich, wenn der finale Mart PII enthält?
3. Was sollte die Quelle der Wahrheit sein: das dbt-Modell oder die Datenproduktspezifikation?