Data Observability: Definition, fünf Säulen, Abgrenzung

Data Observability (deutsch: Datenbeobachtbarkeit) bezeichnet die laufende technische Überwachung einer Datenlandschaft, also aller Tabellen, Datenströme und Auswertungen, mit denen ein Unternehmen arbeitet. Gemessen werden fünf Kern-Bausteine: Frische (ist der Datensatz aktuell?), Volumen (ist die Datenmenge plausibel?), Struktur (haben sich Spalten oder Datentypen verändert?), Verteilung (sehen die Werte in einer Spalte normal aus?) und Herkunft (woher stammt der Datensatz, wer nutzt ihn?). Ziel ist, Fehler in den Daten zu erkennen, bevor Berichte, KI-Modelle oder datenbasierte Produkte auf falschen Werten arbeiten.

Was ist Data Observability?

Data Observability überträgt ein Prinzip aus dem Software-Betrieb auf die Datenwelt. Im Software-Betrieb überwachen Teams laufende Anwendungen über drei Signalarten: Metriken (Messwerte wie Antwortzeit), Logs (Ereignis-Protokolle) und Traces (nachvollzogene Wege eines Requests durch das System). Genau dieses Prinzip, den Zustand eines Systems über seine Signale sichtbar zu machen, wird bei Data Observability auf Tabellen (strukturierte Datenbestände), Streams (kontinuierliche Datenströme), Jobs (planmäßig laufende Verarbeitungs-Schritte) und Modelle (statistische oder KI-Modelle, die aus Daten lernen) übertragen. Überwacht wird: Ist eine Tabelle so aktuell wie erwartet, sind die eingehenden Datenmengen plausibel, hat sich die Struktur verändert, sind die Werteverteilungen stabil, welche nachgelagerten Berichte und Modelle hängen an dieser Tabelle? Der Begriff hat sich um 2020 im Umfeld der Anbieter Monte Carlo und Bigeye etabliert und ist inzwischen ein eigener Bestandteil des Betriebs moderner Datenplattformen.

Die Fachwelt beschreibt Data Observability über fünf Säulen. Freshness misst den Zeitabstand zwischen erwartetem und tatsächlichem letzten Schreibzugriff auf ein Datenobjekt. Volume prüft, ob sich das Zeilen-Delta einer Tabelle innerhalb der historisch erwarteten Bandbreite bewegt; zu wenig deutet auf Ingestion-Ausfälle, zu viel auf Duplikate oder Backfill-Fehler. Schema überwacht Änderungen an Spalten, Datentypen und Nullbarkeit; Schema-Drift bricht Downstream-Konsumenten häufig stumm. Distribution beobachtet statistische Eigenschaften einzelner Spalten (Min/Max, Null-Anteil, Kardinalität, Kategorienverteilung) und meldet Ausreißer gegen eine gelernte Baseline. Lineage stellt die Beziehungs-Karte bereit, über die Vorfälle auf konsumierende Reports, ML-Features und Datenprodukte zurückverfolgbar werden.

Die Signal-Erzeugung geschieht auf zwei Wegen. Agent-lose Plattformen wie Databricks Lakehouse Monitoring werten Query-Logs, System-Tables und Katalog-Metadaten aus und benötigen keine Instrumentierung an den Pipelines. Agent-basierte Plattformen wie Monte Carlo, Bigeye, Anomalo oder Soda binden sich über Konnektoren an Warehouses, Lakehouses und Orchestratoren an und ergänzen dort ihre eigene Baseline. Auf den erhobenen Signalen laufen Alerts, SLOs und Incident-Prozesse: Ein Freshness-SLA wie „Silber-Tabelle X ist bis 07:00 Uhr aktuell" wird an einen Runbook-Alarm gekoppelt, ein Distribution-Ausreißer öffnet ein Data-Quality-Ticket. Regulatorisch verankert der EU AI Act (Art. 10) Datenqualitäts-Nachweise für Hochrisiko-Systeme; Data Observability liefert dafür die technische Mess-Schicht neben Lineage und Data Contracts.

Abgrenzung zu Data Quality, Data Lineage und Data Testing

Data Observability wird häufig mit angrenzenden Disziplinen synonym verwendet, obwohl die Begriffe unterschiedliche Rollen im Betriebs-Stack einnehmen.

Begriff	Achse	Kernunterschied
Data Quality	Zielzustand	Data Quality definiert das Soll über Dimensionen wie Accuracy, Completeness, Consistency und Timeliness und prüft es über explizite Regeln. Data Observability ist das Betriebs-Instrument, das den Ist-Zustand kontinuierlich misst und Abweichungen meldet. Beide gehören zusammen: Data Quality beschreibt, was gilt, Data Observability zeigt, ob es gilt.
Data Lineage	Sicht-Typ	Lineage ist die statische Struktur-Sicht (Beziehungs-Karte zwischen Assets). Data Observability ist die dynamische Signal-Sicht auf denselben Assets. Bei einem Vorfall meldet Observability das Symptom, Lineage zeigt die Kette der betroffenen Downstream-Konsumenten.
Data Testing (dbt tests)	Prüf-Modell	Assertion-basierte Tests wie dbt-Tests, Great Expectations oder SQL-Constraints prüfen bei jeder Pipeline-Ausführung eine explizit formulierte Regel (etwa: Null-Anteil unter fünf Prozent). Data Observability arbeitet mit lernenden Baselines und Anomalie-Erkennung; sie fängt Abweichungen ab, für die vorab keine Regel formuliert wurde. Tests decken Bekanntes ab, Observability das Unbekannte.
Application Observability	Objekt	Klassisches APM überwacht Anwendungs-Signale (Latenz, Speicher, HTTP-Status). Data Observability überwacht Daten-Signale (Frische, Volumen, Verteilungen). Die Signal-Modelle sind unterschiedlich, obwohl das Grundprinzip (Symptom, Trace, Root Cause) übertragen wurde.
Agent Observability	Domäne	Agent Observability misst das Laufzeitverhalten von KI-Agenten: Token-Kosten, Tool-Trajectories, Halluzinations-Rate, Guardrail-Trigger. Data Observability misst den Zustand der Daten, aus denen Agenten und Modelle lesen. Beide Disziplinen sitzen im selben Betriebs-Stack, adressieren aber verschiedene Ebenen.

Die zentrale Trennlinie verläuft zwischen Sollzustand und Messung. Data Quality, Data Contracts und dbt-Tests formulieren, was Daten leisten müssen. Data Observability liefert die kontinuierliche Messung darauf. Lineage bildet das Substrat, auf dem beide operieren.

Beispiel: Freshness- und Distribution-SLO auf einem Lakehouse

Ein Analytics-Team betreibt auf Databricks eine Silber-Schicht, die stündlich aus Bronze-CDC-Streams aktualisiert wird und drei Gold-Marts für BI-Dashboards speist. Databricks Lakehouse Monitoring läuft agent-los auf den relevanten Delta-Tabellen und errechnet nächtlich Metriken pro Tabelle: Freshness anhand des letzten Schreibzugriffs, Volume als Zeilen-Delta gegen den 30-Tage-Median, Schema-Drift über neue oder entfernte Spalten, Distribution über Null-Anteil, Min/Max und Kardinalität ausgewählter Spalten. Die Ergebnisse landen in Unity-Catalog-System-Tables und in einer Dashboard-Sicht auf denselben Tabellen.

Auf den Signalen laufen zwei SLOs. Der erste ist ein Freshness-SLO: „Silber ist bis 07:00 Uhr aktuell". Liegt die letzte Schreibmarke nach 07:15 Uhr, feuert ein PagerDuty-Alert an den Pipeline-Owner mit einem Trace-Link in die Lineage-Sicht, aus der sofort ersichtlich ist, welche Gold-Marts und Dashboards betroffen sind. Der zweite SLO läuft auf customer_id: Wenn der Null-Anteil an einem Tag um mehr als zwei Standardabweichungen vom Rolling-Mittelwert abweicht, öffnet das System automatisch ein Data-Quality-Ticket beim zuständigen Domain-Team. Beide Signale wären für dbt-Tests nur schwer als feste Schwellwerte formulierbar; der Baseline-Ansatz macht sie betreibbar. Für Kunden mit Monte Carlo, Bigeye oder Anomalo ist der Aufbau identisch, nur die Signal-Quelle sitzt außerhalb des Katalogs und liest über Konnektoren.