Lakehouse Monitoring auf Databricks: Drift und Datenqualität zentral überwachen
Wie Lakehouse Monitoring mit Snapshot, Time Series und Inference Profile Drift und Datenqualität in Unity Catalog beobachten kann.
Die Kernaussagen auf einen Blick.
- Lakehouse Monitoring stellt in Unity Catalog eine Beobachtungsschicht für Tabellen bereit. Es unterstützt drei Profile: Snapshot für den aktuellen Qualitätsstand, Time Series für Drift über die Zeit und Inference Profile für Modell-Inferenz-Logs.
- Ein wesentlicher Vorteil liegt in der engen Plattform-Integration. Metriken werden als UC-Tabellen abgelegt, Dashboards und Alerts sind direkt anschließbar, und der Tabellen-Owner kann als verantwortliche Stelle einbezogen werden.
- Vor einem Rollout sollten unter anderem folgende Punkte geklärt werden: für welche Tabellen ein Monitoring als Standard sinnvoll ist, welche Modelle ein Inference Profile benötigen und wie Drift-Befunde an Re-Train-Workflows angebunden werden können.
- Empfehlenswert ist, Lakehouse Monitoring als Standard für UC-Datenprodukte vorzusehen und für produktive Modelle ein Inference Profile zu aktivieren. Ergänzende Werkzeuge kommen dort infrage, wo die Beobachtung über die UC-Tabellen hinausgehen soll.
Inhaltsverzeichnis
Monatelang falsche Vorhersagen, niemand merkt es
Wenn ein produktives Modell schleichend an Qualität verliert, ist das oft erst über fachliche Auswirkungen sichtbar. Ein Churn-Modell etwa kann über mehrere Monate hinweg Vorhersagen liefern, die nicht mehr zur tatsächlichen Abwanderung in einer Region passen. In solchen Fällen folgt häufig eine aufwendige Analyse, in der sich zeigt, dass sich die Verteilung einer Feature-Tabelle verschoben hat und niemand diese Veränderung früh genug bemerkt hat. Das Resultat können Wochen oder Monate ungenauer Vorhersagen mit entsprechenden Auswirkungen auf nachgelagerte Prozesse sein.
Ähnliche Muster können auftreten, sobald erste Datenprodukte produktiv genutzt werden und keine klar zugeordnete Verantwortung für deren Beobachtung definiert ist. Eine Bronze-Tabelle kann etwa unbemerkt einen deutlich höheren Anteil an Null-Werten in einer Schlüsselspalte aufweisen, während die Pipeline weiterläuft. Inferenz-Logs eines Modells können sich gegenüber dem Trainingsstand verschoben haben, ohne dass dies systematisch verglichen wird. Eigene Werkzeuge für Datenqualität, andere für Modell-Drift und parallel dazu die Unity-Catalog-Lineage führen zu mehreren Sichten, deren Konsistenz nicht ohne Weiteres gegeben ist.
In dieser Konstellation stellen sich typischerweise folgende Fragen:
- Wer ist verantwortlich, wenn eine UC-Tabelle ihre statistischen Eigenschaften verändert?
- Wie lässt sich ein Drift-Befund frühzeitig als Re-Train-Signal nutzen, bevor er sich in Geschäftskennzahlen zeigt?
- Reicht das vorhandene Werkzeug für Datenqualität aus oder beobachtet es eine andere Schicht?
- Wie werden die Inferenz-Logs eines Model-Serving-Endpoints regelmäßig ausgewertet?
Ein möglicher Ansatz: Daten- und Modellqualität in einer gemeinsamen Beobachtungsschicht zusammenführen, die direkt mit den UC-Tabellen verbunden ist. Andernfalls können Drift und Qualitätsabweichungen leicht zu Zufallsbefunden werden.
Was ist Databricks Lakehouse Monitoring?
Lakehouse Monitoring (offiziell Mosaic AI Lakehouse Monitoring, in der Microsoft-Doku auch unter Data Quality Monitoring geführt) beobachtet UC-Tabellen anhand statistischer Kennzahlen. Pro überwachte Tabelle wird ein Profil angelegt, das seine Ergebnisse in zwei generierten UC-Tabellen speichert: _profile_metrics für Statistiken pro Spalte, Slice und Zeitfenster sowie _drift_metrics für Drift-Signale gegenüber einer Baseline. Ergänzend wird je Monitor ein Dashboard angelegt.
Die Schicht ist nicht als Modell-Evaluations-Engine konzipiert. Sie ermittelt zum Beispiel keine Accuracy-Werte gegenüber Hold-out-Sets; diese Aufgaben übernimmt MLflow Evaluate, gegebenenfalls in Verbindung mit LLM-Judge-Methoden. Sie bewertet stattdessen, ob sich die Verteilung von Eingaben und Ausgaben gegenüber einer Referenz verschiebt. Auch fachliche Regelprüfungen auf Zeilenebene gehören nicht zu ihrem Funktionsumfang; diese können DLT-Expectations oder Werkzeuge wie Great Expectations abbilden. Im Fokus steht die statistische Stabilität von Daten und Modell-Ein-/Ausgaben.
Daraus ergibt sich ein klar abgegrenztes Einsatzfeld: Lakehouse Monitoring siedelt sich zwischen Pipeline-Validierung und Modell-Evaluation an.
Pipeline-Expectations
Prüfen einzelne Zeilen gegen Regeln und greifen aktiv in den Pipeline-Lauf ein.
Lakehouse Monitoring
Betrachtet ganze Spalten und Verteilungen über die Zeit, rein beobachtend und ohne Eingriff.
Modell-Evaluation
Vergleicht Vorhersagen mit Labels, typischerweise vor dem Rollout eines Modellkandidaten.
Erst im Zusammenspiel dieser drei Schichten entsteht eine durchgängige Beobachtungsstruktur für eine produktive ML-Plattform.
Drei Profile bilden den Kern. Die folgende Übersicht zeigt, welches Profil sich für welche Tabellenart eignet:
| Profil | Beobachtet | Use Case | Voraussetzung |
|---|---|---|---|
| Snapshot | Aktueller Stand der Tabelle | Daten-Qualität, Verteilungen, Schema-Sicht auf eine Stichtags-Tabelle | UC-Tabelle, optional Baseline-Snapshot |
| Time Series | Statistiken über Zeitfenster | Drift einer Datenprodukt-Tabelle gegen frühere Fenster oder Baseline | Time-Series-Spalte (Timestamp), optional Baseline-Tabelle |
| Inference Profile | Inferenz-Logs eines Modells | Modell-Input-/Output-Drift, Klassifikations-/Regressions-Metriken pro Modell-Version | Spalten , , optional und |
Wie sich Lakehouse Monitoring in das größere AI-Umfeld auf Databricks einordnen lässt (Feature Store, MLflow, Model Registry, Serving, Governance), zeigen wir im Überblick zu Artificial Intelligence auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie zeigt Snapshot-Monitoring die Qualität?
Ein Snapshot-Monitor wird ohne Zeit-Achse auf eine Tabelle angewendet. Er berechnet Aggregat-Statistiken über alle Zeilen, zum Beispiel Null-Anteil pro Spalte, Distinct-Count, Minimum und Maximum, Mittelwert, Quantile und Verteilungseigenschaften. Die Ergebnisse werden in _profile_metrics abgelegt und enthalten pro Refresh einen entsprechenden Eintrag.
Dieses Profil eignet sich für Tabellen, die als Ganzes betrachtet werden sollen. Dazu zählen beispielsweise Referenzdaten, Stammdaten oder Stichtags-Snapshots aus dem Bronze-Layer. Bei einer einmal täglich neu geschriebenen Kundenstamm-Tabelle kann Snapshot-Monitoring etwa rasch erkennbar machen, wenn sich der Anteil fehlender Werte in einer wichtigen Spalte deutlich erhöht oder die Anzahl aktiver Kunden ungewöhnlich abweicht. Über eine optionale Baseline-Tabelle (eine zweite UC-Tabelle mit identischem Schema und festem Referenzstand) lässt sich zusätzlich ein Vergleich mit einer bekannten Referenzversion einrichten. Die Drift-Distanz wird in diesem Fall pro Spalte gegen die Baseline berechnet.
Snapshot deckt eine andere Schicht ab als Expectations in Lakeflow Declarative Pipelines. Eine Expectation kann eine Zeile ablehnen oder die Pipeline anhalten, etwa wenn email IS NULL. Snapshot zeigt dagegen, dass der Null-Anteil aktuell beispielsweise bei 12 Prozent liegt, während er zuvor bei 0,5 Prozent lag. Der Befund ist damit primär beobachtend. Beide Ansätze haben ihre Berechtigung: harte Regelprüfung auf Zeilenebene und statistische Sicht auf die Spalte.
Wie erkennt Time-Series-Monitoring Drift?
Time Series ist das vorgesehene Profil für Drift-Beobachtung über die Zeit. Es speichert Statistiken pro Zeitfenster, mit einer Default-Granularität (Detail-Stufe der Zeitfenster) auf täglicher oder stündlicher Ebene. Verglichen werden in der Regel zwei Konstellationen: Zeitfenster gegen Zeitfenster (zum Beispiel die Verteilung von gestern gegenüber vorgestern) und Zeitfenster gegen eine Baseline-Tabelle (zum Beispiel die Verteilung der letzten 24 Stunden gegen den Trainings-Cut-off eines nachgelagerten Modells).
Die Drift-Signale liegen in _drift_metrics. Für numerische Spalten kann der Monitor Wasserstein-Distanz und Kolmogorov-Smirnow-Statistik berechnen, für kategoriale Spalten Chi-Quadrat-Werte. Schwellenwerte sind nicht fest vorgegeben. Als grobe Orientierung können Wasserstein-Distanzen über 0,1 als Hinweis auf relevante Verschiebungen dienen, höhere Werte ab etwa 0,3 als Anlass für einen Alarm. Im konkreten Anwendungsfall sollten Schwellen jedoch anhand der jeweiligen Daten kalibriert werden.
Das Profil benötigt eine Zeitachsen-Spalte. Eine Feature-Tabelle mit einer Spalte wie event_ts ist dafür typisch. Detail-Stufe und Slice-Spalten (zum Beispiel region oder product_segment) beeinflussen die Aussagekraft der Befunde. Sehr viele Slices können die Kosten der Refresh-Pipeline erhöhen. Sehr wenige Slices können dazu führen, dass Drift in einem Mittelwert verborgen bleibt, der gegenläufige Segmente glättet. Die Auswahl der Slices ist daher eine Modellierungsentscheidung und sollte sich am fachlichen Zuschnitt der Datenprodukte orientieren.
Drift-Beobachtung ohne Baseline kann sinnvoll sein, wenn die zugrunde liegenden Datenmuster grundsätzlich stabil bleiben sollen. Drift gegen eine Baseline bietet sich an, wenn ein konkretes Modell die Tabelle als Trainingsquelle nutzt und die Trainings-Snapshot-Version als Referenz dienen soll. Welche Modellversion die Baseline definiert, hängt unter anderem vom Champion-Eintrag in der Registry ab. Der konkrete Bezug zur Modellversion wird im Überblick zur Mosaic AI Model Registry genauer beschrieben.
Wie erkennt das Inference Profile Modell-Drift?
Inference Profile ist das jüngste der drei Profile und auf Model-Serving-Endpoints zugeschnitten. Es kann auf die Auto-Capture-Tabelle eines Endpoints zugreifen, also auf die Inference Table, in der Databricks Anfragen, Antworten, Latenzen und Modellversion pro Aufruf protokolliert. Daraus lassen sich zum Beispiel Drift der Input-Features gegen eine Baseline ableiten, typischerweise gegen die Trainings-Verteilung der Champion-Version. Wenn eine label-Spalte vorhanden ist, können zusätzlich Klassifikations- oder Regressions-Metriken berechnet werden.
Die Spaltenkonvention ist klar definiert: prediction, model_id, optional label und optional eine features-Struktur. Bei Model Serving mit aktivierten Inference Tables stellt die Plattform diese Struktur bereits zur Verfügung. Bei Endpoints außerhalb von Databricks muss die Log-Tabelle vor dem Profil-Lauf in dieses Schema überführt werden. Das Profil arbeitet anschließend grundsätzlich identisch, ein direkter Bezug zur MLflow-Version geht in diesem Fall jedoch verloren.
Inference Profile bezieht sich auf einen anderen Zeitpunkt im Modelllebenszyklus als MLflow Evaluate. Evaluate vergleicht Kandidatenmodelle in einem Eval-Lauf gegen ein Hold-out-Set. Inference Profile beobachtet ein produktives Modell anhand seiner Inferenz-Logs. Beide Sichten liefern Qualitätssignale zu unterschiedlichen Zeitpunkten: Evaluate vor dem Rollout, Inference Profile im laufenden Betrieb danach. Wie die Eval-Seite mit MLflow zusammenspielt, betrachten wir im Überblick zu Managed MLflow auf Databricks.
Ein praktischer Hinweis zur Inference Table als Quelle: Die Auto-Capture-Tabelle sollte vom Endpoint-Owner in einem UC-Schema mit klar geregelter Verantwortung angelegt werden. Andernfalls besteht das Risiko, dass das Inference Profile auf einer Log-Tabelle aufsetzt, die nicht dauerhaft gepflegt wird, und Drift-Befunde keiner verantwortlichen Stelle zugeordnet sind. Wie Auto-Capture und Inference Tables konkret aufgesetzt werden, zeigen wir im Überblick zu Model Serving auf Databricks.
Die Monitor-Tabellen weiterverwenden
Jeder Monitor erzeugt zwei UC-Tabellen in einem konfigurierbaren Monitoring-Schema. <tabelle>_profile_metrics enthält Statistiken pro Spalte und Zeitfenster, <tabelle>_drift_metrics enthält Drift-Signale pro Spalte und Vergleichsanker (Zeitfenster gegen Zeitfenster, Zeitfenster gegen Baseline). Ein wichtiger Vorteil der Plattform-Integration besteht darin, dass Drift- und Qualitätsinformationen in Form regulärer UC-Tabellen vorliegen. Für diese Metriken-Tabellen sind die üblichen UC-Mechanismen nutzbar, beispielsweise SQL-Abfragen, BI-Anschluss, Verarbeitung in Jobs, Berechtigungsmodell und Lineage.
Eine beispielhafte Abfrage auf _drift_metrics für ein Inference Profile, die die Wasserstein-Drift einer Input-Spalte gegen die Baseline darstellt:
Daraus ergibt sich eine organisatorische Konsequenz. Auch die Metriken-Tabelle hat einen Owner, in der Regel denselben wie der Monitor, der wiederum den Tabellen-Owner widerspiegelt. Ein konsequent gepflegter Owner-Eintrag in UC kann Drift-Befunde direkt einer verantwortlichen Stelle zuordnen. Wie Owner-Eintrag und Lineage auf Tabellenebene funktionieren, zeigen wir im Überblick zur Unity-Catalog-Lineage.
Vom statistischen zum fachlichen Befund
Die Standardmetriken decken die statistische Sicht ab. Fachliche Schwellen erfordern in der Regel Custom Metrics. Sie werden als SQL-Expression definiert und mit jedem Refresh berechnet.
Aggregate Metric
Ein fachlicher Aggregatwert pro Zeitfenster, zum Beispiel der durchschnittliche Auftragswert pro Region.
Derived Metric
Eine abgeleitete Größe pro Zeile, zum Beispiel ein Quotient zwischen zwei Feature-Spalten.
Drift Metric
Eine fachlich definierte Drift-Distanz, zum Beispiel die Differenz zwischen erwartetem und beobachtetem Verteilungs-Quantil.
Slicing kann eine aggregierte Verteilung in segmentspezifische Sichten auflösen. Ein Modell kann auf Mittelwerten stabil erscheinen, in einzelnen Regionen oder Produktsegmenten jedoch bereits Veränderungen zeigen. Bis zu rund hundert Slice-Kombinationen können sinnvoll sein, darüber hinaus können die Refresh-Kosten überproportional steigen und einzelne Befunde statistisch dünn werden. Die Auswahl der Slices sollte sich an den Verantwortlichkeiten und Datenproduktgrenzen orientieren und nicht an der maximalen Detail-Stufe, die SQL technisch erlaubt.
Custom Metrics können als fachliche Brücke zwischen Anwendungsbereich und Monitoring-System dienen. Ohne definierte Schwellen liefert der Monitor zwar technische Daten, ohne dass daraus fachliche Reaktionen ausgelöst werden. Mit definierten Schwellen rücken Befunde auf eine Ebene, auf der konkrete Entscheidungen abgeleitet werden können.
Dashboards und Alerts
Pro Monitor erzeugt Databricks ein Dashboard, das wichtige Verteilungen und Drift-Signale visualisiert. Das Dashboard wird automatisch angelegt und ist anpassbar. Es ersetzt keinen vollständigen BI-Layer, kann aber als Standardeinstieg ohne weiteren Konfigurationsaufwand dienen. Für eine übergreifende Sicht über mehrere Tabellen oder Modelle (zum Beispiel alle Drift-Befunde in einer Übersicht) lässt sich ein eigenes Databricks-SQL-Dashboard auf den Metriken-Tabellen aufbauen.
Alerts lassen sich über Databricks SQL Alerts auf den Metriken-Tabellen einrichten. Ein typisches Beispiel könnte sein: Eine Wasserstein-Distanz einer als kritisch eingestuften Input-Spalte überschreitet im 24-Stunden-Vergleich gegen die Baseline einen definierten Schwellenwert wie 0,25. Der Alert enthält Schwelle, Empfänger und Aktualisierungsintervall. Die Befunde können von dort an externe Systeme wie Slack, PagerDuty oder E-Mail weitergeleitet werden, ohne dass ein zweites Werkzeug die Daten zusätzlich vorhalten muss.
Operativ wird der Monitor in eine geplante Refresh-Pipeline eingebunden. Refresh-Frequenz, Detail-Stufe der Time-Series und Anzahl der Slices wirken sich auf die Kosten pro Refresh aus. Eine stündliche Inference-Profile-Refresh-Pipeline für ein hochfrequentes Modell mit feinem Slicing verursacht in der Regel deutlich mehr Aufwand als ein tägliches Snapshot-Profil auf einer Stammdaten-Tabelle. Eine engmaschige Drift-Erkennung im Stundenraster hat ihren Preis. Ein größerer zeitlicher Abstand reduziert die Kosten meist erheblich.
Integration in den ML-Stack
In einer produktiven ML-Plattform kann Drift an mehreren Punkten sichtbar werden: am Eingang in den Feature Store, beim Modelltraining, beim Eintrag in der Model Registry sowie am Inferenz-Endpoint. Lakehouse Monitoring kann an drei dieser Stationen unterstützen.
Am Feature-Eingang kann Time-Series-Monitoring auf den Feature-Tabellen Verschiebungen erkennen. Bewegt sich die Verteilung einer Trainings-Feature, kann dies ein frühes Drift-Signal sein. Wie Feature-Tabellen organisiert werden und welche Schicht die Verantwortung trägt, zeigen wir im Überblick zum Feature Store auf Databricks.
Während des Modelltrainings ist Lakehouse Monitoring nicht direkt im Einsatz. Trainingsläufe werden in der Regel mit MLflow nachverfolgt. Sobald ein Modell jedoch als Champion in der Registry geführt wird, kann seine Trainings-Verteilung als natürliche Baseline für nachgelagerte Inference-Profile-Monitore dienen. Konzeptionell entspricht die Baseline-Tabelle des Inference Profiles häufig der Snapshot-Version des Trainingsdatensatzes der Champion-Version.
Am Inferenz-Endpoint kann das Inference Profile auf die Auto-Capture-Tabelle aufsetzen. Damit kann der Kreis zwischen Training und produktivem Betrieb geschlossen werden: Drift gegenüber der Trainings-Verteilung der Champion-Version macht erkennbar, ob das produktive Modell noch in einem Datenkontext arbeitet, der dem ursprünglichen Trainingskontext entspricht.
Kein Re-Training auf Knopfdruck
Lakehouse Monitoring sieht keinen integrierten Re-Train-Trigger vor. Stattdessen werden Drift-Signale als UC-Tabelle bereitgestellt. Ein Re-Train kann anschließend über einen Databricks Workflow ausgelöst werden, der diese Tabelle regelmäßig abfragt und auf definierte Schwellen reagiert. Überschreitet ein Drift-Signal die zulässige Grenze, kann der Workflow einen Re-Train-Job anstoßen.
Diese Trennung ist bewusst gewählt. Ein automatisches Re-Training bei jedem Drift-Befund ist selten zielführend. Auch ein Datenproblem, ein Saisonalitätseffekt oder eine einmalige Kampagne können Drift verursachen, ohne dass das Modell tatsächlich an Qualität verloren hat. Der Workflow stellt die Stelle dar, an der zwischen technischem Befund und ausgelöster Aktion eine fachliche Bewertung vorgesehen werden kann.
Eine pragmatische Umsetzung: Ein täglich laufender Workflow liest die Drift-Metriken-Tabelle, vergleicht die Tagesmaxima ausgewählter Spalten mit Schwellenwerten aus einer Konfigurationstabelle und entscheidet zwischen drei möglichen Aktionen:
Moderate Drift
Eine Slack-Benachrichtigung informiert das verantwortliche Team.
Höhere Drift
Ein Ticket im Issue-Tracker mit erforderlicher fachlicher Bewertung wird erstellt.
Höhere Drift + weitere Bedingungen
Der Trainings-Workflow wird automatisch getriggert.
Der Monitor stellt die Datenbasis, der Workflow trägt die fachliche Logik.
Drift als Teil der AI-Governance
Der EU AI Act und vergleichbare regulatorische Rahmenwerke sehen für Hochrisiko-KI-Systeme eine kontinuierliche Beobachtung von Leistung und Robustheit nach Inverkehrbringen vor. Ein Inference Profile mit aktivierter Drift-Erkennung und angebundener Alert-Strecke kann eine technische Grundlage hierfür bilden: Die Beobachtung erfolgt automatisiert, Befunde liegen in einer auditierbaren UC-Tabelle vor, eine verantwortliche Stelle ist über UC zugeordnet, und Reaktionen sind in einem Workflow dokumentiert.
Damit dieser Anschluss tragfähig ist, sollten unter anderem folgende Konventionen etabliert werden.
Eindeutiger Owner
Die Inference Table eines Endpoints hat einen eindeutig benannten Verantwortlichen.
Standard-Monitor pro Endpoint
Jeder Endpoint bekommt einen zugehörigen Monitor als Standardvorgabe.
Audit-Trail für Reaktionen
Reaktionen auf Drift-Befunde sind nachvollziehbar dokumentiert, etwa über Tickets, Workflow-Ausführungen oder Modellversion-Updates.
Wie der breitere Governance-Rahmen für KI-Modelle auf Databricks aussehen kann, behandeln wir im Überblick zur AI-Governance auf Databricks.
Wann ergänzen externe Werkzeuge?
Lakehouse Monitoring ist auf die Beobachtung von Tabellen in Unity Catalog ausgerichtet. Für Anwendungsfälle außerhalb dieses Bereichs können externe Werkzeuge sinnvoll sein. Gleichzeitig gibt es Konstellationen, in denen Doppelungen eher schaden.
Sinnvoll als Ergänzung können Werkzeuge sein, deren Beobachtungsumfang über die Databricks-Plattform hinausgeht. Lösungen wie Monte Carlo oder Anomalo können beispielsweise Cross-System-Lineage über mehrere Datenquellen hinweg darstellen, etwa wenn Postgres, Snowflake und Databricks gemeinsam betrachtet werden sollen. Werkzeuge wie Arize, WhyLabs oder Evidently bieten zudem speziellere Funktionen für Modellbeobachtung, beispielsweise Embeddings-Drift, RAG-Qualitätssignale oder den Vergleich mehrerer Modelle. Solche Funktionen können über das hinausgehen, was Inference Profile aktuell abdecken.
Doppelungen können entstehen, wenn ein externes Werkzeug dieselbe UC-Tabelle beobachtet wie Lakehouse Monitoring. Ein zusätzliches Great-Expectations-Setup für Verteilungschecks auf einer Silver-Tabelle kann zu zwei Quellen für denselben Befund führen, gegebenenfalls mit unterschiedlichen Schwellen, Refresh-Intervallen und Owner-Modellen. Die Sichten werden in diesem Fall breiter, jedoch weniger eindeutig.
Externes Tool ergänzen, wenn
- Beobachtung über mehrere Datenquellen hinweg nötig ist, etwa Postgres, Snowflake und Databricks gemeinsam
- Modellspezifische Signale wie Embeddings-Drift oder RAG-Qualität gebraucht werden
- Mehrere Modelle direkt gegeneinander verglichen werden sollen
Kein zusätzliches Tool nötig, wenn
- Dieselbe UC-Tabelle bereits von Lakehouse Monitoring beobachtet wird
- Die Beobachtung sich auf UC-Tabellen und produktive Modelle beschränkt
- DLT-Expectations die Zeilenebene bereits regelbasiert prüfen
Eine pragmatische Aufteilung kann diese Doppelungen vermeiden:
DLT-Expectations
Regelbasierte Zeilenprüfungen direkt in der Pipeline.
Lakehouse Monitoring
Statistische Sicht auf UC-Tabellen.
Externe Werkzeuge
Dort, wo die Beobachtung über Unity Catalog hinausgeht.
Was Lakehouse Monitoring nicht abdeckt
In Plattform-Diskussionen treten regelmäßig drei Verwechslungen auf, die hier kurz abgegrenzt werden sollen.
Keine Modell-Evaluations-Engine
Vergleicht keine Modellkandidaten gegen ein Hold-out-Set, berechnet keine F1-Scores und führt keine LLM-Judge-Bewertungen aus. Das übernehmen MLflow Evaluate und entsprechende LLM-Erweiterungen.
Kein Pipeline-Orchestrator
Greift nicht aktiv in einen Pipeline-Lauf ein und lehnt keine Zeilen ab. Betrachtet das Ergebnis einer Pipeline aus statistischer Sicht.
Kein System-Monitoring
Cluster-Auslastung, Job-Laufzeiten und Endpoint-Latenz liegen außerhalb des Beobachtungsbereichs. Dafür stehen andere Werkzeuge wie das Databricks-System-Monitoring zur Verfügung.
Wie die System Tables in der Plattform eingesetzt werden, zeigen wir im Überblick zu Unity Catalog System Tables.
Grenzen
Lakehouse Monitoring fokussiert auf die statistische Sicht auf UC-Tabellen. Es deckt nicht alle Drift- und Qualitätsanforderungen einer ML-Plattform vollständig ab.
Kein eingebauter Re-Train-Trigger
Ein automatisierter Re-Train muss über einen separaten Workflow umgesetzt werden. Ein einfacher täglicher Job auf der Drift-Metriken-Tabelle kann ein praktikabler Einstieg sein.
Custom-Metrics-API mit Einarbeitung
Die SQL-Expression-Form ist flexibel, jedoch nicht trivial. Die Definition belastbarer fachlicher Schwellen erfordert in der Regel mehrere Iterationen, bis ein passendes Signal-Rausch-Verhältnis erreicht ist.
Begrenzte Anzahl an Slices
Bis zu rund hundert Slice-Kombinationen pro Monitor sind in der Praxis sinnvoll. Eine feiner aufgelöste Segmentierung erfordert geteilte Monitore oder ein zusätzliches Observability-Werkzeug.
Kosten pro Refresh
Jeder Refresh ist ein Compute-Job. Hochfrequentes Monitoring auf großen Tabellen mit vielen Slices kann nennenswerte Kosten verursachen. Refresh-Frequenz und Detail-Stufe sind hier zentrale Kostenhebel.
Keine semantische Bewertung von LLM-Antworten
Für die Qualität von LLM-Ausgaben (etwa Relevanz, Faithfulness, Toxizität) eignen sich MLflow Evaluate und LLM-Judge-Methoden besser. Lakehouse Monitoring rechnet keine semantischen Metriken.
Reifegradhinweis
Inference Profile war über einen längeren Zeitraum als Public Preview verfügbar. Vor einem produktiven Einsatz sollte der aktuelle Status für die eigene Cloud, Region und Konstellation geprüft werden, bevor Service-Level zugesagt werden.
Fazit
Lakehouse Monitoring kann besonders dann Mehrwert bieten, wenn erste Datenprodukte und Modelle produktiv betrieben werden und Drift- oder Qualitätsbefunde zuverlässig erfasst werden sollen.
Der Nutzen ist besonders hoch, wenn Owner-Verantwortung, AI-Governance-Anschluss und Re-Train-Logik gemeinsam in einer Plattform abgebildet werden sollen. Die Integration mit Unity Catalog kann diese drei Aspekte in einer gemeinsamen Schicht zusammenführen.
Steht die Einführung von Unity Catalog noch am Anfang und sind klare Verantwortlichkeiten für die einzelnen Tabellen noch nicht etabliert, ist Lakehouse Monitoring nicht zwingend der nächste sinnvolle Schritt. Ohne klar zugeordnete Verantwortung können Drift-Befunde organisatorisch nicht wirksam werden.
Empfehlenswert ist folgender Ansatz: Lakehouse Monitoring als Standard für UC-Datenprodukte vorsehen (Time-Series-Profil), Inference Profile für produktive Modelle aktivieren und Re-Train-Trigger als Workflow auf _drift_metrics aufsetzen. Externe Werkzeuge kommen dort in Betracht, wo die Beobachtung über UC hinausgehen soll, etwa bei Cross-Plattform-Lineage oder LLM-spezifischen Drift-Signalen. Auf dieser Grundlage kann in überschaubarer Zeit eine Beobachtungsschicht entstehen, die mit der Plattform wächst.
<!-- CTA rendert automatisch zwischen Fazit und FAQ aus Frontmatter cta: (articleCta-Block), kein eigener Body-Content mehr nötig. -->
FAQ
Lakehouse Monitoring ist die Tabellen-Beobachtungsschicht in Unity Catalog. Sie misst statistische Eigenschaften von UC-Tabellen über drei Profile: Snapshot für den aktuellen Stand, Time Series für Drift über Zeit und Inference Profile für Modell-Inferenz-Logs. Die Metriken landen als generierte UC-Tabellen (, ) mit auto-generiertem Dashboard pro Monitor.
