Data Observability: Datenqualität überwachen, ein Score je Lauf

Weil ein Bericht nicht zeigt, wie alt seine Zahlen sind. Ein stehender Ladelauf meldet sich nicht. Der Bericht öffnet sich wie jeden Morgen und zeigt Zahlen. So beginnt der Auftrag für einen Data & AI Berater: Ein Bericht hat tagelang Zahlen gezeigt, und sie waren alt. Aufgefallen ist es durch Zufall, weil jemand einen Auftrag vom Vortag suchte.

Das Team will vom Berater eines wissen: woran es den Stillstand am ersten Morgen erkannt hätte. Er sucht deshalb zuerst, was gefehlt hat, damit jemand den Fehler sieht. Es sind vier Dinge. Der Bericht nennt das Alter seiner Daten nicht. Niemand zählt die Sätze zwischen den Schichten. Kein Lauf hinterlässt ein Ergebnis, mit dem sich der nächste vergleichen ließe. Und niemand ist benannt, der bei einem Stillstand handelt.

Für diese Lücke gibt es einen Begriff: Data Observability. Meist werden fünf Merkmale genannt, die Tabelle unter der Kurzantwort zeigt sie. Data Quality Monitoring ist der Teil davon, der Regeln mit Zielwert nach jedem Ladelauf misst. Im Deutschen heißt das: Datenqualität überwachen.

Der Berater baut dafür kein neues Werkzeug. Die Regeln gibt es schon, sie stammen aus der ersten Messung. Wie aus einer Regel ein Test wird, steht im Kapitel Datenvalidierung. Hier geht es um das, was danach kommt: Die Tests laufen nach jedem Ladelauf, und ihr Ergebnis bleibt erhalten. Diese Messung heißt im Folgenden kurz: der Lauf.

Am jüngsten Ladezeitstempel in den Daten, nicht allein am Status des Ladelaufs. Ein Ladelauf kann ohne Fehler enden und trotzdem nichts laden, etwa weil die Quelle nichts geliefert hat. Der Status sagt dann: gelaufen. Die Daten sagen: seit Tagen nichts Neues.

Der Berater liest deshalb beides, den Status und die Daten. Eine Task führt SQL nach Zeitplan aus, eine Dynamic Table hält das Ergebnis einer Abfrage selbst aktuell. Für beide gibt es eine Historie mit dem Status jedes Laufs. Die Tabelle nennt die Messpunkte, Stand November 2026. Was die Rolle nicht sehen darf, fehlt auch hier.

Dazu kommen zwei Regeln aus dem Katalog, beide als Satz mit Zielwert. Die erste: Der jüngste Ladezeitstempel jeder Schicht ist höchstens zwei Tage alt. Die zweite: Zwei Schichten zählen gleich viele Sätze, mit einem Zielwert von zum Beispiel 99,5 %. Jede Regel ist eine Abfrage, die zählt und vergleicht. Einzelne Datensätze liest sie nicht.

Eine Stelle im Code kann den Stillstand zusätzlich verdecken. Endet die Datumsachse eines Berichts an der Systemuhr, zeigt er jeden Tag ein neues Datum, auch ohne neue Daten. Die Regel dazu gehört zur Messung am Code: Die Datumsachse endet am letzten Ladelauf.

Jeder Lauf speichert sein Ergebnis in einem eigenen Ordner und schreibt eine Zeile in eine Verlaufsdatei. Im Ordner liegen das Ergebnis je Regel, die Themen mit fehlenden Punkten und das Protokoll der Abfragen. So lässt sich jeder Score später nachrechnen. Die Zeile im Verlauf nennt Zeitpunkt, Score und die Version des Regelkatalogs.

Die Version steht dabei, weil sich zwei Läufe nur mit denselben Regeln und Zielwerten vergleichen lassen. Kommt eine Regel dazu, ändert sich der Score, ohne dass sich die Daten geändert haben. Der Verlauf zeigt deshalb auch, wie viele Regeln gewertet wurden, zum Beispiel 38 von 42 Regeln. Wer einen Sprung im Score sieht, prüft zuerst diese beiden Angaben.

Gemessen wird in zwei Takten. Die Regeln für die Daten laufen nach jedem Ladelauf, denn jede Lieferung kann die Daten ändern. Die Regeln für den Code laufen nach jeder Änderung am Code, dazwischen ändert er sich nicht. Was eine geplante Änderung berührt, zeigt eine Abfrage auf dem Graphen schon im Merge Request.

Auf Ordnern und Verlaufsdatei liegt ein Bericht in Power BI. Sein Modell ist selbst in drei Schichten gebaut. Bronze übernimmt die Dateien eins zu eins, Silber gibt ihnen Typen und Namen, Gold stellt die Kennzahlen bereit. Für das Monitoring gelten damit dieselben Regeln wie für das Warehouse, das es prüft. Der Bericht liest nur Ergebnisse, also Zählungen, Anteile und Zeitpunkte.

Sechs Elemente, und jedes beantwortet genau eine Frage. Die erste Seite ist für den Morgen gebaut. Wer sie öffnet, soll ohne Klick sehen, ob er den Zahlen heute trauen kann. Alles Weitere steht auf den Seiten dahinter.

Die Reihenfolge folgt den Fragen des Lesers. Zuerst kommt der Score mit seiner Richtung. Danach die Dimension, in der Punkte fehlen. Dann das Alter der Daten je Schicht, denn ein guter Score von vorgestern hilft heute niemandem. Die Tabelle zeigt alle sechs Elemente mit Beispielwerten.

Am vierten Element hängt, ob etwas geschieht. Ein Score ohne Namen daneben ändert nichts. Deshalb stehen die drei Themen mit den meisten fehlenden Punkten auf der ersten Seite, jedes mit einem Zuständigen. Bleibt das Feld leer, ist das der erste Befund des Monitorings.

Das Alter der Daten gehört außerdem in jeden Bericht, der aus dem Warehouse liest. Dort sieht es auch, wer das Monitoring nie öffnet. Bei einem Datenprodukt ist das Alter Teil der zugesagten Qualität. Mehr dazu steht im Kapitel Datenprodukte finden.

Der Zuständige eines Themas, und nur, wenn eine Schwelle unterschritten ist. Eine Nachricht nach jedem Lauf wird zur Gewohnheit und dann überlesen. Deshalb bekommt der Score drei Farben: Grün ab 90 Punkten, Gelb ab 70 Punkten, darunter Rot. Die Schwellen sind Beispielwerte, das Team legt sie selbst fest.

Die Nachricht kommt aus dem Warehouse oder aus dem Werkzeug, das die Ladeläufe plant. In Snowflake gibt es dafür Alerts, Stand November 2026. Ein Alert ist ein Objekt mit drei Teilen: einer Bedingung, einem Zeitplan und einer Aktion. Die Aktion verschickt zum Beispiel eine E-Mail oder ruft einen Webhook auf. Bei Data Metric Functions kann Snowflake außerdem melden, wenn eine Erwartung verletzt ist. Einen Alert für veraltete Daten zeigt das Beispiel unter der Tabelle.

Der Berater legt mit dem Team je Nachricht drei Dinge fest: den Auslöser, den Empfänger und den ersten Handgriff. Der Handgriff steht in einer kurzen Anleitung, auf die die Nachricht verweist. Was danach geschieht, entscheidet der Zuständige. Der Agent misst, der Mensch entscheidet.

Fehlt einem Team die Zeit, die erste Seite jeden Morgen zu lesen, kann das jemand übernehmen. Bei Managed Agentic BI führt DBI Dokumentation, Regelprüfung und Monitoring als laufenden Service, die Freigabe bleibt beim Team. Wie ein solcher Betrieb als Kreislauf aussieht, zeigt das Kapitel BI Operations mit Agenten.

Am Vergleich zweier Versionen der Struktur, vor und nach einer Änderung. Eine Spalte, die umbenannt wird oder ihren Typ wechselt, muss keinen Ladelauf brechen. Sie trifft die Sicht, die sie liest. Die Regeln für Aktualität und Menge bleiben dabei erfüllt.

Dafür nutzt der Berater den Graphen in ABIS. Nach jeder Änderung am Code exportiert er die Definitionen neu, nur lesend, und liest sie in ABIS ein. Jedes Einlesen erzeugt eine neue Version des Graphen. Der Vergleich zweier Versionen zeigt, was in der Struktur dazugekommen, weggefallen oder anders ist. Die Wirkungsanalyse zeigt dazu, welche Sichten an einer geänderten Spalte hängen.

Das Einlesen startet ein Mensch. ABIS führt kein SQL auf Snowflake aus und beobachtet nichts zur Laufzeit. Es kennt weder Zeitplan noch Benachrichtigung. Aktualität, Menge und Nachricht bleiben deshalb Aufgaben des Warehouse.

Zur Laufzeit zählt Snowflake selbst, Stand November 2026. Die Data Metric Function SCHEMA_CHANGE_COUNT zählt Spalten, die zwischen zwei Auswertungen hinzugekommen, entfallen, umbenannt oder im Typ geändert sind. Sie sagt, dass sich etwas geändert hat. Der Graph sagt, was daran hängt. Beides zusammen ergibt die Nachricht, die ein Zuständiger braucht.

Das Monitoring zeigt, ob Daten und Code den vereinbarten Regeln folgen. Mehr zeigt es nicht. Ob eine Kennzahl fachlich richtig definiert ist, klärt weiter der Fachbereich. Snowflake ist dabei das Beispiel. Ordner, Verlauf und erste Seite lassen sich auf jedes Warehouse übertragen, das SQL spricht.

• Es misst nur, wofür es eine Regel gibt. Ein Fehler, den keine Regel beschreibt, fällt nicht auf. Nach jedem Vorfall kommt deshalb die Regel in den Katalog, die ihn gezeigt hätte.
• Ein Score ist nur mit demselben Katalog vergleichbar. Ändern sich Regeln oder Zielwerte, beginnt im Verlauf eine neue Reihe.
• Fällt der Ladelauf aus, kann die Messung mit ausfallen. Deshalb prüft ein eigener Alert, ob heute gemessen wurde.
• Es sieht, was die Rolle sieht. Objekte ohne Leserecht fehlen, und zwar ohne Hinweis.
• Der Graph ist eine Momentaufnahme, keine Überwachung. Er zeigt die Struktur zum Zeitpunkt des Einlesens. Was sich danach ändert, zeigt erst das nächste Einlesen.