Datenqualität automatisieren

In vielen Unternehmen sieht Datenqualitätssicherung heute so aus: Ein Analyst öffnet einen Report, stutzt über eine Zahl, recherchiert manuell und korrigiert den Fehler – oder, was häufiger vorkommt, bemerkt ihn nicht. Dieses Modell hat drei fundamentale Schwächen.

Reaktiv statt präventiv: Fehler werden erst entdeckt, wenn sie bereits in Reports, Dashboards oder Entscheidungsvorlagen eingeflossen sind. Der Schaden – eine falsche Prognose, eine fehlerhafte Kundensegmentierung, eine ungenaue Bestandsmeldung – ist dann bereits eingetreten.

Abhängig von Einzelpersonen: Die Qualitätskontrolle funktioniert nur, solange die Person, die die Daten kennt, verfügbar ist. Wissen über erwartete Wertebereiche, saisonale Muster und bekannte Ausnahmen ist implizit und undokumentiert. Wenn dieser Mitarbeiter das Unternehmen verlässt, geht das Qualitätswissen mit.

Nicht skalierbar: Ein Mensch kann eine Handvoll Tabellen prüfen. Bei hunderten von Datenpipelines, die täglich Millionen von Datensätzen verarbeiten, ist manuelle Prüfung physisch unmöglich. Die Lücke zwischen Datenvolumen und Prüfkapazität wächst mit jedem neuen Datenprodukt.

Die Konsequenz ist nicht, dass manuelle Prüfung überflüssig wird. Sie muss ergänzt werden durch automatisierte Mechanismen, die den Grossteil der Qualitätsprobleme erkennen, bevor ein Mensch die Daten überhaupt sieht.

Data Contracts sind das Äquivalent von API-Verträgen für Daten. Sie definieren verbindlich, welche Struktur, welche Qualität und welche Semantik ein Datensatz hat – und wer dafür verantwortlich ist.

Ein Data Contract enthält typischerweise:

• Schema-Definition: Welche Felder existieren, welche Datentypen haben sie, welche sind Pflichtfelder? Schemaänderungen müssen angekündigt und abwärtskompatibel sein – oder explizit als Breaking Change kommuniziert werden
• Qualitätsregeln: Welche Wertebereiche sind gültig? Welche Felder dürfen Null-Werte enthalten? Welche Eindeutigkeitsbedingungen gelten? Welche referenziellen Integritäten müssen eingehalten werden?
• SLA: Wann werden die Daten bereitgestellt? Welche maximale Latenz ist akzeptabel? Welche Verfügbarkeit wird garantiert?
• Ownership: Wer ist der verantwortliche Data Owner? An wen werden Qualitätsprobleme eskaliert?
• Semantik: Was bedeuten die Felder? Ein Feld namens "revenue" kann Bruttoumsatz, Nettoumsatz oder etwas ganz anderes meinen. Der Contract macht die Definition verbindlich.

Data Contracts wirken an der Schnittstelle zwischen Teams. Wenn das CRM-Team eine Kundentabelle bereitstellt und das Analytics-Team sie konsumiert, definiert der Contract die Erwartungen beider Seiten. Abweichungen werden automatisiert erkannt – nicht erst im Quartalsreport.

Der kulturelle Effekt ist ebenso bedeutsam wie der technische: Data Contracts machen Datenqualität verhandelbar und messbar. Sie verschieben die Diskussion von «Die Daten stimmen nicht» zu «Welche Qualität brauchen wir – und was kostet sie».

Datenqualitätsregeln sind nur dann wirksam, wenn sie automatisiert und in Echtzeit geprüft werden – nicht in einem monatlichen Audit, sondern bei jeder Ausführung der Pipeline.

Die Integration folgt dem Prinzip der Pipeline-nativen Validierung:

Beim Einlesen (Ingestion): Daten werden am Eintrittspunkt validiert. Stimmt das Schema? Sind Pflichtfelder gefüllt? Liegen die Werte im erwarteten Bereich? Fehlerhafte Datensätze werden isoliert, nicht verworfen – sie fliessen in eine Quarantäne-Zone zur manuellen Prüfung.

Nach der Transformation: Jede Transformation kann Qualitätsprobleme einführen. Joins können Duplikate erzeugen, Aggregationen können Null-Werte verschlucken, Typkonvertierungen können Präzision verlieren. Automatisierte Tests nach jeder Transformationsstufe stellen sicher, dass die Ausgabe den erwarteten Qualitätskriterien entspricht.

Vor der Auslieferung: Bevor Daten in ein Data Warehouse, einen Report oder ein Dashboard fliessen, durchlaufen sie eine finale Validierung gegen den Data Contract. Nur Daten, die alle Regeln erfüllen, werden freigegeben.

Frameworks wie Great Expectations, dbt Tests oder Soda Core ermöglichen es, Qualitätsregeln deklarativ zu definieren und in bestehende Pipelines zu integrieren. Die Regeln leben im Code-Repository, werden versioniert und im Code Review geprüft – wie jeder andere Teil der Codebasis.

Entscheidend ist die Frage, was bei einem Verstoss passiert. Die Optionen reichen von Logging über Alerting bis zum Abbruch der Pipeline. Die richtige Wahl hängt von der Kritikalität der Daten und den nachgelagerten Konsequenzen ab.

IT-Organisationen überwachen Server, Netzwerke und Anwendungen mit ausgereiften Monitoring-Systemen. Datenqualität wird in den meisten Unternehmen nicht überwacht. Data Observability schliesst diese Lücke.

Das Konzept überträgt die Prinzipien von Application Monitoring auf Daten und verfolgt fünf Dimensionen:

Freshness: Sind die Daten aktuell? Wenn eine Pipeline normalerweise um 6 Uhr morgens liefert und um 8 Uhr noch keine Daten eingetroffen sind, liegt ein Problem vor – unabhängig davon, ob das System selbst als gesund gemeldet wird.

Volume: Stimmt die Menge? Wenn eine Tabelle normalerweise 100.000 neue Datensätze pro Tag erhält und plötzlich nur 50.000 ankommen – oder 500.000 – ist das ein Signal, das untersucht werden muss.

Schema: Hat sich die Struktur verändert? Wenn ein Quellsystem eine Spalte umbenennt, einen Datentyp ändert oder ein Feld entfernt, bricht die nachgelagerte Pipeline – oft leise und ohne Fehlermeldung.

Distribution: Bewegen sich die Werte im erwarteten Bereich? Wenn der Durchschnittswert einer Metrik plötzlich um 40 Prozent abweicht, liegt entweder eine reale Veränderung vor – oder ein Datenfehler. Data Observability erkennt statistische Anomalien und unterscheidet sie von normaler Varianz.

Lineage: Woher kommen die Daten, und wohin fliessen sie? Wenn eine Quelltabelle fehlerhaft ist, zeigt Data Lineage, welche nachgelagerten Reports, Dashboards und Modelle betroffen sind. Ohne Lineage ist Fehleranalyse ein Blindflug.

Data Observability ist kein zusätzliches Tool, das nebenbei läuft. Sie ist ein integraler Bestandteil der Dateninfrastruktur – genauso selbstverständlich wie ein Health Check für einen Webserver.

Die schwierigsten Datenqualitätsprobleme sind die, die keine Regelverstösse produzieren. Der Wert liegt im gültigen Bereich, der Datentyp stimmt, das Schema ist intakt – und trotzdem ist der Datensatz falsch.

Beispiele:

• Ein Umsatzwert von 50.000 Euro ist plausibel. Dass er doppelt so hoch ist wie im Vormonat, weil eine Fehlbuchung im Quellsystem vorliegt, erkennt keine Schemavalidierung
• Eine Kundenadresse ist syntaktisch korrekt, aber der Kunde ist vor drei Monaten umgezogen. Die Adresse ist technisch valide, inhaltlich veraltet
• Ein Sensor meldet 22 Grad Raumtemperatur – ein plausibler Wert. Dass derselbe Sensor seit drei Tagen exakt denselben Wert meldet und offensichtlich ausgefallen ist, fällt ohne statistische Analyse nicht auf

Statistische Anomalieerkennung adressiert diese Klasse von Problemen:

Zeitreihenanalyse: Algorithmen lernen das normale Verhalten einer Metrik über Zeit – saisonale Muster, Tageszyklen, Trends – und melden Abweichungen, die über die normale Streuung hinausgehen.

Verteilungsvergleiche: Die Verteilung eines Feldes wird mit historischen Verteilungen verglichen. Wenn sich die Verteilung signifikant verschiebt, wird ein Alert ausgelöst.

Cross-Source-Validierung: Dieselbe Information wird aus verschiedenen Quellen bezogen und verglichen. Wenn CRM und ERP unterschiedliche Kundenzahlen melden, liegt ein Konsistenzproblem vor.

Anomalieerkennung erzeugt unvermeidlich False Positives. Die Kunst liegt in der Kalibrierung: empfindlich genug, um echte Probleme zu finden, aber nicht so empfindlich, dass das Team die Alerts ignoriert.

Die besten Werkzeuge sind wirkungslos, wenn Datenqualität nicht als gemeinsame Verantwortung verstanden wird. Automatisierung ersetzt keine Kultur – sie macht eine gute Kultur skalierbar.

Data Ownership operationalisieren: Jedes Datenprodukt hat einen verantwortlichen Owner, der nicht nur formal benannt ist, sondern aktiv die Qualität überwacht, auf Alerts reagiert und Verbesserungen vorantreibt. Data Ownership ist eine Rolle, keine Zeile in einem Organigramm.

Qualitätsmetriken sichtbar machen: Datenqualitäts-Dashboards zeigen in Echtzeit den Zustand der wichtigsten Datenprodukte. Vollständigkeit, Aktualität, Regelkonformität und Anomalie-Rate werden für jedes Team sichtbar. Was gemessen wird, wird beachtet.

Incident-Management für Daten: Datenqualitätsprobleme werden wie Software-Incidents behandelt – mit Severity-Leveln, Eskalationspfaden und Post-Mortems. Wenn ein fehlerhafter Report die Geschäftsführung erreicht, muss der Prozess klar sein: Wer untersucht? Wer kommuniziert? Wie wird verhindert, dass derselbe Fehler erneut auftritt?

Qualität in den Entwicklungsprozess einbetten: Data-Quality-Tests sind Teil des Code Reviews. Neue Pipelines werden erst freigegeben, wenn Validierungsregeln, Monitoring und Alerting konfiguriert sind. Die Definition of Done für Datenprodukte schliesst Qualitätssicherung ein.

Datenqualität ist kein Projekt mit Anfang und Ende. Sie ist eine operative Disziplin, die – wie Software-Testing oder Security – nur funktioniert, wenn sie in den Alltag eingebettet ist. Die Werkzeuge dafür sind verfügbar. Die organisatorische Bereitschaft, sie konsequent einzusetzen, ist die eigentliche Herausforderung.