Was ist ODCS? Der Open Data Contract Standard, erklärt

Was der Open Data Contract Standard ist, was in einem v3-Contract tatsächlich steht, warum ein offener Standard das Regelformat eines Anbieters schlägt, und wie Import und Export von ODCS Ihre Datenqualitätsregeln portabel halten.

2026-09-02 · 8 min read

Der Open Data Contract Standard (ODCS) ist eine offene Spezifikation, um zu beschreiben, was ein Dataset zusagt: sein Schema, seine verantwortliche Stelle, seine Service Levels und — der Teil, der die meisten Teams interessiert — seine Datenqualitätsregeln. Er ist ein YAML-Dokument, versioniert wie Code, lesbar für Menschen und ausführbar durch Werkzeuge. ODCS wird offen als Teil des Bitol-Projekts unter dem AI-&-Data-Dach der Linux Foundation entwickelt, das heißt: Kein einzelner Anbieter kontrolliert ihn, und kein einzelner Anbieter kann Ihre Regeln stranden lassen.

Das Problem, das er löst

Jedes Datenqualitätswerkzeug erfindet sein eigenes Regelformat. dbt hat tests in einer schema.yml. Great Expectations hat Expectation Suites in JSON. Soda hat SodaCL. Monte Carlo hat Monitore in seiner Oberfläche. Jedes Format ist für sich vernünftig, und keines davon reist mit.

Das hat drei praktische Folgen:

Ihre Erwartungen sind an einen Runner gebunden. Der Wechsel von einem Werkzeug zum anderen bedeutet, jede Regel von Hand neu zu schreiben — weshalb Teams nicht wechseln, weshalb das Format sein gefangenes Publikum behält.
Produzenten und Konsumenten sind sich uneinig, was zugesagt wurde. Die Regeln liegen im Repository der Pipeline, im Format des Pipeline-Teams. Das Analyseteam, das von der Tabelle abhängt, kann sie nicht lesen, geschweige denn eine Änderung prüfen.
Nichts ist prüfbar. Eine in einer Anbieteroberfläche geänderte Regel hinterlässt keinen Diff. Ob der Schwellenwert verschoben wurde, weil sich das Geschäft geändert hat oder weil jemand den Alarm satthatte, lässt sich nicht mehr rekonstruieren.

Ein Data Contract löst alle drei Punkte, indem er das Versprechen selbst zum Artefakt macht — getrennt vom Werkzeug, das es durchsetzt, versioniert im selben Repository wie alles andere und geschrieben in einem Format, das beide Seiten der Schnittstelle lesen können.

Was tatsächlich in einem ODCS-Contract steht

Ein v3-Contract ist ein YAML-Dokument mit einer kleinen Zahl von Blöcken auf oberster Ebene. Das Wesentliche:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.2.0
  owner: data-platform
schema:
  - name: orders
    physicalName: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        physicalType: uuid
        required: true
        primaryKey: true
        description: Business key, stable across restatements.
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
          - rule: duplicateCount
            dimension: uniqueness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"
    quality:
      - rule: rowCount
        dimension: consistency
        severity: warning
        mustBe: "> 0"

Von oben nach unten gelesen:

apiVersion und kind weisen das Dokument als ODCS-v3-Data-Contract aus. Werkzeuge entscheiden daran, ob sie es überhaupt parsen können.
info trägt die Metadaten für Menschen — Titel, semantische Version, verantwortliche Stelle. Die Version ist die des Contracts, nicht die der Daten, und sie sagt einem Konsumenten, ob eine Änderung additiv oder brechend war.
schema beschreibt die physischen Objekte. properties sind die Spalten, jeweils mit einem logicalType (portabel: string, number, timestamp) und einem physicalType (dem der Engine eigenen: uuid, NUMERIC, datetime2). Beides zu führen ist das, was einem Contract erlaubt, dasselbe Dataset in Postgres und in BigQuery zu beschreiben.
quality-Blöcke hängen Erwartungen an — entweder an eine Spalte oder an die Tabelle als Ganzes.

Die Anatomie einer Qualitätsregel

Vier Felder leisten die Arbeit:

Feld	Was es bedeutet
`rule`	Die auszuführende Prüfung — `nullCount`, `duplicateCount`, `validValues`, `between`, `regex`, `freshness`, `rowCount`, `referentialIntegrity`, `customSql`
`dimension`	Zu welcher Qualitätsdimension sie gehört — Vollständigkeit, Eindeutigkeit, Konformität, Genauigkeit, Aktualität, Konsistenz
`severity`	`error` lässt den Lauf scheitern; `warning` protokolliert den Verstoß und macht weiter
`mustBe`	Der Schwellenwert, in einer kleinen, lesbaren Grammatik

mustBe ist der Teil, der Contracts angenehm lesbar macht. Es ist keine Sprache für boolesche Ausdrücke, sondern eine Kurzschreibweise je Regel:

Zählende Regeln nehmen einen Vergleich: "0", "<= 5", "> 0". Eine nackte Zahl bedeutet „genau".
between nimmt Grenzen: "[0, 100000]".
validValues nimmt eine Liste: "['pending', 'paid']".
regex nimmt ein in Anführungszeichen gesetztes Muster: "'^ORD-[0-9]{6} #39;".
freshness nimmt ein maximales Alter: "<= 24h", "<= 2d".
referentialIntegrity nimmt ein Ziel: "customers.id".

Wer das Werkzeug nie benutzt hat, kann mustBe: "<= 24h" auf einer freshness-Regel lesen und weiß genau, was passieren wird. Das ist der ganze Sinn.

Dimensionen sind keine Dekoration

Das Feld dimension wirkt wie Taxonomie um ihrer selbst willen — bis Sie hundert Regeln haben. Dann ist es der einzige Weg, die Fragen zu beantworten, die tatsächlich gestellt werden: *Sind wir bei der Aktualität über unsere kritischen Datasets hinweg abgedeckt, oder nur bei der Vollständigkeit?* Nach Dimension gruppierte Regeln werden zu einer Abdeckungsmatrix, und die Lücken in dieser Matrix sind meist aufschlussreicher als jede einzelne scheiternde Prüfung.

Die sechs gängigen Dimensionen — Vollständigkeit, Eindeutigkeit, Konformität, Genauigkeit, Aktualität, Konsistenz — sind verbreitet genug, dass ein Abdeckungsbericht über Teams hinweg dasselbe bedeutet.

Warum ein offener Standard den Aufwand wert ist

Portabilität ist das Offensichtliche. Derselbe Contract beschreibt dasselbe logische Dataset, ob es in PostgreSQL, BigQuery oder SQL Server landet. Der Runner kompiliert nullCount in das SQL der jeweiligen Engine. Eine Data-Warehouse-Migration ist damit keine Regelmigration mehr.

Prüfbarkeit ist das Unterschätzte. Weil der Contract eine Datei ist, ist eine Schwellenwertänderung ein Diff im Pull Request, mit Autor und Begründung. Die wertvollste Eigenschaft eines Data Contracts ist nicht, dass eine Maschine ihn ausführen kann — sondern dass ein Mensch ihm widersprechen kann, bevor er gemergt wird.

Unabhängigkeit ist das Strategische. Regeln, die in einem offenen Standard geschrieben sind, sind kein Vermögenswert desjenigen, der sie ausführt. Wenn Sie das Validierungswerkzeug ersetzen, kommen die Contracts mit. Das verändert die Verhandlungsposition — und es verändert, wie viel Sie überhaupt bereit sind, in das Schreiben von Regeln zu investieren.

Interoperabilität mit Katalogen. Weil ODCS auch Verantwortlichkeiten, Beschreibungen und Service Levels trägt, speist dasselbe Dokument einen Katalog, ein Lineage-Werkzeug und einen Qualitäts-Runner, ohne dass drei getrennte Quellen der Wahrheit auseinanderdriften.

Import und Export in der Praxis

Ein Standard ist nur so viel wert wie die Leichtigkeit, in ihn hinein- und aus ihm herauszukommen. Zwei Faustregeln:

Der Import sollte Sie dort abholen, wo Sie stehen. Richten Sie ein Werkzeug auf eine bestehende Tabelle, und es sollte information_schema lesen, Spalten und Typen ableiten, aus dem Gefundenen einen Basisvertrag vorschlagen — aus Pflichtspalten werden nullCount-Regeln, aus Primärschlüsseln duplicateCount-Regeln, aus Zeitstempeln freshness-Kandidaten — und Sie von dort aus weiterarbeiten lassen. Mit einem generierten Entwurf von dreißig Regeln zu starten und zehn davon zu löschen, ist eine völlig andere Erfahrung, als mit einer leeren Datei zu beginnen.

Der Export sollte Byte für Byte das sein, was Sie bearbeiten. Hier scheitern die meisten Werkzeuge stillschweigend. Wenn das YAML nur die Darstellung einer Datenbankzeile ist, formatiert jeder Roundtrip durch die Oberfläche die Datei um, ordnet die Schlüssel neu und verwirft Ihre Kommentare — und der Diff in Ihrem Pull Request wird zu unlesbarem Rauschen. Der Contract muss das Speicherformat *sein*, nicht eine Projektion davon.

Catalyst nimmt den zweiten Punkt wörtlich. Das YAML ist die Quelle der Wahrheit; der visuelle Regel-Builder bearbeitet das Dokument an Ort und Stelle und erhält Kommentare und Schlüsselreihenfolge, sodass eine in der Oberfläche hinzugefügte Regel einen einzeiligen Diff erzeugt. Der Export ist ein Dateidownload, der Import akzeptiert jedes gültige v3-Dokument, und nichts wird in einer Form gespeichert, aus der Sie es nicht wieder herausbekommen.

Einen Contract versionieren

Verwenden Sie semantische Versionierung auf info.version — und meinen Sie es ernst:

Patch — ein gelockerter oder verschärfter Schwellenwert, eine verbesserte Beschreibung. Konsumenten müssen es nicht wissen.
Minor — eine neue Spalte, eine neue Regel. Additiv; bestehende Konsumenten funktionieren weiter.
Major — eine entfernte oder umbenannte Spalte, ein geänderter Typ, eine Regel, die nun Daten ablehnt, die zuvor akzeptiert wurden. Brechend; Konsumenten brauchen eine Vorwarnung.

Die Disziplin zahlt sich in dem Moment aus, in dem jemand fragt, ob eine Spalte gefahrlos entfernt werden kann. Mit versionierten Contracts und einem Diff ist das ein Fünf-Minuten-Gespräch statt einer Woche grep.

Wie Contracts sich zu dbt-Tests verhalten

Sie sind keine Konkurrenten, und es lohnt sich, den Unterschied präzise zu fassen.

dbt-Tests laufen innerhalb eines dbt-Builds und decken Modelle ab, die dbt gehören. Genau darin sind sie ausgezeichnet, und wenn jede Tabelle, die Ihnen wichtig ist, ein dbt-Modell ist, genügen sie womöglich.

Ein Data Contract sitzt eine Ebene darüber. Er beschreibt die Zusagen des Datasets unabhängig davon, was es erzeugt hat — dbt, Airflow, ein Spark-Notebook, das Replikationswerkzeug eines Anbieters, ein handgeschriebener Loader — und unabhängig davon, wer die Prüfung ausführt. Er ist die Schnittstelle zwischen einem Produzenten und einem Konsumenten, versioniert als erstklassiges Artefakt.

In der Praxis legen Teams, die beides nutzen, schnelle, billige Assertions in dbt-Tests, wo sie den Build scheitern lassen, und die dauerhaften Zusagen in den Contract, wo sie geprüft, versioniert und nach Zeitplan überwacht werden — unabhängig davon, welche Pipeline die Tabelle heute geschrieben hat.

Häufig gestellte Fragen

Wofür steht ODCS?

Für Open Data Contract Standard. Es ist eine offene Spezifikation, um Schema, Verantwortlichkeit, Service Levels und Datenqualitätserwartungen eines Datasets in einem einzigen versionierten YAML-Dokument zu beschreiben, entwickelt als Teil des Bitol-Projekts unter dem AI-&-Data-Dach der Linux Foundation.

Ist ODCS dasselbe wie ein Data Contract?

„Data Contract" ist das Konzept — ein vereinbartes, versioniertes Versprechen zwischen einem Datenproduzenten und seinen Konsumenten. ODCS ist ein konkretes, offenes Format, um dieses Versprechen festzuhalten. Sie können Data Contracts auch ohne ODCS führen, in einem selbstgebauten Format; ein offener Standard ist das, was sie zwischen Werkzeugen portabel macht.

Was ist der Unterschied zwischen ODCS und dbt-Tests?

dbt-Tests sind Assertions innerhalb eines dbt-Projekts, begrenzt auf Modelle, die dbt baut, und sie laufen als Teil eines dbt-Builds. Ein ODCS-Contract beschreibt die Zusagen des Datasets unabhängig vom Werkzeug, das es erzeugt oder prüft, wird als eigenes Artefakt versioniert und kann von jedem kompatiblen Runner durchgesetzt werden. Viele Teams nutzen beides.

Welche Datenqualitätsregeln unterstützt ODCS?

Der Quality-Block der Spezifikation ist offen genug, um jede Regel zu tragen, die ein Runner versteht. In der Praxis ist der gängige Satz: Vollständigkeit (nullCount), Eindeutigkeit (duplicateCount), erlaubte Werte (validValues), Zahlenbereiche (between), Mustererkennung (regex), Aktualität (freshness), Zeilenzahlen (rowCount), referenzielle Integrität und ein Notausstieg für eigenes SQL. Jede trägt eine Dimension und eine Severity, sodass sich die Ergebnisse zu einer Abdeckungsansicht verdichten.

Kann ich einen bestehenden ODCS-Contract in Catalyst importieren?

Ja. Catalyst liest jedes gültige ODCS-v3-Dokument, validiert es gegen die importierten Spalten des Datasets — eine Regel, die auf eine nicht existierende Spalte verweist, wird also beim Speichern erkannt, mit Zeilennummer — und speichert das YAML selbst als Quelle der Wahrheit. Der Export gibt Ihnen dieselbe Datei zurück, Kommentare und Reihenfolge intakt.