Lernleitfaden: Teil 12. Datenverträge: ODCS und dbt-Vertragsprüfungen

Thema: Teil 12. Datenverträge: ODCS und dbt-Vertragsprüfungen

Schwierigkeitsgrad: Mittel

Geschätzte Lernzeit: 3-4 Stunden (Theorie ~1,5 Stunden, Praxis ~2 Stunden, Fallanalyse ~0,5 Stunden)

Voraussetzungen: Sichere Beherrschung von SQL (SELECT, JOIN, GROUP BY, Fensterfunktionen)

Grundlegendes Verständnis von dbt (Modelle, Materialisierungen, Sources, Refs)

Kenntnisse der Prinzipien zum Aufbau von Data Marts (Grain, Slowly Changing Dimensions)

Verständnis des Softwareentwicklungs-Lebenszyklus (PR, Review, CI/CD)

Grundlegende Kenntnis der YAML-Syntax

Vorstellung von Data Quality und Datentests

Lernziele: Die zwei Ebenen des Datenvertrags unterscheiden: die Produktebene (ODCS) und die Modellebene (dbt schema.yml) und verstehen, wofür jede Ebene verantwortlich ist

Die drei Arten von Vertragsdrift identifizieren (Schema-, Semantik-, Prozessdrift) und die Konsequenzen für den Konsumenten formulieren

Eine minimale Auswirkungsnotiz auf den Vertrag bei einer Modelländerung nach vorgegebener Vorlage erstellen

ODCS-Verpflichtungen mit konkreten dbt-Tests, Singular-Tests und manuellen Review-Fakten verknüpfen und die Abdeckung bewerten

Einen Prompt für einen LLM-Assistenten (z. B. Qwen Code) formulieren, um Drift und Lücken in der Testabdeckung ohne Dateiänderungen zu finden

Übersicht: Ein Datenvertrag ist eine überprüfbare Schicht zwischen dem Produktversprechen des Marts und seiner SQL-Implementierung. Im Rahmen der SDD-Data-Spezifikation ist ein Datenvertrag keine dekorative YAML-Datei, sondern eine formale Vereinbarung über Schema, Qualität, SLA und die Politik brechender Änderungen. Das Kapitel betrachtet zwei Vertragsebenen: ODCS (Open Data Contract Standard) als technischen Vertrag des Datenprodukts und den dbt-Modellvertrag als konkrete Form eines bestimmten Modells. Besondere Aufmerksamkeit gilt der Vertragsdrift – der Situation, dass sich der Modellcode ändert, der Vertrag aber gleich bleibt, was zu einer stillen Auseinanderentwicklung der Datenbedeutung beim Konsumenten führt. Untersucht werden die drei Driftarten (Schema-, Semantik-, Prozessdrift), Methoden zu deren Erkennung und die Rolle der dbt-Tests als Beweisgrundlage des Vertrags. Der praktische Teil dreht sich um eine Qwen-Anfrage, die die ODCS-Spezifikation, die Modellbeschreibung, schema.yml und den SQL-Code vergleicht und eine minimale Auswirkungsnotiz auf den Vertrag für die Verwendung in der PR-Beschreibung erstellt.

Schlüsselkonzepte: Odcs (open data contract standard): Standard für eine maschinenlesbare Beschreibung des technischen Vertrags eines Datenprodukts. Im Rahmen des Kurses durch die Datei specs/customer_360_contract.odcs.yaml repräsentiert. Enthält das Versprechen über das Schema (Felder, Typen, Pflicht), die Qualität (SLA für Aktualität, Vollständigkeit, Eindeutigkeit), die PII-Politik und die Beschreibung brechender Änderungen. Dies ist der Vertrag auf Produktebene: Er beantwortet die Frage „Was verspricht der Mart der Außenwelt?“.

Dbt-Modellvertrag: Beschreibung der Form eines konkreten dbt-Modells in models/schema.yml: Name, Beschreibung, Spalten mit Typen, Tests und Verweisen auf die Dokumentation. Dies ist der Vertrag auf Modellebene: Er beantwortet die Frage „Wie genau ist das Versprechen in diesem Projekt umgesetzt?“. Im Lernbeispiel wird contract.enforced: true nicht aktiviert, um den ersten Durchlauf nicht mit Adapter-Einschränkungen zu vermischen; in der Produktion wird es dort aktiviert, wo die Materialisierung dies unterstützt.

Die zwei Vertragsebenen und ihre Trennung: ODCS beschreibt das Produkt, schema.yml und Tests das konkrete Modell. Keine Schicht ersetzt die andere. Wenn man nur dbt-Tests behält, kann man ein grünes Modell mit falscher Bedeutung erhalten. Wenn man nur ODCS behält, kann man einen schönen Vertrag ohne Beweise für dessen Erfüllung erhalten.

Schemadrift: Erste Art der Vertragsdrift. Entsteht, wenn im Modell Felder hinzugefügt, gelöscht oder umbenannt werden, die ODCS-Spezifikation aber nicht aktualisiert wird. Beispiel: In mart_customer_360 wird die Spalte product_code hinzugefügt, aber ODCS listet weiterhin den bisherigen Feldsatz. dbt kann alle Tests bestehen, während der Konsument eine Struktur erhält, die im Vertrag nicht beschrieben ist.

Semantischer Drift: Zweite Driftart. Das Feld bleibt im Schema erhalten, aber seine Bedeutung ändert sich. Beispielsweise wird die Metrik risk_event_count_7d für ein anderes Zeitintervall berechnet oder bezieht Ereignisse eines anderen Typs ein. Technisch ist das Schema intakt, die Geschäftsbedeutung hat sich geändert. Dies ist die gefährlichste Driftart, da automatische Tests sie in der Regel nicht erkennen.

Prozessdrift: Dritte Driftart. validation.md, der Reviewer-Bericht oder ein anderer Prozessartefakt spiegelt die tatsächliche Modelländerung nicht wider. Beispielsweise hat der Reviewer die Änderung genehmigt, aber vergessen, die Testabdeckungsmatrix oder den Changelog-Eintrag zu aktualisieren. Formal ist der Prozess durchlaufen, tatsächlich ist die Beweisgrundlage des Vertrags verloren.

Beweisgrundlage des Vertrags: Prinzip: Wenn ODCS sagt, dass ein Feld pflichtig ist (z. B. not_null), dann muss mindestens ein dbt-Test, Singular-Test oder ein manueller Reviewer-Faktor existieren, der diese Eigenschaft bestätigt. Ein Vertrag ohne Beweise bleibt ein Versprechen, das weder bestätigt noch widerlegt werden kann.

Minimale Auswirkungsnotiz auf den Vertrag: Strukturierter Markdown-Block, der in der Beschreibung jedes PR erscheinen muss, der ein Modell mit Vertrag betrifft. Enthält sechs Felder: geänderte Felder, brechende Änderung, PII-Auswirkung, SLA-Auswirkung, Prüfabdeckung, ob eine Bestätigung durch eine Person erforderlich ist. Sie ist der Beweis dafür, dass der PR-Autor die Vertragsauswirkungen erkannt hat.

Grain als Teil der Schnittstelle: Prinzip, nach dem der Grain (z. B. „eine Zeile pro customer_id“) Teil der öffentlichen Schnittstelle des Marts ist, ebenso wie die Spaltenliste. Eine Änderung des Grains ist eine brechende Änderung, selbst wenn das Schema gleich bleibt. Dies ist ein zentraler Begriff zum Verständnis des semantischen Drifts.

Qwen-Anfrage zur Drift-Suche: Vorgegebener Prompt für einen LLM-Assistenten, der vier Artefakte vergleicht: specs/customer_360_contract.odcs.yaml, specs/models/mart_customer_360.md, models/schema.yml und models/marts/mart_customer_360.sql. Der Assistent soll Drift und Lücken in der Testabdeckung finden, wobei er die Dateien nicht ändern darf. Das Ergebnis ist eine analytische Notiz für den Reviewer.

Wichtige Termine: Entstehung des odcs-Standards: Die ODCS-Spezifikation (Open Data Contract Standard) wird von der Community seit 2023 aktiv weiterentwickelt als Versuch, maschinenlesbare Datenverträge analog zu OpenAPI für REST zu vereinheitlichen.

Einführung von dbt contracts: Die Funktion contract.enforced in dbt erschien in Version 1.5 (Ende 2023) und stabilisierte sich ab 1.6+, mit Unterstützung der Materialisierungen table und incremental für eine Reihe von Adaptern.

Konzept data mesh (zhamak dehghani): Ab 2019–2020 hat das Konzept Data Mesh Datenverträge als Pflichtelement von data-as-a-product etabliert, was die Entstehung von ODCS und dbt-Verträgen beeinflusst hat.

Entwicklung des Begriffs data contract: Bis 2022 wurde der Begriff „data contract“ eher marketingtechnisch verwendet; ab 2023 wurde er ein formalisiertes Engineering-Artefakt in großen Unternehmen (GoCardless, Shopify, Netflix).

Übungsaufgaben: Name: Zuordnung von ODCS-Verpflichtungen und dbt-Tests

Problem: Ihnen werden zwei Auszüge gegeben. Auszug A – Auszug aus specs/customer_360_contract.odcs.yaml:

columns:
  - name: customer_id
    dataType: integer
    required: true
    primaryKey: true
  - name: risk_event_count_7d
    dataType: integer
    required: true
  - name: email
    dataType: string
    required: false
    classification: PII

Auszug B – Auszug aus models/schema.yml:

models:
  - name: mart_customer_360
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: risk_event_count_7d
        tests:
          - not_null
      - name: email
        # keine Tests

Listen Sie die Pflichtfelder auf und geben Sie an, durch welchen dbt-Test, Singular-Test oder manuellen Reviewer-Faktor jedes Feld abgedeckt ist. Für Felder ohne Abdeckung formulieren Sie einen Singular-Test oder eine Reviewer-Aktion.

Lösung: Schritt 1. Bestimmen der Pflichtfelder laut ODCS: customer_id (required, primaryKey) und risk_event_count_7d (required). Das Feld email ist nicht pflichtig.

Schritt 2. Zuordnung zu den Tests in schema.yml:

• customer_id: abgedeckt durch die Tests unique und not_null in schema.yml. Beide ODCS-Verpflichtungen (required + primaryKey) sind durch automatische Tests geschlossen.
• risk_event_count_7d: abgedeckt durch den Test not_null. Die Verpflichtung required ist geschlossen, aber es ist nicht nachgewiesen, dass die Werte sinnvoll sind (z. B. ≥0). Ein zusätzlicher Singular-Test auf den Wertebereich ist erforderlich.

Schritt 3. Für das Feld email (in ODCS als PII klassifiziert, aber nicht durch Tests abgedeckt): es ist entweder ein Singular-Test erforderlich, der das Fehlen von E-Mails an unerwarteten Stellen prüft, oder ein expliziter Reviewer-Faktor: „E-Mail wird im Mart nicht verwendet, Spalte ist reserviert“. Dieser Faktor wird in validation.md festgehalten.

Schritt 4. Ergebnistabelle der Abdeckung:

Komplexität: intermediate

Name: Klassifikation der Driftart

Problem: Bestimmen Sie für jede der vier Situationen die Driftart (Schema-, Semantik-, Prozessdrift) und begründen Sie, ob es sich um eine brechende Änderung handelt.

Situation 1: In mart_customer_360 wurde eine nullable-Spalte product_code hinzugefügt. Situation 2: Die Metrik total_revenue in mart_finance wurde in net_revenue umbenannt und zieht nun Retouren ab. Situation 3: Der Reviewer hat einen PR mit Änderung des Grains genehmigt, aber validation.md nicht aktualisiert. Situation 4: In der ODCS-Spezifikation ist das Feld email als PII markiert, aber in schema.yml wurde es entfernt, im SQL ist es weiterhin vorhanden.

Lösung: Situation 1: Schemadrift. Die Spalte wurde hinzugefügt – ODCS und schema.yml divergieren. Die Änderung ist NICHT brechend für bestehende Konsumenten (sie ignorieren einfach die neue Spalte), aber potenziell semantisch bedeutsam: product_code kann als neue Geschäftsmetrik wahrgenommen werden. Eine explizite Beschreibung im PR ist erforderlich.

Situation 2: Semantischer Drift + Schemadrift. Das Feld wurde umbenannt (Schemadrift) und seine Bedeutung hat sich geändert (Abzug von Retouren, semantischer Drift). Dies ist eine BRECHENDE Änderung: jedes Dashboard, das auf total_revenue verwies, wird entweder fehlschlagen oder andere Zahlen ohne sichtbaren Fehler anzeigen.

Situation 3: Prozessdrift. Die Änderung wurde im Code übernommen, der Reviewer hat sie genehmigt, aber das Prozessartefakt (validation.md) wurde nicht aktualisiert. Die Änderung selbst kann beliebig sein, aber die Beweisgrundlage ist verloren. Sie gilt als brechend, wenn die Änderung vertraglich relevant ist, aber die Validierung nicht festgehalten wurde.

Situation 4: Schema- + Prozessdrift. ODCS sagt, dass das PII-Feld existiert; schema.yml sagt, es existiert nicht; SQL sagt, es existiert. Drei Quellen widersprechen sich. Dies ist eine brechende Änderung aus Prozesssicht: ein Konsument, der schema.yml liest, wird annehmen, dass E-Mail fehlt, und möglicherweise keine Maskierung anwenden.

Komplexität: intermediate

Name: Erstellung einer minimalen Auswirkungsnotiz

Problem: Sie sind der Autor eines PR. Änderung: In mart_customer_360 wurde eine nullable-Spalte middle_name (Vatersname) hinzugefügt, der Grain wurde nicht geändert, customer_id bleibt Primary Key, es wurden keine neuen Tests hinzugefügt, die PII-Politik wurde nicht berührt (middle_name ist in ODCS als PII klassifiziert). Füllen Sie die minimale Auswirkungsnotiz auf den Vertrag gemäß der Vorlage aus dem Kapitel aus.

Lösung: ```markdown Geänderte Felder: nullable-Spalte middle_name (PII) hinzugefügt Brechende Änderung: nein (nullable, ändert den Grain nicht, bestehende Konsumenten sind nicht betroffen) PII-Auswirkung: PII-Spalte middle_name wurde im Mart hinzugefügt; es ist zu prüfen, dass Downstream-Konsumenten die Klassifikation berücksichtigen; in schema.yml muss das Feld classification: PII sowie ein Test oder eine Singular-Regel haben, die die Verbreitung ohne Maskierung verbietet SLA-Auswirkung: keine (Aktualität und Vollständigkeit nicht betroffen) Prüfabdeckung: für middle_name wurde ein Singular-Test hinzugefügt, der prüft, dass die Spalte nur in Marts mit Zugriffsstufe confidential vorhanden ist; customer_id ist weiterhin durch unique + not_null abgedeckt Bestätigung erforderlich: ja, eine explizite Bestätigung durch den Data Steward ist erforderlich, da eine neue PII-Spalte hinzugefügt wurde

Schlüsselpunkt: Selbst eine nicht brechende Änderung erfordert eine Bestätigung durch eine Person, wenn sie PII betrifft oder potenziell die Erwartungen der Konsumenten verändert.

Komplexität: intermediate

Name: Formulierung eines Qwen-Prompts für ein konkretes Modell

Problem: Sie haben ein Modell mart_orders mit Vertrag in specs/orders_contract.odcs.yaml. Formulieren Sie einen Prompt für Qwen Code, der die Vertragsdrift für dieses Modell prüft. Der Prompt muss: alle vier Artefakte zum Vergleich auflisten, explizit angeben, dass die Dateien nicht geändert werden dürfen, und darum bitten, ein strukturiertes Ergebnis auszugeben.

Lösung: ```text
Vergleiche specs/orders_contract.odcs.yaml,
specs/models/mart_orders.md, models/schema.yml und
models/marts/mart_orders.sql.
Finde Vertragsdrift und Lücken in der Testabdeckung.
Ändere keine Dateien.
Gib das Ergebnis in folgender Form aus:
1. Liste der Pflichtfelder laut ODCS und deren Testabdeckung.
2. Liste der Felder, die im SQL vorhanden, aber nicht in ODCS beschrieben sind.
3. Liste der Felder, die in ODCS beschrieben, aber im SQL nicht vorhanden sind.
4. Erkannte semantische Inkonsistenzen (Änderung des Grains, Umbenennung von Metriken, Änderung der Berechnungslogik).
5. Minimale Auswirkungsnotiz auf den Vertrag gemäß der Vorlage aus dem Kapitel.

Schlüsselelemente eines korrekten Prompts: explizite Dateiliste, explizites Änderungsverbot, strukturierte Ausgabe, Bezug zu den Begriffen des Kapitels (Drift, Abdeckung, Grain).

Komplexität: intermediate

Name: Erkennung brechender Änderungen

Problem: Gegeben sind fünf Änderungen an Modellen mit Vertrag. Bestimmen Sie für jede, ob sie brechend ist und ob eine Bestätigung durch den Data Steward erforderlich ist.

1. Umbenennung der Spalte status in order_status.
2. Hinzufügen einer nullable-Spalte discount_amount.
3. Änderung des Grains von „eine Zeile pro customer_id“ zu „eine Zeile pro (customer_id, month)“.
4. Löschen der Spalte legacy_score, die 6 Monate nicht verwendet wurde.
5. Änderung der Berechnungsformel von ltv_90d von sum(amount) zu sum(amount) - sum(refund).

Lösung: 1. BRECHEND. Eine Umbenennung bricht jedes Dashboard, das auf status verweist. Eine Bestätigung durch den Steward und eine Migrationsphase sind erforderlich.

1. NICHT brechend (formal). Eine nullable-Spalte bricht bestehende Konsumenten nicht. Wenn discount_amount jedoch als neue Geschäftsmetrik wahrgenommen wird, ist eine Benachrichtigung und möglicherweise eine Bestätigung durch den Product Owner erforderlich.

1. BRECHEND. Eine Änderung des Grains ist die gefährlichste Art brechender Änderungen: die Zeilenanzahl ändert sich, Downstream-Aggregate liefern andere Zahlen. Eine obligatorische Bestätigung durch den Steward und eine produktspezifische Abstimmung sind erforderlich.

1. BEDINGT BRECHEND. Wenn legacy_score tatsächlich nicht verwendet wurde, ist das Löschen sicher. Aber „6 Monate nicht verwendet“ ist ein schwacher Beweis: Dashboards könnten archiviert statt gelöscht worden sein. Eine Bestätigung durch den Product Owner ist erforderlich.

1. BRECHEND. Semantische Änderung: Die Zahlen ändern sich ohne Umbenennung der Spalte. Dies ist der schlimmste Fall – Tests können bestehen, Konsumenten sehen andere Daten. Eine Bestätigung durch den Steward, eine obligatorische Benachrichtigung der Konsumenten sowie eine Aktualisierung von ODCS und Tests auf den Wertebereich sind erforderlich.

Komplexität: advanced

Fallstudien: Name: Hinzufügen einer „sicheren“ Spalte hat das Reporting zerstört

Szenario: Fintech-Unternehmen, ~200 Mitarbeiter, 12 Marts in dbt. Der Mart mart_customer_360 wird vom Risikomanagement-Team für den täglichen Bericht über Kunden mit hohem Risiko verwendet. Der Vertrag in ODCS beschreibt den Grain als „eine Zeile pro customer_id“ und listet 14 Felder auf, darunter risk_event_count_7d (pflichtig). Ein Dashboard in Tableau aggregiert nach customer_id und berechnet den Anteil der Kunden mit risk_event_count_7d > 5.

Aufgabe: Ein Analyst hat im Modell die nullable-Spalte product_code (Code des Hauptprodukts des Kunden) hinzugefügt, hielt die Änderung für sicher und reichte den PR ohne Aktualisierung von ODCS ein. Die dbt-Tests bestanden, der Reviewer genehmigte ohne Rückfragen. Drei Wochen später stellte das Risikomanagement-Team fest, dass der Bericht über „Kunden mit hohem Risiko“ nun 2,3-mal mehr Datensätze enthielt. Die Untersuchung zeigte: In der Tableau-Berechnung wurde versehentlich product_code als zusätzlicher Gruppierungsschlüssel verwendet, und der Grain des Berichts wechselte implizit von customer_id zu (customer_id, product_code).

Lösung: Das Team führte drei Prozessänderungen ein. Erstens wurde in die PR-Vorlage der obligatorische Block „Auswirkungsnotiz auf den Vertrag“ nach dem Vorbild aus dem Kapitel aufgenommen. Zweitens wurde Qwen Code als automatische Prüfung im CI eingerichtet: Für jeden PR, der ein Modell mit ODCS betrifft, vergleicht der Bot die vier Dateien und hinterlässt einen Kommentar mit Drift-Verdacht. Drittens wurde eine Regel eingeführt: Wenn ein PR eine nullable-Spalte zu einem Modell mit Vertrag hinzufügt, muss der Reviewer explizit bestätigen, dass die neue Spalte den Grain nicht ändert und nicht als Geschäftsmetrik wahrgenommen wird.

Ergebnis: Im ersten Quartal nach der Einführung entdeckte der Bot 7 potenzielle Drifts vor dem Merge, von denen sich 2 als echte semantische Probleme herausstellten, die von normalen dbt-Tests übersehen worden wären. Die durchschnittliche Review-Zeit für PRs sank um 18 %, da die Autoren die Auswirkungsnotiz selbst ausfüllten und die Reviewer keine Zeit damit verbrachten, herauszufinden, „was diese Spalte bedeutet“.

Gewonnene Erkenntnisse: Eine nullable-Spalte ist keine sichere Änderung: wenn sie als neuer Gruppierungsschlüssel wahrgenommen wird, ändert sich der Grain implizit

Automatische dbt-Tests erkennen keine Änderungen des Grains – dafür ist entweder ein separater Test auf Eindeutigkeit des Schlüssels oder ein expliziter Reviewer-Faktor erforderlich

Die Auswirkungsnotiz auf den Vertrag funktioniert wie eine Checkliste: allein das Ausfüllen zwingt den PR-Autor, an den Konsumenten zu denken

Verwandte Konzepte: Schemadrift

Semantischer Drift

Grain als Teil der Schnittstelle

Minimale Auswirkungsnotiz

Qwen-Anfrage zur Drift-Suche

Name: Stille Änderung der Metrikformel

Szenario: E-Commerce-Plattform, der Mart mart_finance_daily wird vom Finanzteam zur Umsatzberechnung verwendet. Die Metrik gross_revenue ist in ODCS beschrieben als „Summe der Kosten aller erfolgreich abgeschlossenen Bestellungen pro Tag“. Das SQL implementiert dies als SUM(amount) FROM fct_orders WHERE status = 'completed'. Der Mart wird von drei Dashboards in Looker und einer ML-Pipeline zur Umsatzprognose konsumiert.

Aufgabe: Ein Ingenieur änderte die Formel, indem er den Filter on NOT refunded_at IS NULL hinzufügte, um „Retouren im Bruttoumsatz nicht zu berücksichtigen“. Die Änderung wurde als „kleine Logikverbesserung“ reviewt. ODCS wurde nicht aktualisiert, schema.yml wurde nicht angerührt, dbt-Tests bestanden. Einen Monat später stellte das Finanzteam eine Abweichung von 12 % zwischen dem Mart-Bericht und dem ERP-System-Bericht fest. Die Untersuchung ergab, dass ein Teil der Retouren zuvor in gross_revenue enthalten war, nun aber nicht mehr.

Lösung: Das Team stoppte die Änderung, rollte das SQL auf die vorherige Formel zurück, aktualisierte ODCS und fügte eine neue Metrik net_revenue mit expliziter Beschreibung „Summe der Kosten erfolgreich abgeschlossener und nicht retournierter Bestellungen“ hinzu. In schema.yml wurde ein separater Test hinzugefügt, der prüft, dass gross_revenue ≥ net_revenue für jeden Tag ist. In die PR-Vorlage wurde eine Warnung aufgenommen: „Wenn eine SQL-Änderung die Berechnung von in ODCS beschriebenen Metriken betrifft, gilt die Änderung als brechend und erfordert die Bestätigung des Data Steward“.

Ergebnis: Sechs Monate nach dem Vorfall gab es keinen einzigen Fall einer stillen Metrikänderung. Die ML-Pipeline zur Umsatzprognose lief ohne Ausfälle weiter. Das Team formalisierte die Politik: „Jede Änderung der Metrikformel = brechende Änderung = erfordert eine Major-Version des Vertrags und eine Benachrichtigung aller Konsumenten 2 Wochen im Voraus“.

Gewonnene Erkenntnisse: Semantischer Drift ist gefährlicher als Schemadrift: Das Schema ist intakt, Tests sind grün, die Zahlen ändern sich still

Logikverbesserung ≠ sichere Änderung, wenn die Logik im Vertrag beschrieben ist

Ein Vertrag muss Metriken und ihre Formeln explizit auflisten, andernfalls ist jede „Optimierung“ ein Drift

Verwandte Konzepte: Semantischer Drift

Brechende Änderung

ODCS als Verpflichtung

Beweisgrundlage des Vertrags

Name: ODCS ohne Tests: Ein schöner Vertrag für ein totes Produkt

Szenario: Versicherungsunternehmen, Legacy-Projekt. Ein Analyst des Data-Governance-Teams erstellte ODCS-Spezifikationen für 30 Marts, committete sie feierlich ins Repository und berichtete der Geschäftsleitung über die „Einführung von Data Contracts“. Die Marts wurden wie bisher weiterentwickelt: ohne Bezug zu ODCS, schema.yml beschrieb nur einen kleinen Teil der Spalten, es gab wenige Tests.

Aufgabe: Nach einem halben Jahr zeigte ein Audit, dass 18 der 30 ODCS-Spezifikationen vollständig veraltet waren: Felder wurden umbenannt, Metriken neu berechnet, der Grain geändert. Formal existierten die Verträge weiterhin, die Berichterstattung an den Regulator sah „grün“ aus. Die Rechts- und Compliance-Abteilungen verwendeten ODCS als Beweis „bei uns ist alles unter Kontrolle“, tatsächlich erhielten die Konsumenten jedoch Daten, die nicht dem Vertrag entsprachen.

Lösung: Das Team führte die Verknüpfung „ODCS-Verpflichtung → dbt-Test oder Singular-Test oder Reviewer-Faktor“ ein. Für jedes Pflichtfeld in ODCS wurde mindestens ein Test erstellt. Im CI wurde eine Prüfung hinzugefügt: Wenn in ODCS required: true angegeben ist, muss in schema.yml ein Test not_null vorhanden sein. Wenn in ODCS classification: PII angegeben ist, muss in schema.yml oder einem Singular-Test eine explizite Regel zum Umgang mit diesem Feld vorhanden sein. Alle 18 veralteten Spezifikationen wurden entweder auf den tatsächlichen Stand der Marts aktualisiert oder als deprecated mit explizitem SLA bis zur Abschaltung markiert.

Ergebnis: Innerhalb eines Quartals erhielten 100 % der Pflichtfelder in aktuellen ODCS eine Testabdeckung. Das Regulator-Audit verlief ohne Beanstandungen zu Data Contracts. Das Team formulierte das Prinzip: „ODCS ohne Beweisgrundlage ist kein Vertrag, sondern Marketing“.

Gewonnene Erkenntnisse: ODCS allein hat keinen Wert: Wert entsteht, wenn jede Verpflichtung überprüfbar ist

Ein Vertrag muss mit der Implementierung synchronisiert sein, sonst wird er zur Quelle falscher Sicherheit

Die Verbindung ODCS ↔ schema.yml ↔ SQL muss im CI automatisiert werden, sonst ist Drift unvermeidlich

Verwandte Konzepte: Beweisgrundlage des Vertrags

Zwei Vertragsebenen

Prozessdrift

Verbindung zwischen Vertrag und Tests

Lerntipps: Lesen Sie Änderungen wie ein Reviewer, nicht wie ein Autor. Der Autor sieht, „ob das SQL besser geworden ist“, der Reviewer sieht, „ob das Versprechen dasselbe geblieben ist“. Wechseln Sie bei jedem PR mit einem Modell, das einen Vertrag hat, die Perspektive.

Lernen Sie die sechs Felder der minimalen Auswirkungsnotiz auswendig und behalten Sie sie als Checkliste im Kopf: geänderte Felder, brechende Änderung, PII-Auswirkung, SLA-Auswirkung, Prüfabdeckung, ob eine Bestätigung erforderlich ist. Dies ist die praktischste Fähigkeit des Kapitels.

Unterscheiden Sie „Test bestanden“ und „Vertrag eingehalten“. Ein Test prüft eine Eigenschaft einer Spalte zu einem Zeitpunkt. Ein Vertrag ist die Gesamtheit der Verpflichtungen über den Lebenszyklus des Marts. Grüne Tests bedeuten nicht, dass der Vertrag lebt.

Üben Sie das Formulieren von Qwen-Prompts: Nehmen Sie Ihr Arbeitsmodell und bitten Sie den LLM-Assistenten, ODCS, Modellbeschreibung, schema.yml und SQL zu vergleichen. Bewerten Sie, welche Drifts er gefunden hat, welche er übersehen hat, und verfeinern Sie den Prompt. Diese Fähigkeit ist skalierbar.

Verwechseln Sie Schema- und semantischen Drift nicht. Schemadrift betrifft die Spaltenliste. Semantischer Drift betrifft die Bedeutung der Spalten, die geblieben sind. Semantischer Drift ist 5- bis 10-mal gefährlicher, da automatische Tests ihn in der Regel nicht erkennen.

Wenn Sie eine nullable-Spalte hinzufügen, fragen Sie sich: „Wenn ich Konsument wäre, würde ich diese Spalte als neue Geschäftsmetrik wahrnehmen?“ Wenn ja, ist dies keine „sichere“ Änderung, auch wenn sie nullable ist.

Denken Sie an den Grain als Teil der Schnittstelle. Eine Änderung des Grains ist immer eine brechende Änderung, selbst wenn alle Spalten gleich bleiben. Ein unique-Test auf den Grain-Schlüssel ist eine Pflicht-Hygiene für jedes Modell mit Vertrag.

Aktivieren Sie contract.enforced: true nicht im ersten Lerndurchlauf. Lernen Sie zunächst, Drift mit eigenen Augen und über Qwen Code zu lesen. Die mechanische Adapter-Einschränkung ist der zweite Schritt, wenn das Team versteht, warum dies nötig ist.

Zusätzliche Ressourcen: Odcs offizielle Spezifikation: https://bitol-io.github.io/data-contract-specification/ – Primärquelle des im Kurs verwendeten Open Data Contract Standard

Dbt-Dokumentation zu contracts: https://docs.getdbt.com/docs/mesh/contracts – Abschnitt der offiziellen dbt-Dokumentation zu contract.enforced und unterstützten Materialisierungen

Artikel von zhamak dehghani zu data mesh: https://martinfowler.com/articles/data-mesh-principles.html – konzeptionelle Grundlage von data-as-a-product und Datenverträgen

Dbt-utils-Paket: https://github.com/dbt-labs/dbt-utils – Standardtests und Makros zur Erweiterung der Vertragsprüfungs-Abdeckung

Great expectations: https://greatexpectations.io/ – Framework für Data-Quality-Assertions, das als zusätzliche Prüfschicht neben dbt-Tests dienen kann

Базовый data: https://www.elementary-data.com/ – Open-Source-Datenbeobachtbarkeit für dbt, einschließlich Anomalien und Tests

Buch 'data contracts' (andrew jones): https://datacontract.com/ – praktischer Leitfaden zur Einführung von Data Contracts in Organisationen

Qwen code Dokumentation: https://qwenlm.github.io/ – Materialien zur Arbeit mit dem LLM-Assistenten zur Analyse von Code und Spezifikationen

Zusammenfassung: Ein Datenvertrag ist eine überprüfbare Schicht zwischen dem Produktversprechen des Marts und seiner SQL-Implementierung. In SDD Data werden zwei Ebenen unterschieden: ODCS beschreibt das Produkt (Schema, Qualität, SLA, PII-Politik), schema.yml und dbt-Tests beschreiben das konkrete Modell. Keine Schicht ersetzt die andere: Tests ohne ODCS ergeben ein grünes Modell mit falscher Bedeutung, ODCS ohne Tests ergeben einen schönen Vertrag ohne Beweise. Vertragsdrift entsteht, wenn sich der Code ändert, der Vertrag aber gleich bleibt, und es gibt drei Arten: Schemadrift (Felder hinzugefügt/gelöscht/umbenannt), semantischer Drift (Bedeutung des Felds ändert sich ohne Schemaänderung) und Prozessdrift (Prozessartefakte spiegeln die Änderung nicht wider). Semantischer Drift ist am gefährlichsten, da automatische Tests ihn in der Regel nicht erkennen. Die wichtigste praktische Fähigkeit ist das Ausfüllen der minimalen Auswirkungsnotiz auf den Vertrag bei jedem PR und die Formulierung eines Qwen-Prompts zur automatischen Drift-Suche. Merken Sie sich die sechs Felder der Notiz: geänderte Felder, brechende Änderung, PII-Auswirkung, SLA-Auswirkung, Prüfabdeckung, ob eine Bestätigung erforderlich ist. Und denken Sie an das Hauptprinzip: Das Hinzufügen einer nullable-Spalte ist keine sichere Änderung, wenn sie als neue Geschäftsmetrik wahrgenommen wird oder den Grain ändert.