Thema: Teil 19. Semantische Ebene, Metriken und Exposures
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 3-4 часа
Voraussetzungen: Verständnis der Architektur von Data Marts
Erfahrung mit dbt oder ähnlichen Transformationswerkzeugen
Kenntnisse der Prinzipien von Data Quality und Prüfungsfakten
Grundlegendes Verständnis von YAML und Markdown für Dokumentation
Erfahrung mit BI-Tools und Berichtswesen
Lernziele: Eine Metrik als Spalte von einer Metrik als semantischen Vertrag mit Formel, Granularität, Eigentümer und Konsumenten unterscheiden
Den Zeitpunkt bestimmen, an dem ein Team tatsächlich eine semantische Ebene benötigt, und diese von einer bürokratischen Ebene abgrenzen
Ein semantisches Register in Markdown erstellen, um gemeinsame Metriken zu dokumentieren
Exposures verwenden, um Konsumenten eines Datenprodukts zu erfassen und Breaking Changes zu steuern
Den Qwen-Prompt einsetzen, um gemeinsame Metriken in Data Marts zu finden und zu validieren
Übersicht: Teil 19 des Kurses widmet sich der semantischen Ebene, Metriken und Exposures – Konzepten, die kritisch wichtig werden, sobald dieselben Metriken in mehreren Berichten, Anwendungen oder Teams verwendet werden. Vor dem Auftreten wiederholter Nutzung reichen klar definierte Data Marts und Prüfungsfakte aus. Doch wenn Felder wie total_balance_rub, aktive Einwilligung oder risk_event_count in verschiedenen Kontexten auftauchen, entsteht die Notwendigkeit, ihre Definitionen zu zentralisieren. Eine Metrik ist nicht einfach eine Spalte, sondern ein vollwertiger Vertrag: Name, Formel, Granularität, Filter, Aktualität, Eigentümer und Liste der Konsumenten. dbt unterstützt semantic models und metrics, doch im Lernpfad ist es wichtiger, die semantische Absicht festzuhalten, bevor eine technische Ebene hinzugefügt wird. Exposures ergänzen das Bild, indem sie zeigen, wer tatsächlich das Datenprodukt liest – Dashboard, API, Notebook oder Bericht –, was entscheidend ist, um Vertragsdrift und Breaking Changes zu steuern.
Schlüsselkonzepte: Semantische Ebene: Eine zentralisierte Schicht für Metrikdefinitionen, die Unstimmigkeiten zwischen Teams beseitigt. Wird nur eingeführt, wenn dieselben Metriken in mehreren Kontexten verwendet werden. Sie ist kein Selbstzweck – sie ist ein Werkzeug gegen Definitionsdrift.
Metrik als Vertrag: Eine Metrik ist keine umbenannte Spalte, sondern ein vollwertiger semantischer Vertrag, der Folgendes umfasst: Name, Berechnungsformel, Granularität (grain), angewandte Filter, erwartete Datenaktualität, Eigentümer der Definition und Liste der Konsumenten.
Granularität (grain): Die Detailebene einer Metrik: pro Zeile, pro Kunde, pro Scope, pro Produkt, pro Tag usw. Ohne explizite Granularität lässt sich nicht garantieren, dass verschiedene Berichte die Metrik gleich interpretieren.
Dbt semantic models: Ein in dbt integrierter Mechanismus zur Beschreibung von Metriken über YAML-Konfigurationen. Umfasst entities, measures, dimensions. Wird in reifen Stacks eingesetzt, erfordert jedoch eine vorherige Abstimmung über die Bedeutung der Metriken.
Exposure: Eine dokumentierte Beziehung zwischen einem Datenprodukt (Data Mart) und seinem Konsumenten: Dashboard, API, Notebook, regelmäßiger Bericht. Sie ermöglicht es zu sehen, wen eine Schema- oder Grain-Änderung des Data Marts betrifft.
Semantisches Register: Ein Markdown-Dokument oder eine YAML-Datei, die Definitionen gemeinsamer Metriken in folgender Form festhält: Name, Definition, Granularität, Eigentümer, Konsumenten, Prüfungsfakt. Eine minimal ausreichende Alternative zu einer vollständigen semantischen Ebene.
Vertragsdrift: Eine Situation, in der derselbe Metrikname in verschiedenen Teams unterschiedliche Definitionen oder Formeln hat. Beispiel: Ein Team zählt eine aktive Einwilligung über null in revoked_at, ein anderes schließt alte Einwilligungen nach Datum aus – das sind zwei verschiedene Metriken mit demselben Namen.
Prüfungsfakt für eine Metrik: Eine konkrete Assertion oder ein Test, der die korrekte Berechnung der Metrik validiert. Beispiel: Die Summe aller positiven Werte muss mit dem Aggregat aus der Quelle übereinstimmen.
Breaking Change: Eine Änderung an einem Data Mart oder einer Metrik, die sich auf Downstream-Konsumenten auswirkt: Umbenennung eines Felds, Wechsel des Grains, Änderung der Formel. Exposures helfen, solche Konsumenten frühzeitig zu identifizieren.
Qwen-Prompt für Metriken: Eine standardisierte Anfrage an ein LLM, die Data Marts und Specs liest, felder findet, die gemeinsamen Metriken ähneln, und für diese Definition, Grain, Eigentümer, Konsumenten und Prüfungsfakt vorschlägt – ohne automatisch semantic models zu erstellen.
Wichtige Termine: Phase 1: vor der Wiederverwendung: Data Marts und Prüfungsfakte reichen aus. Metrikdefinitionen können beim Data Mart verbleiben.
Phase 2: Auftreten eines zweiten Konsumenten: Der Moment, in dem über ein semantisches Register nachgedacht werden muss. Konsumenten divergieren, wenn Definitionen nicht explizit festgehalten sind.
Phase 3: mehrere Teams mit einer Metrik: Der Punkt, an dem das Fehlen einer semantischen Ebene Drift erzeugt, während ihre Existenz eine Voraussetzung für Datentrauen ist.
Übungsaufgaben: Name: Ausfüllen des semantischen Registers für active_consent_count
Problem: Im Data Mart mart_open_api_consents gibt es ein Feld, das aktive Einwilligungen widerspiegelt. Füllen Sie das semantische Register aus: Geben Sie Definition, Granularität, Eigentümer, Konsumenten und Prüfungsfakt an. Wenn Eigentümer oder Konsument unbekannt sind, fügen Sie keine semantic model hinzu.
Lösung: 1. Öffnen Sie die Spec des Data Marts mart_open_api_consents und suchen Sie die Feldbeschreibung. 2. Formulieren Sie die Definition: 'Anzahl der Einwilligungen, bei denen revoked_at is null'. 3. Bestimmen Sie das Grain: auf Scope-Ebene (z. B. Einwilligungstyp). 4. Fragen Sie den Produkteigentümer der Open API, wer für diese Definition verantwortlich ist. 5. Fragen Sie das Monitoring-Team der Open API, ob es Konsument ist. 6. Formulieren Sie den Prüfungsfakt: 'Die Summe von active_consent_count für den Zeitraum entspricht der Anzahl der Zeilen in der Quelle, bei denen revoked_at is null'. 7. Wenn mindestens einer der Schritte 4-5 nicht bestätigt werden kann, halten Sie an und klären Sie die Produktzusage.
Komplexität: intermediate
Name: Erkennung von Drift der Metrik total_balance_rub
Problem: Zwei Berichte verwenden das Feld total_balance_rub, liefern aber unterschiedliche Ergebnisse. Bestimmen Sie, an welchem Punkt die Drift auftritt, und schlagen Sie vor, wie sie über das semantische Register behoben werden kann.
Lösung: 1. Vergleichen Sie die SQL-Abfragen beider Berichte zum Data Mart. 2. Finden Sie die Abweichung: Beispielsweise filtert einer nach client_status='active', der andere schließt geschlossene Konten ein. 3. Halten Sie fest, dass total_balance_rub ein Spaltenname ist, keine Metrik. 4. Erstellen Sie im Register zwei separate Einträge: 'total_balance_rub_active' (nur aktive Kunden) und 'total_balance_rub_all' (alle Kunden) mit expliziten Grains und Definitionen. 5. Vereinbaren Sie mit den Teams den Übergang zu den neuen Namen. 6. Halten Sie einen Prüfungsfakt fest: Die Summe über die neue Metrik muss bei gleichen Filtern mit dem Aggregat aus der Quelle übereinstimmen.
Komplexität: intermediate
Name: Anwendung des Qwen-Prompts zur Suche nach gemeinsamen Metriken
Problem: Verwenden Sie die Qwen-Anfragevorlage, um drei Data Marts des Projekts zu analysieren und Felder zu finden, die gemeinsame Metriken sein könnten. Erstellen Sie keine semantic models – schlagen Sie nur Kandidaten vor.
Lösung: 1. Formulieren Sie die Anfrage: 'Lies die Data Marts und Specs. Finde Felder, die wie gemeinsame Metriken aussehen. Schlage für jedes eine Definition, ein Grain, einen Eigentümer, einen Konsumenten und einen Prüfungsfakt vor. Erstelle keine semantic models ohne Bestätigung.' 2. Übergeben Sie in der Anfrage die Beschreibung von drei Data Marts (z. B. mart_clients, mart_accounts, mart_transactions). 3. Erhalten Sie eine Liste von Kandidaten: total_balance_rub, active_client_count, transaction_volume, avg_transaction_amount. 4. Prüfen Sie für jeden Kandidaten: Tritt das Feld in mehreren Data Marts oder Berichten auf? Wenn ja – ist es ein Metrik-Kandidat. 5. Schreiben Sie das Ergebnis in einen Register-Entwurf und markieren Sie jeden Eintrag mit dem Status 'Eigentümer-Bestätigung erforderlich'.
Komplexität: intermediate
Name: Entscheidung: semantische Ebene einführen oder nicht
Problem: Ein Team aus 3 Analysten arbeitet mit 5 Data Marts. Jeder Data Mart wird von einem Bericht verwendet. Lohnt es sich, eine vollständige dbt-semantische Ebene einzuführen? Begründen Sie die Entscheidung.
Lösung: 1. Prüfen Sie, ob es gemeinsame Metriken gibt: Nehmen Sie die Liste der Felder aller 5 Data Marts und vergleichen Sie sie mit der Liste der Felder aller Berichte. 2. Wenn es keine gemeinsamen Metriken gibt (jeder Data Mart ist für einen Bericht), wird die semantische Ebene zur Bürokratie. 3. Empfehlung: Belassen Sie die Definitionen bei den Data Marts als dbt-Doc-Blöcke oder Kommentare in der Spec. 4. Legen Sie einen Auslöser fest: Sobald ein zweiter Konsument für eine beliebige Metrik auftaucht – erstellen Sie einen Eintrag im semantischen Register. 5. Überdenken Sie die Entscheidung, wenn die Anzahl der Konsumenten 3-4 Teams übersteigt.
Komplexität: beginner
Fallstudien: Name: Drift der Metrik 'aktiver Kunde' in einem Fintech-Startup
Szenario: Ein Fintech-Startup mit 4 Analystenteams. Das Risikoteam zählt aktive Kunden nach dem Kriterium 'in den letzten 90 Tagen mindestens eine Transaktion durchgeführt'. Das Marketingteam – nach dem Kriterium 'Konto nicht geschlossen und in den letzten 30 Tagen in der App angemeldet'. Beide Teams nennen die Metrik active_client_count und veröffentlichen sie in Dashboards. Das Management sieht eine Abweichung von 18 % zwischen den Berichten und verliert das Vertrauen in die Daten.
Aufgabe: Fehlender einheitlicher semantischer Vertrag für dieselbe Metrik. Verschiedene Teams wenden unterschiedliche Filter, Grains und Formeln an, verwenden aber denselben Namen. Eine Lösung im BI-Tool gibt es nicht, da das Problem auf Definitionsebene liegt, nicht in der Visualisierung.
Lösung: 1. Der Data Lead führte ein Audit durch: Sammelte alle Definitionen von active_client_count bei allen Teams. 2. Hielt im semantischen Register drei separate Metriken fest: active_client_90d (Transaktionen), active_client_30d (Login), active_client_strict (beide Bedingungen). 3. Bestimmte einen Eigentümer für jede Metrik: Risiken, Marketing, Produkt. 4. Fügte Exposures in dbt hinzu: Risiko-Dashboard → active_client_90d, Marketing-Dashboard → active_client_30d. 5. Hielt für jede Metrik einen Prüfungsfakt fest: Die Summe über das Grain stimmt mit dem Aggregat aus der Quelle bei gleichen Filtern überein. 6. Führte keine vollständige dbt-semantische Ebene ein – beschränkte sich auf ein Markdown-Register, da die Anzahl der Metriken < 10 ist.
Ergebnis: Nach 6 Wochen wurde die Drift behoben: Die Berichte der Teams stimmten überein, das Management erhielt ein einheitliches Verständnis, welche Metrik was bedeutet. Risiko- und Marketingteam begannen, Metrikänderungen über die Eigentümer abzustimmen, statt in Chat-Diskussionen zu streiten. Das Vertrauen in die Daten wurde wiederhergestellt. Nach 4 Monaten, als die Anzahl der gemeinsamen Metriken auf 12 stieg, entschied sich das Team für den Übergang zu dbt semantic models – aber nur, weil echte Konsumenten und wiederholbare Definitionen vorhanden waren.
Gewonnene Erkenntnisse: Die semantische Ebene wird nicht um der Vollständigkeit des Stacks willen benötigt, sondern wenn mehrere Konsumenten einer Metrik vorhanden sind
Drift entsteht nicht im BI, sondern durch das Fehlen eines expliziten Vertrags auf Definitionsebene
Exposures sind eine Möglichkeit zu sehen, wen eine Metrikänderung betrifft, und frühzeitig zu warnen
Halten Sie zuerst die Absicht fest (Markdown-Register) und wählen Sie erst danach das Werkzeug (dbt semantic layer)
Verwandte Konzepte: Semantisches Register
Vertragsdrift
Exposure
Granularität
Prüfungsfakt für eine Metrik
Name: Übergang von Ad-hoc-Data Marts zur semantischen Ebene in einer Bank
Szenario: Eine mittelgroße Bank, 15 Analyseteams, 40+ Data Marts in dbt. Die Metrik risk_event_count wird in 8 Berichten verwendet: regulatorische Berichterstattung, Anti-Fraud, operationelles Risiko, Scoring. Die Definitionen unterscheiden sich: Einige Teams zählen über die Tabelle events, andere über die Tabelle alerts, einige beziehen manuelle Untersuchungen ein, andere nur automatische Auslösungen.
Aufgabe: Der Regulator forderte einen Bericht zu risk_event_count, und die Bank konnte keine konsistente Zahl liefern: Verschiedene Teams lieferten Werte, die um 40 % voneinander abwichen. Reputation und regulatorische Fristen waren gefährdet. Die Einführung einer vollständigen dbt-semantischen Ebene schien übertrieben, aber das Fehlen eines Vertrags erzeugte operationelles Risiko.
Lösung: 1. Eine Arbeitsgruppe wurde gebildet: Data Steward + Eigentümer der 4 Konsumententeams. 2. Es fanden mehrere Treffen zur Abstimmung der Definition von risk_event_count statt: Quelle (events), Filter (event_type in scope), Grain (client_id, date), Formel (count distinct). 3. Im semantischen Register festgehalten: Definition, Grain, Eigentümer (Team für operationelles Risiko), 8 Konsumenten über Exposures, Prüfungsfakt (Summe über Grain für den Zeitraum gleich Aggregat aus source.events). 4. Praxis eingeführt: Jede Änderung an risk_event_count wird mit dem Eigentümer abgestimmt, und Benachrichtigungen gehen an alle Exposure-Konsumenten. 5. Erst nach 3 Monaten, als es 7 solcher 'gemeinsamen' Metriken gab, begann die Bank, dbt semantic models für diese zu pilotieren, während die übrigen im Markdown-Register blieben.
Ergebnis: Der regulatorische Bericht wurde pünktlich mit einer konsistenten Zahl eingereicht. Die Bank vermeidet eine Strafe. Nach einem halben Jahr stieg die Anzahl der 'semantischen' Metriken auf 15, und die Bank standardisierte den Ansatz: Jede gemeinsame Metrik erscheint zunächst im Register und wird erst bei 3+ Konsumenten in den dbt semantic layer überführt. Breaking Changes benachrichtigen jetzt alle Exposure-Konsumenten automatisch.
Gewonnene Erkenntnisse: Die semantische Ebene geht nicht über Technologie (dbt vs. Markdown), sondern über die Abstimmung der Bedeutung zwischen Teams
Exposures ermöglichen es, den Blast Radius einer Änderung zu sehen und das operationelle Risiko zu senken
Eine vollständige dbt-semantische Ebene lohnt sich erst nach dem Auftreten realer gemeinsamer Metriken, sonst ist es Bürokratie
Der Eigentümer einer Metrik ist nicht der Analyst, der sie berechnet hat, sondern der Produkt-Stakeholder, der für die Definition verantwortlich ist
Verwandte Konzepte: Exposure
Breaking Change
dbt semantic models
Eigentümer der Metrik
Semantisches Register
Lerntipps: Beginnen Sie mit einer Prüfung: Nehmen Sie 2-3 Data Marts Ihres Projekts und finden Sie Felder, die in mehreren Berichten vorkommen – das sind Kandidaten für gemeinsame Metriken
Führen Sie nicht vorschnell eine dbt-semantische Ebene ein: Halten Sie zuerst die Absicht im Markdown-Register fest und erwägen Sie eine Automatisierung erst bei 3+ Konsumenten
Stellen Sie für jede Metrik 5 Fragen: Name, Formel, Grain, Eigentümer, Konsumenten – wenn auch nur eine unbeantwortet bleibt, ist die Metrik nicht bereit
Verwenden Sie den Qwen-Prompt als Helfer für einen Register-Entwurf, aber vertrauen Sie ihm keine automatische Erstellung von semantic models an – bestätigen Sie immer den Eigentümer
Denken Sie an Exposures als Abhängigkeitskarte: Jede Exposure ist eine Verpflichtung, den Konsumenten vor einer Breaking Change zu warnen
Unterscheiden Sie 'Metrik' und 'Spalte': Eine Spalte ist ein physisches Feld, eine Metrik ist ein Vertrag zu deren Interpretation
Ein Zeichen für Drift: Ein Team sagt 'die Metrik ist gestiegen', ein anderes 'gefallen', aber die Daten sind gleich – das bedeutet, die Definitionen sind auseinandergegangen
Verwechseln Sie die semantische Ebene nicht mit einem Namenskatalog: Ein Metrik-Register handelt von Bedeutung und Formeln, nicht von der Umbenennung von Spalten
Zusätzliche Ressourcen: Dbt semantic layer (offizielle Dokumentation): https://docs.getdbt.com/docs/build/dimensions – offizieller Leitfaden zu entities, dimensions, measures in dbt
Dbt metrics (veraltet, aber nützlich zum Verständnis der Entwicklung): https://docs.getdbt.com/docs/build/metrics – historischer Kontext des semantic layer in dbt
Buch 'Fundamentals of Data Engineering' (O'Reilly): Joe Reis und Matt Housley – Kapitel zur semantischen Ebene und Metriken im modernen Stack
Artikel 'What is a Semantic Layer?' (Towards Data Science): Praktische Erklärung des Konzepts mit Beispielen aus realen Unternehmen
Cube.dev – alternative semantische Ebene: https://cube.dev/docs – Ansatz, der eine Alternative zum dbt semantic layer darstellt
dbt Labs Blog: 'The Rise of the Semantic Layer': https://blog.getdbt.com – Artikelserie vom dbt-Team zur Evolution des Ansatzes
Kursmaterialien: Teil 18 (Data Marts und Prüfungsfakte): Vorheriger Teil des Kurses, der zum Verständnis des Kontexts der semantischen Ebene notwendig ist
Zusammenfassung: Teil 19 des Kurses führt die Konzepte der semantischen Ebene, Metriken und Exposures als Antwort auf Definitionsdrift bei der Wiederverwendung von Daten ein. Die zentrale Idee: Eine Metrik ist keine Spalte, sondern ein semantischer Vertrag mit Formel, Granularität, Eigentümer und Konsumenten. Eine semantische Ebene einzuführen ist nur dann sinnvoll, wenn mehrere Konsumenten gemeinsamer Metriken vorhanden sind, sonst wird sie zur Bürokratie. Im Übungsprojekt reicht ein Markdown-Register, das die Absicht festhält, bevor zu dbt semantic models übergegangen wird. Exposures zeigen, wer das Datenprodukt liest, und helfen, Breaking Changes durch Benachrichtigungen an Konsumenten zu steuern. Die wichtigste praktische Erkenntnis: Halten Sie zuerst Definition, Grain, Eigentümer, Konsumenten und Prüfungsfakt fest – und entscheiden Sie erst danach, ob eine formale semantische Ebene notwendig ist.