Data Quality

Data Quality im Überblick

Data Quality misst, wie gut Daten für ihren Zweck geeignet sind.

Die 6 Dimensionen:

Technisch betrachtet

Data Quality Score

def calculate_dq_score(df):
    scores = {
        'completeness': 1 - df.isnull().mean().mean(),
        'uniqueness': 1 - df.duplicated().mean(),
        'validity': validate_formats(df)
    }
    return sum(scores.values()) / len(scores)

Monitoring

# Beispiel für automatisches Data-Quality-Monitoring
checkpoint = gx.Checkpoint(
    name="orders_quality_check",
    data_context=context,
    validations=[
        {"batch_request": batch, "expectation_suite_name": "orders"}
    ]
)

# In Orchestrierung oder Pipeline-Monitoring einbinden
results = checkpoint.run()
if not results.success:
    alert_data_team(results)

Data Quality ist relativ zum Zweck

„Fitness for Use” ist das zentrale Konzept: Dieselben Daten können für einen Zweck ausreichend und für einen anderen unbrauchbar sein. Eine Kundenliste mit veralteten Telefonnummern ist für eine Umsatzanalyse völlig in Ordnung, für eine Callcenter-Kampagne aber wertlos. Deshalb beginnt jede Data-Quality-Initiative mit der Frage: Wer nutzt diese Daten wofür, und welche Dimension ist dafür kritisch? Pauschale Qualitätsziele („99 % Vollständigkeit über alle Tabellen”) verfehlen meist den Punkt.

Reaktiv vs. präventiv

Die Faustregel: Je früher ein Fehler abgefangen wird, desto günstiger ist er. Ein Tippfehler im Eingabeformular kostet eine Korrektur; derselbe Fehler, der durch Pipelines in Reports und ML-Modelle propagiert, kostet ein Vielfaches – plus das Vertrauen der Datennutzer.

Data Quality für Machine Learning

ML-Systeme stellen zusätzliche Anforderungen, die klassische Dimensionen nicht abdecken:

• Label-Qualität: Falsch gelabelte Trainingsbeispiele setzen eine Obergrenze für die erreichbare Modellgüte – oft wirksamer verbessert als der Modelltyp.
• Verteilungsstabilität: Auch formal valide Daten können driften. Wenn sich die Verteilung eines Features zwischen Training und Produktion verschiebt (Data Drift), degradiert das Modell schleichend.
• Train/Serving-Konsistenz: Features müssen im Training und in der Inferenz identisch berechnet werden (Training-Serving Skew) – ein häufiger, schwer sichtbarer Fehler.
• Repräsentativität: Ein Datensatz kann vollständig und korrekt sein, aber wichtige Subgruppen unterrepräsentieren – das Modell versagt dann genau dort.

Typische Fehler in der Praxis

• Qualität einmalig messen statt kontinuierlich: Datenqualität ist ein Zustand, kein Projekt. Ohne Monitoring degradiert sie unbemerkt, etwa wenn ein Quellsystem sein Verhalten ändert.
• Metriken ohne Konsequenzen: Ein Dashboard mit roten Kennzahlen ändert nichts, wenn niemand für die Behebung verantwortlich ist. Jede Metrik braucht einen Owner und einen definierten Eskalationspfad.
• Alles gleich behandeln: Kritische Felder (Rechnungsbeträge, IDs) verdienen strengere Checks als Kommentarfelder. Priorisierung nach Geschäftsauswirkung spart Aufwand.
• Nur Spalten prüfen, nicht Beziehungen: Viele Fehler zeigen sich erst im Zusammenhang – verwaiste Fremdschlüssel, inkonsistente Summen zwischen Detail- und Aggregattabellen oder Zeitreihen mit Lücken.