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 fehlerhafte Daten sendet. Sechs Wochen schlechte Daten in Produktion. Sechs Wochen Entscheidungen auf Basis falscher Informationen.

Das Shift-left-Prinzip stammt aus dem Software Engineering: Fehler so früh wie möglich im Entwicklungsprozess finden, denn einen Bug in Produktion zu beheben ist 100-mal teurer, als ihn im Code Review zu finden. 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: Datenqualitätsprüfungen laufen sofort, wenn Daten in Ihre Infrastruktur gelangen. Wenn das Schema nicht zum Contract passt, stoppt die Pipeline. Wenn die Vollständigkeit unter das SLA fällt, wird ein Alert ausgelöst. Great Expectations und Soda führen hier Prüfungen im Assertion-Stil aus (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: Es ist Data Observability, überwacht Freshness, Volumen und Schema Drift über Ihr Warehouse hinweg und alarmiert, wenn etwas auffällig ist, statt eine Pipeline anhand einer festen Regel zu blockieren. Zu beachten: Monte Carlo hat 2024 den kommerziellen Teil von Great Expectations übernommen, das Open-Source-Projekt läuft weiter.

Auf der Transformationsebene: dbt (data build tool) hat eingebautes Testing: 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 führen ihre dbt-Tests in CI/CD-Pipelines aus, keine ungetestete Transformation erreicht das Data Warehouse.

Auf der Serving-Ebene: Dashboards und Reports, die Daten für Business-Nutzer 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 argumentiert die Lektion, dass es besser ist, ein Datenqualitätsproblem an der Quelle zu finden 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-Datenqualitätskontrollen 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: Datenqualitätstests laufen in CI/CD-Pipelines, fehlgeschlagene Builds werden vom Deployment ausgeschlossen, und Qualitätsmetriken werden im selben Dashboard wie die Engineering-Metriken verfolgt.

Das erfordert:

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.

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

Quality Gates für die Promotion: Daten gehen nicht von Staging in Produktion, ohne Qualitätsprüfungen zu passieren. Im Software Engineering ist das Standard (man deployt keinen kaputten Code). Im Data Engineering sollte es ebenfalls Standard 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 zu Inkonsistenz führte 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 Data Team) und über alle BI-Tools, Data-Science-Modelle und Experimente hinweg konsistent genutzt werden.

Der entscheidende Punkt: Minerva verlagert die Frage "Was bedeutet diese Metrik?" von der Ad-hoc-Einschätzung einzelner Analysten zu einer governierten, versionierten Definition. Wenn sich eine Business-Metrik ändert (eine neue Rückgaberichtlinie ä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 eine der wirkungsvollsten Data-Governance-Investitionen, die Airbnb gemacht hat, und das Muster ist heute weit verbreitet. Der dbt Semantic Layer läuft auf MetricFlow (dbt Labs hat 2023 Transform und dessen MetricFlow-Engine ü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: Zahl 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 Datasets, die ihr Freshness-SLA erfüllen

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

Key Takeaways

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

Häufige Fragen

Was bedeutet „shift-left“ für die Datenqualität?

Shift-left bei der Datenqualität heißt, Datenfehler so nah wie möglich an der Quelle abzufangen, statt sie erst in einem Report zu entdecken. Der Begriff stammt aus dem Software Engineering, wo die Behebung eines Bugs in Produktion etwa 100x mehr kostet als beim Code Review. Auf Daten übertragen bedeutet das: Validierungsregeln in der Quellanwendung, Schema-Checks bei der Ingestion, Tests bei der Transformation und Qualitätsindikatoren auf den Dashboards.

Wo entstehen Datenqualitätsprobleme in der Regel?

Fast immer im Quellsystem, nicht im Warehouse. Eine typische Untersuchung falscher Umsatzzahlen arbeitet sich rückwärts durch das Warehouse, die ETL-Pipeline, die Staging-Datenbank und die API-Integration und landet schließlich bei einem Quellsystem, das schon Wochen vorher fehlerhafte Daten geliefert hat. Diese Verzögerung ist der eigentliche Schaden: Wochen an Entscheidungen auf Basis falscher Informationen, bevor es jemandem auffällt.

Worin unterscheiden sich Great Expectations und Monte Carlo?

Great Expectations (wie auch Soda) arbeitet mit Assertion-Checks: Sie definieren eine Regel, und die Pipeline stoppt, wenn die Daten dagegen verstoßen. Monte Carlo ist Data Observability: Es überwacht Freshness, Volumen und Schema Drift im gesamten Warehouse und schlägt Alarm, wenn etwas auffällig aussieht, ohne an einer festen Regel zu blockieren. Beide ergänzen sich: Assertions fangen bekannte Verstöße ab, Observability macht Probleme sichtbar, für die Sie nie einen Test geschrieben hätten. Monte Carlo hat 2024 das kommerzielle Geschäft von Great Expectations übernommen, das Open-Source-Projekt läuft weiter.

Sollten dbt-Tests in CI/CD-Pipelines laufen?

Ja, und ein dbt-Run mit fehlschlagenden Tests darf nie in Produktion gehen. dbt bringt Tests für Not-null, Unique, referenzielle Integrität, Accepted Values und eigene SQL-Tests mit, und jedes Modell sollte welche haben. Laufen sie in CI/CD, erreicht keine ungetestete Transformation das Warehouse. Das ist dieselbe Disziplin, die Softwareteams bei Code bereits anwenden.

Welches Problem löst ein Metrics Layer wie Minerva von Airbnb?

Er löst semantische Inkonsistenz: Hunderte Analysten definieren dieselbe Kennzahl unterschiedlich, und das zerstört das Vertrauen in die Daten. Minerva ist ein zentrales Repository, in dem Business-Kennzahlen einmal definiert werden, gemeinsam von Fachbereich und Datenteam, und dann von BI-Tools, Data-Science-Modellen und Experimenten identisch genutzt werden. Ändert sich eine Geschäftsregel, wird die Definition an einer Stelle angepasst und greift überall. Der dbt Semantic Layer (auf Basis von MetricFlow), Looker Measures und Cube adressieren dasselbe Problem.

Welche Kennzahlen zeigen, ob ein Datenqualitätsprogramm tatsächlich wirkt?

Fünf, monatlich erfasst: Testabdeckung (Anteil der Data Assets mit automatisierten Qualitätstests), Pipeline-Incidents pro Woche, Mean Time to Detection (MTTD), Mean Time to Resolution (MTTR) und Einhaltung der Freshness-SLAs. Für die Testabdeckung sollte der CDO ein Ziel setzen, zum Beispiel 90 %, und es quartalsweise überprüfen. Als Trend gelesen und nicht als Momentaufnahme zeigen diese fünf Kennzahlen, ob sich die Qualität wirklich verbessert oder nur so aussieht.

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 →