Thema: Teil 14. Silver Layer: Kunden, Konten, Karten, Zahlungen
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2,5–3 Stunden (Theorie — 1 Stunde, Praxis — 1 Stunde, Fallbeispiele und Wiederholung — 1 Stunde)
Voraussetzungen: Verständnis der Medallion-Architektur (Bronze/Silver/Gold) in einem Data Lakehouse
Grundkenntnisse in dbt: Modelle, ref(), Sources, Tests
SQL-Kenntnisse auf dem Niveau von JOIN, GROUP BY und Fensterfunktionen
Vorstellung vom Fachgebiet Bankdaten: Kunden, Konten, Karten, Zahlungen
Vertrautheit mit den Begriffen Grain, PII, Lineage
Lernziele: Die Rolle des Silver-Layers als wiederverwendbare Zwischenschicht zwischen Staging und Mart erklären
Den Grain (die Granularität) der Mittel-Modelle int_customer_balances und int_customer_card_activity bestimmen und formulieren
Die Regeln des Silver-Layers anwenden: Verbot des PII-Durchsickerns, verständlicher Grain, keine Produktentscheidungen, Verwendung von ref() für die Lineage
Eine Abnahmeprüfung von Silver-Modellen anhand formalisierter Qualitätskriterien durchführen
Eine Zuordnungstabelle Grain / Eingaben / Verwendung / Validierungslücke für Mittel-Modelle ausfüllen
Übersicht: Der Silver Layer in der dbt-Architektur der Bankfachdomäne ist eine Schicht stabiler Zwischenentitäten, die zwischen den rohen Staging-Modellen und den finalen Mart-Datensätzen liegt. Sie beseitigt die technische Unsauberkeit der Quellen (Typumwandlung, Schlüsselnormalisierung, einfachste Aggregationen), trifft jedoch keine Produktentscheidungen, die das Geschäftsversprechen beeinflussen. Im Lernbeispiel wird der Silver Layer durch zwei Mittel-Modelle repräsentiert: int_customer_balances (Aggregation von Konten bis auf die Kundenebene) und int_customer_card_activity (Aggregation von Kartenoperationen und Risikosignalen). Der Hauptwert des Silver Layers liegt in der Wiederverwendbarkeit: ein und dasselbe Modell kann vom Customer-360-Mart, vom Kredit-Mart und vom Risiko-Mart gelesen werden, ohne die Logik zu duplizieren. Diese Wiederverwendbarkeit erfordert jedoch Disziplin: verständlicher Grain, dokumentierte Zeitfenster für Zähler, eine PII-Richtlinie und die obligatorische Verwendung von ref() zum Aufbau der Lineage.
Schlüsselkonzepte: Silver Layer (Zwischenschicht): Eine Schicht in der Medallion-Architektur, die stabile, wiederverwendbare Entitäten aus Rohdaten erzeugt. Sie verbindet Staging (Bereinigung und Typisierung der Quellen) mit Mart (Geschäftsdatensätze für Konsumenten). Sie ist kein Endprodukt, aber auch keine Rohquelle mehr.
Mittel-Modell (int ): Ein Modelltyp in dbt, der zwischen Staging und Mart liegt. Hat das Präfix int_. Enthält Zwischentransformationen und -aggregationen. In diesem Teil: int_customer_balances und int_customer_card_activity.
Grain (Granularität): Eine Schlüsseleigenschaft einer Tabelle — eine Zeile pro welcher Entität (customer_id, account_id, transaction_id). Bestimmt, was als Datensatz in der Tabelle zählt. Ein Modell mit nicht offensichtlichem Grain wird für die Wiederverwendung ungeeignet.
Int customer balances: Ein Mittel-Modell, das Daten aus stg_accounts bis auf die Kundenebene aggregiert. Grain: eine Zeile pro customer_id. Wird in mart_customer_360 verwendet. Enthält aggregierte Salden des Kunden über alle seine Konten.
Int customer activity: Ein Mittel-Modell, das Kartenoperationen aus stg_card_transactions aggregiert und Signale auf Kundenebene zählt, einschließlich Risiko-Zählern (z. B. risk_event_count_7d). Grain: eine Zeile pro customer_id.
Pii (personally identifiable information): Personenbezogene Daten des Kunden (Vor- und Nachname, Reisepass, Telefon, E-Mail). Der Silver Layer darf direkte PII nicht weitergeben, als nötig, und nur mit einer Verarbeitungsrichtlinie.
Ref(): Eine dbt-Funktion, die verwendet wird, um auf andere Modelle im Projekt zu verweisen. Erzeugt eine explizite Lineage (Datenherkunft), die der Reviewer im DAG sieht. Im Silver Layer müssen alle Eingabemodelle ausschließlich über ref() gelesen werden.
Lineage (Datenherkunft): Ein Abhängigkeitsgraph zwischen Modellen, der von dbt automatisch auf Basis von ref() aufgebaut wird. Ermöglicht zu verstehen, welche Modelle von einem bestimmten Modell abhängen und welche Quellen es verwendet.
Risiko-Zähler mit verständlichem Zeitfenster: Eine Aggregation (z. B. risk_event_count_7d), bei der das Zeitfenster (7 Tage) und die Definition des Risiko-Flags in der Modellspezifikation explizit beschrieben sein müssen. Ohne diese Angaben ist das Modell nicht überprüfbar.
Wiederverwendbarkeit des Silver Layers: Die Eigenschaft, dass ein und dasselbe Mittel-Modell von mehreren Mart-Datensätzen ohne Duplizierung der Logik verwendet werden kann. Verringert das Risiko von Abweichungen zwischen den Datensätzen.
Validierungslücke (validation gap): Eine Situation, in der ein Modell keine ausreichende Spezifikation zur Überprüfung der Datenqualität besitzt: kein Zeitfenster beschrieben, kein Nullwert erklärt, kein Grain definiert. Eine leere Validierungslücke = das Modell ist ausreichend beschrieben.
Produktentscheidung: Eine Geschäftsregel, die festlegt, was als „aktiver Kunde“, „überfällige Zahlung“, „kreditwürdig“ gilt. Der Silver Layer sollte solche Entscheidungen nicht treffen, wenn er wiederverwendbar ist — dies ist die Aufgabe des Mart-Layers.
Qwen-Anfrage für das Review: Ein spezialisierter Prompt für einen LLM-Assistenten, der Mittel-Modelle mit den Spezifikationen und Anforderungen der Marts vergleicht, Grain, Eingaben und Validierungslücken erkennt, ohne Dateien zu verändern.
Wichtige Termine: Etappe 1 — Entwurf des Silver Layers: Eine architektonische Entscheidung über die Abtrennung von Zwischenentitäten vor der Erstellung der Mart-Datensätze. Sie ist nicht an ein Kalenderdatum gebunden, aber ein obligatorischer Meilenstein des Projekts.
Etappe 2 — Abstimmung der Spezifikationen: Der Moment, in dem jedes int_-Modell einen dokumentierten Grain, Zeitfenster für Zähler und eine PII-Richtlinie erhält. Vor diesem Moment gilt das Modell nicht als bereit für den Merge.
Etappe 3 — Abnahmeprüfung: Ein formaler Durchlauf anhand der Checkliste: ref() bei den Eingaben, eine Zeile pro customer_id für Kundenmodelle, keine unerklärten Nullwerte, verständliche Zeitfenster für Risiko-Zähler.
Übungsaufgaben: Name: Erstellung einer Zuordnungstabelle für zwei Mittel-Modelle
Problem: Erstellen Sie anhand des Materials aus Teil 14 die Tabelle Grain / Eingaben / verwendet in / Validierungslücke für die Modelle int_customer_balances und int_customer_card_activity. Geben Sie für jedes Modell an: (1) die Granularität — auf welche Entität eine Zeile entfällt; (2) die Eingaben — welche Staging-Modelle es über ref() liest; (3) wo es verwendet wird — welche Mart-Modelle es lesen; (4) die Validierungslücke — was in der Spezifikation nicht beschrieben ist (wenn alles beschrieben ist, lassen Sie die Zelle leer).
Lösung: Schritt 1. Bestimmen wir den Grain für int_customer_balances: Das Modell aggregiert Konten bis auf die Kundenebene, also entspricht eine Zeile = ein customer_id. Schritt 2. Eingaben laut Text: stg_accounts. Schritt 3. Verwendet in: mart_customer_360. Schritt 4. Validierungslücke: Im Material sind Grain und Eingaben explizit angegeben, Zeitfenster werden nicht verwendet (Aggregation von Salden), PII wird nicht als Problembereich erwähnt — die Lücke ist leer. Schritt 5. Bestimmen wir den Grain für int_customer_card_activity: Das Modell aggregiert Kartenoperationen bis auf die Kundenebene, eine Zeile = ein customer_id. Schritt 6. Eingaben: stg_card_transactions. Schritt 7. Verwendet in: mart_customer_360. Schritt 8. Validierungslücke: Das Modell berechnet risk_event_count_7d, aber in der Spezifikation muss erklärt werden, was „7 Tage“ bedeutet (Zeitfenster ab welchem Datum, gleitend oder fest) und woher risk_flag stammt (Schwellenwert, Quelle). Wenn dies nicht beschrieben ist, besteht eine Lücke. Ergebnistabelle: siehe Abschnitt „Mindestausgabe“ im Material.
Komplexität: intermediate
Name: Erkennung von Produktentscheidungen in einem Silver-Modell
Problem: Ihnen wurde SQL-Code von int_customer_card_activity übergeben, der die Zeile enthält: WHERE balance > 0 AND last_transaction_date > CURRENT_DATE - INTERVAL '90 days'. Ein Kollege behauptet, dies sei lediglich ein Filter für „Aktivität“. Stellen Sie fest, ob dies die Regeln des Silver Layers verletzt und welche Konsequenzen dies haben kann.
Lösung: Schritt 1. Analysieren wir die Logik: balance > 0 ist eine Geschäftsregel darüber, dass der Kunde „über Mittel verfügt“. last_transaction_date > CURRENT_DATE - INTERVAL '90 days' ist eine Geschäftsdefinition der „Aktivität“ eines Kunden. Schritt 2. Vergleichen wir mit den Silver-Regeln: Der Silver Layer sollte keine Produktentscheidungen treffen, wenn das Modell wiederverwendbar ist. Schritt 3. Ziehen wir eine Schlussfolgerung: Die Bedingung verwandelt das Silver-Modell in eine Produktentscheidung (Definition des „aktiven Kunden“), wodurch es für andere Mart-Datensätze ungeeignet wird, in denen die Aktivitätsdefinition abweichen kann (z. B. kann das Kredit-Scoring 180 Tage verwenden). Schritt 4. Empfehlung: Entfernen Sie den Filter aus dem int_-Modell. Aggregate (z. B. days_since_last_transaction, has_positive_balance) sollten als Felder ausgegeben werden, und die Entscheidung über die „Aktivität“ sollte im Mart-Layer getroffen werden.
Komplexität: intermediate
Name: Audit der Lineage über ref()
Problem: Im Projekt wurde das Modell int_customer_card_activity_v2 gefunden, das stg_card_transactions direkt über source() liest, anstatt über ref() auf stg_card_transactions. Wie wirkt sich dies auf das Review aus und welche Risiken entstehen dadurch?
Lösung: Schritt 1. Überprüfen wir die Anforderungen des Silver Layers: „Eingabemodelle werden ausschließlich über ref() gelesen“. Schritt 2. Was passiert bei Verwendung von source() anstelle von ref(): dbt nimmt die Abhängigkeit zwischen int_customer_card_activity_v2 und stg_card_transactions nicht als Model-to-Model-Beziehung in den DAG des Projekts auf. Schritt 3. Konsequenzen für den Reviewer: Der Reviewer sieht in der Lineage nicht, dass das int_-Modell vom stg_-Modell abhängt; er kann nicht nachvollziehen, welche Mart-Datensätze bei einer Änderung der Quelle betroffen sind; Tests auf stg_card_transactions werden nicht automatisch auf abhängige Modelle übertragen. Schritt 4. Empfehlung: Korrigieren Sie den Code zu ref('stg_card_transactions') und prüfen Sie, ob das Modell im DAG erscheint (Befehl dbt ls --select int_customer_card_activity_v2 --output name).
Komplexität: beginner
Name: Dokumentation eines Risiko-Zählers
Problem: Das Modell int_customer_card_activity enthält das Feld risk_event_count_7d mit dem Wert 0 oder einer ganzen Zahl. Schreiben Sie eine Spezifikation für dieses Feld, damit es die Abnahmeprüfung des Silver Layers besteht.
Lösung: Die Spezifikation muss Folgendes enthalten: (1) Definition eines Risiko-Ereignisses — z. B. „eine Transaktion, die in stg_card_transactions mit dem Flag is_risk markiert ist“ oder „eine Transaktion mit einem Score > 0,8 gemäß dem Anti-Fraud-Modell“. (2) Definition des Zeitfensters — „die letzten 7 Kalendertage bis zum Ausführungsdatum des Modells (execution_date - 7 days)“ oder „7 Tage bis zum Transaktionsdatum“. (3) Art des gleitenden Zeitfensters — fest oder rollierend (rolling). (4) Quelle des Risiko-Flags — stg_card_transactions.is_risk oder eine separate Tabelle risk_scores. (5) Behandlung von Nullwerten — wenn risk_score leer ist, wird das Ereignis nicht gezählt (oder doch, eine explizite Anweisung ist erforderlich). (6) Grain des Ergebniswerts — Anzahl der Ereignisse pro customer_id innerhalb des Zeitfensters. Ohne eine solche Spezifikation ähnelt das Modell eher SQL als einem stabilen Daten-Asset.
Komplexität: intermediate
Name: Refactoring eines breiten int_-Modells
Problem: Im Repository wurde das Modell int_customer_universe gefunden, das Folgendes enthält: Kundensalden, Aggregate von Kartenoperationen, Produktflags, Status der AML-Prüfung und Kundeneinwilligungen. Erklären Sie, warum dies die Regeln des Silver Layers verletzt, und schlagen Sie einen Refactoring-Plan vor.
Lösung: Schritt 1. Überprüfen wir die Regeln: Der Silver Layer sollte unverwandte Domänen nicht vermischen und sollte einen verständlichen Grain sowie einen einzigen Zweck haben. Schritt 2. Analysieren wir das Modell: Es vermischt mindestens drei Domänen — Kundenfinanzen (Salden), Verhaltenssignale (Kartenoperationen), Compliance (AML, Einwilligungen). Jede dieser Domänen hat ihre eigene Aktualisierungsdynamik, ihre eigenen Verantwortlichen und ihre eigenen Mart-Konsumenten. Schritt 3. Ein Grain (customer_id) ist formal vorhanden, aber ein einzelner Zweck fehlt: Das Modell versucht, eine universelle Sammelstelle für alle Mart-Datensätze gleichzeitig zu sein. Schritt 4. Refactoring-Plan: Aufteilen in drei int_-Modelle — int_customer_balances, int_customer_card_activity, int_customer_compliance (mit AML und Einwilligungen). Wenn der Customer-360-Mart alle drei benötigt, führt er den JOIN selbst über ref() durch. Schritt 5. Überprüfen wir anhand des Kriteriums aus dem Material: „Hilft die Schicht dabei, eine wiederkehrende Entität auszudrücken und ihre Qualität nachzuweisen?“. Nach der Aufteilung — ja; vor der Aufteilung — nein.
Komplexität: advanced
Fallstudien: Name: Fallbeispiel: Abweichung bei „aktiven Kunden“ zwischen Risiko- und CRM-Datensätzen
Szenario: Eine Bank aus den Top 20 (bedingtes Beispiel) baute ein Data Lakehouse auf dbt auf. Der Silver Layer enthielt das Modell int_customer_activity, das Operationen und Konten auf der Ebene customer_id aggregierte. Davon hingen zwei Mart-Datensätze ab: mart_risk_scoring (für das Kredit-Scoring) und mart_crm_active_customers (für Marketingkampagnen). In int_customer_activity war ein Filter eingebaut: customer_id IN (SELECT customer_id FROM stg_accounts WHERE balance > 0).
Aufgabe: Nach einem halben Jahr forderte das Produktteam für das Risiko-Scoring eine Neuberechnung mit einer anderen Aktivitätsdefinition (unter Berücksichtigung von Kreditlinien, ohne die Anforderung eines positiven Saldos). Parallel dazu bat das CRM-Team darum, den Filter zu verschärfen (nur Kunden mit Operationen in den letzten 30 Tagen). Es wurde deutlich, dass das Silver-Modell nicht wiederverwendbar war — jeder Mart-Datensatz musste seine eigene Kopie der Logik erstellen. Es entstanden Abweichungen: mart_risk_scoring_v1 zeigte 1,2 Mio. „aktive“ Kunden, mart_crm_active_customers_v1 — 800 Tsd., und mart_credit_eligibility_v2 (ein neuer Datensatz) — 950 Tsd. Analysten stritten darüber, welche Zahl die richtige sei, und die Prüfer stellten einen Verstoß gegen das Prinzip der einzigen Quelle der Wahrheit fest.
Lösung: Das Datenteam führte ein Refactoring des Silver Layers nach den in Teil 14 beschriebenen Prinzipien durch. Schritt 1: int_customer_activity wurde gelöscht. Schritt 2: Es wurden zwei getrennte int_-Modelle erstellt — int_customer_balances (Aggregate der Salden, ohne Filter für „Aktivität“) und int_customer_card_activity (Aggregate von Operationen mit dokumentiertem Zeitfenster risk_event_count_7d). Schritt 3: Für mart_risk_scoring wurde das Feld has_positive_balance als Attribut hinzugefügt, und der Aktivitätsfilter wurde in den Mart selbst verlagert. Schritt 4: Für mart_crm_active_customers wurde ebenfalls days_since_last_transaction als Attribut verlagert, und der Geschäftsfilter „30 Tage“ lebt im Mart. Schritt 5: Für mart_credit_eligibility — eine eigene Definition im Mart. Schritt 6: Es wurde eine Abnahmeprüfung anhand der Silver-Checkliste durchgeführt — ref() bei den Eingaben, eine Zeile pro customer_id, keine unerklärten Nullwerte, Zeitfenster für Zähler dokumentiert.
Ergebnis: Zwei Monate nach dem Refactoring: (1) Drei Mart-Datensätze lesen dieselben Silver-Modelle, Abweichungen in der Definition von „Aktivität“ wurden sichtbar und diskutierbar; (2) die Zeit für die Änderung der Aktivitätslogik verkürzte sich von 3 Wochen (als drei Kopien geändert werden mussten) auf 3 Tage (wenn nur der Mart geändert wird); (3) das Audit wurde ohne Beanstandungen hinsichtlich des Prinzips der einzigen Quelle der Wahrheit abgeschlossen; (4) die Lineage in dbt wurde transparent — jede Änderung in int_customer_card_activity ist in allen abhängigen Marts sichtbar.
Gewonnene Erkenntnisse: Der Silver Layer darf keine Produktfilter enthalten — andernfalls verliert er seine Wiederverwendbarkeit
Abweichungen zwischen Mart-Datensätzen sind ein Symptom für eingebaute Geschäftsregeln im Silver Layer
Das Prinzip „ein Modell — ein Zweck — ein Grain“ ist wichtiger als architektonische Schönheit
Die Dokumentation von Zeitfenstern und Quellen der Flags ist obligatorisch für das Bestehen eines Audits
Verwandte Konzepte: Grain
Wiederverwendbarkeit des Silver Layers
Produktentscheidung im Silver Layer
Lineage über ref()
Trennung der Verantwortlichkeiten zwischen Silver und Mart
Name: Fallbeispiel: PII-Durchsickerung durch ein wiederverwendbares Silver-Modell
Szenario: Ein Fintech-Unternehmen (Beispiel auf Basis realer Vorfälle in der Branche) baute int_customer_profile zur Aggregation von Kundendaten auf. Das Modell las stg_customers, das Vor- und Nachnamen, E-Mail, Telefon, Reisepassdaten und Geburtsdatum enthielt, und aggregierte all dies in eine Zeile pro customer_id. Das Modell war bequem — es wurde an fünf Mart-Datensätze angeschlossen, darunter mart_marketing_segments (für externe Aussendungen).
Aufgabe: Die Informationssicherheitsabteilung entdeckte bei einem Routineaudit, dass mart_marketing_segments mit dem vollständigen Vor- und Nachnamen und der Reisepassnummer des Kunden in die Marketingplattform exportiert wurde, obwohl für die Segmentierung nur der E-Mail-Hash und die Altersgruppe benötigt wurden. Formal lag kein Verstoß vor — die Daten waren beim Onboarding „einverstanden“. Die PII-Verarbeitungsrichtlinie verlangte jedoch Datenminimierung: Jeder Mart-Datensatz darf nur die PII erhalten, die durch seinen Zweck gerechtfertigt sind. Die Übermittlung des Reisepasses an das Marketing wurde als übermäßig eingestuft.
Lösung: Das Datenteam wendete die Regel aus Teil 14 an: „Direkte PII nicht weitergeben, als nötig“. Schritt 1: int_customer_profile wurde aufgeteilt in int_customer_identity (Vor- und Nachname, Reisepass — nur für Compliance-Marts) und int_customer_attributes (Altersgruppe, Segment, E-Mail-Hash — für alle anderen). Schritt 2: Im Modell wurde die Richtlinie explizit festgelegt: „Felder *_pii sind nur für Modelle mit dem Tag compliance_use_case verfügbar“. Schritt 3: mart_marketing_segments liest nun int_customer_attributes, das nur den E-Mail-Hash enthält. Schritt 4: Es wurde eine Abnahmeprüfung durchgeführt — Punkt „PII sickert nicht ohne Richtlinie in die wiederverwendbare Schicht durch“.
Ergebnis: Das IS-Audit wurde ohne Beanstandungen abgeschlossen. Die Marketingplattform erhält den minimal notwendigen Datensatz. Der Compliance-Mart behält den Zugriff auf die vollständigen PII über einen separaten geschützten Zweig. Die Onboarding-Zeit für neue Mart-Konsumenten verkürzte sich — die Felder in int_customer_profile müssen nicht mehr manuell gefiltert werden.
Gewonnene Erkenntnisse: PII im Silver Layer ist keine technische, sondern eine politische Frage: Jeder Mart braucht eine Begründung
Ein breites Modell mit PII ist ein Anti-Pattern für einen wiederverwendbaren Silver Layer
Die Trennung von PII und Attributen muss vor der Skalierung der Anzahl der Marts erfolgen
Tags in dbt helfen dabei, die Kontrolle über PII-Richtlinien zu automatisieren
Verwandte Konzepte: PII
Richtlinie zur Verarbeitung personenbezogener Daten
Wiederverwendbarkeit des Silver Layers
Grain
Tags in dbt
Lerntipps: Halten Sie das Schema der Medallion-Architektur bereit: Zeichnen Sie bei jedem Beispiel Pfeile von Bronze → Silver → Gold, um die Schichten nicht zu verwechseln
Merken Sie sich die Triade eines Silver-Modells: Grain + ein Zweck + dokumentierte Zeitfenster. Wenn auch nur eines dieser Elemente fehlt, ist das Modell nicht bereit
Überprüfen Sie beim Lesen einer fremden int_-Datei in dbt immer drei Dinge: (1) ref() bei den Eingaben, (2) das Vorhandensein von Tests auf die Eindeutigkeit des Grain-Schlüssels, (3) das Vorhandensein einer Beschreibung in properties.yml
Messen Sie die Qualität des Silver Layers nicht an der Anzahl der Modelle. Ein sorgfältiges int_-Modell ist besser als drei Schichten mit schönen Namen — dies ist die Kernbotschaft von Teil 14
Verwenden Sie die Qwen-Anfrage aus dem Material als Vorlage: „Vergleiche Mittel-Modelle mit den Spezifikationen und Anforderungen der Marts. Zeige Grain, Eingaben ref(), wiederverwendbare Felder und Validierungslücken“
Lernen Sie bei der Vorbereitung auf ein Review, jedes Feld eines int_-Modells in 30 Sekunden zu erklären: was es ist, woher es kommt, wofür es die Mart-Konsumenten benötigen
Erstellen Sie die Tabelle Grain/Eingaben/verwendet in/Validierungslücke für jedes neue int_-Modell, bevor Sie mit der Entwicklung beginnen — das diszipliniert
Vermeiden Sie die Versuchung, den Silver Layer „ein wenig zu verbessern“ — einen Filter hinzuzufügen, einen Risiko-Indikator umzubenennen, ein bequemes Merkmal zu berechnen. Jede solche Verbesserung muss in der Spezifikation festgehalten werden
Zusätzliche Ressourcen: Dbt documentation — intermediate models: https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview (Abschnitt über staging → intermediate → marts)
Dbt documentation — ref() function: https://docs.getdbt.com/reference/dbt-jinja-functions/ref
Dbt documentation — graph operators und lineage: https://docs.getdbt.com/reference/dbt-jinja-functions/graph-operators
Data quality in dbt — Tests und properties.yml: https://docs.getdbt.com/best-practices/warnings
The medallion architecture (databricks): https://www.databricks.com/glossary/medallion-architecture
Dbt tags für Zugriffsrichtlinien: https://docs.getdbt.com/reference/resource-configs/tags
Qwen (tongyi qianwen) — llm für das Review von dbt-Code: https://qwen.alibaba.com/
Buch 'data mesh' (zhamak dehghani): Das Konzept data-as-a-product überschneidet sich mit dem Prinzip „ein int_-Modell — ein Zweck“
Zusammenfassung: Der Silver Layer in der Architektur von Bankdaten (Kunden, Konten, Karten, Zahlungen) ist eine Schicht stabiler, wiederverwendbarer Entitäten, die die technische Unsauberkeit der Quellen beseitigt, jedoch keine Produktentscheidungen trifft. Im Lernbeispiel wird er durch zwei Mittel-Modelle repräsentiert: int_customer_balances (Aggregation von Konten bis auf die Kundenebene) und int_customer_card_activity (Aggregation von Kartenoperationen und Risiko-Zählern). Die Hauptregeln des Silver Layers: verständlicher Grain (eine Zeile pro customer_id für Kundenmodelle), Verwendung von ref() zum Aufbau der Lineage, Verbot des PII-Durchsickerns ohne Richtlinie, dokumentierte Zeitfenster für Zähler (z. B. was „7 Tage“ in risk_event_count_7d bedeutet), keine Vermischung unverwandter Domänen. Das Qualitätskriterium des Silver Layers ist einfach: Hilft die Schicht dabei, eine wiederkehrende Entität auszudrücken und ihre Qualität nachzuweisen? Wenn nicht — wurde das Modell um der architektonischen Symmetrie willen erstellt, nicht für den Leser oder den Datenkonsumenten. Zur Selbstprüfung verwenden Sie die Tabelle Grain / Eingaben / verwendet in / Validierungslücke und die Kontrollfragen: Warum sollte der Silver Layer nicht an ein einzelnes Produkt gebunden sein, welche PII dürfen nicht ohne Richtlinie weitergegeben werden, wie hilft ref() dem Reviewer.