Data Observability: schlechte Daten abfangen, bevor sie Entscheidungen erreichen

Die Kosten schlechter Daten, die bis zu einer Entscheidung durchdringen, zeigen sich selten als einzelner katastrophaler Ausfall. Meist summieren sie sich leise: ein Revenue-Forecast auf Basis unvollständiger PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →-Daten, ein Churn-Modell, das auf falsch gelabelten Kundendatensätzen trainiert wurde, ein Board-Report mit Zahlen, die das Finance-Team nicht mehr abstimmen kann. Gartner hat die durchschnittlichen Kosten schlechter Datenqualität für große Organisationen auf 12,9 Millionen US-Dollar pro Jahr geschätzt, und diese Zahl liegt vor der Verbreitung von Echtzeit-ML-Pipelines, in denen veraltete oder beschädigte Daten innerhalb von Minuten durch Dutzende nachgelagerte Systeme laufen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen.

Der Druckpunkt 2026 ist die Geschwindigkeit, mit der Daten sich bewegen. Als Pipelines nächtliche Batch-Jobs ausführten, konnte ein Data Analyst Anomalien morgens erkennen, bevor etwas Folgenreiches passierte. Heute fließen Daten kontinuierlich in Dashboards, in AI-Inference-Pipelines, in automatisierte Pricing- und Kreditentscheidungen. Das Fenster zwischen dem Eintreffen von Daten in einem System und dem Moment, in dem diese Daten eine Handlung beeinflussen, ist zusammengeschrumpft. Observability ist die Disziplin, die diese Lücke füllt.

Eine Data-Observability-Praxis aufbauen: eine praktikable Reihenfolge

Schritt 1: die Decision Surfaces kartieren, nicht die Data Assets

Die meisten Organisationen gehen Datenqualität an, indem sie Tabellen katalogisieren und Owner zuweisen. Das ist notwendig, aber nicht ausreichend. Beginnen Sie stattdessen mit den Entscheidungen, die für das Geschäft am wichtigsten sind, und verfolgen Sie rückwärts, welche Daten sie speisen. Bei einer Retail-Bank kann die Decision Surface die Anpassung von Kreditlimits durch ein automatisiertes Modell sein. Bei einem Logistikunternehmen die dynamische Routenoptimierung. Listen Sie fünf bis zehn solcher Surfaces auf. Dokumentieren Sie für jede, welche Tabellen, Felder und Transformationen im kritischen Pfad liegen. Das verengt das Observability-Problem auf die Stellen, an denen Fehler tatsächlich wehtun.

Schritt 2: die fünf Dimensionen der Datengesundheit instrumentieren

Die Branche hat sich weitgehend auf fünf messbare Dimensionen verständigt: Freshness (kommen die Daten planmäßig an?), Volume (liegen die Row Counts in den erwarteten Grenzen?), SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → (haben sich Spaltentypen oder -namen geändert?), Distribution (sind Wertebereiche und Null-Raten stabil?) und Lineage (lässt sich eine Zahl bis zur Quelle zurückverfolgen?). Tools wie Monte Carlo (ein Anbieter, mit der entsprechenden kommerziellen Einordnung der von ihm veröffentlichten Benchmarks) und Open-Source-Optionen wie Great Expectations und Soda Core erlauben es, Expectations über diese Dimensionen zu definieren und bei Verletzungen zu alarmieren. Es geht nicht darum, am ersten Tag eine Plattform zu installieren. Es geht darum, für jede kritische Pipeline zu definieren, wie „normal“ aussieht, und diese Definition in einer Form festzuhalten, die eine Maschine prüfen kann.

Schritt 3: Thresholds am Entscheidungsimpact ausrichten, nicht am Datenvolumen

Ein häufiger Fehler ist, alle Anomalien gleich zu behandeln. Ein Rückgang der täglichen Transaktionszeilen um 2 % in einer Reporting-Tabelle für Quartalsreviews ist etwas völlig anderes als ein Rückgang um 2 % im Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen →, der ein Echtzeit-Fraud-Modell speist. Priorisieren Sie Alert-Thresholds nach nachgelagerten Konsequenzen. Für Pipelines, die automatisierte Entscheidungen speisen, setzen Sie enge Grenzen und leiten Alerts an On-Call-Engineers. Für Pipelines, die Wochen-Dashboards speisen, genügt ein täglicher Digest. Das verhindert Alert Fatigue, den schnellsten Weg, ein Observability-Programm zu beenden.

Schritt 4: den Kreis mit Data SLAs schließen

Observability ohne Verantwortlichkeit ist ein Monitoring-Dashboard, das niemand ansieht. Formalisieren Sie Data SLAs mit den Teams, die kritische Daten produzieren und konsumieren. Das müssen keine langen Rechtsdokumente sein. Eine einseitige Vereinbarung mit erwarteter Freshness, akzeptablen Null-Raten und Eskalationswegen reicht. Das Data-Engineering-Team von Airbnb hat öffentlich darüber geschrieben, wie interne SLAs die Mean Time to Detect und Repair bei Pipeline-Fehlern senken. Das SLA schafft eine gemeinsame Sprache: Wenn ein Alert auslöst, weiß jeder, wer den Fix verantwortet und welches Auflösungsfenster akzeptabel ist.

Schritt 5: Checks in die Pipeline integrieren, nicht daneben

Tests, die als nachträgliche Checks auf einer fertigen Pipeline laufen, erkennen Fehler erst, nachdem die Daten im Zielsystem gelandet sind. Instrumentieren Sie Checks möglichst an Transformationsgrenzen, sodass ein Fehler die Weitergabe blockiert. In dbt (data build tool) heißt das, das native Test-Framework zu nutzen, um einen Run zu stoppen, wenn ein Uniqueness- oder Not-Null-Test fehlschlägt, statt schlechte Zeilen in Produktionstabellen laufen zu lassen. Je früher in der Pipeline ein Fehler erkannt wird, desto günstiger ist die Behebung.

Fallstricke, die Observability-Programme scheitern lassen

Der erste: eine Plattform kaufen, bevor das Problem definiert ist. Anbieter in diesem Feld, darunter Monte Carlo, Acceldata und Bigeye (alle kommerzielle Produkte), verkaufen ausgefeilte Anomalieerkennung. Diese Fähigkeiten sind wirklich nützlich, aber Teams, die sie einführen, ohne zuerst die Decision Surfaces zu kartieren, überwachen am Ende alles und handeln bei nichts.

Der zweite: Observability als Data-Engineering-Projekt behandeln. Wenn Business-Stakeholder nicht wissen, dass ein Data SLA existiert, melden sie keine Fehler, sondern verlieren stillschweigend das Vertrauen in die Daten und kehren zu Spreadsheets zurück. Die Aufgabe des CDO ist es, Datenqualität als Business-Metrik sichtbar zu machen, nicht als technische Metrik. Nehmen Sie Fehlerraten und SLA-Compliance in denselben Review-Rhythmus wie Pipeline-Uptime auf.

Der dritte Fallstrick sind statische Thresholds auf dynamischen Daten. Das Transaktionsvolumen eines Händlers im Dezember sieht völlig anders aus als im Februar. Anomalieerkennung mit festen Grenzen löst in der Peak Season hunderte False Alerts aus. Nutzen Sie Baselines, die Saisonalität berücksichtigen, oder prüfen Sie Thresholds mindestens quartalsweise.

Quick Wins für diese Woche

• Wählen Sie ein Dashboard oder Modell mit hohem Einsatz. Schreiben Sie in einfacher Sprache auf, wie die zuführenden Daten aussehen sollen: erwartete Row Counts, Null-Raten der Schlüsselfelder, Refresh-Zeitplan. Das ist Ihr erster SLA-Entwurf.
• Fügen Sie einer einzelnen Produktionstransformation eine Great-Expectations-Suite oder einen dbt-Test-Block hinzu. Selbst drei oder vier einfache Tests schaffen eine Erkennungsschicht, die es gestern noch nicht gab.
• Ziehen Sie die Incident-Logs der Pipelines der letzten sechs Monate. Identifizieren Sie die drei Fehler, die nachgelagert die größte Verwirrung ausgelöst haben. Diese Pipelines sind Ihre vorrangigen Instrumentierungsziele.
• Setzen Sie ein 30-minütiges Gespräch zwischen einem Data Engineer und dem Business Owner eines kritischen Reports an, um abzustimmen, was „schlechte Daten“ für diesen konkreten Use Case bedeutet.

Observability ist keine Produktkategorie. Es ist ein Set von Praktiken, die bewusstes Design, Rückhalt der Stakeholder und laufende Kalibrierung erfordern. Ein Team, das klare Expectations definiert, die richtigen Checkpoints instrumentiert und Alerts mit verantwortlichen Ownern verbindet, fängt die meisten Fehler ab, bevor sie eine Entscheidung erreichen. Das ist das Ergebnis, auf das es sich hinzuarbeiten lohnt.