Qualitätsergebnisse sind Metadaten

Begriffe vor dem Lesen

• Data Quality / DQ — Eignung von Daten für einen konkreten Zweck, nicht ein allgemeiner Schönheitswert.
• Regel — Prüfbare Erwartung an Daten mit Umfang, verantwortliche Person, Schwelle und Konsequenz.
• Quality Prüfpunkt — Entscheidungspunkt, der Daten nur bei erfüllter Erwartung weitergibt oder veröffentlicht.
• Vereinbarung / Vertrag — Vereinbarung zwischen Anbieter und Nutzer über Bedeutung, Qualität, Aktualität und Änderung.
• Incident — Vorfall, bei dem eine vereinbarte Erwartung verletzt wurde und daraus gelernt werden muss.

Ausgangslage

CI zeigt zwölf Nullen an sales_otc.customer_id — im Catalog und BI-Browser sieht der Analyst nur „grün“. Qualitätsergebnisse sind Metadaten; ohne Sichtbarkeit am Asset bleiben sie Engineering-Interna.

Diese Trennung erzeugt zwei widersprüchliche Realitäten. Technische Teams wissen, dass ein Produkt degradiert ist; Consumer interpretieren seine bloße Verfügbarkeit als Freigabe. Oder ein einzelner unkritischer Check ist rot, während das Asset weiterhin für die meisten Zwecke geeignet ist, doch ein pauschaler Alarm zerstört Vertrauen. In beiden Fällen fehlt nicht unbedingt eine weitere Prüfung. Es fehlt die Veröffentlichung der vorhandenen Evidenz in einer Form, die am regierten Asset verständlich und handlungsfähig ist.

Ein Testergebnis ist selbst Metadatum. Es beschreibt zu einem Zeitpunkt eine Beziehung zwischen Regel, Population, Asset und Erwartung. Pass oder Fail allein reicht nicht. Ohne Ausführungszeit, Datenstand, Scope, beobachteten Wert, Schwelle, Schweregrad und bekannte Ausnahme lässt sich das Ergebnis nicht sicher verwenden.

Auch Freshness ist Metadatum. Ein Asset kann technisch erreichbar sein, aber einen alten fachlichen Stand haben. Eine bekannte Lücke ist Metadatum. Sie erklärt, welche Population fehlt, warum sie fehlt, bis wann die Abweichung akzeptiert wurde und welche Nutzung betroffen ist. Werden diese Aussagen nur in Logs gehalten, kann Governance sie nicht mit Verantwortung, Lineage, Beschreibung und Nutzung verbinden.

Leitentscheidung

Wir veröffentlichen aktuelle Qualitätsevidenz zurück an das regierte Asset. Consumer sehen dort mindestens den Freigabestatus für relevante Use Cases, den letzten fachlich vollständigen Datenstand, kritische Pass/Fail-Ergebnisse, betroffene Populationen und aktive bekannte Lücken. Detaillierte Logs bleiben in ihren operativen Systemen; der Catalog oder Asset-Kontext erhält die verdichtete, erklärbare und verlinkte Evidenz.

Schichten klären: Qualitätsergebnisse sind Metadaten (zeitgebundene Fitness-Assertions); ein Data Catalog ist eine Anwendung, die diese Signale an auffindbaren Assets publiziert; ein BI-Dashboard/Cockpit monitoriert Trends und Remediation — es ist weder der Katalog noch die Metadaten selbst. Das Qualitäts- oder Ausführungssystem bleibt autoritativ für rohe Testergebnisse. Der Catalog wird nicht zur zweiten Test-Engine und nicht zum manuellen Kopierziel. Er übernimmt definierte Ergebnisfelder automatisiert, verbindet sie mit Assets und zeigt ihre Provenienz. Fachliche Owner verantworten Bedeutung, Freigabelogik und akzeptierte Ausnahmen; technische Owner verantworten korrekte Ausführung und Übertragung.

Die Darstellung folgt dem Prinzip der progressiven Offenlegung. Ein Consumer erkennt in wenigen Sekunden, ob das Asset für seinen Zweck aktuell verwendbar ist. Bei Bedarf kann er Dimension, Regel, Trend, betroffene Datensätze, Incident und technischen Lauf öffnen. So bleiben Trust-Signale verständlich, ohne komplexe Evidenz auf eine irreführende Ampel zu reduzieren.

Diese Entscheidung ist stack-neutral. Ein Catalog kann OpenMetadata, eine andere Plattform oder ein eigenes Portal sein. Ergebnisse können aus dbt, Spark, SQL, einem Warehouse, einer Pipeline, einem Observability-Produkt oder BI kommen. Entscheidend ist der stabile Ergebnisvertrag zwischen Erzeuger, Asset und Consumer.

Vom Log-Ereignis zum Trust-Signal

Ein Log sagt häufig: test_customer_email_not_null failed: 842 rows. Für einen Consumer fehlen entscheidende Fragen:

• Welches veröffentlichte Asset und welche Version sind betroffen?
• Beziehen sich 842 Fehler auf tausend oder hundert Millionen Datensätze?
• Welche Grundgesamtheit wurde geprüft und welcher Datenstand gilt?
• Ist die Regel für den eigenen Use Case blockierend oder nur informativ?
• Ist der Fehler neu, bekannt oder bereits akzeptiert?
• Bleibt das Asset teilweise nutzbar?
• Wer entscheidet und wann folgt ein Update?

Ein Trust-Signal übersetzt das technische Ergebnis nicht in Marketing-Sprache, sondern ergänzt seinen Kontext. Beispiel: „Versandsteuerung eingeschränkt: 842 von 24.110 versandbereiten Bestellungen ohne Lieferregion; Datenstand 08:00; erstmals erkannt 08:12; operative Nutzung blockiert, aggregierte Volumenanalyse nicht betroffen; Owner Logistics Data; nächste Aktualisierung 09:00.“

Die technische Detailseite darf weiterhin Query, Stacktrace und fehlerhafte Beispiele enthalten. Auf dem Asset steht die entscheidungsrelevante Aussage. Beide Ebenen sind über eine stabile Run- oder Result-ID verbunden.

Der minimale Ergebnisvertrag

Damit Ergebnisse systemübergreifend publiziert werden können, braucht es ein kleines, konsistentes Schema. Es sollte mindestens enthalten:

• stabile Regel-ID und verständlicher Regelname;
• Asset-ID sowie optional Spalte, Partition oder semantisches Objekt;
• Use Case oder Qualitätsvertrag, für den die Regel relevant ist;
• Dimension und Schweregrad;
• Status wie passed, failed, warning, error, skipped oder unknown;
• beobachteter Wert, Schwelle und Einheit;
• geprüfte Grundgesamtheit, Nenner und Zahl betroffener Datensätze;
• Datenstand, Ausführungsbeginn und -ende;
• ausführendes System, Umgebung und Run-ID;
• Link zu Details oder Incident;
• Owner und Eskalationsziel;
• aktive Ausnahme mit Grund, Entscheider und Ablaufdatum.

error ist nicht dasselbe wie failed. Ein Fail bedeutet, dass die Regel ausgeführt und die Erwartung verfehlt wurde. Error bedeutet, dass keine belastbare Aussage entstand, etwa wegen fehlender Berechtigung oder abgebrochener Abfrage. skipped und unknown dürfen ebenfalls nicht als bestanden erscheinen. Diese Unterscheidung verhindert grüne Assets ohne aktuelle Evidenz.

Der Vertrag sollte unveränderliche Einzelereignisse unterstützen. Der aktuelle Status wird daraus abgeleitet. So lassen sich verspätet eintreffende Ergebnisse, Wiederholungen und Korrekturen nachvollziehen, ohne Historie zu überschreiben.

Asset-Identität zuverlässig auflösen

Der schwierigste Teil der Übergabe ist oft nicht das API, sondern die Identität. Ein Test kennt vielleicht prod.analytics.fct_orders, der Catalog eine interne UUID und BI ein semantisches Objekt mit anderem Namen. Ein Ergebnis darf nicht aufgrund einer unscharfen Namenssuche am falschen Asset landen.

Definiert eine kanonische Asset-Referenz aus Plattform, Umgebung, Service, Namespace, physischem Namen und gegebenenfalls Versions- oder Branch-Kontext. Transformationstools sollten diese Referenz bereits in ihren Artefakten tragen. Für umbenannte Assets braucht es kontrollierte Aliase oder Lineage, nicht dauerhaftes Fuzzy Matching.

Ergebnisse für Entwicklung und Produktion bleiben getrennt. Ein bestandener Test in einer Preview-Umgebung ist keine Evidenz für Produktion. Ebenso muss eine Spaltenregel an der Spalte und eine BI-Regel am semantischen Objekt sichtbar sein, kann aber zusätzlich auf das übergeordnete Produkt aggregiert werden.

Status ist eine zeitgebundene Aussage

Ein grünes Ergebnis von letzter Woche ist für eine stündliche Lieferung kein aktueller Nachweis. Jeder publizierte Status braucht deshalb ein Gültigkeitsfenster. Dieses kann aus erwarteter Ausführungsfrequenz, Daten-SLA und tolerierter Verzögerung abgeleitet werden.

Nach Ablauf wechselt ein Ergebnis nicht still zu „bestanden“, sondern zu stale oder unknown. Consumer sehen dann: Die letzte Prüfung war erfolgreich, aber die Evidenz ist nicht mehr aktuell. Das ist etwas anderes als ein fachlicher Fail und erfordert möglicherweise einen anderen Owner.

Auch Datenstand und Testzeit sind zu trennen. Ein Test kann um 10:00 Uhr erfolgreich laufen und Daten mit Stand 06:00 Uhr prüfen. Für den Consumer ist beides relevant. Zeigt die Oberfläche nur die Laufzeit, wirkt das Asset frischer als seine Population.

Freshness als fachliches Trust-Signal

Freshness sollte den letzten fachlich vollständigen Stand zeigen, nicht nur die jüngste technische Änderung. Eine Tabelle kann um 09:10 Uhr neu geschrieben worden sein, obwohl eine kritische Quelle fehlt. Ein Dashboard-Extract kann heute aktualisiert sein, aber auf einem veralteten Mart basieren.

Ein aussagekräftiges Freshness-Signal enthält:

• erwarteten Rhythmus und fachliche Cut-off-Zeit;
• letzten vollständigen As-of-Zeitpunkt;
• aktuell beobachtete Verzögerung;
• langsamste oder fehlende kritische Abhängigkeit;
• nächste erwartete Aktualisierung;
• Auswirkung auf benannte Use Cases.

Bei mehreren Inputs ist ein einzelner maximaler Timestamp gefährlich. Das Signal sollte der freigegebenen Completeness-Logik folgen: Ein Umsatzprodukt ist beispielsweise erst dann vollständig, wenn Rechnungen, Retouren und Kurse für den Cut-off vorhanden sind. Der Catalog muss nicht diese Logik selbst berechnen; er zeigt das Ergebnis des autoritativen Kontrollpunkts.

Bekannte Lücken als First-Class-Metadaten

Nicht jeder Fehler wird sofort behoben. Daten können wegen einer Quellmigration, eines verspäteten Partners oder historischer Altlasten begrenzt sein. Eine solche Lücke zu dokumentieren ist kein Zeichen schlechter Governance, sondern eine Voraussetzung für ehrliche Nutzung.

Eine bekannte Lücke benötigt:

• betroffene Assets, Felder, Zeiträume und Populationen;
• konkrete Auswirkung auf Kennzahlen oder Entscheidungen;
• betroffene und weiterhin erlaubte Use Cases;
• Entstehungsgrund und Erkennungszeit;
• Workaround oder alternative Quelle;
• verantwortlichen verantwortliche Person;
• Akzeptanzentscheidung und Ablaufdatum;
• Link zu Incident, Problem oder Verbesserungsarbeit.

Freitext allein reicht für Suche und automatische Darstellung nicht. Kritische Felder wie Status, Scope, Severity und Ablauf sollten strukturiert sein; eine verständliche Beschreibung ergänzt sie. Nach Ablauf wird die Ausnahme erneut entschieden, nicht automatisch verlängert.

Eine Ausnahme ändert nicht das rohe Testergebnis. Der Check bleibt fehlgeschlagen; die Governance-Entscheidung sagt zusätzlich, dass eine bestimmte Nutzung befristet fortgesetzt werden darf. Diese Trennung erhält Evidenz und verhindert, dass Akzeptanz mit technischer Korrektheit verwechselt wird.

Use-Case-spezifische Freigabe statt globaler Ampel

Ein Asset kann für einen Zweck geeignet und für einen anderen ungeeignet sein. Fehlende Postleitzahlen blockieren vielleicht regionale Versandplanung, aber nicht die Gesamtzahl der Bestellungen. Ein verspäteter Tagesstand kann eine Echtzeitsteuerung verhindern, während Monatsanalysen weiter funktionieren.

Die Oberfläche sollte daher nicht nur healthy oder unhealthy zeigen. Ein kleines Modell kann lauten:

• Freigegeben: alle blockierenden Regeln aktuell bestanden;
• Eingeschränkt: bekannte Lücke mit klar erlaubten und verbotenen Nutzungen;
• Nicht freigegeben: mindestens eine blockierende Erwartung verfehlt;
• Unbekannt: keine aktuelle, vollständige Evidenz;
• In Prüfung: Ergebnis oder Ausnahme wird verantwortlich bewertet.

Die globale Asset-Anzeige kann den strengsten relevanten Status zusammenfassen, muss aber den Weg zur Use-Case-Sicht öffnen. Ein Score allein ist auch hier nicht ausreichend.

Historie, Trends und Änderungserkennung

Ein einzelnes Ergebnis erklärt den aktuellen Zustand. Eine Historie zeigt, ob das Problem einmalig, wiederkehrend oder schleichend ist. Sie unterstützt Capacity Planning, Ursachenanalyse und die Review-Frage, ob eine Schwelle noch sinnvoll ist.

Historisiert werden sollten mindestens Status, Messwert, Nenner, Fehlerzahl, Datenstand und Dauer. Trends brauchen stabile Regel-IDs. Wenn eine Regel fachlich geändert wird, erhält sie eine neue Version oder einen sichtbaren Änderungsmarker. Sonst erscheint eine geänderte Schwelle fälschlich als Qualitätsverbesserung.

Nicht jedes Einzelereignis muss dauerhaft im Catalog gespeichert werden. Ein spezialisiertes Ergebnissystem kann die vollständige Historie halten; der Catalog zeigt aktuellen Status, kompakten Trend und Link zur Detailanalyse. Retention richtet sich nach Betriebs- und Auditbedarf.

Auch „keine Ausführung“ ist ein Signal. Ein erwarteter Lauf, der ausbleibt, muss als Evidenzlücke sichtbar werden. Monitoring nur auf fehlgeschlagene Tests übersieht ausgefallene Testsysteme.

Publikationsarchitektur

Eine robuste Übergabe folgt einem einfachen Muster:

1. Die Test-Engine erzeugt strukturierte Ergebnisse und stabile IDs.
2. Ein normalisierender Schritt übersetzt proprietäre Felder in den Ergebnisvertrag.
3. Asset-Identitäten werden deterministisch aufgelöst.
4. Ergebnisse werden idempotent publiziert; Wiederholungen erzeugen keine Duplikate.
5. Der Catalog oder das Portal berechnet beziehungsweise empfängt den aktuellen Trust-Status.
6. Links führen zurück zu Details, Incident und verantwortlichem Owner.
7. Metriken überwachen die Übergabe selbst: Latenz, Mapping-Fehler und verwaiste Ergebnisse.

Push und Pull sind beide möglich. Eine Pipeline kann nach einem Lauf Ergebnisse senden, oder ein Ingestion-Prozess kann Artefakte regelmäßig abrufen. Entscheidend sind Aktualität, Wiederholbarkeit und Fehlertransparenz. Ein Übertragungsfehler darf nicht den zuletzt grünen Zustand unbegrenzt konservieren.

Bei OpenMetadata kann die Übergabe über unterstützte Ingestion, Test- und Profiler-Metadaten oder eine kontrollierte API-Integration erfolgen. Der OpenMetadata-Ingestion-Generator kann den optionalen Catalog-Handoff vorbereiten. Die fachliche Spezifikation sollte trotzdem unabhängig vom konkreten Catalog bestehen.

Was nicht in den Catalog gehört

Der Catalog ist kein Ersatz für rohe Logs, Debug-Samples oder sensible fehlerhafte Datensätze. Publiziert aggregierte Counts, Scope und sichere Beispiele nur dort, wo Berechtigungen passen. Ein fehlgeschlagener PII-Check darf nicht durch die Anzeige der betroffenen Werte ein neues Datenschutzproblem erzeugen.

Auch hochfrequente technische Metriken müssen nicht alle am Asset erscheinen. CPU, Query-Plan oder Stacktrace bleiben im operativen System. Im Catalog stehen Signale, die Bedeutung, Eignung und Handlung für Consumer erklären. Engineers gelangen per Link zur Diagnose.

Manuelle Statuspflege sollte die Ausnahme sein. Sie veraltet schnell und kann automatisierte Resultate überschreiben. Manuelle Governance-Entscheidungen wie Ausnahme, Freigabe oder Kommentar sind legitim, müssen aber getrennte Provenienz und Ablaufregeln besitzen.

Ein durchgängiges Beispiel

Das Datenprodukt daily_orders wird täglich bis 08:00 Uhr bereitgestellt. Um 08:12 schlägt eine Regel fehl: 842 versandbereite Bestellungen besitzen keine Lieferregion. Der Testdienst veröffentlicht Regel-ID, Asset-ID, Datenstand 08:00, Population 24.110, Fehlerzahl, Severity und Run-Link.

Der Trust-Service kombiniert das Ergebnis mit dem Vertrag. Für „Versandsteuerung“ ist die Regel blockierend, für „aggregierte Auftragsmenge“ nur warnend. Im Catalog erscheint das Asset insgesamt als eingeschränkt. Beide Use Cases zeigen ihren eigenen Status. Freshness bleibt grün, weil die Lieferung vollständig und pünktlich war; Vollständigkeit der Lieferregion ist rot. Die Signale werden nicht vermischt.

Der Owner akzeptiert keine dauerhafte Ausnahme, erlaubt aber die aggregierte Nutzung bis 12:00 Uhr. Eine strukturierte Gap-Notiz beschreibt betroffene Region, Workaround, Incident und Ablauf. Um 09:05 läuft ein korrigierter Batch. Das neue Ergebnis besteht, der aktuelle Status wechselt, und die Historie behält Fail, Entscheidung und Recovery.

Ein Consumer muss weder CI noch Orchestrator kennen. Er sieht am Asset, dass Versandsteuerung zwischen 08:12 und 09:05 nicht freigegeben war. Ein Engineer kann über die Run-ID die fehlerhaften Lieferungen untersuchen. Governance und Betrieb verwenden dieselbe Evidenz mit passender Detailtiefe.

Hilfe beim Umsetzen

Beginnt mit einem kritischen Asset und drei bis fünf blockierenden Regeln. Definiert zuerst den Consumer-Status und welche Felder ihn erklären. Nehmt ein reales Ergebnis und schreibt die ideale Asset-Anzeige in zwei Sätzen. Daraus lässt sich der minimale Ergebnisvertrag ableiten.

Prüft anschließend Identität und Zeit. Kann jedes Ergebnis deterministisch einem Produktions-Asset zugeordnet werden? Sind Datenstand und Ausführungszeit getrennt? Wann wird Evidenz stale? Was geschieht, wenn die Übergabe ausfällt? Diese Fragen sind wichtiger als ein aufwendiges Score-Design.

Der dbt-DQ-History-Generator unterstützt beim Aufbau einer auswertbaren Ergebnishistorie. Der Schema-YML-Editor hält Regelbeschreibungen und Asset-Kontext zusammen. Mit dem dbt-DQ-Regel-Generator lassen sich stabile Regeldefinitionen vorbereiten. Für OpenMetadata kann der OpenMetadata-Ingestion-Generator als optionaler Handoff dienen.

Testet die Consumer-Sicht mit vier Situationen: alles bestanden, kritischer Fail, veraltete Evidenz und akzeptierte Lücke. Ein Consumer sollte jeweils erkennen, ob und wie er das Asset nutzen darf. Testet zusätzlich einen Mapping-Fehler und einen ausgefallenen Publikationslauf. Das System darf in diesen Fällen nicht fälschlich grün bleiben.

Checkliste

• Ergebnisse werden automatisiert an das richtige regierte Asset publiziert.
• Regel-, Run- und Asset-IDs sind stabil und deterministisch.
• Produktions-, Test- und Preview-Ergebnisse bleiben getrennt.
• Pass, Fail, Error, Skipped, Unknown und Stale sind unterscheidbar.
• Datenstand und Ausführungszeit werden separat angezeigt.
• Jedes Ergebnis nennt Grundgesamtheit, Nenner, Messwert und Schwelle.
• Kritische Einzelregeln bleiben trotz Aggregation sichtbar.
• Freigabestatus ist für benannte Use Cases interpretierbar.
• Freshness bezeichnet den letzten fachlich vollständigen Stand.
• Bekannte Lücken nennen Umfang, Auswirkung, Owner und Ablaufdatum.
• Ausnahmen ändern nicht das rohe Testergebnis.
• Historie und Trends verwenden versionierte Regeldefinitionen.
• Ausbleibende Ausführungen erzeugen eine sichtbare Evidenzlücke.
• Übergabefehler und nicht zuordenbare Ergebnisse werden überwacht.
• Detail-Logs bleiben verlinkt, sensible Fehlerwerte geschützt.
• Nutzer können aus dem Trust-Signal eine konkrete Handlung ableiten.

Artefakt

Das zentrale Artefakt ist ein Quality Result Publication Contract. Es verbindet Testsystem, Catalog und Consumer und enthält:

• kanonische Identität von Regel, Asset, Spalte und Umgebung;
• Statusmodell einschließlich Unknown und Stale;
• Pflichtfelder für Messwert, Grundgesamtheit, Zeit und Provenienz;
• Zuordnung von Regeln zu Use Cases und Schweregrad;
• Logik für Freigabe, Einschränkung und Blockade;
• Schema für bekannte Lücken und befristete Ausnahmen;
• Freshness-Definition und Gültigkeitsfenster;
• Historisierung, Versionierung und Retention;
• Publikationsweg, Idempotenz und Retry-Verhalten;
• Berechtigungen, sichere Detailtiefe und Links;
• verantwortliche Person für Regel, Asset, Übergabe und Incident;
• Monitoring des Handoffs selbst.

Der Vertrag ist bewusst unabhängig von einer API oder einem Hersteller. Adapter übersetzen native Testergebnisse in diese gemeinsame Semantik. Dadurch kann ein Catalog ersetzt oder eine zweite Test-Engine ergänzt werden, ohne dass Consumer eine neue Vertrauenssprache lernen müssen.

Tools

• dbt-DQ-History-Generator — Ergebnisverlauf, Trends und wiederkehrende Fehler sichtbar machen.
• dbt-DQ-Regel-Generator — stabile, verständliche Regeldefinitionen und Schwellen vorbereiten.
• Schema-YML-Editor — Qualitätsbeschreibungen am Modell und an Spalten pflegen.
• OpenMetadata-Ingestion-Generator — optionalen Handoff von technischen Metadaten und Evidenz in den Catalog konfigurieren.