Was sind Data Contracts? Ein Einsteigerleitfaden mit Beispielen

Semantische Data Contracts

Semantische Datenvalidierungen stellen sicher, dass Daten logisch konsistent sind und zur Business-Logik passen.

Semantische Validierungen müssen explizit durchgesetzt werden.

Im Gegensatz zu Schema-Checks beruhen semantische Data Contracts auf Business-Logik und werden extern implementiert.

In vielen Anwendungsfällen wirken Semantiken wie eine Erweiterung schema-validierter Verträge. Oft hängen sie von Geschäftsregeln ab und bilden eine Menge von Zeilenbedingungen ab, die unser Datenmodell erfüllen muss. 

Ein Beispiel für einen semantischen Vertrag kann Folgendes sein:

• Metrikabweichung: von gleitendem Mittelwert oder einem anderen Schwellenwert. Beispielsweise können wir akzeptieren, dass die Zahl aktiver Nutzer gestern auf unter 75% des 7-Tage-Mittels fällt, aber 0% sind inakzeptabel.
• Business-Logik: Alerts aus dem Transaktionsmonitoring und Fraud-Preventionscores. In diesem Fall muss der Auszahlungsbetrag 0 sein.
• Data Lineage: Beschreibt die Entwicklung von Datenentitäten. Zum Beispiel darf transaction_completed_at nicht vor created_at liegen.
• Referentielle Integrität: Beziehungen zwischen Entitäten sind wichtig und lassen sich ebenfalls über semantische Verträge abbilden. Betrachte den folgenden dbt-Code: Er stellt sicher, dass jede refund_id einer gültigen transaction.id zugeordnet ist.

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: id

Es liegt an dir, die Alarmstufe für semantische Verträge festzulegen. Häufig geschieht das über individuelle Data-Quality-Tests.

Verschiedene Geschäftsregeln zielen oft auf die Datenintegrität ab. Unlogische Datenszenarien können durch Fehler in Datenbank- und Serverkonfigurationen oder durch das versehentliche Einspeisen von Testdaten in die Produktion entstehen. Integritätsprüfungen validieren Daten gegen diese Geschäftsregeln und helfen, Werte zu erkennen, die nicht plausibel sind.

Datenbankentitäten stehen immer in Beziehung. Das nennt sich Entity-Relationship und wird oft im Entity-Relationship-Diagramm (ERD) dargestellt. Unzureichende referentielle Integrität kann zu fehlenden oder unvollständigen Daten führen. Data Contracts müssen diese Fallstricke adressieren, um Integrität und Genauigkeit sicherzustellen.

Ein häufiges Beispiel ist die 1:n-Beziehung zwischen customers und orders: Ein Kunde kann mehrere orders haben. In so einem Fall ist eine Bestellung nur gültig, wenn sie eine gültige customer_id im customers-Dataset enthält.

Dieser Constraint, eine Referenzintegritätsbedingung, stellt sicher, dass Beziehungen zwischen Entitäten korrekt abgebildet sind.

Service Level Agreements (SLAs) in Data Contracts

SLAs sind eine zusätzliche Ebene von Datenqualitätschecks, die sich über Data Contracts umsetzen lassen.

SLAs beziehen sich auf Datenaktualität.

Da Datenmodelle regelmäßig mit neuen Daten aktualisiert werden, können SLAs Checks für den spätesten Zeitpunkt enthalten, zu dem neue Daten erwartet werden, oder die maximal zulässige Verzögerung. In dbt lässt sich das zum Beispiel über Freshness-Tests erreichen:

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1

Angenommen, wir wollen einen Bericht zu den gestrigen Fakten erstellen. Dann müssen wir sicherstellen, dass diese Daten existieren. Es wäre ungewöhnlich, mehrere Tage lang keine neuen Bestellungen zu sehen.

Im Beispiel unten testen wir unser Dataset auf unerwartete Verzögerungen bei Bestellungen über die Testkonfiguration in dbt. So kannst du den Test mit einem spezifischen Namen auswählen und referenzieren.

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"

Mit einem eigenen Namen steuerst du vollständig, wie der Test in Logmeldungen und Metadaten-Artefakten erscheint.

Ähnlich gilt in Echtzeitpipelines, dass Daten in der Regel nur wenige Stunden alt sein dürfen. SLAs sind besonders wichtig für Stream-Processing-Anwendungen, in denen Daten nahezu in Echtzeit mit Minuten- oder sogar Sekundenlatenz verarbeitet werden.

In Streaming-Apps wollen wir die maximal zulässige Verspätung spät eintreffender Events sowie Metriken wie Mean Time Between Failures (MTBF) und Mean Time to Recovery (MTTR) prüfen. Die Umsetzung erfordert eine sorgfältige Incident-Erfassung und das Auslesen relevanter Daten aus Monitoring- und Incident-Management-Tools wie PagerDuty, Datadog und Grafana.

Data-Governance-Verträge

Der korrekte Umgang mit personenbezogenen Daten (PII) ist integraler Bestandteil der Datentransformation. Für viele Unternehmen ist es entscheidend, dass diese Datasets mindestens DSGVO-konform sind und Datenschutzvorgaben wie HIPAA oder PCI DSS einhalten.

Data-Governance-Verträge stellen sicher, dass angemessene Richtlinien zur Pseudonymisierung oder Datenmaskierung bestehen. 

Sieh dir den folgenden dbt-Code an. Als tests durchgesetzte Verträge verlangen, dass user_email ein SHA256-Hash (maskiert) ist:

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matching

Andererseits wollen wir für andere Tabellen vielleicht Pattern Matching erzwingen. Im Beispiel unten muss das Feld transaction_reference dem Muster [“TRX-%”, “%-2023”] folgen:

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: any

Data-Governance-Verträge sind auch hilfreich, wenn sie Spalten mit sensiblen Daten, Metadaten (Datenverantwortliche usw.) und Nutzerrollen enthalten, die Zugriff auf ein Datenprodukt haben.

Zum Beispiel können wir mit dem meta-Feld in dbt die Eigentümerschaft und die Entwicklungsphase unseres Datenmodells angeben:

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: true

Das meta-Feld erlaubt es, Metadaten für eine Ressource zu setzen. Diese werden in die von dbt erzeugte manifest.json kompiliert und sind in der automatisch generierten Dokumentation sichtbar. 

Wir können Pakete wie dbt-checkpoint nutzen, um dies während des Pull-Requests zu prüfen und sicherzustellen, dass Pflichtfelder in den Metadaten vorhanden sind. Der Hook schlägt fehl, wenn ein Modell (aus Manifest oder YAML-Dateien) die geforderten Meta-Keys nicht hat.

Die meta-Keys des Modells müssen in der YAML-Datei oder im Manifest stehen.

Muster für die Implementierung von Data Contracts

Vertragsvalidierung kann in Streaming-Datenpipelines (pro Zeile) vor der Aufnahme und danach — an der Quelle (Schicht des Quelldatenmodells) — erfolgen.

Wenn wir Daten „as is“ aufnehmen, wirkt die Validierung wie ein Transformationsschritt: Vertragsregeln werden durchgesetzt und ungültige Daten herausgefiltert, z. B. in eine dedizierte View oder Tabelle zur weiteren Untersuchung.

Validierungschecks können auch nachträglich angewendet werden, wenn Daten direkt in einen Raw Data Lake geladen werden.

Der Hauptvorteil der Validierung von Data Contracts in Echtzeit ist die Möglichkeit, ungültige Datensätze zu filtern, bevor sie ihr Ziel erreichen — einen Data Lake oder ein Data Warehouse. Dieser Ansatz ist verbreitet in ereignisgetriebener oder Echtzeitverarbeitung wie bei Change Data Capture (CDC). Dabei werden bestimmte Aspekte des Vertrags geprüft, während die Daten durch die Pipeline fließen.

Tools für Data Contracts

Die Data-Community erkennt zunehmend das Potenzial von Data Contracts, einem sich rasant entwickelnden Bereich des Data Engineerings. Es gibt bereits viele Tools, einige davon noch in den Anfängen. dbt kann als universelles Framework für Data Contracts gelten.

Ähnliche Verträge lassen sich mit Googles Dataform auf der Quellschicht (Quelldatenmodell) umsetzen, also wenn die Daten erfolgreich in unser Data Warehouse geladen wurden. Dafür eignen sich einfache Zeilenbedingungen. 

Betrachte dieses Beispiel. Es wendet bestimmte Zeilenbedingungen auf unsere Tabelle an:

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …

Unten folgt ein weiteres Beispiel für die Umsetzung von Data Contracts mit Soda.io, einem spezialisierten Data-Quality-Framework:

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0

Über die Alert-Einstellungen kannst du festlegen, dass ein Check eine Warnung statt eines Fehlers ausgibt. Ein Soda-Scan führt die im Vertrag definierten Checks aus, prüft die YAML-Datei oder Inline-Aufrufe im Code und liefert für jeden Check ein Ergebnis: pass, fail oder error.

Nach meiner Erfahrung ist die Einführung von Data Contracts in vielen Unternehmen noch fragmentiert. Das hängt u. a. von Pipeline-Designmustern (Batch oder Echtzeit), der Datenspeicherung und -serialisierung sowie den verwendeten Systemen zur Speicherung und Verarbeitung ab.

Die Umsetzung von Data Contracts richtet sich nach Geschäftsanforderungen und -logik.

Great Expectations, eine Python-Bibliothek, kann für semantische Data Contracts eingesetzt werden. Installation via pip: pip install great_expectations. 

Nach great_expectations init geht es weiter mit der Datenvalidierung:

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:

Das folgende Snippet zeigt, wie du eine Datenprüfung für die Spalte price definierst:

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},

Best Practices für Data Contracts

Es gibt kein Patentrezept, denn der Erfolg hängt stark von den Geschäftsanforderungen ab. Damit Data Contracts wirksam sind, befolge diese zentralen Empfehlungen:

• Skalierbarkeit: Implementiere Mechanismen für Erweiterbarkeit (z. B. on_schema_change: append) und Versionierung, um Vertragskonditionen anpassen zu können, ohne bestehende Integrationen zu stören. Denke Data Contracts von Anfang an zukunftsfähig und skalierbar. So passen sie sich wandelnden Anforderungen und Wachstum an.
• Klare Regeln: Formuliere einfach und präzise, um Missverständnisse zu vermeiden. Der Vertrag sollte so geschrieben und benannt sein, dass alle Beteiligten ihn verstehen — unabhängig vom technischen Hintergrund.
• Zusammenarbeit: Eine gemeinsame Erarbeitung sorgt für ein ganzheitliches Verständnis der Anforderungen. Beziehe beim Erstellen von Data Contracts Producer, Data Engineers, Data Scientists sowie Fachbereiche, IT, Legal und Compliance ein.
• Metadaten: Stelle ausführliche Dokumentation und Metadaten bereit. Detaillierte Beschreibungen, Felddefinitionen, Validierungsregeln und weitere Hinweise unterstützen Anwendung und Wartung des Vertrags.
• Regelmäßige Reviews: Ein strukturierter Prozess für Monitoring und Updates hält den Vertrag aktuell, richtet ihn an neuen Geschäftsanforderungen aus und berücksichtigt geänderte Regularien.

Fazit

Zuletzt hat sich die Verantwortung für Daten stärker in die Fachdomänen verlagert: Domain-Teams verantworten ihre Datenprodukte. Dadurch mussten Organisationen Erwartungen an Datenqualität neu definieren — formalisiert über Data Contracts.

Semantische Validierungen stellen sicher, dass Daten logisch konsistent sind und zur Business-Logik passen. Sie helfen, Pipelines auf Ausreißer bei Werten, Lineage und referenzieller Integrität zu prüfen. Unzureichende Referenzintegrität führt leicht zu fehlenden oder unvollständigen Daten und ist daher besonders relevant. 

Data-Governance-Verträge lassen sich auch in CI/CD-Pipelines einbinden und sind sehr hilfreich, wenn sie sensible Spalten, Metadaten (Datenverantwortliche usw.) und Nutzerrollen mit Zugriffsrechten auf ein Datenprodukt kenntlich machen. 

Die Metadaten eines Modells — zusammen mit weiteren vom Entwickler vorgegebenen Pflichtfeldern — unterstützen das Monitoring von Ressourcenverbrauch und Performance. 

Service Level Agreements (SLAs) innerhalb von Data Contracts definieren konkrete Zusagen zu Datenaktualität, Vollständigkeit und Fehlerbehebung.

Data Contracts sind ein Kernbaustein moderner Datenmodellierung und helfen, eine fehlertolerante und skalierbare Datenplattform aufzubauen. Die Behebung von Datenqualitätsproblemen kann teuer werden. Gerade für Enterprise-Unternehmen wird es immer wichtiger, den Return on Investment (ROI) aus Daten zu maximieren, indem bestehende Tools zur Vertragsvalidierung gezielt eingesetzt werden.