Qualität durch Transformationen

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

Der Fehler sitzt in der Raw-zu-Staging-Join für sales_otc — getestet wurde nur das fertige Mart-Dashboard. Qualität durch Transformationen prüft dort, wo Bedeutung entsteht, nicht erst am Ende.

Transformationen transportieren Qualität nicht einfach unverändert. Sie können Fehler erkennen und beheben, aber auch Bedeutung verändern, Unsicherheit verdecken oder neue Fehler erzeugen. Eine customer_id, die in der Quelle optional ist, kann nach einem Filter vollständig erscheinen, weil alle Datensätze ohne ID entfernt wurden. Ein Mart kann eindeutige Zeilen enthalten, obwohl vorher Duplikate nach einer willkürlichen Sortierung verworfen wurden. Ein Dashboard kann grün sein, obwohl es nur den erfolgreich geladenen Teil der Population zeigt.

Nur am Ende zu testen führt zu langen Diagnosewegen und zu falscher Sicherheit. Nur an der Quelle zu testen reicht ebenfalls nicht: Korrekte Eingaben garantieren keine korrekten Joins, Aggregationen, Klassifikationen oder Kennzahlen. Jede Schicht beantwortet andere Fragen und braucht Regeln, die zu ihrem Zweck passen.

Das Problem ist technologieunabhängig. „Quelle“, „Staging“, „fachliche Transformation“, „Mart“ und „BI“ sind logische Kontrollpunkte, keine vorgeschriebene Architektur. In einem Lake können sie Zonen oder Tabellen sein, in Spark DataFrames oder Jobs, in einem Warehouse Schemas, in dbt Modelle und in einer BI-Plattform semantische Modelle. Auch wenn mehrere Schritte physisch zusammenfallen, bleiben ihre Verantwortungen unterscheidbar.

Leitentscheidung

Wir entwerfen Qualität entlang der Transformationen als Kette komplementärer Nachweise. Regeln werden dort platziert, wo eine Erwartung erstmals beurteilt werden kann und ein Fehler noch eindeutig diagnostizierbar ist. Kritische Erwartungen werden an späteren Übergängen erneut als Reconciliation oder Output-Vertrag geprüft. Das Ziel ist keine maximale Anzahl von Tests, sondern eine lückenlose Beweiskette für die wesentlichen Bedeutungsänderungen.

Jeder Transformationsschritt, der Grain, Population, Zeitlogik, fachliche Klassifikation, Währung, Einheit, Nullbehandlung, Deduplizierung oder Autorität verändert, wird dokumentiert. Diese semantisch materiellen Transformationen erhalten explizite Eingangsannahmen, Ausgangsgarantien und eine Reconciliation. Rein technische Schritte können leichter dokumentiert werden, sofern sie Bedeutung und Population nachweislich nicht verändern.

Ein Mart-Test bleibt wichtig, aber er ist die letzte Verteidigungslinie und nicht die gesamte Strategie. Source- und Landing-Regeln sichern Lieferung und Form. Staging-Regeln normalisieren und machen Quellprobleme sichtbar. Fachliche Transformationen prüfen Beziehungen und Bedeutungswechsel. Marts sichern Consumer-Verträge. BI prüft die tatsächlich veröffentlichte Semantik.

Eine Kontrollkette statt fünf isolierter Testpakete

Die Schichten dürfen nicht jeweils eigene, widersprüchliche Qualitätsdefinitionen erfinden. Eine Erwartung wandert als nachvollziehbare Aussage durch den Flow. Beispiel: „Jede gebuchte Rechnungsposition erscheint genau einmal im Nettoumsatz des Buchungsmonats.“ An der Quelle wird geprüft, ob gebuchte Positionen identifizierbar und geliefert sind. Im Staging wird ihre technische Eindeutigkeit und Typisierung geprüft. In der Transformation wird die Buchungsperiode und Behandlung von Retouren validiert. Im Mart werden Anzahl und Betrag reconciled. Im BI-Modell wird geprüft, dass der veröffentlichte KPI dieselbe Population und Zeitlogik verwendet.

Nicht jede Regel muss fünfmal laufen. Eine Formatregel für einen Rohwert ist nach sauberer Typisierung vielleicht nicht mehr nötig. Eine kritische Vollständigkeits- oder Summenregel sollte dagegen vor und nach einer populationverändernden Transformation stehen. Die Platzierung folgt dem Risiko:

• früh, wenn ein Fehler dort entsteht oder am leichtesten einer Lieferung zugeordnet werden kann;
• am Übergang, wenn fachliche Ebene, Grundgesamtheit oder Bedeutung wechselt;
• spät, wenn ein Nutzer-Vertrag oder eine veröffentlichte Kennzahl abgesichert wird;
• wiederholt, wenn ein späterer Schritt die zuvor bewiesene Eigenschaft erneut gefährden kann.

Quelle und Ingestion: Lieferung beweisen

Am ersten kontrollierbaren Punkt geht es nicht darum, die gesamte Fachlogik der Quelle nachzubauen. Geprüft werden Lieferfähigkeit und die Annahmen, auf denen nachgelagerte Verarbeitung beruht:

• erwartete Dateien, Topics, Tabellen, Partitionen oder Extrakte sind angekommen;
• Volumen und Kontrollsummen liegen in einem erklärbaren Bereich;
• erforderliche Schlüssel und Änderungsmarker sind vorhanden;
• Schemaänderungen sind erkannt;
• Quellzeit, Extraktionszeit und Ladezeit sind unterscheidbar;
• Löschungen, Retries und Nachlieferungen haben ein definiertes Verhalten.

Wenn kein Zugriff auf die operative Quelle möglich oder sinnvoll ist, wird die Landing-Zone zum ersten Kontrollpunkt. Dann ist transparent zu benennen, dass die Prüfung die gelieferte Repräsentation und nicht den Zustand im Ursprung beweist. Ein Liefermanifest, eine Quellkontrollsumme oder ein CDC-Offset kann die Lücke verkleinern.

Quellregeln sollten Fehler nicht still reparieren. Ein ungültiges Datum darf in Quarantäne verschoben oder technisch als unlesbar markiert werden; die ursprüngliche Beobachtung und Anzahl müssen erhalten bleiben. Sonst sieht Staging sauber aus, während niemand mehr weiß, wie groß das Eingangsproblem war.

Staging: normalisieren, ohne Herkunft zu verlieren

Staging schafft eine konsistente technische Repräsentation. Typen werden vereinheitlicht, Namen normalisiert, Timestamps auf eine gemeinsame Zone gebracht und offensichtliche technische Duplikate behandelt. Die Qualitätsfrage lautet: Ist die gelieferte Population vollständig und reproduzierbar in eine analysierbare Form überführt worden?

Geeignete Regeln vergleichen Input und Output: Zeilenzahl, distinct fachliche Schlüssel, Kontrollsummen kritischer Beträge, Anzahl verworfener Datensätze und Verteilung auf Quellsegmente. Jede Abweichung braucht eine klassifizierte Behandlung: akzeptiert, korrigiert, in Quarantäne, dupliziert, verworfen oder ungeklärt.

Staging darf keine unsichtbare fachliche Auswahl treffen. Ein Filter status != 'test' kann legitim sein, ist aber bereits eine Populationsentscheidung und gehört in eine dokumentierte fachliche Transformation. Auch coalesce(country, 'DE') ist keine neutrale Bereinigung. Es imputiert Bedeutung und muss als solche sichtbar sein.

Bewahrt, soweit vertretbar, Quellschlüssel, Ladezeit, Batch- oder Event-ID und eine Referenz auf den unveränderten Input. Diese Felder sind keine Dekoration; sie ermöglichen, einen Fehler vom Consumer bis zur Lieferung zurückzuverfolgen.

Fachliche Transformation: Bedeutung kontrolliert verändern

In der fachlichen Schicht entstehen die wichtigsten Qualitätsrisiken. Joins verändern Populationen, Filter definieren Scope, Window-Funktionen wählen Gewinner, Mappings erzeugen Klassifikationen, Währungs- und Einheitentransformationen verändern Werte, und Aggregationen ändern den Grain. Jeder dieser Schritte benötigt eine explizite Behauptung.

Für Joins reicht „Relationship-Test bestanden“ nicht. Dokumentiert:

• erwartete Kardinalität, etwa viele Positionen zu genau einer Bestellung;
• Verhalten bei fehlendem Match;
• Verhalten bei mehreren Matches;
• zeitliche Join-Logik für historisierte Dimensionen;
• Auswirkungen auf Zeilen- und Betragszahlen;
• autoritative Seite für konfliktbehaftete Attribute.

Vor und nach einem kritischen Join sollten mindestens Population, fachliche Schlüssel und zentrale Summen verglichen werden. Eine gleichbleibende Zeilenzahl allein beweist wenig: verlorene und vervielfachte Zeilen können sich zufällig ausgleichen.

Bei Deduplizierung wird die Auswahlregel Teil der fachlichen Definition. „Neuester Datensatz gewinnt“ benötigt ein verlässliches Zeitfeld und einen Tie-Breaker. Außerdem muss die Zahl und Art der Konflikte sichtbar bleiben. Ein eindeutiges Ergebnis ist kein Beweis für konfliktfreie Eingaben.

Bei Aggregationen ist der neue Grain festzuhalten. Reconciliation verbindet Detail- und Aggregatebene: Welche Beträge müssen sich erhalten, welche dürfen sich durch Ausschlüsse oder Umrechnung ändern, und welche Rundungstoleranz gilt? Nicht additive Kennzahlen wie Bestände, Quoten oder eindeutige Kunden dürfen nicht wie Summen behandelt werden.

Mart und konsumierbares Produkt: Vertrag absichern

Ein Mart oder konsumierbares Datenprodukt prüft die Garantien, auf die Consumer sich verlassen. Dazu gehören stabile Spalten, fachliche Schlüssel, erlaubte Werte, erforderliche Felder, Aktualität, dokumentierte Population und kritische Kennzahlen. Diese Regeln sind bewusst näher an der Nutzung als an der Implementierung formuliert.

Mart-Regeln duplizieren nicht blind alle früheren Tests. Sie sichern Eigenschaften, die durch den gesamten Flow erhalten bleiben müssen, und prüfen den Vertrag nach der letzten materiellen Transformation. Besonders wichtig sind End-to-End-Reconciliations: Erhaltene Transaktionszahlen, Beträge, Abdeckungsperioden oder definierte Ausschlüsse werden gegen einen früheren Kontrollpunkt verglichen.

Ein grünes Mart beweist nur den aktuellen Vertrag und die beobachtete Population. Wenn problematische Datensätze vorher in Quarantäne gingen, muss das Mart diesen bekannten Gap als Metadatum tragen. Sonst wird eine kontrollierte Degradation zu scheinbarer Vollständigkeit.

BI und semantische Schicht: Veröffentlichung prüfen

Die Qualitätskette endet nicht an der letzten Tabelle. BI-Modelle können Joins, Filter, berechnete Felder, Security-Kontext, Aggregationsverhalten und Zeitzonen erneut verändern. Ein korrektes Mart kann durch eine Many-to-many-Beziehung oder eine lokale Measure-Definition falsch dargestellt werden.

Prüft für kritische Kennzahlen mindestens:

• der BI-fachliche Ebene und die Aggregation entsprechen der freigegebenen Definition;
• Standardfilter schließen keine unerwartete Grundgesamtheit aus;
• Beziehungen vervielfachen oder verlieren keine Fakten;
• Zeit- und Währungslogik stimmen mit dem Vertrag überein;
• fachliche Totals lassen sich gegen das konsumierbare Asset reconciliieren;
• gecachte oder extrahierte Daten zeigen einen verständlichen Stand;
• Warnungen und bekannte Lücken erreichen den Nutzer.

Das bedeutet nicht, jedes Dashboard mit einer zweiten Testplattform nachzubauen. Für wenige kritische Kennzahlen reichen Referenzabfragen, kontrollierte Exporte, API-basierte Vergleiche oder wiederholbare Abnahmeszenarien. Entscheidend ist, dass die veröffentlichte Aussage geprüft wird, nicht nur ihr Input.

Materielle Transformationen dokumentieren

Code zeigt, wie ein Wert berechnet wird, aber selten ausreichend, warum seine Bedeutung geändert wurde. Ein Review braucht deshalb eine kompakte Beschreibung materieller Transformationen. Dazu zählen:

• fachliche Ebene-Wechsel durch Aggregation, Pivot oder Explode;
• Ein- und Ausschlüsse, die die Grundgesamtheit verändern;
• Deduplizierung, Survivorship und Merge-Regeln;
• Imputation, Defaultwerte und Nullbehandlung;
• Mapping, Klassifikation und Schwellen;
• Währungs-, Einheiten- und Zeitzonenumrechnung;
• historisierte Gültigkeitslogik und Point-in-time-Joins;
• abgeleitete Kennzahlen und Allokationen;
• manuelle Overrides und Korrekturbuchungen.

Für jede solche Transformation werden Eingangsannahme, Regel, Ausgangsbedeutung, unveränderte Invarianten, erwartete Verluste und Prüfnachweis festgehalten. Beispiel: „net_amount_reporting konvertiert den fakturierten Nettobetrag ohne Steuer zum freigegebenen Monatskurs des Buchungsdatums. Fehlt ein Kurs, wird die Position nicht mit 1,0 imputiert, sondern als nicht konvertierbar ausgewiesen und aus der freigegebenen Reporting-Population ausgeschlossen.“

Diese Aussage erlaubt gezielte Tests: Kursabdeckung, Eindeutigkeit des Monatskurses, Summe ausgeschlossener Beträge, Vergleich in Quellwährung und Nachweis des verwendeten Kursstands. Ohne Dokumentation könnte ein grüner Non-null-Test die eigentliche Unsicherheit verstecken.

Reparieren, quarantänisieren oder durchlassen

Nicht jeder Fehler muss den gesamten Flow stoppen. Das Betriebsmodell braucht definierte Behandlungen:

• Blockieren: Weiterverarbeitung oder Veröffentlichung ist für einen kritischen Fehler unzulässig.
• Quarantänisieren: Betroffene Datensätze werden isoliert; Umfang und Nutzer-Auswirkung bleiben sichtbar.
• Degradieren: Ein Produkt wird mit klarer Warnung und eingeschränktem Use Case veröffentlicht.
• Korrigieren: Eine deterministische, freigegebene Regel behebt den Wert und erhält Original sowie Korrekturgrund.
• Durchlassen: Der Fehler wird bewusst akzeptiert, gemessen und mit Ablaufdatum dokumentiert.

Eine technische Defaultbehandlung ist keine Governance-Entscheidung. Wer unknown einsetzt oder Datensätze ausschließt, muss wissen, welche Kennzahl dadurch beeinflusst wird. Die Behandlung sollte als Ergebnis und Transformation nachvollziehbar sein.

Ein durchgängiges Beispiel

Eine Umsatzstrecke erhält Aufträge, Positionen, Rechnungen, Retouren und Wechselkurse. Im Landing werden erwartete Tageslieferungen, CDC-Fortschritt und Quellkontrollsummen geprüft. Staging typisiert IDs und Zeitfelder, erhält Quellzeilen und weist unlesbare Beträge aus. Reconciliations zeigen, wie viele Datensätze technisch nicht übernommen werden konnten.

Die fachliche Transformation verbindet Rechnungspositionen mit Aufträgen, ordnet Retouren zu und konvertiert Beträge. Vor dem Join wird die Eindeutigkeit der Rechnungsschlüssel geprüft, nach dem Join die Kardinalität. Nicht zuordenbare Retouren bleiben in einer Gap-Population sichtbar. Vor und nach der Konvertierung werden Beträge pro Währung abgestimmt; fehlende Kurse führen nicht zu stillen Nullen.

Das Monats-Mart aggregiert auf Buchungsmonat, Gesellschaft und Produktgruppe. Tests prüfen den neuen Grain, Periodenabdeckung, erlaubte Gesellschaften und Reconciliation zum Detailmodell. Das BI-Modell vergleicht den veröffentlichten Nettoumsatz mit einer Referenzabfrage und zeigt den letzten vollständigen Buchungsstand.

Wenn eine Kennzahl abweicht, reduziert diese Kette den Suchraum. Lieferkontrollen zeigen, ob Inputs fehlen. Staging weist Parse- oder Schemafehler aus. Join-Metriken zeigen Vervielfachung. Konvertierungsmetriken zeigen Kurslücken. Mart- und BI-Reconciliations lokalisieren spätere Bedeutungsänderungen. Qualität wird damit nicht nur gemessen, sondern diagnostizierbar.

Hilfe beim Umsetzen

Zeichnet für einen kritischen Flow fünf logische Kontrollpunkte: erster kontrollierbarer Eingang, normalisierte Repräsentation, wesentliche fachliche Transformation, konsumierbares Produkt und veröffentlichte Nutzung. Markiert alle Stellen, an denen Grain, Population, Zeit, Einheit oder Autorität wechselt. Beginnt mit diesen Stellen, nicht mit einer vollständigen Inventur sämtlicher Modelle.

Definiert pro Übergang ein bis drei Invarianten und ein bis drei erlaubte Änderungen. Eine Invariante kann sein: „Die Summe fakturierter Beträge in Quellwährung bleibt erhalten.“ Eine erlaubte Änderung kann lauten: „Testbestellungen werden entfernt und separat gezählt.“ Daraus entstehen konkrete Reconciliations und Gap-Metriken.

Der dbt-DQ-Regel-Generator unterstützt bei der Formulierung schichtspezifischer Regeln. Wiederkehrende Join-, Reconciliation- oder Bereichslogik lässt sich mit dem dbt-DQ-Makro-Generator standardisieren. Der Schema-YML-Editor hilft, Regeln direkt neben Modell- und Spaltenbeschreibungen reviewbar zu halten. Die Prinzipien lassen sich 1:1 in andere Engines übertragen.

Reviewt Fehlerwege praktisch. Nehmt einen fehlenden Input, ein Duplikat, einen nicht passenden Join und einen fehlenden Wechselkurs. Prüft, an welchem Kontrollpunkt der Fehler sichtbar wird, welche Population betroffen ist und ob der Consumer die Einschränkung erfährt. Wenn der einzige Hinweis ein roter Pipeline-Log ist, ist die Qualitätskette noch nicht vollständig.

Checkliste

• Der Flow besitzt benannte logische Kontrollpunkte vom Eingang bis zur Veröffentlichung.
• Regeln sind dort platziert, wo sie erstmals sinnvoll und diagnostisch sind.
• Kritische Eigenschaften werden nach materiellen Transformationen erneut geprüft.
• Quell- und Landing-Regeln sichern Lieferung, Schema, Volumen und Zeitbezug.
• Staging erhält Provenienz und quantifiziert verworfene oder korrigierte Datensätze.
• Fachliche Filter werden nicht als technische Bereinigung versteckt.
• Join-Kardinalität, fehlende Matches und Mehrfachtreffer werden gemessen.
• Deduplizierung dokumentiert fachlichen Schlüssel, Gewinnerregel und Konfliktzahl.
• Aggregationen benennen den neuen fachliche Ebene und passende Abgleich.
• Währungs-, Einheiten- und Zeitumrechnung haben explizite Referenzdaten.
• Imputation und Defaultwerte sind sichtbar und fachlich freigegeben.
• Auswertungstabelle-Regeln sichern den Nutzer-Vertrag statt nur Implementierungsdetails.
• Kritische BI-Kennzahlen werden gegen eine autoritative Referenz geprüft.
• Blockieren, Quarantäne, Degradation, Korrektur und Akzeptanz sind unterschieden.
• Bekannte Gaps bleiben bis zum konsumierten Asset sichtbar.
• Die Diagnose kann einen Fehler einem konkreten Übergang zuordnen.

Artefakt

Das zentrale Artefakt ist eine Transformation Quality Map. Sie verbindet Lineage mit Qualität, ohne an ein bestimmtes Tool gebunden zu sein. Pro Kontrollpunkt enthält sie:

• Asset oder logischen Verarbeitungsschritt;
• Eingangs- und Ausgangs-fachliche Ebene;
• einbezogene und ausgeschlossene Populationen;
• materielle Transformationen und fachliche Begründung;
• Eingangsannahmen, Invarianten und Ausgangsgarantien;
• Regeln, Reconciliations und Ausführungsrhythmus;
• Fehlerbehandlung und sichtbare Gap-Metriken;
• verantwortliche Person für Code, fachliche Bedeutung und Incident;
• Verweis auf ausführbare Implementierung und letzte Evidenz.

Die Map muss nicht jede technische Operation abbilden. Sie konzentriert sich auf Stellen, an denen eine Entscheidung falsch werden könnte. Dadurch bleibt sie reviewbar und übersteht einen Plattformwechsel besser als eine reine Jobgrafik.

Tools

• dbt-DQ-Regel-Generator — Regeln passend zu Quelle, Staging, Transformation und Auswertungstabelle entwerfen.
• dbt-DQ-Makro-Generator — Reconciliations und wiederkehrende Übergangsprüfungen standardisieren.
• Schema-YML-Editor — Beschreibungen, Spaltenverträge und Tests gemeinsam pflegen.
• dbt-DQ-History-Generator — Fehlerquoten und Gap-Populationen über Läufe hinweg verfolgen.