Teil 14. Silver-Layer: Kunden, Konten, Karten, Zahlungen
Der Silver-Layer erzeugt stabile Zwischenentitäten. Es sind keine endgültigen Data Marts für Konsumenten, aber auch keine rohen Quellen mehr. Silver muss wiederverwendbar sein: Customer 360, das Risiko-Mart und das Kredit-Mart können dieselben Zwischenmodelle lesen, ohne Logik zu kopieren.
Was gehört zum Silver-Layer
Im Lernbeispiel wird Silver durch Intermediate-Modelle dargestellt:
int_customer_balances;int_customer_card_activity.
Sie aggregieren Konten und Kartenoperationen zu Signalen auf Kundenebene, die anschließend von mart_customer_360 verwendet werden.
Silver-Regeln
- keine direkten PII weitergeben, als nötig;
- eine verständliche Granularität beibehalten;
- keine unverwandten Domänen vermischen;
- keine Produktentscheidungen treffen, wenn das Modell wiederverwendbar ist;
ref()verwenden, damit die Lineage in dbt lesbar ist.
Wenn int_customer_card_activity risk_event_count_7d berechnet, muss die Spezifikation erklären, was diese 7 Tage bedeuten und woher das Risiko-Flag stammt. Wenn dies fehlt, ähnelt das Modell eher SQL als einem stabilen Daten-Asset.
Abnahmefakten
Für Silver:
- Eingabemodelle werden nur über
ref()gelesen;
- Modelle auf Kundenebene haben eine Zeile pro
customer_id; - Beträge werden nicht ohne Erklärung null;
- Risiko-Zähler haben ein verständliches Zeitfenster;
- PII gelangen nicht ohne Richtlinie in die wiederverwendbare Schicht.
Qwen-Abfrage
Vergleiche Intermediate-Modelle mit Spezifikationen und Mart-Anforderungen.
Zeige die Granularität jedes Intermediate-Modells, die `ref()`-Eingaben, wiederverwendbare Felder
und Prüfungslücken.
Ändere keine Dateien.Minimale Ausgabe
Erstellen Sie eine Tabelle:
| Modell | Granularität | Eingaben | Verwendet in | Prüfungslücke |
|---|---|---|---|---|
| int_customer_balances | customer_id | stg_accounts | mart_customer_360 | |
| int_customer_card_activity | customer_id | stg_card_transactions | mart_customer_360 |
Eine leere Prüfungslücke bedeutet, dass das Modell ausreichend beschrieben und prüfbar ist.
Erläuterung für den Leser
Der Silver-Layer wird oft zum Ort, an dem ein Projekt entweder reift oder in zufälligen Transformationen versinkt. Hier sind die Quellen bereits auf verständliche Typen gebracht, aber noch nicht zu Produkten geworden. Das bedeutet, dass die Versuchung entsteht, die Daten „ein wenig zu verbessern": Kunden mit Konten verbinden, seltsame Zeilen entfernen, Risiken umbenennen, ein bequemes Merkmal berechnen. Wenn diese Entscheidungen nicht dokumentiert sind, wird der Silver-Layer zu einer versteckten Geschäftsschicht.
Ein guter Silver-Layer baut stabile Entitäten auf: Kunde, Konto, Transaktion, Kredit, Einwilligungen. Er beseitigt technischen Schmutz, nimmt sich aber nicht das Recht, das Produktversprechen zu ändern. Beispielsweise kann man customer_id auf einen einheitlichen Namen bringen und Salden für die weitere Aggregation vorbereiten. Ohne Spezifikation darf man nicht entscheiden, dass ein Kunde nur bei positivem Saldo aktiv ist, wenn dies die Konsumenten beeinflusst.
Silver ist auch als Wiederverwendungsschicht nützlich. Wenn jedes Gold-Mart selbst Kunden und Konten bereinigt, werden Abweichungen unvermeidlich auftreten. Ein Mart behandelt null anders, ein anderes filtert geschlossene Konten anders, ein drittes berechnet die Überfälligkeit anders. Eine gemeinsame Silver-Schicht macht diese Entscheidungen sichtbar und reduziert Duplikation, aber nur, wenn sie selbst verständlich und prüfbar bleibt.
Für den Leser ist es wichtig, Silver nicht an der Anzahl der Modelle zu messen. Manchmal ist ein sorgfältiges Intermediate-Modell besser als drei Schichten mit schönen Namen. Das Kriterium ist einfach: Hilft die Schicht, eine wiederholbare Entität auszudrücken und ihre Qualität zu beweisen? Wenn die Antwort nein ist, wurde das Modell wahrscheinlich für architektonische Symmetrie geschaffen, nicht für den Leser oder Datenkonsumenten.
Praxis
Erstellen Sie eine Tabelle mit Granularität / Eingaben / Verwendet in für die zwei Intermediate-Modelle des Beispiels. Wenn ein Modell mehr als einen Verwendungszweck hat, trennen Sie die Verwendungszwecke mit Worten, bevor Sie SQL ändern.
Typischer Fehler
Silver in eine „Müllhalde bequemer CTEs" verwandeln. Wenn sich ein Modell nicht mit einer Granularität und einem Verwendungszweck beschreiben lässt, ist es zu breit.
Kontrollfragen
- Warum sollte Silver nicht an ein einzelnes Produkt gebunden sein?
- Welche Felder aus dem Staging dürfen nicht ohne Richtlinie weitergetragen werden?
- Wie hilft
ref()dem Reviewer?