Teil 7. Spezifikation des ersten Datenprodukts

Das erste Datenprodukt des Buches ist customer_360. Es soll Analysten einen Kundenschnitt ohne direkte PII liefern. In diesem Schritt ist es wichtig, kein SQL zu schreiben. Zuerst muss das Produktversprechen formuliert werden: wer der Konsument ist, welche Ausgabe, welcher Grain, welche Felder obligatorisch sind, welche Aktualität und welche Prüfungen die Bereitschaft belegen.

Artefakte

specs/customer_360_product.odps.yaml
specs/customer_360_contract.odcs.yaml
specs/models/mart_customer_360.md
specs/validation/customer_360.md

ODPS beschreibt das Produkt. ODCS beschreibt den technischen Vertrag. Die Modellspezifikation beschreibt den Grain und die Abnahmefakten. Die Prüfnotiz verbindet die Spezifikation mit den Befehlen und Prüfungen des Reviewers.

Grain

Für mart_customer_360 ist der Grain einfach:

eine Zeile pro `customer_id`

Wenn account_id, product_code oder scope hinzugefügt werden, ist das bereits ein anderes Mart. Eine solche Änderung erfordert eine Bestätigung, da der Konsument weiter unten in der Kette sonst eine andere Zeileneinheit erhält.

PII-Richtlinie

Staging darf pii_email lesen, um das Risiko aufzuzeigen. Das Mart darf es nicht offenlegen. Die Regel muss überprüfbar sein:

models/marts/mart_customer_360.sql enthält keine direkten PII-Felder.
dbt-Singular-Test assert_customer_360_no_direct_pii gibt 0 Zeilen zurück.

SLA und Aktualität

Im Lehrbeispiel beträgt die Aktualität 24 Stunden. Lokal bauen wir keinen Scheduler, daher bleibt die Aktualität ein Produktversprechen und ein Releasehinweis. In einer produktiven Umgebung muss sie durch Lade-Metadaten, Quell-Aktualität oder einen Orchestrator unterstützt werden.

Anfrage für Qwen Code

Lies specs/customer_360_product.odps.yaml,
specs/customer_360_contract.odcs.yaml und specs/models/mart_customer_360.md.
Formuliere Grain, PII-Richtlinie, SLA, obligatorische Felder und Abnahmefakten.
Ändere keine Dateien.

Minimale Ausgabe

Nach dem Kapitel soll eine Tabelle vorhanden sein:

Diese Tabelle wird zum Orientierungspunkt für die Teile 10–16.

Analyse für den Leser

Die Datenproduktspezifikation ist der Ort, an dem die technische Tabelle zum ersten Mal

zu einem Versprechen wird. Davor sieht mart_customer_360 wie ein Modellname aus. Danach ist es bereits ein Vertrag mit dem Konsumenten: wer das Mart benötigt, was die Zeile bedeutet, welche Felder obligatorisch sind, welche Felder verboten sind, welches Datenalter zulässig ist. Wenn dieser Vertrag nicht aufgeschrieben ist, beginnt SQL die Rolle des Produkts zu spielen, obwohl SQL nur die Art der Berechnung zeigt.

ODPS und ODCS trennen zwei verschiedene Gespräche. ODPS spricht über das Produkt: wer der Konsument ist, warum das Mart existiert, welches Ergebnis es verspricht. ODCS spricht über den technischen Vertrag: welche Felder, Typen, SLA und Änderungsregeln erhalten bleiben müssen. Wenn diese Schichten vermischt werden, wird das Review unklar. Man kann nicht erkennen, ob der Produktsinn oder nur die technische Form gebrochen ist.

Grain sollte vor dem SQL geschrieben werden, weil der Autor nach dem SQL bereits einen konkreten Join, eine konkrete Gruppierung und einen konkreten bequemen Spaltensatz sieht. In dieser Phase ist es leicht, eine übermäßige Detaillierung zu rechtfertigen: «sie wird nützlich sein», «sie stört nicht», «so lässt es sich leichter prüfen». Aber für den Konsumenten kann es ein anderes Produkt sein. Eine Zeile pro Kunde und eine Zeile pro Kunden-Produkt sind unterschiedliche Versprechen, auch wenn beide Tabellen Customer 360 heißen.

Eine gute Spezifikation versucht nicht, die gesamte Zukunft zu beschreiben. Sie legt das Minimum fest, das für die erste Version nötig ist: Konsument, Grain, PII-Richtlinie, obligatorische Felder, SLA und Abnahmefakten. Das reicht aus, damit ein Agent das Mart implementieren kann und damit ein Reviewer es ablehnen kann. Wenn der Reviewer keinen Ablehnungsgrund nennen kann, ist die Spezifikation zu vage.

Übung

Vergleichen Sie ODPS, ODCS und die Modellspezifikation für Customer 360. Finden Sie je ein Feld, das zum Produkt, zum technischen Vertrag und zur Abnahme auf Modellebene gehört. Wenn ein Feld in der falschen Schicht vorkommt, notieren Sie, warum dies ein Risiko ist.

Typischer Fehler

«customer 360» als allgemeines Schlagwort aufzuschreiben. Für den Agenten ist das zu breit. Es muss explizit angegeben werden, welche Quellen einbezogen werden, welcher Grain, welche Felder verboten sind und was als Bereitschaft gilt.

Kontrollfragen

1. Wodurch unterscheidet sich ODPS von ODCS?
2. Warum sollte Grain vor dem SQL geschrieben werden?
3. Wie kann man überprüfen, dass das Mart keine PII offenlegt?