DQ-Ergebnisse als Historie führen
Warum Data-Quality-Ergebnisse als Verlauf mit Rule-ID, Owner, Ursache und Evidence gespeichert werden müssen.
Diese Story ist Teil 2 der Serie Operatives DQ-Monitoring. Teil 1 erklärt, warum ein einzelner Testlauf noch kein Betriebsmodell ist. Dieser Teil macht aus Testergebnissen eine auswertbare Historie.
Begriffe vor dem Lesen
- Rule-ID — stabile Kennung einer fachlichen Qualitätsregel über Tools und Plattformen hinweg.
- Result History — gespeicherter Verlauf von Regel-Läufen mit Status, geprüften Zeilen, Fehlern, Zeit und verantwortliche Person.
- Schweregrad — fachliche Schwere eines Befunds: Welche Entscheidung, Pflicht oder Lieferung ist betroffen?
- Nachweis — Nachweis, welche Regel wann lief, was sie gefunden hat und wie entschieden wurde.
- Remediation — nachvollziehbare Behebung mit Ursache, Owner und Wirksamkeitsprüfung.
Ausgangslage
Ein Team hat Tests in dbt, Fabric oder Databricks. Jeder Lauf zeigt rot oder grün. Im Review fragt der Fachbereich aber: Seit wann tritt der Fehler auf? Welche Produkte sind betroffen? Ist die Fehlerrate schlimmer geworden? Wurde der Fehler nur im Mart kaschiert oder in der Quelle behoben?
Wenn diese Fragen nicht beantwortet werden können, ist Qualität nur ein Momentbild. Governance braucht Verlauf.
Was gespeichert werden muss
Das gemeinsame Format ersetzt keine gemeinsame Regelbedeutung. Für Vergleiche müssen Regelversion, Population, Zählebene und Fehlerzählung passen. Null geprüfte Zeilen sind kein pauschaler 100-Prozent-Erfolg; technisch nicht ausgeführte Tests bleiben gesondert sichtbar.
Eine brauchbare DQ-Historie speichert mindestens Rule-ID, Datenprodukt, Laufzeitpunkt, geprüfte Population, Anzahl geprüfter Zeilen, Fehlerzahl, Fehlerrate, Severity, Owner, betroffene Consumer, Entscheidung und Evidence-Link.
Wichtig ist nicht, dass alle Plattformen identisch testen. Wichtig ist, dass ihre Ergebnisse auf dasselbe fachliche Ergebnisformat gemappt werden können.
Quellkorrektur statt schöner Downstream
Wenn der Fehler aus dem Quellsystem kommt, sollte die Ursache dort korrigiert oder als Quellbefund dokumentiert werden. Eine ETL-Bereinigung kann sinnvoll sein, aber sie darf die Wahrheit nicht verstecken. Wird ein Wert ersetzt, geschätzt, normalisiert oder ausgeschlossen, muss das als Transformation sichtbar bleiben.
Für AI ist das kritisch: Retrieval, Training und Agenten sehen sonst nur den bereinigten Wert. Ohne Kennzeichnung können sie eine Annahme als beobachteten Fakt behandeln.
Mini-Check
- Hat jede Regel eine stabile Rule-ID?
- Wird der Lauf als Historie gespeichert, nicht nur als Log?
- Ist sichtbar, ob die Ursache in Quelle, Transformation oder Nutzer liegt?
- Gibt es eine verantwortliche Person für Entscheidung und Behebung?
- Ist die Korrektur für BI, KI-Suche, Training oder Agentennutzung nachvollziehbar?
KNIME-Prüfergebnisse als verwertbare Betriebshistorie führen
Eine exportierte Fehlerliste pro Lauf ist noch keine zusammenhängende DQ-Historie. Für KNIME muss dieselbe fachliche Regel über Zeit, Eingabeversion und erneute Ausführung unterscheidbar bleiben. Der nachfolgende Entwurf ist ein vereinbartes Nachweisschema, keine automatisch vorhandene KNIME-Standardtabelle.
| Feld | Wozu es gebraucht wird |
|---|---|
run_id, attempt_id |
Fachlichen Lauf und Wiederholungsversuch unterscheiden |
dataset_version, rule_version |
Eingabe und geprüfte Bedeutung identifizieren |
checked_at, source_as_of |
Ausführungszeit und Quellalter getrennt auswerten |
rule_id, checked_rows, failed_rows |
Regel und Nenner nachvollziehen |
result, owner, evidence_ref |
Befund, Bearbeitung und geschützten Nachweis verbinden |
Für den synthetischen Auftragsfall sind sechs Zeilen geprüft und vier Zeilen zurückgestellt. Die Statusgruppen erklären diese vier Zeilen; daraus wird keine allgemeine Unternehmensfehlerquote. Eine technische Wiederholung darf nicht als zweiter unabhängiger Geschäftslauf gezählt werden. Beide Versuche bleiben mit derselben Laufreferenz nachvollziehbar.
Die Ablage kann eine vorhandene berechtigte Datenbank oder ein kontrolliertes Dateiverfahren sein. Aufbewahrung, Zugriffe, Auswertung und Bearbeitungsweg vorab vereinbaren. Keine Rohdaten oder Zugangsdaten in ein öffentliches Cockpit schreiben.
Abnahme: Der Betreiber erklärt eine Historienzeile bis zu Eingabe, Regel und Bearbeiter. Danach an die bestehende DQ-Behebung übergeben: Befund allein ist noch keine Korrektur. Die Betriebscheckliste prüft auch das Vermeiden doppelter Zählung.
Operational DQ monitoring
Part 2 of 3
View series