Data Quality

Einfach erklärt

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

Die 6 Dimensionen:

Dimension	Frage	Metrik
Vollständigkeit	Fehlen Werte?	Anteil vorhandener Werte
Genauigkeit	Sind Werte korrekt?	Anteil plausibler oder validierter Werte
Konsistenz	Stimmen Quellen überein?	Abgleich über Quellen
Aktualität	Wie alt sind Daten?	Datenalter relativ zum Bedarf
Einzigartigkeit	Gibt es Duplikate?	Anteil eindeutiger Datensätze
Validität	Entsprechen Werte dem Format?	Anteil formatvalider Werte

Technischer Deep Dive

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

Ansatz	Beispiel	Wirkung
Reaktiv: Cleansing	Duplikate entfernen, Formate korrigieren	Symptome beheben, wiederkehrender Aufwand
Präventiv: Validierung am Eingang	Pflichtfelder und Formate beim Erfassen erzwingen	Fehler entstehen gar nicht erst
Präventiv: Ursachenanalyse	Warum liefert Quelle X unvollständige Daten?	Nachhaltig, erfordert Prozessänderung

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.