Teil 16. Mart Customer 360
mart_customer_360 ist der erste finale Mart. Er vereint Kundenattribute, Salden auf Konten und Kartenaktivität. Dies ist das wichtigste Lernbeispiel: Hier zeigt sich, wie Produktspezifikation, ODCS, Modellspezifikation, dbt-Tests und Prüftatsachen zusammenarbeiten müssen.
Abnahmetatsachen
- eine Zeile pro
customer_id; customer_idnot null und unique;- keine direkten PII;
total_balance_rubnot null;risk_event_count_7dnot null;- Pflichtfelder des Vertrags vorhanden;
- Lineage ist über
ref()lesbar.
Umsetzung
Öffnen Sie:
models/marts/mart_customer_360.sql
models/schema.yml
specs/models/mart_customer_360.md
specs/validation/customer_360.md
Prüfen Sie, dass das SQL der Spezifikation folgt und die Tests die wichtigsten Tatsachen abdecken. Beschränken Sie sich nicht auf das Lesen des SQLs: PII-Lecks und Vertragsdrift müssen separate Prüfungen haben.
Abnahmematrix
| Tatsache | Nachweis |
|---|---|
eine Zeile pro customer_id | dbt-Test unique |
customer_id nicht leer | dbt-Test not_null |
| keine direkten PII | singulärer Schematest |
| Gesamtsaldo vorhanden | dbt-Test not_null |
| Risiko-Counter vorhanden | dbt-Test not_null |
| Vertragsfelder vorhanden | singulärer Test der Vertragsspalten |
Wenn die Nachweiszeile leer ist, ist das keine Bereitschaft, sondern eine Lücke.
Qwen-Anfrage
Vergleiche models/marts/mart_customer_360.sql, models/schema.yml,
specs/customer_360_contract.odcs.yaml und specs/validation/customer_360.md.
Zeige, welche Abnahmetatsachen abgedeckt sind, welche manuell sind und welche
fehlen. Dateien nicht ändern.
Minimale Ausgabe
Erstellen Sie eine Reviewer-Notiz:
Granularität: eine Zeile pro `customer_id`.
PII: keine direkten PII.
Vertragsfelder: `customer_id`, `total_balance_rub`, `risk_event_count_7d`.
Prüfungen: `dbt build`, Mart-Tests, Liste verbotener PII, Vertragsspalten.
Offene Fragen: die Definition von `risk_event_count_7d` hängt vom eingehenden
Risiko-Flag ab.
Analyse für den Leser
Customer 360 ist ein guter erster Mart, weil der Name vertraut und deshalb gefährlich ist. Fast jeder Projektbeteiligte glaubt, dessen Bedeutung zu verstehen, aber bei verschiedenen Leuten sind es unterschiedliche Tabellen. Für einen Analysten kann es ein Kundenschnitt sein. Für das Marketing ein Profil mit Segmenten. Für das Risiko Verhaltensaggregate. Für das Operationsteam ein Satz Identifikatoren. SDD zwingt dazu, eine Version des Versprechens zu wählen und sie vor dem SQL aufzuschreiben.
In diesem Buch ist Customer 360 bewusst eingeschränkt. Eine Zeile pro Kunde. Direkte PII werden nicht offengelegt. Der Saldo wird aus Konten berechnet. Risikoereignisse stammen aus einem synthetischen Aktivitätsfenster. Eine solche Einschränkung mag arm erscheinen, macht das Beispiel jedoch ehrlich: Jedes Feld lässt sich mit einer Spezifikation und einer Prüfung verknüpfen. Wenn man alles auf einmal hinzufügt, sieht der Studierende eine große Tabelle, aber nicht die Produktdisziplin.
Besondere Aufmerksamkeit verdient risk_event_count_7d. Der Name selbst verspricht ein Sieben-Tage-Fenster. Wenn das SQL einfach alle Risikoereignisse zählt, sieht das Feld plausibel aus, täuscht aber den Konsumenten. Deshalb muss das Fenster beschrieben und durch einen separaten Test geprüft werden. Dies ist ein kleines Beispiel einer großen Idee: Der Feldname wird Teil des Vertrags. Wenn der Name eine Frist, Währung, einen Status oder eine Aggregationsebene enthält, muss die Prüfung genau das bestätigen.
Customer 360 zeigt auch, warum die PII-Richtlinie nicht als allgemeine Phrase bleiben darf. In raw und staging darf es pii_email geben, damit der Studierende das Risiko sieht. Im Mart darf es nicht vorkommen. Das ist keine Frage der Schema-Ästhetik, sondern eine Produktgrenze. Der Reviewer muss nicht nur die endgültige select-Anweisung prüfen, sondern auch den Test, der das Fehlen direkter PII-Felder nachweist.
Übung
Führen Sie nur die Prüfungen für Customer 360 aus und ordnen Sie jede Ausgabezeile der Abnahmematrix zu. Wenn eine Tatsache nur durch manuelles Review bestätigt wird, schreiben Sie genau das auf.
Typischer Fehler
SQL nur mit den Augen prüfen. In SDD ist ein Nachweis nötig: dbt-Test, Schema-Review, explizite Prüftatsache oder Reviewer-Bericht.
Kontrollfragen
- Warum darf
pii_emailnicht in den Mart gelangen? - Welche Felder machen den Mart zur Kundenebene?
- Was ändert sich, wenn eine Detaillierung nach Produkt hinzugefügt wird?