Material: Teil 16. Customer 360 Schaufenster

Lektion 1 von 5 im Modul «Teil 16. Customer 360 Schaufenster»
Sie sehen die Lektion ohne Anmeldung an. Anmelden, um Ihren Fortschritt zu speichern und Tests zu absolvieren.

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_id not null und unique;
  • keine direkten PII;
  • total_balance_rub not null;
  • risk_event_count_7d not 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

TatsacheNachweis
eine Zeile pro customer_iddbt-Test unique
customer_id nicht leerdbt-Test not_null
keine direkten PIIsingulärer Schematest
Gesamtsaldo vorhandendbt-Test not_null
Risiko-Counter vorhandendbt-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

  1. Warum darf pii_email nicht in den Mart gelangen?
  2. Welche Felder machen den Mart zur Kundenebene?
  3. Was ändert sich, wenn eine Detaillierung nach Produkt hinzugefügt wird?
Meine Notizen
0 / 10000

Notizen werden in diesem Browser gespeichert. Auf anderen Geräten erscheinen sie nicht.

Kursmenü

Kurs

SDD Data. Datenplattform einer Bank mit Qwen Code und dbt
Fortschritt 0 / 110