+45 XP

Shift-left Data Quality: Governance in der Engineering-Pipeline verankern

Fehler in der Datenqualität haben eine Geografie: Sie entstehen fast immer an der Quelle.

Ein Report zeigt falsche Umsatzzahlen. Die Untersuchung führt zurück über das Data Warehouse, die ETL-Pipeline, die Staging-Datenbank, die API-Integration und schließlich zu einem Quellsystem, das seit sechs Wochen fehlerhaft formatierte Daten sendet. Sechs Wochen schlechte Daten in Produktion. Sechs Wochen Entscheidungen auf Basis falscher Informationen.

Das Prinzip „Shift-left“ kommt aus dem Software Engineering: Defekte so früh wie möglich im Entwicklungsprozess abfangen, weil die Behebung eines Bugs in Produktion 100-mal teurer ist als der Fund im Code Review. Auf Daten übertragen: Qualitätsprobleme an der Quelle abfangen, nicht im Nachhinein.

Wie Shift-left Data Quality aussieht

Im Quellsystem: Validierungsregeln, die in der Anwendung eingebaut sind, die die Daten erzeugt. Wenn ein Feld nicht null sein darf, erzwingt die Anwendung das, die Data-Pipeline sieht nie Null-Werte, weil sie nie ins System gelangen.

Auf der Ingestion-Ebene: Data-Quality-Checks laufen sofort, wenn Daten in Ihre Infrastruktur eintreten. Passt das Schema nicht zum Contract, stoppt die Pipeline. Fällt die Vollständigkeit unter das SLA, wird ein Alert ausgelöst. Great Expectations und Soda führen hier Prüfungen im Assertion-Stil durch (Great Expectations ist 2024 auf die GX 1.0 API umgestiegen, ältere Expectation-Syntax aus Tutorials passt daher möglicherweise nicht zur aktuellen Doku). Monte Carlo arbeitet neben diesen Tools, hat aber eine andere Rolle: Data Observability, also Monitoring von Freshness, Volumen und Schema-Drift über Ihr Warehouse hinweg und Alerting, wenn etwas auffällig aussieht, statt eine Pipeline auf Basis einer festen Regel zu blockieren. Beachten Sie, dass Monte Carlo 2024 den kommerziellen Teil von Great Expectations übernommen hat, das Open-Source-Projekt läuft aber weiter.

Auf der Transformationsebene: dbt (data build tool) bringt Tests mit: not-null-Tests, unique-Tests, Tests auf referenzielle Integrität, accepted-value-Tests, eigene SQL-Tests. Jedes dbt-Modell sollte Tests haben. Ein dbt run mit fehlgeschlagenen Tests sollte nicht in Produktion deployt werden. Viele Organisationen lassen ihre dbt-Tests in CI/CD-Pipelines laufen, keine ungetestete Transformation erreicht das Data Warehouse.

Auf der Serving-Ebene: Dashboards und Reports, die Daten für Business-User bereitstellen, sollten Indikatoren zur Datenqualität enthalten: „Letzte Aktualisierung: vor 2 Stunden. Quality Score: 94 %. Bekannte Probleme: 0.“

Data Contracts: The Key to Data Quality - with Chad Sanderson

Watch on YouTube

Wissenscheck

1. Was ist das Kernprinzip hinter Shift-left Data Quality?

2. Warum ist es laut Lektion besser, ein Datenqualitätsproblem an der Quelle abzufangen als in einem Produktions-Report?

3. Was ist auf der Transformationsebene die empfohlene Best Practice in Bezug auf dbt-Tests und Deployment?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die korrekt beschreiben, wo Shift-left-Kontrollen für Datenqualität wirken.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Praktiken, die dafür stehen, Datenqualität in eine CI/CD-Pipeline einzubauen.

Wählen Sie alle richtigen Antworten aus.

Datenqualität in CI/CD einbauen

Der Goldstandard für Shift-left Data Quality: Data-Quality-Tests laufen in CI/CD-Pipelines, fehlgeschlagene Builds werden vom Deployment ausgeschlossen, und Qualitätsmetriken werden im selben Dashboard wie Engineering-Metriken verfolgt.

Das erfordert:

1. Testabdeckung für Daten: Jede kritische Pipeline hat dokumentierte Qualitätstests. Als Metrik verfolgt: „Anteil der Data Assets mit Qualitätstests: 67 %.“ Der CDO sollte ein Ziel setzen, etwa 90 %, und es quartalsweise verfolgen.

2. Automatisierte Validierung beim Merge: Wenn ein Data Engineer einen Pull Request einreicht, der eine Pipeline ändert, laufen automatisierte Tests gegen eine Stichprobe der Produktionsdaten. Schema-Änderungen, die Downstream-Contracts brechen würden, lassen den Build vor dem Merge fehlschlagen.

3. Quality Gates für die Promotion: Daten gehen nicht von Staging in Produktion, ohne Qualitätsprüfungen zu bestehen. Im Software Engineering ist das Standard (man deployt keinen kaputten Code). Im Data Engineering sollte es das ebenfalls sein.

Das Minerva-Framework von Airbnb

Airbnb hat ein internes Framework namens Minerva gebaut, um ein konkretes Problem zu lösen: Hunderte Analysten definierten dieselben Metriken unterschiedlich, was Inkonsistenz erzeugte und das Vertrauen in Daten untergrub.

Minerva ist ein Metrics Layer, ein zentrales Repository, in dem Business-Metriken einmal definiert werden (vom Business, gemeinsam mit dem Datenteam) und konsistent über alle BI-Tools, Data-Science-Modelle und Experimente hinweg genutzt werden.

Der entscheidende Punkt: Minerva verlagert die Frage „Was bedeutet diese Metrik?“ von der Ad-hoc-Einschätzung eines Analysten zu einer governten, versionierten Definition. Wenn sich eine Business-Metrik ändert (eine neue Rückgaberegelung verändert, wie Umsatz gezählt wird), wird die Definition an einer Stelle aktualisiert und fließt zu allen Konsumenten.

Das ist Shift-left Data Quality, angewandt auf semantische Konsistenz statt auf technische Qualität. Es ist eines der wirkungsvollsten Data-Governance-Investments von Airbnb, und das Muster ist inzwischen weit verbreitet. Der dbt Semantic Layer läuft auf MetricFlow (dbt Labs hat Transform und dessen MetricFlow-Engine 2023 übernommen und integriert), Looker hat seine Measures, und Cube bietet einen eigenständigen Metrics Layer. Alle lösen dasselbe Problem wie Minerva.

Was CDOs verfolgen sollten

  • Testabdeckung: % der Data Assets mit automatisierten Qualitätstests
  • Incident-Rate der Data Pipelines: Anzahl der Pipeline-Fehler pro Woche, im Trend
  • Mean Time to Detection (MTTD): Wie schnell Datenqualitätsprobleme erkannt werden
  • Mean Time to Resolution (MTTR): Wie schnell erkannte Probleme behoben werden
  • Einhaltung der Data-Freshness-SLA: % der Datensätze, die ihr Freshness-SLA erfüllen

Monatlich verfolgt zeigen diese Metriken, ob Ihr Shift-left-Programm funktioniert.

Key Takeaways

  • Schlechte Daten gelangen meist an der Quelle ins System, die günstigste Stelle zum Abfangen ist also upstream, nicht im Warehouse.
  • Nutzen Sie für jede Ebene das passende Tool: Assertion-Checks (Great Expectations auf der GX 1.0 API, Soda) fangen bekannte Regelverstöße ab, Observability-Tools (Monte Carlo) machen Anomalien sichtbar, an die Sie beim Testen nicht gedacht haben.
  • dbt-Tests gehören in CI/CD, fehlgeschlagene Builds werden von der Produktion ausgeschlossen, dieselbe Disziplin, die Softwareteams längst auf Code anwenden.
  • Ein Metrics Layer (Minerva von Airbnb, der dbt Semantic Layer auf MetricFlow, Looker, Cube) governt, was eine Metrik bedeutet, damit Umsatz überall gleich gezählt wird.
  • Verfolgen Sie MTTD, MTTR, Testabdeckung, Incident-Rate und Einhaltung der Freshness-SLA monatlich, um zu wissen, ob das Programm tatsächlich funktioniert.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Data Contracts zuerst auf den fünf geschäftskritischsten Datenflüssen implementieren
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.