Lakehouse Monitoring: Definition, Metriken, Abgrenzung

Lakehouse Monitoring ist eine in Databricks eingebaute Funktion, die dauerhaft misst, wie sich die Daten in einer Tabelle verändern (Zahlenverteilungen, Lücken, Ausreißer) und Alarm schlägt, sobald sich das Bild vom Normalzustand entfernt. Databricks meint mit „Lakehouse" seine eigene Daten-Plattform; „Monitoring" heißt hier: automatische Kennzahlen-Tabellen, ein mitgeliefertes Dashboard (Übersichtsseite mit Diagrammen) und Alerts (E-Mail- oder Ticket-Benachrichtigungen), sobald ein Schwellenwert überschritten wird.

Was ist Lakehouse Monitoring?

Lakehouse Monitoring ist ein Dienst innerhalb des Unity Catalog (der Berechtigungs- und Katalog-Schicht von Databricks, in der alle Tabellen und Modelle registriert sind). Der Dienst prüft kontinuierlich, wie die Daten in einer Tabelle aussehen (Verteilung der Werte, Anteil an Null-Werten, Extremwerte) und wie stark sich dieses Bild gegenüber einer Referenzperiode verschiebt. Databricks hat die Funktion 2023 als Public Preview (öffentliche Testphase) vorgestellt und 2024 in die General Availability (GA, offizieller Produktivbetrieb) überführt. Sie ersetzt die frühere Kombination aus selbstgebauten Metrik-Jobs und MLflow-basiertem Data-Drift-Monitoring (Modell-Abweichungs-Überwachung im Databricks-Machine-Learning-Werkzeug MLflow) durch ein einzelnes Monitor-Objekt, das direkt am Katalog-Eintrag der Tabelle hängt.

Pro überwachter Tabelle wird ein Monitor angelegt. Databricks unterscheidet drei Analyse-Typen. TimeSeries berechnet Profil- und Verteilungs-Metriken über eine Timestamp-Spalte und ist der Standard-Typ für Bronze- und Silber-Tabellen mit Event-Charakter. Snapshot berechnet die Kennzahlen pro Refresh-Lauf ohne Zeitachse und passt für tabellarische Referenzdaten oder Dimensionstabellen. InferenceLog ist der Model-Monitoring-Typ: Er erwartet eine Prediction-Spalte, optional eine verzögert eintreffende Ground-Truth-Spalte und liefert Modell-Drift-, Genauigkeits- und Fairness-Kennzahlen für Modelle, die auf Databricks Model Serving oder außerhalb laufen.

Die erzeugten Metriken decken drei Ebenen ab. Auf der Tabellen-Ebene entstehen Zeilenzahl, Refresh-Zeitpunkt und Änderungs-Deltas. Auf der Spalten-Ebene werden Null-Anteil, Kardinalität, Min, Max, Mittelwert, Standardabweichung und Perzentile berechnet; für kategoriale Spalten zusätzlich Kategorien-Verteilungen. Auf der Drift-Ebene vergleicht der Monitor jedes Fenster gegen eine Baseline-Tabelle oder das vorhergehende Fenster und liefert statistische Distanzmaße wie Jensen-Shannon-Divergenz, Chi-Quadrat oder Wasserstein-Distanz. Benutzerdefinierte Metriken sind als SQL-Expression konfigurierbar und laufen im selben Refresh mit.

Der Output landet als zwei Delta-Tabellen pro Monitor im Katalog, benannt nach der überwachten Tabelle: eine Profile-Metrics-Tabelle mit den Kennzahlen pro Spalte und Fenster und eine Drift-Metrics-Tabelle mit den Vergleichs-Kennzahlen. Zusätzlich generiert der Dienst ein Databricks-SQL-Dashboard mit Zeitreihen-Views auf beide Tabellen. Refresh-Jobs laufen auf Serverless-Compute, entweder ad-hoc oder per Cron-Zeitplan. Konfiguriert wird der Monitor über die Catalog-UI, den REST-API-Endpunkt /api/2.1/unity-catalog/tables/{table}/monitor, das Databricks-Python-SDK, Databricks Asset Bundles oder den Terraform-Provider.

Abgrenzung zu Data Observability, Data Quality und Anomaly Detection

Lakehouse Monitoring wird häufig mit angrenzenden Begriffen synonym verwendet, obwohl die Rollen im Betriebs-Stack unterschiedlich sind.

Begriff	Achse	Kernunterschied
Data Observability	Disziplin vs. Produkt	Data Observability ist die Betriebs-Disziplin (Freshness, Volume, Schema, Distribution, Lineage) unabhängig vom Werkzeug. Lakehouse Monitoring ist eine konkrete Implementierung dieser Disziplin auf Databricks, mit Schwerpunkt auf Distribution und Drift; Freshness- und Schema-Signale kommen aus Unity-Catalog-System-Tabellen und Lineage-Objekten.
Data Quality	Soll vs. Ist	Data Quality definiert Sollzustände über Regeln, CHECK-Constraints, dbt-Tests oder Data Contracts. Lakehouse Monitoring liefert die kontinuierliche Ist-Messung; die Regel-Definition selbst bleibt außerhalb des Monitors.
Anomaly Detection	Methode vs. Framework	Anomaly Detection ist die statistische Methode (Isolation Forest, DBSCAN, Z-Score, LOF). Lakehouse Monitoring nutzt statistische Distanzmaße als Baustein hinter den Drift-Metriken; es bleibt ein Monitoring-Framework mit festem Metrik-Katalog und keine offene Anomalie-Engine.
Data Lineage	Signal vs. Struktur	Data Lineage bildet die statische Beziehungs-Karte zwischen Tabellen, Notebooks und Dashboards. Lakehouse Monitoring erzeugt Signal-Zeitreihen auf einzelnen Tabellen. Bei einem Vorfall zeigt der Monitor das Symptom, die Unity-Catalog-Lineage zeigt die betroffenen Downstream-Konsumenten.
Deequ / Great Expectations	Assertion vs. Baseline	Assertion-Frameworks wie Deequ und Great Expectations prüfen bei jeder Pipeline-Ausführung explizit formulierte Regeln (Null-Anteil < 5 %, Wertebereiche, Foreign-Key-Konsistenz). Lakehouse Monitoring arbeitet ohne Regel-Deklaration mit lernenden Baselines und Distanzmaßen und deckt damit Abweichungen ab, für die vorab keine Regel formuliert wurde.

Die Trennlinie verläuft zwischen Konzept, Regel und Messung. Data Observability, Data Quality und Anomaly Detection bezeichnen Disziplinen oder Methoden. Lakehouse Monitoring ist die produktisierte Umsetzung dieser Disziplinen in Unity Catalog: die kontinuierliche Baseline-Ebene neben den Assertion-Tests und Data Contracts, die weiter auf Regel-Ebene arbeiten.

Beispiel: TimeSeries- und InferenceLog-Monitor auf einer Delta-Tabelle

Ein Analytics-Team betreibt in Unity Catalog die Silber-Tabelle sales.silver.orders und legt darauf einen TimeSeries-Monitor an. Konfiguriert werden ein 24-Stunden-Fenster über order_ts, die Spalten customer_id, product_id und amount_eur, eine Baseline-Referenz auf den Vormonats-Snapshot und ein Cron-Refresh 02:00 UTC. Nach jedem Lauf entstehen zwei Metrics-Tabellen im selben Schema: sales.silver.orders_profile_metrics und sales.silver.orders_drift_metrics. Auf der Drift-Tabelle läuft ein Databricks-SQL-Alert, der die Wasserstein-Distanz von amount_eur gegen die Baseline überwacht und den Data-Owner benachrichtigt, sobald die Distanz über 0,25 steigt. Das automatisch generierte Dashboard verlinkt in denselben Metrics-Tabellen die Zeitreihen für Null-Anteile und Kardinalität pro Spalte.

Parallel überwacht das MLOps-Team die Tabelle mlops.gold.churn_predictions über einen InferenceLog-Monitor. Die Konfiguration verweist auf die Prediction-Spalte, das Modell-Version-Label und die verzögert eintreffende Ground-Truth-Spalte. Der Monitor rechnet nach jedem Refresh Prediction-Drift gegen das vorhergehende Fenster und Modell-Genauigkeit (F1, Accuracy, ROC-AUC) gegen die Ground Truth. Ein zweiter Alert öffnet ein Ticket, sobald die F1-Metrik unter einen definierten Schwellwert fällt oder die Fairness-Kennzahl für ein segmentiertes Attribut außerhalb der erwarteten Bandbreite liegt. Beide Monitore laufen auf Serverless-Compute, ihre Konfiguration ist in einem Databricks Asset Bundle abgelegt und wird über die CI/CD-Strecke deployt.