Thema: Teil 22. Praktische Prüfung: vollständiger SDD-Data-Zyklus von der Spezifikation bis zum Reviewer-Bericht
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 3–4 Stunden Eigenarbeit (einschließlich Erstellung der Spezifikation, Implementierung des Modells und Erstellung des Reviewer-Berichts)
Voraussetzungen: Sichere Beherrschung von SQL (Aggregationen, Fensterfunktionen, JOIN)
Grundkenntnisse in dbt (Modelle, Tests, Sources, schema.yml)
Verständnis des Konzepts von Data Contracts und SDD Data (Specification-Driven Development for Data)
Kenntnisse der Prinzipien im Umgang mit PII (Personally Identifiable Information)
Erfahrung mit git und Kommandozeile
Verständnis des Unterschieds zwischen Staging-, Mittel- und Mart-Schichten
Lernziele: Daten-Spezifikationen kritisch bewerten und mindestens 10 Schwachstellen finden, bevor mit der SQL-Implementierung begonnen wird
Schwache Lastenhefte in vollständige SDD-Data-Spezifikationen mit Abschnitten zu Grain, PII, Contract und Abnahmefakten umschreiben
Ein dbt-Modell der Mart-Schicht entwerfen mit der Garantie „eine Zeile pro Schlüssel“ als Grain und mit Abdeckung der vorgeschriebenen Tests
Die Rollen von Autor und Reviewer trennen und einen Reviewer-Bericht mit Trennung von Fakten, Annahmen und offenen Bestätigungen erstellen
Eine SDD-Data-Retrospektive durchführen und bestimmen, welche Phase des nächsten Features eingegrenzt oder detaillierter beschrieben werden muss
Übersicht: Der letzte Teil des Kurses prüft nicht das Gedächtnis über die dbt-Syntax, sondern die Fähigkeit, das Versprechen eines Datenprodukts von der Spezifikation bis zum Reviewer-Bericht einzuhalten. Die Prüfung beginnt absichtlich mit einer schwachen Spezifikation der Art „eine nützliche Mart-Tabelle erstellen“, um zu prüfen, ob der Studierende die schwache Aufgabe vor SQL stoppt. Die Prüfung besteht aus vier Blöcken: 12 schnelle schriftliche Fragen zum Verständnis der SDD-Data-Terminologie; Aufgabe, Probleme in einer absichtlich schwachen Spezifikation zu finden; Umschreiben in das korrekte SDD-Data-Format; und schließlich Implementierung der Mart-Tabelle mart_customer_risk_summary in dbt mit einem vollständigen Beweispaket – Spezifikation vor SQL, Tests, Vertragliche Auswirkung, Reviewer-Bericht und Retrospektive. Die Prüfung kann allein oder im Paar (Autor + Reviewer) abgelegt werden – das Paar-Format zeigt, dass Review eine aktive Ingenieurrolle ist und kein passives Lesen von SQL. Die Arbeit wird nach einer 25-Punkte-Rubrik bewertet: 21+ Punkte bedeutet, dass der Prozess für ein reales Datenprodukt übernommen werden kann.
Schlüsselkonzepte: Grain (Granularität): Die Wahrheitsquelle für Grain ist die Modellspezifikation oder der Datenprodukt-Vertrag, nicht SQL. Grain legt fest, dass jeder Zeile der Ausgabe-Mart genau ein Geschäftsobjekt entspricht (z. B. customer_id). Eine Änderung von Grain erfordert immer eine menschliche Bestätigung, selbst wenn SQL „sauber“ zusammengesetzt wird.
ODPS vs ODCS: ODPS (Open Data Product Specification) beschreibt das Produkt und seine Konsumenten: wofür die Mart da ist, wer sie liest, welche Fragen sie beantwortet. ODCS (Open Data Contract Standard) ist der technische Vertrag: Schema, SLA, Format, Eigentümer, Versionierung. SDD Data verwendet beide: ODPS für die Produktbedeutung, ODCS für das technische Versprechen.
dbt-Tests vs Datenvertrag: dbt-Tests (not_null, unique, accepted_values, relationships) prüfen nur einen Teil der Form und teilweise Dateneigenschaften. Sie beweisen nicht die Vollständigkeit der Spezifikation, die Korrektheit der Metrik-Berechnungsmethodik und ersetzen nicht den Produktvertrag. Ein grüner dbt build ist Hygiene, kein Versprechen.
PII-Politik und verbotene Felder: Die Liste der verbotenen direkten PII (Name, E-Mail, Telefon, Passdaten) muss in der Modellspezifikation, in AGENTS.md und in der Reviewer-Checkliste festgehalten werden. Wenn möglich wird sie in einen Singular-Test oder ein Makro umgewandelt, das das finale Schema scannt. Das verwandelt die Politik von einem Slogan in ein prüfbares Artefakt.
Vertragsdrift (Contract Drift): Eine Abweichung zwischen Vertrag/Spezifikation und dem tatsächlich implementierten Modell. Drift entsteht, wenn der Autor einer „kleinen Verbesserung“ stillschweigend das Grain ändert, ein Feld hinzufügt, einen Test abschwächt oder eine Entität umbenennt. Drift vor dem Release zu fangen, ist die Hauptaufgabe des Reviewers.
Breaking Changes: Änderung des Grain, Umbenennen oder Löschen eines Vertragsfelds, Änderung der Metriksemantik, Änderung der PII-Politik, Änderung der SLA. Das Hinzufügen einer Nullable-Spalte ist normalerweise nicht breaking, kann aber breaking werden, wenn Downstream-Systeme sie als neue Geschäftsmetrik interpretieren oder sie das Grain ändert.
Trennung der Rollen von Autor und Reviewer: Der Reviewer muss die Annahmen des Autors prüfen, nicht verteidigen. Daher sind Autor und Reviewer unterschiedliche Rollen (bei der Paarprüfung – zwei verschiedene Studierende). Der Reviewer bearbeitet keine Dateien des Autors, sondern erstellt einen Bericht mit Anmerkungen zu Vertrag, SQL, Tests und Prozess separat.
Was beweist dbt build: dbt build beweist nur die Ausführbarkeit des DAG und das Bestehen der angegebenen Tests auf den aktuellen Daten. Es beweist nicht die Vollständigkeit der Spezifikation, die Korrektheit der Methodik, die Ausreichendheit der Tests und die Übereinstimmung mit dem Konsumentenvertrag.
Schema-Manifest vs Modellspezifikation: Das Schema-Manifest (bzw. schema.yml) beschreibt die beobachtete Quelle: tatsächliche Spalten, Typen, Tests. Die Modellspezifikation beschreibt die versprochene Mart: Grain, Konsument, Methodik, PII-Politik, Abnahmefakten. Sie sind verbunden, aber nicht austauschbar.
Rohdaten und das „Reparieren“ für einen grünen Build: Die Raw-Schicht erhält die Eingabe wie sie ist und wird nicht „repariert“, um einen grünen dbt build zu erreichen. Die Semantik von leeren Werten und null wird im Staging oder explizit in der Spezifikation geregelt. Andernfalls versteckt man schlechte Datenqualität hinter einem validen Modell.
Abnahmefakt (Acceptance Fact): Dies ist ein Artefakt, das vier Elemente enthalten muss: Befehl (SQL/dbt/manueller Schritt), erwartetes Ergebnis, Ausführungsstatus und die Person, die es bestätigt hat. Ohne diese vier Elemente ist eine „Prüfung“ nur ein Kommentar.
Menschliche Bestätigung (Human Confirmation): Erforderlich bei Änderung des Grain, der PII-Politik, der SLA, von Vertragsfeldern oder der Methodik der Risikometrikberechnung. Dies ist eine Liste von Situationen, in denen ein KI-Assistent nicht selbst entscheiden, sondern stoppen und eine Bestätigung anfordern sollte.
Wichtige Termine: Phase 1 – Spezifikation vor SQL: Erstellung von specs/models/mart_customer_risk_summary.md und der Abnahmefakten vor jeder Codeänderung
Phase 2 – Notiz zur Vertragsauswirkung: Festhalten, ob die Mart ein neues Datenprodukt oder eine Erweiterung eines bestehenden ist, vor der Implementierung
Phase 3 – Implementierung und Verifikation: Schreiben des dbt-Modells, Aktualisieren von models/schema.yml, Ausführen von dbt build --profiles-dir .
Phase 4 – Reviewer-Bericht: Der Paar-Reviewer führt data-contract-review aus und erstellt einen Bericht mit Trennung von Fakten, Annahmen und Bestätigungen
Phase 5 – Retrospektive: Ausfüllen der Retrospektivenvorlage mit Bewertung dessen, was die Spezifikation gut beschrieben hat und was nach SQL präzisiert werden musste
Übungsaufgaben: Name: Block 1. Schriftliche Antworten zu 12 schnellen SDD-Data-Fragen
Problem: Beantworten Sie schriftlich, ohne Hilfe eines KI-Assistenten, 12 Fragen: (1) Was ist die Wahrheitsquelle für Grain? (2) Worin unterscheidet sich ODPS von ODCS? (3) Warum ersetzen dbt-Tests keinen Datenvertrag? (4) Wo sollte die Liste der verbotenen PII beschrieben werden? (5) Was ist Vertragsdrift? (6) Wann kann das Hinzufügen einer Nullable-Spalte eine breaking change sein? (7) Warum sollten Autor und Reviewer unterschiedliche Rollen sein? (8) Was beweist dbt build und was beweist er nicht? (9) Worin unterscheidet sich das Schema-Manifest von der Modellspezifikation? (10) Warum müssen Rohdaten nicht „repariert“ werden, um einen grünen dbt build zu erhalten? (11) Was muss ein Abnahmefakt enthalten? (12) Wann ist eine menschliche Bestätigung erforderlich?
Lösung: Referenzantworten: (1) Die Modellspezifikation oder der Datenprodukt-Vertrag, nicht SQL. (2) ODPS beschreibt Produkt und Konsumenten; ODCS den technischen Vertrag. (3) dbt-Tests prüfen einen Teil der Form/Daten, aber nicht die gesamte Produktbedeutung. (4) In der Spezifikation, in AGENTS.md, in der Reviewer-Checkliste und möglichst in einem Singular-Test. (5) Eine Abweichung zwischen Vertrag/Spezifikation und dem tatsächlichen Modell. (6) Wenn sie wie eine neue Geschäftsmetrik aussieht, das Grain ändert oder die API downstream beeinflusst. (7) Der Reviewer muss die Annahmen des Autors prüfen, nicht verteidigen. (8) dbt build beweist die Ausführbarkeit von DAG/Tests, aber nicht die Vollständigkeit der Spezifikation. (9) Das Manifest beschreibt die beobachtete Quelle; die Modellspezifikation beschreibt die versprochene Mart. (10) Raw erhält die Eingabe; die Semantik leerer Werte und null wird im Staging/in der Spezifikation geregelt. (11) Befehl, SQL oder manueller Reviewer-Schritt, Erwartung und Status. (12) Bei Änderung des Grain, der PII-Politik, der SLA, von Vertragsfeldern oder der Risikomethodik.
Komplexität: intermediate
Name: Block 2. Finden Sie 10+ Probleme in einer schwachen Spezifikation
Problem: Gegeben ist eine absichtlich schwache Spezifikation. Analysieren Sie sie und finden Sie alle Schwachstellen. Text der Spezifikation: „# Zusammenfassung Kundenrisiko. Eine nützliche Mart-Tabelle für Kundenrisiken erstellen. ## Daten. customer_360 und Zahlungen verwenden. Notwendige Risikofelder hinzufügen. ## Prüfung. Prüfen, dass die Daten korrekt sind und keine personenbezogenen Daten enthalten.“
Lösung: Schrittweise Analyse: 1) Kein Mart-Name angegeben – das Artefakt kann im Vertrag nicht referenziert werden. 2) Kein Konsument angegeben – Nützlichkeit kann nicht geprüft werden. 3) Keine Granularität (Grain) angegeben – Eindeutigkeit der Zeilen kann nicht bewiesen werden. 4) „Nützlich“ ist ein nicht prüfbares Wort, kein Abnahmekriterium. 5) „Notwendige Felder“ sind nicht definiert – der Konsument kann nicht verstehen, was er erhält. 6) Keine vorgeschriebenen Kennzahlen – nichts zu testen. 7) Die PII-Politik wurde nicht in einen Test anhand der Liste verbotener Felder umgewandelt – das ist ein Slogan, keine Prüfung. 8) Die Vertragsauswirkung ist nicht beschrieben – es kann nicht verstanden werden, ob es eine Erweiterung oder ein neues Produkt ist. 9) Keine Liste der Eingabemodelle als Sources – im DAG ist nichts zu validieren. 10) Keine dbt-Befehle – keine reproduzierbare Prüfung. 11) Keine manuellen Fakten für den Reviewer – keine Beweisgrundlage. 12) Es wurde nicht gesagt, ob dies ein neues Produkt oder eine Erweiterung ist – das Änderungsrisiko kann nicht eingeschätzt werden.
Komplexität: intermediate
Name: Block 3. Schreiben Sie die Spezifikation im SDD-Data-Format neu
Problem: Schreiben Sie die schwache Spezifikation aus Block 2 in ein vollständiges SDD-Data-Format mit den Abschnitten um: Zweck, Konsument, Grain, Eingaben, Ausgabefelder, PII-Politik, Vertragsauswirkung, Abnahmefakten, offene Bestätigungen. Einschränkungen: Grain – eine Zeile pro customer_id; Eingaben – mart_customer_360 und mart_payment_risk_signals; Felder – customer_id, risk_event_count, large_amount_event_count, last_risk_event_date; ohne direkte PII; Prüfungen – customer_id not_null/unique, Risikozähler not_null; bestehender Vertrag mart_customer_360 darf nicht geändert werden.
Lösung: Beispiel einer umgeschriebenen Spezifikation:
# Modellspezifikation: mart_customer_risk_summary
## Zweck
Mart-Tabelle aggregierter Risikosignale pro Kunde für Scoring- und Anti-Fraud-Teams. Wird nicht für Marketing verwendet.
## Konsument
Risikomodellierungs-Team, Downstream-Dashboard im BI; sekundärer Konsument – Anti-Fraud-Alerts.
## Grain
Eine Zeile pro customer_id. Eine Änderung des Grain ist ohne Bestätigung des Produkteigentümers verboten.
## Eingaben
- mart_customer_360 – Kundenstammdaten, Vertrag ist fixiert, wird nicht geändert.
- mart_payment_risk_signals – Ereignisse von Zahlungs-Risikomerkmalen.
## Ausgabefelder
- customer_id (PK, BIGINT, NOT NULL, UNIQUE)
- risk_event_count (INT, NOT NULL) – Gesamtzahl der Risikoereignisse in den letzten 90 Tagen.
- large_amount_event_count (INT, NOT NULL) – Anzahl der Ereignisse mit Betrag über dem Schwellenwert.
- last_risk_event_date (DATE, NULLABLE) – Datum des letzten Ereignisses; NULL ist zulässig, wenn keine Ereignisse vorhanden sind.
## PII-Politik
Verboten sind direkte PII: Name, E-Mail, Telefon, Pass, Adresse. Es wird nur customer_id als Quasi-Identifikator verwendet. Die Liste der verbotenen Felder wird durch den Singular-Test no_pii_columns auf das Schema des Ausgabemodells geprüft.
## Vertragsauswirkung
Neues Datenprodukt, keine Erweiterung eines bestehenden. Der Vertrag mart_customer_360 wird nicht geändert. Downstream-Abhängigkeiten: Das BI-Risiko-Dashboard liest künftig mart_customer_risk_summary statt Ad-hoc-SQL.
## Abnahmefakten
1. dbt run auf dem Modell mart_customer_risk_summary – Erfolg.
2. dbt test auf not_null + unique customer_id – Erfolg.
3. dbt test auf not_null der Risikozähler – Erfolg.
4. Singular-Test no_pii_columns – Erfolg.
5. Manueller Reviewer-Fakt: visuelle Prüfung von 5 zufälligen customer_id im BI – Übereinstimmung.
## Offene Bestätigungen
- Schwellenwert für large_amount: Bestätigung durch den Eigentümer des Risikomodells erforderlich.
- Fenster von 90 Tagen: Bestätigung durch den Konsumenten des BI-Dashboards erforderlich.Komplexität: intermediate
Name: Block 4. Abschlussprojekt – Implementierung von mart_customer_risk_summary
Problem: Fügen Sie dem dbt-Projekt eine neue Mart-Tabelle mart_customer_risk_summary hinzu. Anforderungen: Grain „eine Zeile pro customer_id“; Eingaben – mart_customer_360 und mart_payment_risk_signals; Felder – customer_id, risk_event_count, large_amount_event_count, last_risk_event_date; ohne direkte PII; dbt-Tests; Modellspezifikation und Abnahmefakten; Notiz zur Vertragsauswirkung; Reviewer-Bericht. Befolgen Sie den 10-Schritte-Prozess: vom Arbeitsverzeichnis bis zur Retrospektive.
Lösung: Schrittweise Lösung gemäß Prozess:
- Erstellen Sie einen sauberen git-Branch: git checkout -b feat/mart-customer-risk-summary.
- Erstellen Sie die Datei specs/models/mart_customer_risk_summary.md mit der Spezifikation aus Block 3 – dies geschieht vor jedem SQL.
- Beschreiben Sie vor SQL die Abnahmefakten: Liste der dbt-Befehle, manuellen Schritte und Erwartungen. Zum Beispiel: „dbt test -m mart_customer_risk_summary erwartet 4 grüne Tests“.
- Beschreiben Sie die Vertragsauswirkung: „Neues Datenprodukt, keine Erweiterung von mart_customer_360, das nachgelagerte BI-Dashboard wechselt auf die neue Mart“.
- Implementieren Sie das Modell models/marts/mart_customer_risk_summary.sql. Beispiel-SQL:
{{ config(materialized='table') }}
with payments as (
select customer_id, event_date, amount, is_risk_event
from {{ ref('mart_payment_risk_signals') }}
),
agg as (
select
customer_id,
count(*) filter (where is_risk_event) as risk_event_count,
count(*) filter (where is_risk_event and amount > 100000) as large_amount_event_count,
max(event_date) filter (where is_risk_event) as last_risk_event_date
from payments
group by 1
)
select c.customer_id, a.risk_event_count, a.large_amount_event_count, a.last_risk_event_date
from {{ ref('mart_customer_360') }} c
left join agg a using (customer_id)- Aktualisieren Sie models/schema.yml: fügen Sie das Modell, die Beschreibung, Tests not_null und unique auf customer_id sowie not_null auf die Risikozähler hinzu.
- Führen Sie dbt build --profiles-dir . aus – alle Tests müssen grün sein.
- Erstellen Sie den Reviewer-Bericht (Paar-Partner für die Paarprüfung): trennen Sie die Anmerkungen in Fakten (was geprüft wurde), Annahmen (was auf Treu und Glauben angenommen wurde) und offene Bestätigungen (was den Produkteigentümer erfordert).
- Halten Sie in specs fest, ob die Mart bestehende Verträge ändert (in diesem Fall – nein, mart_customer_360 bleibt unverändert).
- Wenn der Reviewer eine Drift gefunden hat (z. B. last_risk_event_date wurde NOT NULL statt NULLABLE) – korrigieren Sie die Spezifikation oder das SQL vor dem Merge.
Komplexität: intermediate
Fallstudien: Name: Fall 1: Mart-Tabelle für Kundenrisiko – neues Datenprodukt von Grund auf
Szenario: Das Risikomodellierungs-Team in einem Fintech-Unternehmen bittet den Data Engineer, eine Mart mit aggregierten Risikosignalen pro Kunde zu erstellen. Zuvor hat das BI-Dashboard Daten per Ad-hoc-SQL direkt über mart_customer_360 und rohe Zahlungen zusammengetragen. Die Mart soll die Ad-hoc-Abfragen ersetzen und Quelle für Anti-Fraud-Alerts werden.
Aufgabe: Die ursprüngliche Spezifikation des Analysten lautete: „eine nützliche Mart-Tabelle für Kundenrisiken erstellen“. Es fehlten: Mart-Name, Konsument, Grain, Pflichtfelder, PII-Politik, Auswirkung auf den bestehenden Vertrag mart_customer_360, Abnahmekriterien. Risiko: Der Data Engineer erstellt ein „bequemes“ Modell mit Join, das technisch zusammengesetzt wird, aber die Frage des Risikoteams nicht beantwortet und das BI-Dashboard bricht.
Lösung: Der Ingenieur stoppte die Arbeit vor SQL. Gemeinsam mit dem Produkteigentümer und dem Analysten wurden festgehalten: Grain = eine Zeile pro customer_id; drei Pflichtfelder (risk_event_count, large_amount_event_count, last_risk_event_date); die Liste der verbotenen PII (Name, E-Mail, Telefon, Pass, Adresse) wurde in den Singular-Test no_pii_columns umgewandelt; Vertragsauswirkung – neues Datenprodukt, mart_customer_360 wird nicht geändert; die Abnahmefakten umfassen sowohl dbt-Tests als auch die manuelle Prüfung von 5 zufälligen customer_id im BI. Nach Freigabe der Spezifikation wurde das Modell geschrieben, dbt build ausgeführt, der Reviewer erstellte einen Bericht mit Trennung von Fakten und Annahmen.
Ergebnis: Die Mart wurde in einem Sprint in die Produktion gebracht. Das BI-Dashboard wechselte auf die neue Mart, Ad-hoc-SQL-Skripte wurden entfernt. Anti-Fraud-Alerts wurden stabiler, da die Variabilität von Ad-hoc-Abfragen verschwand. Prüfung nach Rubrik: 23/25 Punkte – Verlust von 2 Punkten im Abschnitt „Abnahmefakten“ (im ersten Durchlauf war der manuelle Reviewer-Schritt nicht beschrieben).
Gewonnene Erkenntnisse: Eine schwache Spezifikation ist ein normaler Ausgangspunkt; die Aufgabe des Ingenieurs ist es, sie vor SQL zu stoppen und in ein vollständiges SDD-Data-Artefakt zu verwandeln
Die Verbotsliste für PII muss in einen ausführbaren Singular-Test umgewandelt werden, nicht als Slogan im Chat bleiben
Manuelle Abnahmefakten (visuelle Prüfung im BI) sind obligatorisch – dbt-Tests decken die Produktbedeutung nicht ab
Die Unterscheidung „neues Produkt“ vs. „Erweiterung eines bestehenden“ ist eine vertragliche Entscheidung, keine technische
Verwandte Konzepte: Grain als Wahrheitsquelle
ODPS vs ODCS
PII-Politik und Singular-Test
Abnahmefakten (Befehl + Erwartung + Status + Bestätiger)
Vertragsauswirkung: neues Produkt vs Erweiterung
Name: Fall 2: Vertragsdrift bei einer „kleinen Verbesserung“
Szenario: In der bestehenden Mart mart_customer_360 fügte der Autor im Rahmen der Aufgabe „Kundenprofil für Churn-Analyse anreichern“ eine Nullable-Spalte date_of_birth hinzu. Der Autor stoppte nicht und stimmte die Änderung nicht mit dem Produkteigentümer ab, da die Spalte nullable ist und „nichts kaputt macht“.
Aufgabe: Nach einer Woche baute das Anti-Fraud-Team ein Dashboard, das Kunden nach date_of_birth filterte. Dies verletzte die PII-Politik (das Unternehmen verbietet die Verarbeitung des Geburtsdatums außerhalb des KYC-Kreislaufs). Die Drift wurde nicht erkannt, weil: (a) die Spezifikation keine Liste verbotener PII mit Prüfung enthielt; (b) der Reviewer nur SQL prüfte, nicht den Vertrag; (c) dbt-Tests bestanden – formal ist alles grün.
Lösung: Im Nachhinein: Die Spalte wurde entfernt, der Singular-Test no_pii_columns wurde zu allen Mart-Tabellen hinzugefügt, AGENTS.md wurde um die Liste der verbotenen Felder ergänzt, der Review-Prozess wurde überarbeitet, sodass der Reviewer vor dem Merge die Spezifikation und die PII-Politik abgleicht. In der nächsten Iteration wurde eine ähnliche „kleine Verbesserung“ vom Reviewer in der Spezifikationsphase abgefangen.
Ergebnis: Der Vorfall führte zu einem formellen Verbot, Felder ohne Bestätigung des Produkteigentümers zu bestehenden Mart-Tabellen hinzuzufügen. Der Review-Prozess wurde um den obligatorischen Abgleich mit der PII-Politik und dem ODCS-Vertrag erweitert. Nach den Überarbeitungen wurden ähnliche Drift-Versuche in den folgenden 3 Monaten in 100 % der Fälle vor dem Release abgefangen.
Gewonnene Erkenntnisse: Eine Nullable-Spalte kann eine breaking change sein, wenn Downstream sie als Geschäftsmetrik verwendet oder die PII-Politik verletzt
dbt build grün ≠ Vertrag intakt
Die Liste der verbotenen PII muss ein ausführbares Artefakt sein, kein Dokument in Confluence
Der Reviewer prüft die Annahmen des Autors, nicht SQL – es ist eine aktive Rolle
Verwandte Konzepte: Vertragsdrift
Breaking Changes
Was dbt build beweist
Trennung der Rollen von Autor und Reviewer
PII-Politik als ausführbarer Test
Name: Fall 3: Paarprüfung – Erfahrung mit der Rollentrennung von Autor und Reviewer
Szenario: Zwei Junior-Ingenieure absolvieren die Paarprüfung in SDD Data. Student A ist Autor der Mart mart_marketing_attribution; Student B ist Reviewer. Beide haben den Kurs gerade abgeschlossen und wenden die Methodik erstmals in der Praxis an.
Aufgabe: Der Autor neigt dazu, SQL „mit der Feile nachzubessern“, ohne zur Spezifikation zurückzukehren. Der Reviewer neigt dazu, „kleinere“ Änderungen zu genehmigen, um den Prozess nicht zu bremsen. Beide riskieren, die Prüfung auf ein formales dbt build-Durchlaufen ohne echte Vertragsprüfung zu reduzieren.
Lösung: Vor Beginn der Prüfung einigte sich das Paar auf Regeln: Der Reviewer bearbeitet keine Dateien des Autors; alle Anmerkungen werden in einen Bericht mit Trennung in die Blöcke „Vertrag“, „SQL“, „Tests“, „Prozess“ geschrieben; der Autor wechselt nach der ersten Mart die Rolle mit dem Reviewer für die zweite. Der Reviewer verwendet die data-contract-review-Checkliste: gleicht das tatsächliche Schema mit der Spezifikation ab, führt den PII-Singular-Test aus, prüft, ob die Abnahmefakten erfüllt sind. Der Autor sah nach der ersten Iteration im Reviewer-Bericht drei Drifts: (1) die Spalte region wurde ohne Abstimmung hinzugefügt; (2) die Methode zur Berechnung des attribution_window wurde nicht beschrieben; (3) die Tests decken nur not_null ab, es gibt keine accepted_values für Attributionskanäle.
Ergebnis: Die erste Mart erhielt 18/25 – sie reichte nicht für „produktionsreif“, lieferte aber Material für die Retrospektive. Nach dem Rollenwechsel erhielt die zweite Mart 23/25 – beide Studierenden stellten fest, dass die Rolle des Reviewers viel mehr brachte als die des Autors, da sie dazu zwingt, die eigenen Abnahmekriterien zu formalisieren.
Gewonnene Erkenntnisse: Das Paarformat nimmt die Illusion, dass Review ein passives Lesen von SQL ist
Der Rollenwechsel Autor↔Reviewer hilft zu verstehen, welche Abnahmekriterien tatsächlich funktionieren
Der Reviewer-Bericht muss Fakten, Annahmen und offene Bestätigungen trennen – sonst sind es nur Kommentare
Die Retrospektive nach der Prüfung ist keine Pflichtübung, sondern der Input für die nächste Phase: Wenn „was nach SQL präzisiert werden musste“ mehr als 3 Punkte umfasst, muss die Phase eingegrenzt werden
Verwandte Konzepte: Trennung der Rollen von Autor und Reviewer
Reviewer-Bericht (Fakten, Annahmen, Bestätigungen)
SDD-Data-Retrospektive
Rubrik 25 Punkte
Paarformat der Prüfung
Lerntipps: Versuchen Sie nicht, „zu SQL zu springen“ – schreiben Sie die Spezifikation und die Abnahmefakten strikt vor dem Code. Dies ist die häufigste Ursache für niedrige Punktzahlen nach der Rubrik.
Erstellen Sie eine Checkliste mit den 12 schnellen Fragen aus Block 1 auf einer Karteikarte und gehen Sie sie vor jedem Feature durch – das dauert 5 Minuten und spart Stunden an Nacharbeit.
Legen Sie eine Spezifikationsvorlage in specs/models/ an und bearbeiten Sie sie nicht „auf die Schnelle“ ohne Rücksprache mit dem Produkteigentümer. Jede Änderung der Spezifikation = Vertragsänderung.
Wandeln Sie die PII-Politik sofort in einen Singular-Test no_pii_columns um, in derselben Iteration. Der Slogan „wir haben keine PII“ ohne Prüfung = Drift, die nächste Woche passieren wird.
Vereinbaren Sie mit einem Kollegen/Partner das Paarformat. Wenn kein Partner verfügbar ist, lassen Sie den KI die Rolle des Reviewers über das Szenario /clear + data-contract-review übernehmen, aber zeigen Sie den endgültigen Bericht dennoch einem Menschen.
Führen Sie ein Journal der „offenen Bestätigungen“ in der Spezifikation – dies verringert die Chance, dass Qwen Code die Methodik „errät“ und eine irreversible Annahme trifft.
Führen Sie dbt build mit --profiles-dir . aus und speichern Sie die Ausgabe als Artefakt – das ist Ihr erster Abnahmefakt. Screenshot/Log zusammen mit der Spezifikation aufbewahren.
Überspringen Sie nach der Prüfung nicht die Retrospektive. Wenn im Abschnitt „was nach SQL präzisiert werden musste“ mehr als 3 Punkte stehen, reduzieren oder beschreiben Sie das nächste Feature detaillierter.
Verwenden Sie die empfohlenen Qwen-Szenarien (Spezifikation erstellen → Implementierung → Review) als wörtliches Skript: /clear + Kontext + explizites Verbot, im ersten Schritt Code zu schreiben.
Denken Sie daran: 21+ Punkte nach der Rubrik bedeutet „kann auf ein reales Datenprodukt übertragen werden“. Wenn Sie 16–20 erreicht haben, ist das kein Misserfolg, aber Prüfung und Review müssen vor der Überführung in die Produktion verstärkt werden.
Zusätzliche Ressourcen: Open Data Product Specification (ODPS): Spezifikation zur Beschreibung des Produkts und der Konsumenten eines Datenprodukts – bitol.io/odps oder aktuelle Version auf bitol.io. Wird als Vorlage für die Abschnitte „Zweck“ und „Konsument“ verwendet.
Open Data Contract Standard (ODCS): Technischer Vertrag des Datenprodukts – bitol.io/odcs. Wird als Vorlage für die Abschnitte „Ausgabefelder“ und „Vertragsauswirkung“ verwendet.
dbt-Dokumentation – Tests: Dokumentation zu dbt-Tests (not_null, unique, accepted_values, relationships, singular). Quelle für den Abschnitt „dbt-Prüfungen“ in der Spezifikation.
dbt-Dokumentation – Contracts: Dokumentation zu dbt-Contracts – enforce_schema, enforce_not_null. Nützlich für den Abschnitt „Vertragsauswirkung“ in der Modellspezifikation.
AGENTS.md im Projektstamm: Datei, in der die PII-Politik, die verbotenen Felder, der Stack und die Einschränkungen festgehalten werden. Sollte vom KI-Assistenten vor jedem Codevorschlag gelesen werden.
Qwen Code – Szenario data-contract-review: Internes Review-Szenario in Qwen Code. Wird nach der Implementierung ausgeführt und prüft die Änderung gegen die Spezifikation, die PII-Politik, die Tests und die Abnahmefakten, ohne Dateien des Autors zu bearbeiten.
Vorlage für die SDD-Data-Retrospektive: Markdown-Vorlage mit den Abschnitten „Was die Spezifikation gut beschrieben hat / Was nach SQL präzisiert werden musste / Welche Prüfungen den Fehler gefangen haben / Wo Qwen Code versucht hat, die Bedeutung zu erraten / Was vor der Überführung in den produktiven Kreislauf zu verstärken ist“. Sollte nach jeder Prüfung und jedem größeren Feature ausgefüllt werden.
Zusammenfassung: Teil 22 „Praktische Prüfung“ ist die abschließende Prüfung nicht der dbt-Syntaxkenntnisse, sondern der Fähigkeit, das Versprechen eines Datenprodukts von der Spezifikation bis zum Reviewer-Bericht einzuhalten. Schlüsselidee: Die Prüfung beginnt mit einer absichtlich schwachen Spezifikation („eine nützliche Mart erstellen“), und ein guter Ingenieur muss sie vor SQL stoppen. Die Prüfung besteht aus vier Blöcken: 12 schriftliche Fragen zur SDD-Data-Terminologie (Grain, ODPS vs ODCS, Vertragsdrift, PII, dbt build, Abnahmefakten, menschliche Bestätigung); Aufgabe, 10+ Probleme in einer schwachen Spezifikation zu finden; Umschreiben in ein vollständiges SDD-Data-Format; Implementierung der Mart mart_customer_risk_summary mit einem vollständigen Beweispaket – Spezifikation vor SQL, dbt-Tests, Vertragsauswirkung, Reviewer-Bericht, Retrospektive. Das Paarformat zeigt, dass Review eine aktive Rolle ist. Bewertung nach der 25-Punkte-Rubrik: 21+ Punkte – der Prozess kann auf ein produktives Datenprodukt übertragen werden; 16–20 – das Ergebnis ist für das Lernen nützlich, aber Prüfung und Review müssen verstärkt werden; unter 16 – die Phase ist zu groß oder die Spezifikationen halten die Bedeutung nicht. Wichtigste praktische Erkenntnis: Wenn in der Retrospektive „was nach SQL präzisiert werden musste“ mehr als drei Punkte umfasst, muss das nächste Feature reduziert oder vor der Implementierung detaillierter beschrieben werden.