Teil 3. Überblick über den DataLakeHouse-Prozess

SDD Data folgt demselben Prinzip wie das Basis-SDD: zuerst die Absicht und überprüfbare Fakten, dann die Implementierung. Der Unterschied besteht darin, dass es mehr Artefakte gibt. Für ein gewöhnliches Feature reichen requirements.md, plan.md und validation.md. In einem Datenprojekt kommen das Quellprofil, das Schema-Manifest, ODCS/ODPS, die Modellspezifikation, dbt-Tests, Lineage und der Reviewer-Bericht hinzu.

Kernablauf

Mission -> Quellprofilierung -> Schema-Manifest -> Datenprodukt-Spezifikation
-> Vertrag -> dbt-Modell -> Prüffakten -> Reviewer-Bericht

Dieser Ablauf muss nicht schwerfällig sein. Für ein Lernbeispiel ist jedes Artefakt kurz, doch es beantwortet eine eigene Frage:

• Mission: Warum existiert die Plattform?
• Quellprofilierung: Was ist tatsächlich angekommen?
• Schema-Manifest: Welche Felder beobachten wir und was ist noch unbekannt?
• Datenprodukt-Spezifikation: Was versprechen wir dem Konsumenten?
• Vertrag: Welche Felder, SLAs und Qualität müssen erhalten bleiben?
• dbt-Modell: Wie bauen wir das Ergebnis?
• Prüffakten: Womit belegen wir die Bereitschaft?
• Reviewer-Bericht: Wer hat die Änderung geprüft und wo bleibt ein Risiko?

Rollen von Agent und Mensch

Der Agent erledigt mechanische Aufgaben gut: Er liest CSV-Dateien, schlägt ein Manifest vor, schreibt SQL und findet Diskrepanzen zwischen Spezifikation und Modell. Der Mensch ist für den Sinn verantwortlich: Grain, PII-Richtlinie, Business-Owner, Breaking Changes, Release-Freigabe. Wenn der Agent selbst entscheidet, dass customer_id durch account_id ersetzt werden kann, ist der Prozess bereits gescheitert.

Trennen Sie die Rollen:

• der Profiler liest Quellen und liefert Fakten zurück;
• der Builder schreibt Modelle gemäß genehmigten Spezifikationen;
• der Reviewer vergleicht die Änderung mit Verträgen und Prüffakten.

Auch wenn alle Rollen von einem Werkzeug übernommen werden, starten Sie sie in verschiedenen Sessions nach /clear. So wird geprüft, ob der Kontext ausreichend in den Dateien festgehalten ist.

Minimale Repository-Struktur

specs/
  mission.md
  tech-stack.md
  roadmap.md
  customer_360_product.odps.yaml
  customer_360_contract.odcs.yaml
  models/
    mart_customer_360.md
  validation/
    customer_360.md
models/
  staging/
  intermediate/
  marts/
tests/

Wenn eine wichtige Entscheidung nur im Chat lebt, wird sie der nächste Agent verlieren. Wenn sie in der Spezifikation steht, kann der Reviewer sie unabhängig überprüfen.

Analyse für die Lesenden

Die größte Gefahr beim DataLakeHouse-Prozess besteht darin, dass er einer linearen Treppe ähnelt: Quelle, Manifest, Vertrag, Modell, Prüfung, Review. In Wirklichkeit ist es keine Treppe, sondern ein rückgekoppeltes System. Die Quellprofilierung kann leere Daten zeigen. Der Vertrag kann aufdecken, dass das Produkt zu breit versprochen wurde. Das Review kann den Autor zurück zum Grain führen. SDD verbietet Rückschritte nicht; es macht sie sichtbar.

Jedes Artefakt in diesem Kapitel beantwortet seine eigene Frage. Das Manifest antwortet: „Was haben wir gesehen?“ Der Vertrag antwortet: „Was versprechen wir?“ Das Modell antwortet: „Wie bauen wir es?“ Die Prüfung antwortet: „Womit belegen wir es?“ Der Reviewer-Bericht antwortet: „Wer hat die Verknüpfung als Ganzes betrachtet?“ Wenn man diese Antworten in einem großen Dokument zusammenführt, wird es den Lesenden zunächst leichter und dann schwerer fallen: Quelle, Versprechen und Prüfung beginnen, sich unmerklich gegenseitig zu ersetzen.

Die Rollentrennung ist aus demselben Grund nötig. Der Autor eines Modells verteidigt naturgemäß seine Entscheidung. Selbst wenn der Autor ein Agent ist, ist er bereits den gewählten Weg gegangen und neigt dazu, ihn als richtig darzustellen. Der Reviewer im reinen Lese-Modus schaut anders: Er versucht nicht, die Implementierung zu retten, sondern prüft, ob sie das Versprechen einhält. Nach

/clear wird diese Prüfung ehrlicher, weil sich der Reviewer nicht an das Gespräch erinnert, in dem der Autor möglicherweise nicht dokumentierte Entscheidungen erklärt hat.

In der Praxis soll dieses Kapitel die Lesenden lehren, die leeren Stellen zu erkennen. Wenn es zwar SQL gibt, aber keine validation.md, ist das nicht „fast fertig“. Wenn es einen ODCS gibt, aber keine Prüfung der Pflichtfelder, ist das kein Vertrag, sondern eine Erklärung. Wenn es einen Reviewer-Bericht ohne Verweise auf Spezifikationen gibt, ist das eine Meinung, kein Beleg. SDD Data funktioniert nur, wenn die Lücken früher sichtbar werden als der Fehler die Mart-Tabelle erreicht.

Praxis

Zeichnen Sie eine Artefaktkarte für mart_customer_360: Welche Dateien sind für die Quellfakten, das Produktversprechen, den Vertrag, die Implementierung, validation.md und das Review verantwortlich? Markieren Sie separat die Lücken, in denen eine Datei noch nicht erstellt oder nicht mit einer Prüfung verknüpft ist.

Qwen-Anfrage für den Überblick

Lies AGENTS.md, specs/mission.md, specs/tech-stack.md und specs/roadmap.md.
Erstelle eine Karte der DataLakeHouse-Artefakte: Welche Dateien sind für Quellfakten,
Produktversprechen, Vertrag, dbt-Implementierung und Prüfung verantwortlich.
Ändere keine Dateien.

Minimale Ausgabe

Erstellen Sie workflow-map.md oder eine Arbeitsnotiz:

Quellfakten:
Produktversprechen:
Vertrag:
Implementierung:
Prüfung:

Review:

Geben Sie für jeden Punkt eine Datei an oder markieren Sie eine Lücke. Eine Lücke sieht man besser jetzt als nachdem das SQL bereits geschrieben wurde.

Typischer Fehler

Einen einzigen /sdd:do-everything-Befehl auszuführen. Er ist in einer Demonstration praktisch, zerstört aber die Kontrolle durch den Menschen. In Bankdaten ist es gefährlich, wenn ein Agent selbst die Quelle profiliert, selbst das Grain festlegt, selbst SQL schreibt und selbst die Bereitschaft bestätigt.

Kontrollfragen

1. Wodurch unterscheidet sich das Schema-Manifest von der Datenprodukt-Spezifikation?
2. Warum sollten Builder und Reviewer getrennte Rollen sein?
3. Wie hilft /clear dabei zu prüfen, dass der Prozess in Dateien festgehalten ist?