Datenqualitäts-Metriken: messen, was gesund ist

«Du kannst nicht reparieren, was du nicht messen kannst.» Genau dasselbe gilt für Datenqualität: Ohne Metriken, also ohne KPIs oder andere Indikatoren, weisst du nie, ob deine Daten gesund und verlässlich genug sind, dass Stakeholder darauf bauen können. Diese Seite fasst zusammen, wie man Datenqualität messbar macht.

1. 📉 Data Downtime als Leitgrösse

Ein nützlicher Sammelbegriff ist Data Downtime: Zeiträume, in denen deine Daten unvollständig, fehlerhaft, veraltet oder anderweitig ungenau sind. Statt «gute» und «schlechte» Daten nur zu fühlen, misst du die Zeit, in der den Daten nicht zu trauen ist, ganz analog zur Uptime eines Servers.

Fünf Kernfragen spannen das Feld auf:

• Sind die Daten aktuell (up-to-date)?
• Sind die Daten vollständig?
• Liegen die Felder im erwarteten Wertebereich?
• Ist die Null-Rate höher oder tiefer als sie sein sollte?
• Hat sich das Schema geändert?

Jede dieser Fragen lässt sich in eine konkrete Zahl giessen und über die Zeit beobachten.

2. 🏬 Woher die Metriken kommen

Die Antworten stecken in den Datenassets selbst: Data Warehouses, Data Lakes und den Transformationsschichten dazwischen. Ein Warehouse ist durch seinen strukturierten Inhalt und eine «Schema-on-write»-Architektur charakterisiert, das Schema steht also schon beim Schreiben fest. Genau das macht es zur dankbaren Quelle für Metriken: Du kannst Tabellen und Spalten gezielt abfragen und gegen Erwartungen prüfen.

Beispiel: Webshop

Stell dir den Bestelltisch eines Webshops vor. Eine simple Qualitätsmetrik ist die Null-Rate der Spalte bezahlt_am: Schiesst sie über Nacht von 2 % auf 30 %, ist entweder der Zahlungs-Import kaputt oder ein Upstream-Schema hat sich verschoben. Du siehst das Problem als Zahl, bevor das Reporting falsche Umsätze meldet.

3. ⚙️ Skalierung: Metriken brauchen eine Pipeline

Eine Handvoll Tabellen prüft man von Hand. Bei vielen Tabellen und grossen Datensätzen wird es knifflig: Du musst Aufrufe bündeln (Batching), Queries für den Massstab optimieren, deduplizieren, die verschiedenen Schemas normalisieren und all diese Messwerte in einem skalierbaren Store ablegen, damit sie auswertbar bleiben. Praktisch heisst das: Du baust eine eigene Daten-Pipeline, die du betreibst, aktualisierst und über die Zeit pflegst. Datenqualitäts-Monitoring ist also kein einmaliges Skript, sondern Infrastruktur.

Analogie: Bibliothek

Eine Bibliothek prüft die Qualität ihres Bestands nicht, indem jemand alle Regale einzeln durchgeht. Sie führt einen Index und ein Eingangsbuch (ein Append-only-Log) und kontrolliert anhand dieser Aufzeichnungen, ob Bücher fehlen, falsch einsortiert oder doppelt erfasst sind. Genauso misst die Pipeline Qualität über Metadaten statt über das wiederholte Durchforsten der Rohdaten.

4. 🧩 Über den ganzen Stack hinweg

Datenqualität endet nicht am Warehouse. Daten entstehen weiter oben (operativ) und werden weiter unten ausgewertet (analytisch). Wer nur das Warehouse misst, sieht Probleme erst spät. Sinnvolles Monitoring zieht sich daher über mehrere Stationen des Stacks, von der Quelle bis zum Dashboard. Die Unterscheidung der Datenarten dahinter ist ein eigenes Thema, siehe Operationale vs. analytische Daten.

📚 Weiterführende Links & Quellen

• Operationale vs. analytische Daten (wo im Stack die Daten entstehen und gemessen werden)
• Buch: Data Quality Fundamentals von Barr Moses, Lior Gavish, Molly Vorwerck (O’Reilly), Kapitel zu Data Downtime und Metriken (Quelle dieser Notiz, vgl. S. 17 zur Warehouse-Architektur)
• Wikipedia: Datenqualität