Was ist ein Data Contract? Eine praktische Definition

Was ein Data Contract ist, was darin tatsächlich steht, wie er sich von einem Schema oder einem SLA unterscheidet und wie er durchgesetzt wird — mit einem ausgearbeiteten ODCS-Beispiel.

2026-09-10 · 8 min read

Ein Data Contract ist eine explizite, versionierte Vereinbarung zwischen dem Produzenten eines Datasets und dessen Konsumenten, die festlegt, was das Dataset zusagt: sein Schema, die Bedeutung jedes Feldes, die Erwartungen an die Datenqualität, die es erfüllen muss, und die Service Levels — Aktualität, Verfügbarkeit, Support —, unter denen es bereitgestellt wird. Er ist als maschinenlesbares Dokument geschrieben, liegt neben dem Code in der Versionskontrolle, wird über Pull Requests geprüft und automatisch durchgesetzt, indem seine Qualitätserwartungen gegen die echten Daten ausgeführt werden. Ein Contract ist ein Versprechen über eine Schnittstelle, keine Beschreibung einer Pipeline.

Das Wort „Vertrag" leistet in dieser Definition echte Arbeit. Es setzt zwei benannte Parteien voraus, eine erklärte Verpflichtung, eine Version, auf die man zeigen kann, und Konsequenzen, wenn die Verpflichtung nicht erfüllt wird. Eine Schemadatei hat keine dieser Eigenschaften; ein Contract hat alle vier.

Warum Data Contracts entstanden sind

Drei Fehlermuster haben Teams auf die Idee gebracht, und es lohnt sich, sie zu benennen, weil sie die Form der Lösung erklären.

Schema-Drift ohne Benachrichtigung. Ein Produzententeam benennt eine Spalte um, erweitert einen Typ oder entfernt ein Feld, das es für ungenutzt hält. Die Änderung besteht die eigenen Tests, denn die Tests decken den eigenen Code ab. Weiter unten bricht ein Dashboard, ein Modell trainiert stillschweigend auf NULL-Werten nach, oder ein nächtlicher Job scheitert um 03:00 Uhr. Es gab keine Schnittstelle, also gab es auch nichts, was hätte brechen können — nur eine Tabelle, die sich verändert hat.

Kaputte Dashboards ohne verantwortliche Person. Wenn die Qualität nachlässt, beginnt das Gespräch mit Archäologie. Wer erzeugt diese Tabelle? Was sollte darin stehen? Waren 4 % NULL-Werte in customer_id schon immer normal? Niemand hat es aufgeschrieben, also dauert die Antwort eine Woche, und die Korrektur ist ein Pflaster weiter unten statt einer Lösung weiter oben.

Kopplung von Produzent und Konsument. Ohne erklärte Schnittstelle rekonstruieren Konsumenten die Implementierung des Produzenten — sie lesen Zwischentabellen, verlassen sich auf zufällige Sortierungen, codieren Annahmen über die Werte eines Statusfeldes fest ein. Jede dieser Annahmen wird zu einer ungeschriebenen Verpflichtung, von der der Produzent nichts weiß.

Die Softwarebranche hat das analoge Problem mit API-Contracts gelöst: OpenAPI-Spezifikationen, semantische Versionierung, Abkündigungsfristen. Ein Data Contract überträgt dieselbe Disziplin auf die Datenschnittstelle. Die Kernidee ist, dass das Versprechen selbst zum Artefakt wird — getrennt von der Pipeline, die es erfüllt, und getrennt vom Werkzeug, das es prüft.

Was in einem Data Contract steht

Ein vollständiger Contract trägt fünf Dinge.

Identität und Verantwortung. Was das Dataset ist, welches Team es verantwortet, wie man es erreicht, welche Version der Contract selbst hat. Verantwortung ist keine Dekoration — sie ist die Partei auf der anderen Seite der Vereinbarung.
Schema und Semantik. Die Felder, ihre Typen (logisch wie physisch), ob sie Pflicht sind, und — entscheidend — was jedes einzelne bedeutet. amount ist keine Beschreibung; „Bestellsumme in EUR, ohne USt., nach Rabatten" ist eine.
Qualitätserwartungen. Die Regeln, die die Daten erfüllen müssen, jede mit Schwellenwert und Severity: Pflichtspalten sind nie NULL, Schlüssel sind eindeutig, kategoriale Felder bleiben in einer erlaubten Menge, Zahlen bleiben in einem plausiblen Bereich, Fremdschlüssel lösen auf.
Service Levels. Aktualität (wie kürzlich die Daten aktualisiert worden sein müssen), Verfügbarkeit, Aufbewahrung und die zugehörigen Supporterwartungen.
Änderungsrichtlinie. Wie der Contract versioniert wird, was als Breaking Change gilt und wie viel Vorlauf Konsumenten vor einer brechenden Änderung bekommen.

So sieht das in der Praxis aus, geschrieben im Open Data Contract Standard:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 2.1.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
        description: Lifecycle state. New values require a minor version bump.
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: total_amount
        logicalType: number
        physicalType: numeric
        description: Order total in EUR, excluding VAT, after discounts.
        quality:
          - rule: between
            dimension: accuracy
            severity: error
            mustBe: "[0, 100000]"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"

Lesen Sie es als einen Satz: Das Team data-platform sagt eine Tabelle namens orders zu, deren order_id stets vorhanden und eindeutig ist, deren status genau einer von vier Werten ist, deren total_amount ein Eurobetrag zwischen null und einhunderttausend ist und die nie älter als 24 Stunden ist. Dieser Satz ist der Contract. Alles andere ist Syntax.

Contracts, Schemas und SLAs

Die drei werden häufig vermengt, und genau die Unterschiede sind der Punkt.

	Data Contract	Schema	SLA
Legt fest	Struktur, Bedeutung, Qualität und Service Levels	Nur Struktur und Typen	Ziele für Verfügbarkeit und Aktualität
Hat zwei Parteien	Ja — benannter Produzent und benannte Konsumenten	Nein	Meist
Als Artefakt versioniert	Ja, semantisch, in Git	Manchmal	Selten
Maschinell durchsetzbar	Ja, durch einen Validierungs-Runner	Teilweise, beim Schreiben	Gemessen, nicht erzwungen
Deckt Semantik ab	Ja	Nein	Nein

Ein Schema sagt Ihnen, dass eine Spalte ein string ist. Ein Contract sagt Ihnen, dass es ein Währungscode ist, dass er immer einer der von Ihnen akzeptierten ISO-4217-Werte ist, dass er nie NULL ist und dass das Payments-Team dafür verantwortlich ist. Ein SLA sagt Ihnen, dass die Tabelle täglich aktualisiert wird; ein Contract sagt das und was für die Zeilen darin gelten muss.

Kurz gesagt: Ein Schema ist eine Teilmenge eines Contracts, und ein SLA ist eine Teilmenge eines Contracts. Der Contract ist das Artefakt, das beides an einer Stelle prüfbar macht.

Wie Contracts durchgesetzt werden

Ein Contract, den niemand prüft, ist ein Dokument, keine Vereinbarung. Durchsetzung passiert an drei Punkten.

Beim Review. Weil der Contract eine Datei ist, ist eine Änderung daran ein Diff im Pull Request, mit Autor und Begründung. Das ist die wertvollste und am wenigsten diskutierte Eigenschaft von Data Contracts: Ein Mensch kann einem Schwellenwert widersprechen, bevor er gemergt wird. Eine in einer Anbieteroberfläche gelockerte Regel hinterlässt keine Spur, ob sich das Geschäft geändert hat oder jemand den Alarm satthatte.

Zur Laufzeit. Ein Runner kompiliert jede Qualitätserwartung in eine Abfrage gegen das tatsächliche Dataset und protokolliert das Ergebnis. Aus nullCount wird ein COUNT(*) WHERE col IS NULL; aus freshness wird ein Vergleich mit now(). Das ist gewöhnliche Datenvalidierung — der Contract ist lediglich der Ort, an dem die Erwartungen deklariert werden, statt über Skripte verstreut zu sein, und der Leitfaden zur Datenvalidierung beschreibt, wie diese Abfragen in der Praxis geschrieben, geplant und mit Schwellenwerten versehen werden. Die Severity entscheidet über die Konsequenz: error blockiert oder alarmiert, warning protokolliert einen Trend.

Bei Änderungen. Die semantische Versionierung des Contracts trägt die Bedeutung. Ein Patch lockert oder verschärft einen Schwellenwert; ein Minor fügt additiv eine Spalte oder eine Regel hinzu; ein Major entfernt oder benennt ein Feld um, ändert einen Typ oder beginnt, zuvor akzeptierte Daten abzulehnen. Die Version ist das, was einem Konsumenten erlaubt zu entscheiden, ob ihn eine Änderung betrifft, ohne den Diff zu lesen.

Catalyst setzt genau diese Schleife um: Contracts sind ODCS-YAML mit der Datei als Quelle der Wahrheit, Regeln kompilieren zu engine-nativem SQL über PostgreSQL, BigQuery, SQL Server und weitere, und Ergebnisse verdichten sich nach Qualitätsdimension, sodass Abdeckungslücken sichtbar statt bloß implizit sind.

Wo Sie anfangen

Beginnen Sie nicht damit, alles unter Contract zu stellen. Wählen Sie ein Dataset, das kürzlich etwas kaputtgemacht hat und eine identifizierbare verantwortliche Person hat, schreiben Sie auf, was es implizit ohnehin schon zusagt, und lassen Sie den Produzenten zustimmen. Importieren Sie das Schema aus der Datenbank, statt es abzutippen — ein generierter Entwurf mit dreißig Regeln, den Sie anschließend ausdünnen, ist ein weit besserer Ausgangspunkt als eine leere Datei.

Der erste Contract ist eine Dokumentationsübung. Beim zweiten beginnt die Disziplin sich auszuzahlen, denn bis dahin hat jemand versucht, eine brechende Änderung durchzubringen, und der Contract hat sie abgefangen.

Häufig gestellte Fragen

Was ist ein Data Contract, einfach gesagt?

Ein Data Contract ist eine schriftliche, versionierte Vereinbarung darüber, was ein Dataset zusagt — welche Felder es hat, was sie bedeuten, welche Qualitätsregeln sie erfüllen müssen und wie aktuell die Daten sein werden. Er liegt wie Code in der Versionskontrolle, wird in Pull Requests geprüft und automatisch gegen die echten Daten überprüft.

Was ist der Unterschied zwischen einem Data Contract und einem Schema?

Ein Schema beschreibt die Struktur — Feldnamen und Typen. Ein Data Contract enthält das Schema, ergänzt aber das, was ein Schema nicht ausdrücken kann: was jedes Feld bedeutet, welche Qualitätsregeln die Werte erfüllen müssen, die Service Levels für Aktualität und Verfügbarkeit, die verantwortliche Stelle und eine Versionierungsrichtlinie, die festlegt, was als Breaking Change gilt.

Sind Data Contracts dasselbe wie ODCS?

Nein. „Data Contract" ist das Konzept — ein vereinbartes, versioniertes Versprechen zwischen einem Produzenten und seinen Konsumenten. ODCS, der Open Data Contract Standard, ist ein offenes, anbieterneutrales Format, um dieses Versprechen als YAML festzuhalten. Sie können Data Contracts auch in einem selbstgebauten Format führen; ein offener Standard ist das, was sie zwischen Werkzeugen portabel hält.

Wie wird ein Data Contract durchgesetzt?

Indem seine Qualitätserwartungen in Abfragen kompiliert werden, die nach Zeitplan gegen das echte Dataset laufen, und indem Änderungen am Contract selbst als Pull Requests geprüft werden. Regeln tragen eine Severity, ein Verstoß blockiert also entweder die nachgelagerte Nutzung oder wird als Warntrend protokolliert. Die Durchsetzung ist gewöhnliche Datenvalidierung; der Contract ist nur der Ort, an dem die Erwartungen deklariert sind.

Wer schreibt den Data Contract — der Produzent oder der Konsument?

Der Produzent verantwortet ihn, denn er ist die Partei, die das Versprechen gibt — der erste Entwurf wird aber meist ausgehandelt, weil die Konsumenten wissen, auf welche Zusagen sie tatsächlich angewiesen sind. Ein allein von Konsumenten geschriebener Contract ist eine Wunschliste; ein allein von Produzenten geschriebener neigt dazu, nur das zu versprechen, was ohnehin leicht fällt.