Profiling, Validierung und Observability

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

Observability meldet Freshness grün für sales_otc.fct_orders — der Close scheitert trotzdem an stornierten Zeilen, die kein Business-Test prüft. Profiling, Validation und Observability beantworten unterschiedliche Fragen; eines ersetzt die anderen nicht.

Damit werden drei unterschiedliche Aufgaben vermischt:

1. Profiling beschreibt, was in Daten vorhanden ist.
2. Validierung entscheidet, ob eine bekannte Erwartung erfüllt ist.
3. Observability erkennt und untersucht Veränderungen im laufenden System.

Die Verwechslung tritt in jedem Stack auf. Ein Snowflake-Monitor sieht steigendes Volumen, kennt aber keine gültige Umsatzdefinition. BigQuery-Profiling findet häufige Werte, kann aber nicht entscheiden, ob sie erlaubt sind. Fabric oder Databricks melden Drift, obwohl eine Marketingkampagne die Verteilung korrekt verändert hat. dbt-, Great-Expectations- oder Soda-Regeln bestehen, während ein unbekannter Quellfeed verschwunden ist. Airflow zeigt grüne Tasks, obwohl fachliche Ergebnisse unplausibel sind.

Besonders riskant ist die Gleichsetzung von Anomalie und Fehler. Drift bedeutet „anders als erwartet oder historisch üblich“, nicht „fachlich falsch“. Eine Geschäftsregel bedeutet „vereinbarte Bedingung verletzt“, selbst wenn das Muster seit Monaten stabil ist. Ein dauerhaft falscher Steuersatz driftet nicht. Ein erfolgreicher Produktlaunch driftet stark, ohne Qualitätsdefekt.

Leitentscheidung

Behandle Profiling, Validierung und Observability als drei komplementäre Kontrollschleifen mit unterschiedlichen Fragen, Ergebnissen und Reaktionen. Verknüpfe ihre Evidenz am Datenprodukt, aber ersetze keine Schleife durch eine andere.

• Profiling beantwortet: Was ist da, und welche Hypothesen sollten wir prüfen?
• Validierung beantwortet: Gilt eine ausdrücklich vereinbarte Regel in diesem Umfang?
• Observability beantwortet: Was hat sich unerwartet verändert, wo entstand es und welche Wirkung könnte es haben?

Die Trennung ist konzeptionell, nicht zwingend technisch. Ein Werkzeug darf alle drei Funktionen ausführen. Entscheidend ist, dass Nutzer erkennen, ob ein Wert eine Beschreibung, ein Regelurteil oder ein Anomaliesignal darstellt.

Profiling: Daten verstehen

Aufgabe und typische Metriken

Profiling untersucht Struktur und Inhalt eines Assets. Typische Ausgaben sind Zeilenanzahl, Nullanteil, Distinct Count, Min/Max, Quantile, häufige Werte, Längen, Muster, Datentypen, Duplikate und Beziehungen zwischen Spalten. Für Zeitreihen kommen Abdeckung, Lücken und Saisonalität hinzu.

Das Ziel ist Exploration: Grain-Hypothesen prüfen, Population erkennen, potenzielle Schlüssel finden, Ausnahmen entdecken und sinnvolle Regeln entwerfen. Profiling ist besonders wertvoll bei neuen Quellen, Migrationen und unbekannten Altbeständen.

Profiling beweist keine Akzeptanz

Wenn 97 Prozent der Datensätze eine Währung besitzen, beschreibt das Profil eine Beobachtung. Ob 97 Prozent akzeptabel sind, hängt von Nutzung und Scope ab. Die häufigsten Statuswerte sind nicht automatisch die erlaubte Domäne. Ein maximaler Betrag von zehn Millionen kann legitim oder ein Einheitenfehler sein.

Profile dürfen deshalb Vorschläge erzeugen, aber keine fachlichen Regeln ohne Review autorisieren. „Wert wurde bisher nie gesehen“ ist eine Untersuchungsfrage, kein automatisches Verbot.

Repräsentativität und Datenschutz

Ein Profil ist an Zeitpunkt, Partition, Filter und Sampling gebunden. Ein Sample kann seltene, aber kritische Fälle verpassen. Ein Monatsprofil kann Jahresendprozesse nicht repräsentieren. Dokumentiere Scope, Sampling-Methode und Ausführungszeit.

Profile können sensible Werte, Kardinalitäten oder häufige Identifikatoren offenlegen. Wende Zugriffsschutz, Maskierung und Mindestgruppengrößen an. Für Governance genügt oft eine aggregierte Verteilung statt Rohwertbeispielen.

Validierung: bekannte Erwartungen entscheiden

Aufgabe

Validierung führt die in Teil 2 beschriebenen Regeln aus. Sie bewertet eine definierte Behauptung gegen einen expliziten Scope und liefert bestanden, gewarnt, fehlgeschlagen oder technisch nicht ausführbar. Beispiele sind Eindeutigkeit am fachlichen Grain, zulässige Statusübergänge, referentielle Abdeckung oder Reconciliation mit Finance.

Die Stärke der Validierung ist ihre Entscheidbarkeit. Ein Owner hat vorher festgelegt, welcher Zustand akzeptabel ist und welche Reaktion folgt. Dadurch kann ein Ergebnis Builds blockieren, eine Partition quarantänisieren oder eine Freigabe verlangen.

Deterministisch bedeutet nicht unfehlbar

Ein deterministischer Check kann die falsche Regel perfekt ausführen. Fehlerhafte Filter, unklare Zeitzonen, falsche Join-Grains oder überholte Schwellen erzeugen irreführende Ergebnisse. Rule Code braucht Tests, Reviews und Versionierung wie anderer Produktionscode.

Auch „bestanden“ ist begrenzt: Es gilt für Regelversion, Population, Zeitpunkt und Ausführungsmodus. Ein Check auf einem Sample liefert schwächere Evidenz als ein vollständiger Check. Ein technisch fehlgeschlagener Test darf nicht als fachlich bestanden interpretiert werden.

Zeitpunkt im Datenfluss

Validierung kann an mehreren Kontrollpunkten stattfinden: beim Schreiben, nach Ingestion, nach Transformation, vor Veröffentlichung oder vor einer kritischen Entscheidung. Frühe Checks verkürzen Feedback; spätere Checks sehen mehr fachlichen Kontext. Kritische Pfade nutzen häufig mehrere Ebenen.

Nicht jede Verletzung sollte Rohdaten blockieren. Unveränderte Rohdaten können für Audit und Reparatur nötig sein. Quarantäne oder ein Veröffentlichungs-Gate ist oft sicherer als das Verwerfen des Inputs.

Observability: Veränderung erkennen und erklären

Aufgabe

Data Observability überwacht den Zustand laufender Datenflüsse und ihrer Abhängigkeiten. Sie kombiniert Signale wie Freshness, Volumen, Schemaänderung, Verteilungsdrift, Pipeline-Status, Laufzeit, Lineage und Downstream-Nutzung. Ziel ist schnelle Erkennung, Eingrenzung und Wirkungsschätzung.

Observability ist besonders nützlich für „unknown unknowns“: Änderungen, für die noch keine explizite Geschäftsregel existiert. Eine neue Nullhäufung, ein ungewöhnlicher Kategorienmix oder ein Laufzeitsprung kann auf einen Defekt, einen Prozesswechsel oder ein legitimes Ereignis hinweisen.

Baselines und Anomalien

Baselines können statisch, gleitend, saisonal oder segmentiert sein. Ein Tagesvolumen sollte möglicherweise mit demselben Wochentag verglichen werden, nicht mit gestern. Länder, Produkte und Mandanten brauchen unterschiedliche Muster. Releases, Feiertage und Kampagnen sollten als Kontext einfließen.

Ein Anomaliescore ist keine fachliche Schwere. Die Wirkung hängt von Asset-Kritikalität, betroffenen Consumer-Pfaden und Dauer ab. Ein kleiner Drift in einem regulatorischen Feld kann kritischer sein als ein großer Drift in einer explorativen Sandbox.

Von Signal zu Untersuchung

Ein gutes Observability-Signal enthält betroffene Metrik, erwarteten Bereich, beobachteten Wert, Beginn, Scope, mögliche Upstream-Änderungen und Downstream-Assets. Es unterstützt Triage, ersetzt sie aber nicht.

Nach der Untersuchung gibt es mindestens vier mögliche Ergebnisse:

• Defekt: korrigieren und gegebenenfalls eine dauerhafte Validierungsregel ergänzen.
• Legitime Änderung: Baseline oder Grundgesamtheit kontrolliert aktualisieren.
• Erwartete Einmaligkeit: Ereignis annotieren, ohne Regel zu ändern.
• Unklar: weiter beobachten oder zusätzliche Evidenz sammeln.

So wird Observability zu einem Lernsystem statt zu einer Alarmmaschine.

Zusammenspiel der drei Schleifen

Von Profiling zu Regel

Profiling entdeckt, dass currency_code in 3 Prozent der Positionen fehlt. Die Untersuchung zeigt: Gastbestellungen dürfen Kunden-ID, aber nie Währung vermissen. Daraus entsteht eine validierte Währungsregel für umsatzwirksame Positionen. Das Profil hat die Frage geliefert; der Owner hat die Akzeptanz entschieden.

Von Observability zu Regel

Ein Drift-Signal erkennt erstmals einen starken Anstieg stornierter Aufträge. Der Grund ist ein fehlerhaftes Statusmapping. Nach dem Incident definiert das Team eine Geschäftsregel für zulässige Statusübergänge. Eine unbekannte Veränderung wird in bekannte, künftig deterministisch prüfbare Erwartung überführt.

Von Regelverletzung zu Observability

Eine Reconciliation schlägt fehl. Lineage, Pipeline-Laufzeiten und Volumensignale zeigen, dass ein Ländersource verspätet ist. Die Validierung hat die Geschäftsauswirkung erkannt; Observability verkürzt die Ursachenanalyse.

Feedback statt linearer Reifegrad

Die Beziehung ist zyklisch. Neue Profile erzeugen Hypothesen, Regeln erzeugen Evidenz, Anomalien erzeugen Untersuchungen, Incidents verbessern Regeln und Baselines. Keine Phase ist „fertig“. Änderungen an Produkten, Quellen oder Consumer-Nutzung starten den Zyklus neu.

Durchgängiges Beispiel: gebuchter Nettoumsatz

Für den Revenue-Pfad werden alle drei Aufgaben bewusst getrennt.

Profiling beim Onboarding. Das Team profiliert Auftragspositionen je Land und Monat. Es untersucht Nullraten, Statuswerte, Währungen, Betragsverteilungen, Schlüssel­kandidaten und Ankunftsverzug. Ein Land zeigt negative Beträge außerhalb von Retouren. Das ist zunächst eine Hypothese. Finance erklärt anschließend eine lokale Gutscheinlogik; Population und Berechnung werden dokumentiert.

Validierung im Betrieb. Aktiv sind Regeln für Positionsidentität, Währungsabdeckung, erwartete Länderlieferung, zulässige Statusübergänge und Finance-Reconciliation. Jede hat Scope, Schwelle, Owner und Reaktion. Eine fehlende Währung quarantänisiert die Position; eine Reconciliation-Verletzung blockiert den Monatsabschluss.

Observability für Veränderungen. Überwacht werden Volumen je Land, Anteil der Status, Nettobetragsverteilung, Freshness der Quellen, Laufzeiten und Schemaänderungen. Das System erkennt, dass der mittlere Auftragswert um 40 Prozent steigt. Das ist kein automatischer Fehler. Die Triage findet eine legitime B2B-Kampagne, die versehentlich in der als B2C definierten Population gelandet ist. Damit liegt sowohl eine Population-Verletzung als auch eine neue Regelanforderung vor.

Ein anderes Mal fällt Umsatz an einem Feiertag um 60 Prozent. Das Drift-Signal ist korrekt, aber fachlich unkritisch. Der Kalenderkontext wird verbessert. Hätte das Team jeden Drift als Validierungsfehler behandelt, würde es entweder ständig Fehlalarme bearbeiten oder die Schwellen so weit öffnen, dass echte Änderungen verschwinden.

Stack-neutrale Architektur

Gemeinsame Metrik, unterschiedliche Interpretation

Nullrate, Zeilenanzahl oder Freshness können in allen drei Schleifen vorkommen. Der Unterschied liegt im Zweck:

• Profiling speichert „Nullrate ist heute 2,1 Prozent“ als Beschreibung.
• Validierung bewertet „Nullrate muss im Umfang 0 Prozent sein“ als Regel.
• Observability meldet „Nullrate stieg unerwartet von 0,1 auf 2,1 Prozent“ als Veränderung.

Kennzeichne Ergebnisart, damit Dashboards diese Aussagen nicht vermischen.

Offene Evidenzschicht

Speichere Ergebnisse mit stabilen Asset- und Regel-IDs, Zeit, Scope und Lineage-Bezug. Dann können Warehouse-native Checks, dbt, Spark, GE, Soda und Observability-Plattformen in eine gemeinsame Sicht einfließen, ohne dass ein Tool die fachliche Wahrheit besitzt.

Kosten bewusst steuern

Vollständige Profile großer Tabellen sind teuer. Nutze inkrementelle Partitionen, kontrolliertes Sampling, Approximate Functions und risikobasierte Frequenzen. Kritische Validierung darf höhere Kosten rechtfertigen; exploratives Profiling kann seltener laufen. Observability sollte auf vorhandenen Logs und Metriken aufbauen, bevor sie Daten wiederholt vollständig scannt.

Betriebsmodell

Drei Backlogs, ein Produktgespräch

Halte Profiling-Fragen, aktive Regeln und Observability-Signale unterscheidbar, bespreche sie aber gemeinsam im Datenprodukt-Team. Profiling-Fragen führen zu Definitionen oder Regeln. Regelverletzungen führen zu Remediation. Anomalien führen zu Triage. Dadurch erhält jedes Signal den passenden Workflow.

Alarmqualität

Ein Alert braucht Handlungsfähigkeit. Definiere Routing nach Owner und Kritikalität, dedupliziere nach Root Cause und unterdrücke bekannte Wartungsfenster. Messe nicht nur Anzahl der Alarme, sondern Bestätigungszeit, Anteil handlungsrelevanter Signale, Wiederholungen und Zeit bis zur Ursache.

Änderungskontext

Deployments, Source-Releases, Kampagnen, Feiertage und Migrationen sollten als Annotationen verfügbar sein. Viele „Anomalien“ sind ohne Änderungskontext teuer, mit ihm aber schnell erklärbar. Umgekehrt darf eine Annotation einen echten Regelbruch nicht automatisch entschuldigen.

Einfachste tragfähige Umsetzung

Wählt einen kritischen Datenpfad und richtet drei klar beschriftete Sichten ein:

1. Profil: wöchentlich oder beim Onboarding Grain, Nullraten, Domänen, Quantile und Latenz untersuchen.
2. Regeln: drei bis fünf vereinbarte Assertions mit Owner und Reaktion ausführen.
3. Betrieb: Freshness, Volumen, Schema, Laufzeit und zwei wichtige Verteilungen überwachen.

Führt Ergebnisse an einer Stelle zusammen, aber zeigt ihren Typ. Für jeden Observability-Alarm dokumentiert die Triage „Defekt, legitime Änderung, erwartetes Ereignis oder unklar“. Überführt wiederkehrende bestätigte Defekte in Regeln. Entfernt Signale, die weder Entscheidungen noch Untersuchungen auslösen.

Anti-Patterns

Drift als Geschäftsregel

Historische Normalität ist keine fachliche Zulässigkeit. Drift startet Untersuchung; eine Regel trifft eine vereinbarte Entscheidung.

Profil als Contract

Beobachtete Typen und Werte sind Entwürfe, keine Zusagen. Source-Systeme können historisch falsche oder zufällige Muster enthalten.

Grüne Pipeline als grüne Daten

Technischer Erfolg beweist weder Vollständigkeit aller Quellen noch korrekte Semantik.

Ein Dashboard für alles

Wenn Profilwerte, Regelverletzungen und Anomalien gleich aussehen, reagieren Nutzer falsch. Kennzeichne Evidenzart und erforderliche Handlung.

Alert-Flut ohne Lineage

Ein Upstream-Ausfall kann tausende Downstream-Signale erzeugen. Root-Cause-Gruppierung und Impact-Pfade sind Kernfunktion, kein Komfort.

Selbstlernende Schwellen ohne Governance

Wenn ein Modell jede dauerhafte Verschlechterung in seine Baseline aufnimmt, normalisiert es Defekte. Kritische Metriken brauchen Grenzen und kontrollierte Baseline-Änderungen.

Grenzen

Profiling kann seltene Fehler übersehen, besonders bei Sampling. Validierung ist nur so vollständig wie die bekannten Erwartungen. Observability kann Korrelation und Veränderung erkennen, aber keine fachliche Ursache garantieren. Lineage kann unvollständig sein, und automatische Impact-Analyse kennt nicht jede manuelle Nutzung.

Keine Kombination beweist universelle „Datenkorrektheit“. Der belastbare Anspruch lautet enger: Der Kontext ist bekannt, relevante Regeln wurden im definierten Scope geprüft, Veränderungen werden überwacht, und Abweichungen haben einen verantwortlichen Prozess.

Hilfe beim Umsetzen

Inventarisiert vorhandene Checks und markiert jeden als Profil, Validierung oder Observability. Wenn die Kategorie unklar ist, fehlt meist Zweck oder Reaktion. Ergänzt pro Signal die Frage, die es beantwortet.

Startet bei Incidents mit zwei Spuren: „Welche bekannte Regel wurde verletzt?“ und „Welche unerwartete Veränderung hilft bei der Ursache?“ Nach dem Incident entscheidet der Owner, ob eine neue Regel, eine bessere Baseline, zusätzlicher Kontext oder keine dauerhafte Kontrolle nötig ist.

Checkliste

• Ist jedes Ergebnis als Profil, Regelurteil oder Anomalie gekennzeichnet?
• Sind Profil-Umfang, Sampling und Zeitpunkt sichtbar?
• Werden Profilbefunde vor der Umwandlung in Regeln fachlich geprüft?
• Haben Validierungen Rule-ID, Version, Grundgesamtheit, Schwelle und verantwortliche Person?
• Wird ein technisch nicht ausgeführter Check von „bestanden“ unterschieden?
• Sind Observability-Baselines saisonal und segmentiert, wo nötig?
• Starten Drift-Signale eine Untersuchung statt automatisch Durchsetzung?
• Enthalten Alerts Upstream-Kontext und Downstream-Impact?
• Werden zusammenhängende Alarme nach Ursache dedupliziert?
• Fließen bestätigte neue Defekte in Regeln oder Kontext zurück?
• Sind legitime Änderungen kontrolliert annotiert?
• Werden Kosten, Datenschutz und Evidenzstärke bewusst abgewogen?
• Bleibt die fachliche Definition unabhängig vom Tool?
• Können Nutzer die drei Evidenzarten am Asset unterscheiden?

Artefakt

Verwendet eine Three-Loop Control Map je kritischem Datenprodukt:

• Produkt, Zweck, fachliche Ebene, Grundgesamtheit und Kritikalität
• Profiling-Fragen, Metriken, Umfang, Sample und Frequenz
• aktive Rule-IDs mit verantwortliche Person, Schwelle und Reaktion
• Observability-Signale mit Baseline, Segment und Routing
• gemeinsame Asset-, Source- und Lineage-Kennungen
• Speicherort, Aufbewahrung und Zugriff auf Evidenz
• Kontrollpunkte im Datenfluss
• Triage-Kategorien und Incident-Verknüpfung
• Root-Cause- und Downstream-Impact-Pfade
• bekannte Ereigniskalender und Deployment-Annotationen
• Feedback-Entscheidung: neue Regel, Baseline-Update, Kontextänderung oder keine Aktion
• Reviewdatum, Kostenbudget und verantwortliches Produktteam

Die Map ist kein Toolinventar. Sie zeigt, welche Frage durch welche Schleife beantwortet wird und wie Erkenntnisse zurückfließen.

Tools

Der dbt DQ Rules Generator, der dbt DQ Macro Generator und der Schema YML Editor helfen bei optionalen dbt-Mappings validierter Regeln. Fabric-, Databricks- und Lakehouse-DQ-Generatoren können Regeln in ihre jeweiligen Kontrollpunkte übertragen. Profiling und Observability dürfen aus nativen Plattformmetriken oder spezialisierten Diensten stammen. Das Drei-Schleifen-Modell bleibt unabhängig davon gleich.

Ressourcen

Nützliche Inputs sind Query-Historie, Pipeline-Logs, Incident-Timelines, Release-Kalender, Source-SLAs und fachliche Reconciliation-Berichte. Nutzt sie gezielt; ein weiteres Dashboard ersetzt keine klare Kontrollfrage.