Databricks System Tables: FinOps, Audit und Lineage zentral auswerten
Die Kernaussagen auf einen Blick.
- Databricks System Tables stellen Betriebs-, Abrechnungs-, Audit- und Lineage-Daten als SQL-abfragbare Tabellen im Catalog system bereit.
- Für FinOps und Audit werden dadurch viele manuelle Exporte aus Account-Konsole, Cloud-Abrechnung und Log-Speichern ersetzt oder deutlich reduziert.
- Besonders wichtig sind system.billing, system.access, system.compute, system.lineage und system.information_schema. Zugriffe sollten über klare Gruppen für FinOps, Audit und Plattform-Engineering vergeben werden.
- Für belastbare Kostenberichte reichen System Tables allein nicht aus. Erst verbindliche Tags für Domänen, Kostenstellen, Workloads und Umgebungen machen DBU-Verbrauch fachlich auswertbar.
Inhaltsverzeichnis
Wer die Kosten nicht sieht, steuert sie nicht
Im Quartalsgespräch mit dem CFO zeigt sich ein typisches Problem. Die Databricks-Rechnung ist um achtzehn Prozent gestiegen. Die Kosten lassen sich jedoch nicht zuverlässig einzelnen Domänen und Workloads zuordnen. Die Cloud-Abrechnung zeigt VM-Kosten. Die Account-Konsole zeigt Aggregate. Der FinOps-Verantwortliche zieht ein CSV aus der Konsole, ein zweites aus dem Cloud-Konto, ein drittes aus einem Drittanbieter-Tool. Die Ergebnisse der unterschiedlichen Quellen weichen voneinander ab und lassen sich nur schwer abgleichen.
Kurz darauf fordert die interne Revision eine Auswertung der Tabellenzugriffe des vergangenen Quartals. Die Beantwortung erfordert mehrere Tage manueller Aufbereitung, weil die Logs erst aus dem Storage-Export gefiltert, geparst und gegen das Active Directory abgeglichen werden müssen.
Eine solche Situation entsteht häufig in Plattformen, die über mehrere Teams und Workspaces hinweg wachsen. Die Geschäftsdaten werden bereits über Unity Catalog verwaltet, Betriebs- und Nutzungsdaten liegen jedoch weiterhin in getrennten Systemen. Die Plattform stellt Datenprodukte bereit, bietet aber ohne entsprechende Auswertung keine einheitliche Sicht auf ihren eigenen Betrieb.
Welches Team verantwortet die Zuordnung des DBU-Verbrauchs zu Domänen und Workloads? Auf welche Tabellen wurde in den letzten 90 Tagen lesend zugegriffen? Welcher Job verursacht den größten Anteil am Serverless-Spend? Aus welchen Tabellen und Pipelines stammen die Daten eines zentralen KPI-Dashboards?
So lange diese Fragen außerhalb der Plattform beantwortet werden, bleiben Kostensteuerung und Auditierung reaktiv und mit hohem manuellem Aufwand verbunden. Das zentrale Problem besteht darin, dass Betriebs-, Abrechnungs- und Auditdaten nicht im selben Analyse- und Berechtigungsmodell ausgewertet werden wie die Geschäftsdaten, die daneben gepflegt werden.
Was sind Databricks System Tables?
System Tables stellen accountweite Betriebs- und Governance-Daten als SQL-abfragbare Tabellen im Catalog system bereit. Der Catalog enthält unter anderem Schemas für Abrechnung, Zugriffe, Compute, Lineage und Metadaten als reguläre Delta-Tabellen. Databricks dokumentiert sie als "Databricks-hosted analytical store of your account's operational data", nutzbar für Cost-Monitoring, Security-Audit und Compute-Auswertung.
Drei Eigenschaften verändern das Betriebsmodell für FinOps und Audit wesentlich.
Erstens werden System Tables direkt über Unity Catalog berechtigt. Der Zugriff läuft über GRANT SELECT, die Tabellen lassen sich wie andere Tabellen abfragen, und es braucht kein separates Analyse- oder Berechtigungsmodell.
Zweitens sind System Tables für analytische und forensische Auswertungen gedacht. Sie werden mit zeitlichem Versatz aktualisiert und ersetzen deshalb kein Echtzeit-Monitoring oder unmittelbare Security-Reaktion.
Drittens bleiben Cloud-Kosten, Infrastrukturmetriken und SIEM-Daten wichtige Ergänzungen. VM-Kosten kommen weiterhin aus dem Cloud-Konto, ein SIEM bleibt für Security-Response zuständig. System Tables liefern vor allem die Databricks-interne Sicht auf Verbrauch, Zugriffe und Abhängigkeiten.
Architektonisch folgt daraus: Viele FinOps- und Auditfragen lassen sich direkt in Databricks auswerten, ohne eigene Export- und Aufbereitungspipelines zu bauen. Die Analyse läuft im selben SQL-, Berechtigungs- und Governance-Modell wie andere Plattformdaten. Im Unity Catalog wird die Plattform damit selbst zur Datenquelle.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
System Catalog im Unity Catalog: Billing, Access, Compute, Lineage und Information Schema
Der system-Catalog ist in mehrere Schemas geteilt. Jedes Schema deckt einen klar abgegrenzten Analysebereich ab. Aktivierung und Zugriffsrechte werden für die einzelnen Schemas separat verwaltet.
| Schema | Wichtige Tabellen | Wofür | Aktivierung | Typische Query |
|---|---|---|---|---|
| system.billing | usage, list_prices | DBU-Verbrauch pro Workspace, Cluster, Job, SKU; Listenpreise als Referenz | Default aktiv (GA) | FinOps pro Domäne und Workload |
| system.access | audit, table_lineage, column_lineage | API-/UI-Aktionen, Privilegien-Änderungen, Lese-/Schreib-Zugriffe | Aktivierung pro Schema | Audit-Antworten auf Zugriffe |
| system.compute | clusters, warehouses, node_types, node_timeline | Compute-Konfigurationen, Lebenszyklus, Skalierungs-Events | Aktivierung pro Schema | Lebenszyklus-Auswertung, Idle-Time |
| system.query | history | SQL-Queries mit Laufzeit, Warehouse, Datenmenge, Identität | Aktivierung pro Schema | Teuerste und langsamste Queries |
| system.lineage | table_lineage, column_lineage | Lineage-Events als Tabelle, mit Quelle, Ziel, Workflow, Zeitstempel | Aktivierung pro Schema | Lineage in eigenen Reports |
| system.information_schema | tables, columns, table_privileges, routines | Metadaten zu Catalogs, Schemas, Tabellen, Privilegien | Default aktiv | Inventar und Zugriffsmatrix |
Der Umfang der verfügbaren System-Schemas wird regelmäßig erweitert. Databricks ergänzt Sub-Schemas wie Marketplace, Serving-Endpoints und Storage. Dieser Artikel konzentriert sich auf Billing, Access, Compute, Query History und Lineage, da sie für FinOps und Plattformbetrieb besonders relevant sind. Die folgenden Abschnitte gehen die wichtigsten Schemas einzeln durch.
Information Schema
system.information_schema.* ist Standard-SQL und liefert Metadaten zu Catalogs, Schemas, Tabellen, Spalten und Privilegien. Damit lässt sich der aktuelle Berechtigungsstand von Catalogs, Schemas und Tabellen strukturiert auswerten. Zusammen mit den Auditdaten ergänzt das Information Schema den aktuellen Berechtigungsstand um die Änderungshistorie.
Databricks Billing System Tables für Cost Monitoring und FinOps
system.billing.usage bildet die zentrale Grundlage für die Analyse des Databricks-Verbrauchs, weil sie DBU-Verbrauch pro Workspace, Cluster, Job, SKU und Zeitfenster enthält. Über die Spalten usage_metadata.job_id, cluster_id, warehouse_id, notebook_id lässt sich der Verbrauch einer Workload genau zuordnen. Die Spalte custom_tags trägt die Tags des Compute-Objekts. Auf diesen Metadaten bauen die meisten FinOps-Auswertungen auf.
system.billing.list_prices liefert die Listenpreise nach Region und SKU. Durch die Verknüpfung mit den Listenpreisen lässt sich der Verbrauch in einen geschätzten Geldwert übersetzen. Vertragliche Rabatte und individuelle Konditionen sind darin jedoch nicht automatisch berücksichtigt. Sie müssen in der Reporting-Schicht zusätzlich einbezogen werden.
Auf dieser Basis lassen sich die meisten Fragen rund um FinOps und Kostenkontrolle direkt beantworten, die für Management, FinOps und Plattformbetrieb regelmäßig relevant sind.
DBU pro Domäne und Workload-Familie. Voraussetzung sind einheitliche und verpflichtend vergebene Compute-Tags: der Tag domain auf jedem Job, jedem Warehouse, jedem Cluster. Damit kann der Verbrauch direkt nach Domäne oder Kostenstelle aggregiert werden über usage_metadata.custom_tags['domain']. Eine zusätzliche Export- oder Aufbereitungspipeline ist dafür nicht erforderlich.
Serverless gegen Classic vergleichen. Über sku_name lässt sich Serverless SQL gegen Classic SQL für dasselbe Warehouse vergleichen. Die tatsächlichen Verbrauchsdaten sind die verlässlichste Grundlage für die Entscheidung, ob ein bestehendes Warehouse auf Serverless umgestellt wird.
Job-Kosten priorisieren. Eine Top-50-Liste der teuersten Jobs der letzten 30 Tage, sortiert nach DBU-Verbrauch, joint system.billing.usage mit system.workflow.job_run_timeline. Eine Rangliste der teuersten Jobs ermöglicht eine gezielte Priorisierung von Optimierungsmaßnahmen. In vielen Plattformen entfällt ein großer Teil des Verbrauchs auf eine vergleichsweise kleine Zahl von Jobs.
Die abrechnungsnahe Kostensicht entsteht erst in der Reporting-Schicht. System Tables liefern die Nutzungsmengen, Rabatte und individuelle Konditionen werden anschließend ergänzt. Diese Trennung hält Verbrauchsdaten und Preislogik sauber auseinander.
Access Audit Logs in System Tables auswerten
system.access.audit stellt die zentrale, über Unity Catalog zugängliche Quelle für Databricks-Auditereignisse dar. Sie enthält Anmeldungen, API-Aufrufe, Berechtigungsänderungen, UI-Aktionen und vor allem Datenzugriffe in Form von unityCatalog-Aktionen wie getTable und executeQuery. Das vollständige Audit-Log-Schema mit allen action_name-Werten und Servicekategorien ist in der Databricks-Dokumentation aufgeführt.
Die Tabelle enthält Felder wie event_time, user_identity.email, action_name, request_params, service_name und response. Damit lassen sich die meisten Audit-Anfragen, die Governance und Compliance regelmäßig bekommen, mit standardisierten SQL-Auswertungen beantworten.
Vier typische Audit-Queries:
Lese-Zugriffe auf eine Tabelle
Ein Filter auf die Aktion getTable mit dem Tabellennamen im Request, gruppiert nach Nutzer und Zeitfenster, zeigt alle Lesezugriffe deutlich schneller als eine eigene Exportpipeline mit Dashboard.
Privilegien-Änderungen
Ein Filter auf die Aktion updatePermissions, sortiert nach Zeitstempel, zeigt, wer wann ein Grant auf eine Produktiv-Tabelle vergeben hat.
Sensible Aktionen
Ein Filter auf das Löschen oder Ändern von Catalogs und Schemas fängt kritische Eingriffe ab, die eine regelmäßige Prüfung oder Alarmierung verlangen.
Login-Pattern
Anmeldungen im Service accounts lassen sich über die IP-Felder auch geografisch einordnen und direkt in Databricks analysieren.
Wie Privilegien-Vergaben strukturiert werden, klären wir im Überblick zu Berechtigungen im Unity Catalog.
System Tables ersetzen jedoch kein SIEM (Security Information and Event Management), also die Plattform, die sicherheitsrelevante Events zentral sammelt, korreliert und alarmiert. Die Tabelle hat eine Stunden-Verzögerung und eignet sich vor allem für nachgelagerte Analysen und forensische Auswertungen. Für zeitkritische Erkennung und Reaktion bleibt ein angebundenes SIEM erforderlich.
Compute-Kosten mit Clustern, Warehouses und Jobs verbinden
system.compute.clusters und system.compute.warehouses enthalten Konfigurationen und Lebenszyklus-Ereignisse von Clustern und SQL Warehouses. Erstellt, terminiert, verändert: Änderungen sind mit Zeitstempel und verantwortlicher Identität nachvollziehbar. system.compute.node_timeline ergänzt die Auslastung einzelner Knoten über die Zeit.
Der Wert entsteht in der Verknüpfung mit den Billing-Daten. Die Verbindung zu system.billing.usage läuft über cluster_id und warehouse_id, die Verbindung zu Jobs über usage_metadata.job_id. Damit wird aus reinem DBU-Verbrauch eine Aussage über den Kostentreiber: welche Cluster-Konfiguration, welches Warehouse, welcher Job den Verbrauch verursacht.
Drei Auswertungen sind für den Betrieb besonders nützlich:
Idle-Zeit und Autoscaling. Über node_timeline und die Cluster-Events lässt sich erkennen, welche Cluster lange laufen, ohne ausgelastet zu sein. Überdimensionierte Autoscaling-Grenzen und zu lange Auto-Termination-Fenster werden so sichtbar.
Warehouse-Dimensionierung. Für SQL Warehouses zeigt die Verbindung aus Warehouse-Konfiguration und Verbrauch, ob Größe und Auto-Stop zur tatsächlichen Nutzung passen.
Kostentreiber pro Konfiguration. Der Join aus system.billing.usage und system.compute ordnet den Verbrauch der konkreten Cluster- oder Warehouse-Konfiguration zu. Das trennt teure Konfiguration von teurer Nutzung.
Query History: SQL-Kosten, Performance und Nutzerverhalten analysieren
system.query.history führt jede ausgeführte SQL-Query mit Performance-, Compute- und User-Kontext. Jede Zeile enthält unter anderem die Laufzeit, das verwendete Warehouse, die gelesene Datenmenge und die ausführende Identität. Damit wird die Frage „Welche Queries verursachen die Spitzen im Warehouse?“ zu einer einfachen SQL-Auswertung.
Drei Fragestellungen lassen sich direkt beantworten:
Teuerste Queries. Sortiert nach Laufzeit oder gelesener Datenmenge zeigt die Tabelle, welche einzelnen Abfragen den größten Anteil an der Warehouse-Last tragen. Häufig sind es wenige wiederkehrende Reports.
Performance-Ausreißer. Queries mit auffälliger Laufzeit oder hohem Spill deuten auf fehlende Filter, ungünstige Joins oder zu kleine Warehouses hin.
Nutzerverhalten. Die Gruppierung nach Identität und Zeitfenster zeigt, welche Teams das Warehouse wann belasten. Das ist die Grundlage für die Entscheidung, ob ein gemeinsames Warehouse getrennt werden sollte.
Lineage System Tables für Abhängigkeiten und Audit-Berichte
system.lineage.table_lineage und system.lineage.column_lineage halten Lineage-Events als reguläre Tabelle vor, mit Quell- und Zieltyp, Workflow-Bezug und Zeitstempel.
Gegenüber der grafischen Lineage-Ansicht bringt das einen praktischen Vorteil: Die Events lassen sich per SQL auswerten, mit anderen Metadaten verbinden und in eigene Berichte übernehmen, auch über Workspace-Grenzen hinweg. So werden accountweite Auswertungen möglich, die die Standardansicht nicht abdeckt.
Zwei Anwendungsfälle stechen heraus:
Abhängigkeits-Analyse vor Änderungen. Bevor eine Tabelle umgebaut oder abgeschaltet wird, zeigt die Table-Lineage, welche Tabellen, Dashboards und Jobs daran hängen. Das senkt das Risiko, dass nachgelagerte Pipelines unbemerkt brechen.
Lineage in Audit-Berichten. Kommt die Frage, aus welchen Quellen die Daten eines KPI-Dashboards stammen, liefert die Column-Lineage die vollständige Kette bis zur Quelltabelle, belegbar und exportierbar.
Wie Lineage-Events mit Privilegien und Tag-Achsen zusammenkommen, klären wir im Überblick zu Lineage im Unity Catalog.
Wie aktiviert man System Tables?
Die Aktivierung erfolgt für die jeweiligen System-Schemas separat. system.billing und system.information_schema sind standardmäßig aktiv. system.access, system.compute, system.query und system.lineage müssen einmal aktiviert werden, entweder über die Account-Konsole oder über die Account API mit der Systemschemas-Endpoint-Familie. Aktivierung ist ein einmaliger Schritt pro Schema. Nach der Aktivierung stellt Databricks die entsprechenden Daten in den System Tables bereit.
Zwei Punkte sind operativ relevant. Erstens: Die Aktivierung verlangt Account-Admin-Rechte; Workspace-Admin reicht hier nicht aus. Zweitens: Daten stehen grundsätzlich erst ab dem Zeitpunkt der Aktivierung zur Verfügung. Vergangene Zeiträume lassen sich deshalb nicht nachträglich vollständig aus den System Tables rekonstruieren. Die benötigten Schemas sollten daher möglichst früh im Plattformaufbau aktiviert werden.
Berechtigung läuft über das normale GRANT-Modell. Beispiel:
Die Zugriffsvergabe sollte sich an klar definierten Verantwortungsgruppen orientieren:
- FinOps-Analyse bekommt system.billing und system.compute, weil DBU-Verbrauch und Compute-Lebenszyklus zusammen die Kostenfrage beantworten.
- Audit-Verantwortung bekommt system.access und system.information_schema, weil Zugriffs- und Privilegien-Antworten dort liegen.
- Plattform-Engineering bekommt vollen Lese-Zugriff auf alle Schemas, da das Plattformteam für übergreifende Betriebs- und Fehleranalysen Zugriff auf die relevanten Schemas benötigt.
Berechtigungen sollten nicht direkt an einzelne Personen vergeben werden, weil Mitarbeiterwechsel die Zugriffs-Matrix instabil machen. Accountweite Gruppen mit klarer Rollenbeschreibung sind für eine stabile Berechtigungsstruktur besser geeignet.
System Tables liefern nur dann brauchbare Kostenauswertungen, wenn der Verbrauch sauber zugeordnet werden kann. Ohne gepflegte Tags sieht man zwar technische Nutzung, aber nicht zuverlässig, welche Domäne, Kostenstelle oder Umgebung dafür verantwortlich ist.
Dafür braucht es vor allem zwei Arten von Tags. Compute-Tags auf Clustern und Warehouses helfen, DBU-Verbrauch und Kosten zuzuordnen. Object Tags im Unity Catalog beschreiben Datenobjekte wie Catalogs, Schemas oder Tabellen, zum Beispiel nach Domäne oder Datenklassifikation.
Wichtig ist ein einfaches und verbindliches Tag-Modell. In vielen Plattformen reichen wenige Pflichtfelder, etwa domain, cost-center, environment und data-classification. Diese Tags sollten beim Anlegen von Compute-Ressourcen und Datenobjekten gesetzt werden müssen. Sonst bleiben Teile des Verbrauchs später unklar oder müssen manuell nachgearbeitet werden.
Wie Tags und Vererbung im Unity Catalog funktionieren, ordnen wir im Überblick zu Tags im Unity Catalog ein. Für System Tables gilt: Sie schaffen die Datenbasis für Kosten-, Nutzungs- und Audit-Auswertungen, ersetzen aber kein sauberes Tag-Modell.
FinOps-Dashboards auf System Tables bauen
Für die Visualisierung bieten sich zwei grundlegende Wege an: AI/BI Dashboards direkt auf den System Tables, oder Power BI beziehungsweise Tableau über den Databricks-SQL-Connector.
AI/BI Dashboards direkt wählen, wenn
- Geschwindigkeit vor Integration zählt, weil Dashboards in derselben Plattform entstehen wie die Daten
- Ein gemeinsames Berechtigungsmodell für Daten und Dashboards ausreicht
- Domänen-Teams selbst Self-Service über Workspace-Sharing bekommen sollen
Power BI oder Tableau wählen, wenn
- FinOps- und Auditberichte in eine bestehende unternehmensweite BI-Landschaft integriert werden sollen
- Ein Service-Principal mit Lesezugriff auf die relevanten System-Schemas vorgesehen ist
- FinOps-Domäne und Geschäftsdaten-Domäne im BI-Tool klar getrennt bleiben müssen
Grenzen von Databricks System Tables
System Tables liefern eine strukturierte Sicht auf Nutzung, Kosten, Zugriffe und Abhängigkeiten innerhalb der Databricks-Plattform. Sie ersetzen aber nicht alle bestehenden Betriebs-, Kosten- und Security-Quellen. Für das Betriebsmodell sind vor allem fünf Grenzen wichtig.
Keine Echtzeitquelle
Die Daten werden mit Verzögerung aktualisiert, häufig im Stundenbereich. Für Live-Monitoring, Alerting oder unmittelbare Sicherheitsreaktionen braucht es weiterhin operative Metriken, Logs und Workspace-Telemetrie.
Cloud-Kosten bleiben getrennt
Die Billing-Tabellen zeigen den Databricks-Verbrauch, aber nicht automatisch alle VM-, Netzwerk- und Speicherkosten des Cloud-Anbieters. Eine vollständige Kostenrechnung verbindet deshalb beide Quellen.
Kein Ersatz für ein SIEM
Für die Erkennung und Reaktion auf Sicherheitsereignisse in Minuten braucht es weiterhin Systeme wie Microsoft Sentinel oder Splunk. System Tables ergänzen das um eine SQL-basierte Quelle für spätere Analyse.
Historie ist nicht unbegrenzt
Die Aufbewahrung unterscheidet sich je nach Schema. Für längere Zeiträume braucht es eine regelmäßige Archivierung in einen eigenen Audit- oder Reporting-Catalog.
IDs brauchen fachliche Übersetzung
Technische Felder wie Cluster-, Job- oder Warehouse-ID müssen in der Reporting-Schicht auf Anwendungen, Produkte, Teams oder Kostenstellen gemappt werden.
Zusätzlich sollten produktive Dashboards robust gebaut werden. Databricks kann System Tables erweitern und neue Spalten ergänzen. Explizite Spaltenlisten sind deshalb stabiler als SELECT *.
Die wichtigste Einordnung: System Tables machen Databricks selbst auswertbar. Sie schaffen eine starke Grundlage für Kosten-, Nutzungs- und Audit-Analysen, ersetzen aber kein Echtzeit-Monitoring, keine Cloud-Abrechnung, kein SIEM und kein sauberes fachliches Mapping.
Fazit
System Tables sind die zentrale Grundlage für Kosten-, Audit- und Lineage-Auswertungen in Databricks.
Sie ersetzen keine Cloud-Kostendaten, kein Echtzeit-Monitoring und kein SIEM. Sie machen aber viele Betriebs- und Governance-Fragen direkt in Databricks auswertbar, im selben SQL- und Berechtigungsmodell wie andere Plattformdaten.
Relevant wird das vor allem, wenn Kosten regelmäßig erklärt werden müssen, sich aber nur schwer Teams, Domänen oder Workloads zuordnen lassen. Ebenso bei Audit-Anfragen, die heute noch manuelle Exporte und mehrere Aufbereitungsschritte benötigen. Wenn Unity Catalog bereits eingeführt ist, sollten System Tables früh aktiviert werden. Ohne saubere UC-Grundlage fehlt jedoch die Governance-Basis dafür.
Mein Vorschlag: Billing, Access, Compute und Lineage aktivieren, die Zugriffe getrennt für FinOps, Audit und Plattform-Engineering vergeben und vor dem Dashboard-Aufbau ein verbindliches Tag-Modell festlegen. Zusätzliche FinOps-Tools können danach gezielt ergänzen, statt erst die grundlegende Datengrundlage herstellen zu müssen.
Billing, Access, Compute und Lineage aktivieren, die Zugriffe getrennt für FinOps, Audit und Plattform-Engineering vergeben und vor dem Dashboard-Aufbau ein verbindliches Tag-Modell festlegen.
FAQ
System Tables sind ein vom Unity Catalog bereitgestellter Catalog namens system mit Schemas zu Billing, Access, Compute, Lineage und Metadaten. Sie liefern die operativen Daten der Databricks-Plattform als reguläre SQL-Tabellen unter dem normalen Berechtigungsmodell. Damit werden Kostenmonitoring, Audit-Auswertung und Lineage-Analyse zu SQL-Fragen auf der Plattform selbst.
