1. Warum Data Quality zaehlt
Jede Data Crew hat eine Horrorstory: Ein Dashboard zeigt +40% Umsatz, der CEO kuendigt es an, dann bemerkt jemand einen doppelten Join. Data Quality bedeutet nicht Perfektion, sondern Probleme abzufangen, bevor sie Entscheider sehen.
Die Kosten schlechter Daten
Gartner schaetzt, dass schlechte Daten im Schnitt $12.9 Millionen pro Jahr kosten. Noch schlimmer ist der Vertrauensverlust. Wenn Stakeholder dem Data Stack nicht trauen, nutzen sie ihn nicht mehr und treffen Bauch-Entscheidungen.
Data Quality liefert drei Ergebnisse:
Trust
Stakeholder nutzen Daten mit Vertrauen, weil sie validiert wurden. Kein "lass mich das nochmal pruefen".
Speed
Probleme an der Quelle finden statt Dashboards debuggen. Minuten statt Stunden.
Scale
Automatisierte Checks skalieren mit deinen Daten. Manuelle Spot-Checks nicht, wenn du 500 Tabellen hast.
Aus Erfahrung
Erfolgreiche Teams behandeln Data Quality wie Unit Tests: Du shipst keinen Code ohne Tests und keine Daten ohne Checks. Es ist keine Last, sondern Versicherung.
2. Die sechs Dimensionen von Data Quality
Nicht jede Qualitaetsluecke ist gleich. Diese sechs Dimensionen geben dir ein Raster, was schiefgehen kann und was du testen solltest.
Vollstaendigkeit
Ist alles da?
Test: Null-Rate bei Pflichtfeldern = 0%
Genauigkeit
Spiegelt es die Realitaet?
Test: Gegen Quellsysteme gegenpruefen
Konsistenz
Gleiches Format ueberall?
Test: Datumsformate, Enums, Namenskonventionen
Aktualitaet
Frisch genug?
Test: max(updated_at) innerhalb SLA
Validitaet
Erfuellt es Business-Regeln?
Test: Status in ('active', 'inactive'), price > 0
Eindeutigkeit
Keine unerwuenschten Duplikate?
Test: Primaerschluessel eindeutig, keine doppelten Orders
| Dimension | Frage | Typischer Fehler |
|---|---|---|
| Vollstaendigkeit | Ist alles da? | Nulls in Pflichtfeldern |
| Genauigkeit | Ist es korrekt? | Stale Cache, falsche Joins |
| Konsistenz | Ist es ueberall gleich? | Unterschiedliche Datumsformate |
| Aktualitaet | Ist es frisch genug? | Pipeline-Delays, SLA-Verletzung |
| Validitaet | Macht es Sinn? | Negative Preise, Future Dates |
| Eindeutigkeit | Gibt es Duplikate? | Duplikate durch Fan-Out-Joins |
3. Wo du in der Pipeline testen solltest
Das "test at the boundaries" Prinzip: Validiere Daten, wenn sie reinkommen und wenn sie rausgehen. So erwischst du Upstream-Issues und Transformations-Bugs.
Stufe 1: Source Validation (Ingestion)
Pruefe Daten beim Eintreffen aus Fremdsystemen. Erste Verteidigungslinie gegen Upstream-Probleme.
Was pruefen:
- • Schema passt (keine neuen/fehlenden Spalten)
- • Zeilenanzahl im erwarteten Bereich
- • Pflichtfelder nicht null
- • Daten puenktlich angekommen (Freshness)
Stufe 2: Transformationstests
Pruefe den Output deiner Transformationen. Faengt Logik-Bugs in SQL/Python.
Was pruefen:
- • Primaerschluessel eindeutig (kein Fan-Out)
- • Aggregationen summieren korrekt
- • Business-Regeln enforced
- • Referential Integrity bleibt erhalten
Stufe 3: Output Validation (Delivery)
Pruefe Daten, bevor sie Dashboards und Konsumenten erreichen. Letzte Chance, Fehler abzufangen.
Was pruefen:
- • Metriken im erwarteten Korridor
- • Keine Anomalien vs. Historie
- • Kritische Dashboards haben Daten
- • SLAs werden eingehalten
Pro Tipp
Fail fast, fail loud
Lieber faellt eine Pipeline um 6 Uhr mit klarer Fehlermeldung, als stillschweigend schlechte Daten zu produzieren, die im Board-Meeting auffallen. Konfiguriere Tests so, dass schlechte Daten gestoppt werden.
4. Was du testen solltest (praktische Checks)
Starte mit diesen schnellen Checks. Sie fangen 80% der Probleme mit 20% Aufwand.
Row Count Bounds
Pruefe, ob die Zeilenanzahl im erwarteten Bereich liegt (z. B. 900K-1.1M). Faengt abgeschnittene Loads und doppelte Explosionen.
expect_table_row_count_to_be_between(min=900000, max=1100000)Null-Rate Schwellwerte
Pflichtfelder sollten 0% Nulls haben. Optionale Felder sollten stabile Null-Raten haben (alert, wenn sich die Rate >10% aendert).
expect_column_values_to_not_be_null(column="customer_id")Unique Constraints
Primaerschluessel muessen eindeutig sein. Faengt den gefuerchteten Fan-Out-Join.
expect_column_values_to_be_unique(column="order_id")Freshness SLA
Daten duerfen nicht aelter sein als deine SLA. Pruefe max(updated_at) oder Partition.
expect_column_max_to_be_between(column="updated_at", min=now()-24h)Value Ranges
Numerische Felder muessen in gueltigen Grenzen liegen. Revenue > 0, Alter 0-150, Prozent 0-100.
expect_column_values_to_be_between(column="price", min=0, max=100000)Enum Validation
Status-Felder nur mit erwarteten Werten. Faengt Typos und unerwartete States.
expect_column_values_to_be_in_set(column="status", value_set=["active", "inactive", "pending"])Beispiel: dbt schema test
# models/marts/orders.yml
version: 2
models:
- name: orders_mart
description: "Order-level facts for analytics"
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- not_null
- relationships:
to: ref('dim_customers')
field: customer_id
- name: order_total
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0
max_value: 10000005. Alerting ohne Alert Fatigue
Das groesste Risiko beim Data-Quality-Monitoring ist nicht, etwas zu verpassen, sondern Alert Fatigue. Zu viele False Positives fuehren dazu, dass niemand mehr schaut. So machst du es richtig.
Mach das
- • Alerts tiern: P1 (Pager), P2 (Slack), P3 (E-Mail-Digest)
- • Anomalieerkennung nutzen bei Metriken mit natuerlicher Varianz
- • Kontext in Alerts: was kaputt, Impact, Runbook-Link
- • Schwellwerte passend setzen auf Basis Historie
- • Monatlich reviewen und Feinjustieren
Vermeide das
- • Pager bei jedem fehlgeschlagenen Test
- • Hart codierte Schwellwerte ohne Anpassung
- • Alerts ohne klaren Owner
- • "Flaky" Tests ignorieren statt fixen
- • Keine Runbooks fuer typische Fehler
Alert-Severities
P1 - Page Now
Daten sind in Prod-Dashboards falsch. Executives betroffen. Revenue-Impact.
P2 - Slack Alert
Data Quality degradiert, aber nicht kritisch. Fix in 4h.
P3 - Daily Digest
Kleine Issues, Info. Review im naechsten Sprint.
Aus Erfahrung
Ich war in einem Team mit 200+ Data-Quality-Alerts pro Tag. Alle ignorierten sie. Wir haben auf 15 hoechst-signal Alerts reduziert und ploetzlich wurden Probleme am selben Tag gefixt. Weniger ist mehr.
6. Tools fuer Data Quality
| Tool | Am besten fuer | Ansatz | Pricing |
|---|---|---|---|
| dbt tests | Transformationstests | Schema + Custom Tests | Free (OSS) |
| Great Expectations | Umfassende Validierung | Expectation Suites | Free (OSS) |
| Monte Carlo | Data Observability | ML Anomaly Detection | Enterprise |
| Soda | Data Monitoring | SodaCL Checks | Free Tier + Paid |
| elementary | dbt-native Observability | Anomaly Detection | Free (OSS) |
Proaktives Testing
Du definierst Regeln. Tests laufen bei jedem Pipeline-Run. Explizit und deterministisch.
Tools: dbt tests, Great Expectations, Soda
Anomalieerkennung
ML lernt, was "normal" ist und alertet bei Abweichungen. Findet Unknown Unknowns.
Tools: Monte Carlo, elementary, Bigeye
7. Best-Practice-Checkliste
Test at the boundaries
Validiere beim Ingest (Upstream) und bei Delivery (Transformation). Fange Probleme frueh.
Starte mit High-Value-Tabellen
Fokussiere zuerst Tabellen fuer Executive-Dashboards und kritische Reports. Wert zeigen, dann erweitern.
Regeln + Anomalieerkennung nutzen
Regeln finden bekannte Probleme (Nulls, Duplikate). Anomalieerkennung findet Unbekanntes (ploetzliche Volumenspruenge).
Alerts tiern
Nicht jeder Fail braucht einen Pager. P1 fuer Revenue-Impact, P2 fuer degradiert, P3 Info.
Runbooks in Alerts
Jeder Alert verlinkt eine Doku: Bedeutung, Investigation, Fix-Schritte.
Qualitaetsmetriken tracken
Messe: Test-Pass-Rate, Mean Time to Detection, Mean Time to Resolution. Systematisch verbessern.
Quality in CI/CD
Tests bei jedem PR. Blocke Merges, die Data Quality brechen. Shift left.
Monatlich reviewen
Schwellwerte driften. Datenmuster aendern sich. Monatliche Reviews halten Tests relevant.
Pro Tipp
Der "Wuerde ich Geld wetten?" Test
Bevor du eine Metrik veroeffentlichst, frage: "Wuerde ich $1,000 darauf wetten, dass die Zahl korrekt ist?" Wenn nein, brauchst du mehr Tests. Data Quality geht um Vertrauen, und Vertrauen kommt aus Validation.
8. Haeufige Fragen
Was sind die wichtigsten Dimensionen von Data Quality?
Die sechs Dimensionen: Vollstaendigkeit (keine fehlenden Werte), Genauigkeit (richtige Werte), Konsistenz (gleiches Format), Aktualitaet (frisch genug), Validitaet (Business-Regeln) und Eindeutigkeit (keine Duplikate).
Wie misst man Data Quality?
Automatisierte Tests: Zeilenanzahl vs. Erwartung, Null-Raten je Spalte, Unique-Verletzungen, Freshness, Schema Drift und Business-Regeln. Tracke die Metriken ueber Zeit und setze Schwellwerte fuer Alerts.
Welche Tools eignen sich am besten?
Beliebte Tools: Great Expectations, dbt tests, Monte Carlo, Soda und elementary. Waehle nach Stack und ob du proaktiv testen oder Anomalien finden willst.
Vor oder nach Transformationen testen?
Beides. Quelle vor Transformationen pruefen (fail fast). Outputs nach Transformationen validieren. So erwischst du Probleme am Ingest und bei Delivery.
Dokumentiere deine Data-Quality-Strategie
Erstelle klare Diagramme deiner Pipelines mit markierten Qualitaets-Checkpoints. Zeige Stakeholdern, wo und wie validiert wird.
Verwandte Guides
Data Pipeline Documentation
Pipelines so dokumentieren, dass neue Engineers sie am ersten Tag debuggen koennen
Data Lineage Best Practices
Daten von der Quelle bis zum Dashboard verfolgen
Data Contracts
Data-Quality-SLAs mit formalen Contracts definieren
Medallion Architecture
Data Quality mit Bronze, Silver, Gold layern
ML Pipeline Architecture
Quality Monitoring fuer ML Feature Pipelines