Thema: Teil 15. Gold-Layer: Geschäftsentitäten und Grain
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2-3 Stunden
Voraussetzungen: Grundlegendes Verständnis der Data-Warehouse-Architektur (Bronze/Silver/Gold-Schichten)
Erfahrung mit dbt oder ähnlichen Datentransformationstools
SQL-Kenntnisse auf dem Niveau komplexer Abfragen und Fensterfunktionen
Verständnis der Konzepte Data Lineage und Data Contracts
Vertrautheit mit den Prinzipien der Datenqualität und des Testens von Daten
Lernziele: Den Grain (die Granularität) eines Datendashboards als ein einziges öffentliches Versprechen definieren und formulieren
Zwischen der technischen Bereitschaft eines Modells und seiner Bereitschaft als Gold-Produkt für den Konsumenten unterscheiden
Obligatorische Akzeptanzfakten (not_null, unique, keine PII) für die Gold-Schicht anwenden
Ein Register der Gold-Schicht mit Angabe des Konsumenten, der Granularität, der Pflichtfelder und der PII-Richtlinie erstellen
Eine strenge Überprüfung von Gold-Modellen mit Fokus auf Vertrag, SLA und Qualitätsnachweise durchführen
Übersicht: Die Gold-Schicht ist die finale Schicht in der Datenarchitektur, in der sich die technische Arbeit in ein öffentliches Versprechen gegenüber den Konsumenten verwandelt. Im Gegensatz zu Staging- und Silver-Schichten, in denen Zwischenberechnungen und technische Normalisierung zulässig sind, muss ein Gold-Modell eine konkrete Geschäftsfrage mit festgelegter Granularität beantworten. Das zentrale Konzept ist der Grain – die Definition dessen, was eine Zeile im Datendashboard bedeutet. Wenn der Grain nicht dokumentiert oder überprüft ist, wird der Konsument ihn selbst interpretieren, was zu einer Bedeutungsverschiebung führt. Ein Gold-Modell muss eng definiert sein, einen explizit benannten Konsumenten, Pflichtfelder, eine PII-Richtlinie und Prüffakten aufweisen. Die Ablage des Modells im Ordner models/marts/ macht es nicht automatisch zu einem Gold-Datenprodukt – es ist ein Versprechen, das durch Spezifikation, Vertrag und Prüfung verankert ist.
Schlüsselkonzepte: Gold-Layer: Die finale Schicht der Datenprodukte, in der der Konsument stabile Dashboards sieht und keine Zwischenberechnungen. Gold beginnt mit dem Grain und dem Vertrag, nicht mit einem bequemen SELECT. Es ist nicht der Ordner models/marts/, sondern ein Versprechen an den Konsumenten.
Grain (Granularität): Die Antwort auf die Frage „Was bedeutet eine Zeile“ in einem Datendashboard. Beispiele: eine Zeile pro customer_id, transaction_id, scope oder pro Tag und Kanal. Eine Änderung des Grains ist eine Änderung der Daten-API, keine Kosmetik.
Öffentliches Versprechen des Dashboards: Eine einzeilige Beschreibung, wem und was das Dashboard verspricht. Eine gute Formulierung: „Eine Zeile pro Kunde für die Portfolio-Analyse ohne direkte PII“. Eine schlechte: „Ein nützliches Kunden-Dashboard mit Konten, Zahlungen, Risiken und allem, was sonst noch gebraucht werden könnte“.
Konsument des Dashboards: Ein explizit benannter Benutzer oder ein Team: Kunden- und Portfolio-Analyse, Überwachung von Risikosignalen, Kontrolle des Einwilligungsstatus. Unterschiedliche Konsumenten sollten nicht zufällig den gleichen Grain erhalten.
Akzeptanzfakten (acceptance facts): Eine Reihe von Prüfungen für das Gold-Modell: der Primärschlüssel des Grains besteht not_null und unique (wenn eine Zeile pro Schlüssel angenommen wird), Pflichtkennzahlen bestehen not_null, keine direkten PII, Vertragsfelder sind vorhanden, Lineage ist lesbar.
PII-Richtlinie: Regeln zum Umgang mit personenbezogenen Daten in der Gold-Schicht. Jede überflüssige Spalte mit PII kann in einen Bericht gelangen, wenn die Richtlinie nicht überprüft wird. Das Fehlen direkter PII ist eine obligatorische Voraussetzung für die Bereitschaft.
Bedeutungsdrift des Dashboards: Die schrittweise Erweiterung des Dashboards „reichhaltiger“: Hinzufügen von Produkten, Kanälen, Segmenten, letzten Operationen, Risiko-Flags, Kredit-Stages. Jede Erweiterung verändert die Frage, die die Tabelle beantwortet, obwohl der Name gleich bleibt.
Datenvertrag: Eine Vereinbarung zwischen Lieferant und Konsument über die Zusammensetzung der Felder, ihre Typen und Semantik. Die Vertragsfelder müssen im Gold-Modell vorhanden und durch Tests überprüft sein.
Überprüfung der Gold-Schicht: Ein strengerer Prozess als die Überprüfung von Staging. Die Fragen: Wem ist das Dashboard versprochen, wie wird es verwendet, welche SLAs, PII-Richtlinie, Grain und Nachweise gelten. Wenn der Reviewer den Konsumenten nicht verstehen kann, ist das Modell noch nicht Gold.
Mart customer 360, mart payment risk signals, mart open api consents: Beispiele konkreter Dashboards mit unterschiedlichen Konsumenten und Grains: mart_customer_360 – für Kunden- und Portfolio-Analyse (Grain: customer_id), mart_payment_risk_signals – für die Überwachung von Risikosignalen, mart_open_api_consents – zur Kontrolle der Einwilligungen.
Wichtige Termine: Entstehung des Konzepts der Medallion-Architektur: Ungefähr 2020–2021 – Verankerung der Terminologie der Bronze/Silver/Gold-Schichten in der Branche
Entwicklung des Ansatzes zu Data Contracts: 2022–2024 – Formierung der Praxis expliziter Verträge zwischen Datenlieferanten und -konsumenten
Standardisierung der PII-Richtlinien: Die DSGVO (2018) und ähnliche Regulierungen als Katalysator für die Formalisierung von Datenschutzrichtlinien in der Gold-Schicht
Übungsaufgaben: Name: Formulierung des einzeiligen Versprechens eines Dashboards
Problem: Schreiben Sie für jedes Dashboard in Ihrem Projekt (angenommen, es gibt mart_customer_360, mart_payment_risk_signals, mart_open_api_consents) ein öffentliches Versprechen in einer einzigen Zeile. Überprüfen Sie, ob das Versprechen den Konsumenten und den Grain enthält. Falls nicht – formulieren Sie es um.
Lösung: Schritt 1: Bestimmen Sie den Konsumenten für jedes Dashboard (Kundenanalyst, Risiko-Team, Einwilligungskontrolle). Schritt 2: Formulieren Sie den Grain (eine Zeile pro customer_id, pro transaction_id, pro scope). Schritt 3: Notieren Sie das Versprechen: 'mart_customer_360: eine Zeile pro Kunde für die Portfolio-Analyse ohne direkte PII'. Schritt 4: Überprüfen Sie, dass die Formulierung keine Kommata und Ausnahmen enthält, die auf ein zu breit gefächertes Dashboard hindeuten würden.
Komplexität: beginner
Name: Erstellung eines Registers der Gold-Schicht
Problem: Erstellen Sie ein Register der Gold-Schicht für Ihr Projekt nach folgender Vorlage: Konsument, Granularität, Pflichtfelder, PII-Richtlinie, Prüffakten. Füllen Sie es für drei Dashboards aus.
Lösung: Schritt 1: Erstellen Sie eine Markdown-Datei 'Register der Gold-Schicht.md'. Schritt 2: Für mart_customer_360: Konsument – Kunden- und Portfolio-Analyse, Granularität – eine Zeile pro customer_id, Pflichtfelder – customer_id, Segment, LTV, letzte_Aktivität, PII-Richtlinie – nur gehashte Identifikatoren, keine E-Mail/Telefon, Prüffakten – unique+not_null auf customer_id, not_null auf LTV. Schritt 3: Wiederholen Sie dies für mart_payment_risk_signals (eine Zeile pro transaction_id, Risiko-Flags sind Pflicht) und mart_open_api_consents (eine Zeile pro scope, Einwilligungsstatus ist Pflicht).
Komplexität: intermediate
Name: Identifikation von Dashboards mit nicht nachgewiesenem Grain
Problem: Analysieren Sie mithilfe der Qwen-Abfrage aus dem Material die Ordner specs/models und models/marts. Finden Sie Dashboards, deren Grain nicht durch einen Test oder eine manuelle Tatsache des Reviewers nachgewiesen ist.
Lösung: Schritt 1: Öffnen Sie die Qwen-Abfrage: 'Lies specs/models und models/marts. Bestimme für jedes Dashboard den Grain, die wichtigsten Prüffakten, die PII-Richtlinie und die Auswirkung auf den Vertrag. Finde Dashboards, deren Grain nicht durch einen Test oder eine manuelle Tatsache des Reviewers nachgewiesen ist. Ändere keine Dateien.' Schritt 2: Überprüfen Sie jedes Modell in models/marts/. Schritt 3: Prüfen Sie für jedes Modell: Gibt es eine schema.yml mit Tests unique/not_null auf das Schlüsselfeld des Grains? Gibt es in der README oder einer Beschreibung eine explizite Angabe des Grains? Schritt 4: Erstellen Sie eine Liste von Dashboards ohne Nachweis des Grains und übergeben Sie sie zur Überprüfung, um Tests oder Dokumentation hinzuzufügen.
Komplexität: intermediate
Name: Diagnose der Bedeutungsdrift eines Dashboards
Problem: Das Dashboard mart_customer_360 enthielt ursprünglich eine Zeile pro Kunde. Im Laufe der Zeit wurden hinzugefügt: Produkte des Kunden, Interaktionskanäle, letzte Operationen, Risiko-Flags, Kredit-Stage. Benennen Sie das Problem und schlagen Sie eine Lösung vor.
Lösung: Schritt 1: Identifizieren Sie das Problem – dies ist eine Bedeutungsdrift des Dashboards. Der Grain wurde faktisch zu 'Kunde × Produkt × Kanal', obwohl der Name eine Zeile pro Kunde vermuten lässt. Schritt 2: Der Konsument versteht nicht, was er erhält: einen Kundenschnitt oder einen Kunden-Produkt-Schnitt. Schritt 3: Die Lösung besteht darin, das Dashboard aufzuteilen: mart_customer_360 auf den Grain 'eine Zeile pro Kunde' zurückführen (nur Kundenattribute), separate Dashboards erstellen: mart_customer_products (eine Zeile pro Kunde-Produkt), mart_customer_risk_signals (Risiko-Flags pro Kunde), mart_customer_interactions (Kanäle und Operationen). Schritt 4: Das öffentliche Versprechen jedes Dashboards in einer Zeile festhalten.
Komplexität: advanced
Fallstudien: Name: Bedeutungsdrift im Kunden-Dashboard eines Fintech-Startups
Szenario: Ein Fintech-Startup erstellte das Dashboard mart_customer_360 für das Team der Portfolio-Analyse. Ursprünglich enthielt das Dashboard eine Zeile pro customer_id mit den Feldern: Kundensegment, LTV, Datum der letzten Transaktion, Saldo. Die Analysten verwendeten es für den wöchentlichen Portfolio-Bericht.
Aufgabe: Im Laufe der Zeit begann das Team, dem Dashboard neue Felder hinzuzufügen: eine Liste der Produkte des Kunden (JSON-Array), Kommunikationskanäle, Kredit-Stage, Risiko-Flags, die letzten 5 Operationen. Der Grain änderte sich faktisch von 'eine Zeile pro Kunde' zu 'Kunde mit gesamter Aktivität'. Der Name blieb gleich, aber die Bedeutung veränderte sich. Die Analysten erhielten mehrdeutige Ergebnisse: Im Bericht wurde LTV mal korrekt berechnet, mal mit Duplikaten aufgrund der Vervielfachung der Zeilen nach Produkten. Zusätzlich geriet versehentlich eine Spalte mit E-Mail-Adressen der Kunden in das Dashboard, was gegen die PII-Richtlinie verstieß.
Lösung: Das Team führte eine Überprüfung der Gold-Schicht nach den Prinzipien aus dem Material durch. Es formulierte öffentliche Versprechen: mart_customer_360 – 'eine Zeile pro Kunde für die Portfolio-Analyse ohne direkte PII'. Es erstellte separate Dashboards: mart_customer_products (Grain: customer_id × product_id), mart_customer_risk_signals (Grain: customer_id), mart_customer_recent_activity (Grain: customer_id × operation_id). Es fügte Akzeptanztests hinzu: unique + not_null auf customer_id in allen Dashboards, Überprüfung der PII-Abwesenheit durch einen dbt-Test, Vertragstests auf Pflichtfelder. Es führte eine Überprüfung mit Fokus auf die Fragen durch: Wer ist der Konsument? Was ist der Grain? Welche SLAs gelten?
Ergebnis: Nach der Aufteilung der Dashboards erhielten die Analysten vorhersehbare Ergebnisse in den wöchentlichen Berichten. Die LTV-Drift hörte auf. Die PII-Richtlinie wurde formalisiert: In den Gold-Dashboards verblieben nur gehashte Identifikatoren und aggregierte Kennzahlen. Die Zeit für die Fehlersuche in Berichten reduzierte sich um 60 %. Das Team führte folgende Praxis ein: Jedes Dashboard in models/marts/ muss nun ein einzeiliges öffentliches Versprechen in der README mit Angabe des Konsumenten und des Grains haben.
Gewonnene Erkenntnisse: Die Ablage eines Modells in models/marts/ macht es nicht automatisch zu einem Gold-Datenprodukt
Die Erweiterung eines Dashboards „reichhaltiger“ verändert unbemerkt den Grain und die Bedeutung – Disziplin bei der Aufteilung ist erforderlich
Akzeptanzfakten (unique, not_null, PII-Abwesenheit) müssen für die Gold-Schicht obligatorisch sein
Das einzeilige öffentliche Versprechen ist der beste Weg, einer Drift vorzubeugen
Verwandte Konzepte: Grain als Schutz vor Bedeutungsdrift
Akzeptanzfakten der Gold-Schicht
PII-Richtlinie in Dashboards
Strenge Überprüfung von Gold-Modellen
Öffentliches Versprechen des Dashboards
Name: Impliziter Grain im Dashboard der Risikosignale eines Zahlungssystems
Szenario: Ein Zahlungssystem erstellte das Dashboard mart_payment_risk_signals zur Überwachung durch das Risiko-Team. Das Dashboard wurde aus mehreren Quellen zusammengetragen: Anti-Fraud-Scoring, Verhaltensfaktoren, Geolokalisierung. Das Modell wurde ohne explizite Definition des Grains gebaut – einfach ein bequemer JOIN aller Faktoren.
Aufgabe: Das Risiko-Team begann, doppelte Signale zu erhalten: Die gleiche Zahlung tauchte im Dashboard mehrfach auf, weil verschiedene Faktorquellen zu unterschiedlichen Zeiten mit unterschiedlichen Zeitstempeln ausgelöst wurden. Das Monitoring zeigte Fehlalarme. Darüber hinaus befanden sich direkte PII (Kundenname, E-Mail) im Dashboard, die das Risiko-Team laut Sicherheitsrichtlinie nicht hätte sehen dürfen. Die Staging-Überprüfung verlief ohne Beanstandungen, aber die Gold-Überprüfung wurde nicht streng durchgeführt.
Lösung: Das Team wendete den Ansatz aus dem Material an: Es definierte den Grain explizit – 'eine Zeile pro transaction_id mit dem aktuellen Stand der Risikofaktoren zum Zeitpunkt der letzten Bewertung'. Es formulierte ein einzeiliges Versprechen: 'mart_payment_risk_signals: eine Zeile pro Transaktion mit aktuellen Risiko-Flags für das Monitoring ohne direkte PII'. Es fügte Akzeptanztests hinzu: unique + not_null auf transaction_id, not_null auf risk_score und risk_flags, Test auf das Fehlen von Spalten mit PII über Metadaten. Es entfernte direkte PII und ersetzte sie durch einen gehashten customer_hash. Es führte für jedes Dashboard eine Überprüfung mit den Fragen durch: Wem ist es versprochen? Was ist der Grain? Welche SLAs gelten? Welche Nachweise gibt es?
Ergebnis: Die Duplikation von Signalen hörte auf. Das Monitoring wurde deterministisch: eine Transaktion – ein Datensatz mit aktuellem Stand. Das Risiko-Team sah keine direkten PII mehr, was das Compliance-Risiko beseitigte. Es wurde folgende Praxis eingeführt: Jedes Dashboard durchläuft vor dem Merge in main eine Checkliste mit 6 Punkten zur Bereitschaft eines Gold-Modells (Konsument, Grain, Vertrag, PII, Prüffakten, Reviewer-Bericht).
Gewonnene Erkenntnisse: Ohne expliziten Grain interpretiert der Konsument ihn selbst – dies führt zu mehrdeutigen Ergebnissen
Die Überprüfung von Staging und Gold muss unterschiedlich streng sein: In Gold fragt man nach Konsument, Vertrag und SLA
Die PII-Richtlinie sollte automatisch überprüft werden, nicht auf manueller Kontrolle beruhen
Akzeptanzfakten (unique auf dem Grain-Schlüssel) sind eine obligatorische Voraussetzung für die Bereitschaft
Verwandte Konzepte: Grain als Teil des öffentlichen Vertrags
Akzeptanzfakten der Gold-Schicht
PII-Richtlinie
Strenge Überprüfung von Gold-Modellen
Qwen-Abfrage zur Analyse von Dashboards
Lerntipps: Beginnen Sie mit der Formulierung des öffentlichen Versprechens: Nehmen Sie ein beliebiges Dashboard aus Ihrem Projekt und versuchen Sie, es in einer Zeile zu beschreiben. Wenn dies nicht ohne Kommata gelingt, ist das Dashboard zu breit.
Verwenden Sie die Checkliste zur Bereitschaft eines Gold-Modells als Filter: Wenden Sie die 6 Punkte aus dem Material (Konsument, Grain, Vertrag, PII, Prüffakten, Reviewer-Bericht) auf jedes Modell in models/marts/ an.
Verwechseln Sie nicht den Ordner und das Versprechen: Die Ablage in models/marts/ ist ein technisches Detail. Gold ist ein Vertrag mit dem Konsumenten, verankert durch Spezifikation und Prüfung.
Üben Sie das Erkennen von Drift: Nehmen Sie ein Dashboard mit Änderungshistorie und verfolgen Sie, wie sich der Grain verändert hat. Dies hilft, Drift frühzeitig zu erkennen.
Verwenden Sie die Qwen-Abfrage aus dem Material als Vorlage für die automatische Analyse: Sie findet Dashboards mit nicht nachgewiesenem Grain und spart Zeit bei der manuellen Überprüfung.
Die Strenge der Überprüfung sollte von Staging zu Gold zunehmen: In Gold fragen Sie nach Konsument, Vertrag, SLA, PII, Grain und Nachweisen – und nicht nur nach technischer Korrektheit des SQL.
Gewöhnen Sie sich an: Prüfen Sie bei jeder Erweiterung eines Dashboards zunächst die Frage – verändert dies den Grain? Wenn ja, ist dies keine Kosmetik, sondern eine Änderung der Daten-API.
Teilen Sie Dashboards nach Grain auf: Lieber drei enge Dashboards mit klarem Grain als ein breites, das versucht, alles auf einmal zu sein.
Zusätzliche Ressourcen: dbt-Dokumentation zu Tests: https://docs.getdbt.com/docs/build/data-tests – offizielle Dokumentation zu Schema- und benutzerdefinierten Tests in dbt
Data contracts (bitol): https://bitol.io – offene Spezifikation für Data Contracts vom Team um Andrew Jones
The medallion architecture (databricks): https://www.databricks.com/glossary/medallion-architecture – Beschreibung der Bronze/Silver/Gold-Architektur von Databricks
Data quality fundamentals (great expectations): https://greatexpectations.io – Werkzeuge und Praktiken zur Sicherstellung der Datenqualität
dbt-utils-Paket: https://github.com/dbt-labs/dbt-utils – eine Reihe nützlicher Tests und Makros, einschließlich PII-Prüfung
Buch 'Fundamentals of Data Engineering' (Joe Reis, Matt Housley): Kapitel zu Datenschichten und Verträgen – eine moderne Sicht auf die DWH-Architektur
Artikel 'What is a Data Contract?' (Monte Carlo): https://www.montecarlodata.com/blog-data-contracts-explained – praktische Erklärung von Data Contracts
Zusammenfassung: Die Gold-Schicht ist nicht der Ordner models/marts/, sondern ein öffentliches Versprechen an den Konsumenten. Das Schlüsselkonzept ist der Grain – die Definition dessen, was eine Zeile bedeutet. Ein bereites Gold-Modell verfügt über: einen explizit benannten Konsumenten, einen dokumentierten und überprüften Grain, Pflichtfelder, die an einen Vertrag gebunden sind, eine PII-Richtlinie, Akzeptanzfakten (unique+not_null auf dem Schlüssel, keine direkten PII, Vertragsfelder) und einen Reviewer-Bericht, der Fakten von Annahmen trennt. Der wichtigste Schutz gegen Bedeutungsdrift sind enge Dashboards mit einem einzeiligen öffentlichen Versprechen. Wenn das Versprechen nicht ohne Kommata formuliert werden kann, ist das Dashboard zu breit und muss aufgeteilt werden. Die Gold-Überprüfung muss strenger sein als die Staging-Überprüfung: In ihr fragt man unbedingt nach Konsument, Vertrag, SLA, PII, Grain und Nachweisen. Verwenden Sie die Qwen-Abfrage, um Dashboards mit nicht nachgewiesenem Grain zu finden, und erstellen Sie ein Register der Gold-Schicht mit Angabe des Konsumenten, der Granularität, der Pflichtfelder und der PII-Richtlinie.