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

Lektion 1 von 5 im Modul «Teil 12. Datenverträge: ODCS und dbt-Vertragsprüfungen»

Sie sehen die Lektion ohne Anmeldung an. Anmelden, um Ihren Fortschritt zu speichern und Tests zu absolvieren.

Quelle

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

Ein Datenvertrag ist nötig, damit der nachgelagerte Konsument das Produktversprechen sieht und nicht nur die aktuelle Implementierung. In SDD Data ist ein Vertrag kein dekoratives YAML. Es ist eine überprüfbare Schicht zwischen Produktversprechen und SQL.

Zwei Vertragsebenen

ODCS ist für den technischen Vertrag des Datenprodukts zuständig: Schema, Qualität, SLA und Breaking Changes. Der dbt-Modellvertrag ist für die Form eines bestimmten dbt-Modells zuständig. Im Lernbeispiel verwenden wir models/schema.yml, eingebaute dbt-Tests und Singular-Tests als minimale Vertragsprüfungen; contract.enforced: true ist nicht aktiviert, um den ersten Lerndurchlauf nicht mit Einschränkungen eines bestimmten Adapters zu vermischen. Im Produktivbetrieb kann es dort aktiviert werden, wo Adapter und Materialization dies unterstützen.

Vertragsdrift

Vertragsdrift entsteht, wenn sich das Modell ändert, der Vertrag jedoch nicht. Beispielsweise erhält mart_customer_360 eine neue Spalte product_code, aber der Grain bleibt als «eine Zeile pro customer_id» beschrieben. Das ist gefährlicher als ein Syntaxfehler: dbt kann bestehen, und der Konsument erhält eine andere Bedeutung.

Es gibt drei Arten von Drift:

Schema-Drift: Felder hinzugefügt/entfernt/umbenannt;

semantischer Drift: das Feld bleibt, aber seine Bedeutung hat sich geändert;
prozessualer Drift: validation.md oder der Bericht des Reviewers spiegeln die Änderung nicht wider.

Zusammenhang zwischen Vertrag und Tests

Ein Vertrag muss durch Nachweise abgedeckt sein. Wenn ODCS sagt, dass risk_event_count_7d obligatorisch ist, muss es mindestens einen Test oder einen manuellen Fakt eines Reviewers geben, der das Vorhandensein und das Verhalten von not_null bestätigt. Andernfalls bleibt der Vertrag ein Versprechen ohne Beweise.

Qwen-Abfrage

Vergleiche specs/customer_360_contract.odcs.yaml,
specs/models/mart_customer_360.md, models/schema.yml und
models/marts/mart_customer_360.sql.
Finde Vertragsdrift und Lücken in der Testabdeckung. Ändere keine Dateien.

Minimale Ausgabe

Erstellen Sie eine Notiz zur Vertragsauswirkung:

Geänderte Felder: keine
Breaking Change: keiner
Auswirkung auf PII: direkte PII in der Mart nicht offengelegt
Auswirkung auf SLA: keine
Prüfabdeckung: unique/not_null für customer_id, obligatorische Felder, Liste verbotener PII
Bestätigung erforderlich: nein

Für künftige PRs sollte dieser Block Teil der Änderungsbeschreibung sein.

Erläuterung für den Leser

Ein Datenvertrag ist nicht für die Schönheit von YAML da. Er ist da, damit sich der Konsument auf die Form und Bedeutung der Mart verlassen kann, ohne jedes Mal SQL zu lesen. In der gewöhnlichen Entwicklung darf eine öffentliche API nicht unbemerkt geändert werden; bei Daten ist die Situation dieselbe, nur sieht die API oft wie eine Tabelle aus. Spalte, Grain, Freshness und PII-Richtlinie sind Teile der Schnittstelle.

ODCS, dbt-Vertragsprüfungen und Schema-Tests decken unterschiedliche Ebenen ab. ODCS spricht über das Produkt und sein technisches Versprechen. schema.yml und Tests bestätigen einen Teil der Form. Singular-Tests fangen Regeln ab, die nicht in die Standardprüfungen passen. Keine Schicht ersetzt die anderen. 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 erhalten.

Vertragsdrift ist besonders unangenehm, weil sie oft wie eine nützliche Verbesserung aussieht. Eine Spalte hinzugefügt. Die Granularität erweitert. Eine Kennzahl «für mehr Klarheit» umbenannt. Jeder Schritt einzeln erscheint klein, aber der nachgelagerte Konsument kann einen anderen Satz von Zeilen oder eine andere Geschäftskennzahl erhalten. Deshalb muss die Vertragsauswirkung auch dann beschrieben werden, wenn die Änderung sicher erscheint.

In diesem Kapitel ist es wichtig, eine Änderung wie ein Reviewer zu lesen. Die Frage ist nicht «ist das SQL besser geworden», sondern «ist das Versprechen dasselbe geblieben». Wenn sich das Versprechen geändert hat, ist eine ausdrückliche Bestätigung durch einen Menschen erforderlich. Wenn sich das Versprechen nicht geändert hat, muss auch das bewiesen werden: welche Felder unverändert sind, welcher Grain unverändert ist, welche PII nicht offengelegt werden, welche Tests bestanden wurden.

Übung

Vergleichen Sie customer_360_contract.odcs.yaml und models/schema.yml. Listen Sie die obligatorischen Felder auf und geben Sie an, durch welchen dbt-Test, Singular-Test oder manuellen Fakt sie abgedeckt sind.

Typischer Fehler

Das Hinzufügen einer Spalte als immer sicher anzusehen. Selbst eine Nullable-Spalte kann die Erwartungen der Konsumenten ändern, wenn sie wie eine neue Geschäftskennzahl aussieht oder den Grain verändert.