System Tables (Databricks): Definition und Nutzung

System Tables sind ein von Databricks verwaltetes Set von Delta-Tabellen im accountweiten Katalog system, das operative Metriken der Databricks-Plattform bereitstellt: Billing, Zugriffe, Compute, Query-Historie und Lineage. Sie liefern die Datenbasis für FinOps-Auswertungen, Governance-Reports und Anomalie-Analysen innerhalb des Unity Catalogs.

Was sind System Tables?

System Tables sind read-only Delta-Tabellen, die Databricks im vorbelegten Katalog system bewirtschaftet. Schema und Ladeprozess liegen bei Databricks; Kunden lesen die Tabellen wie andere Delta-Tabellen aus Databricks SQL, Notebooks oder externen BI-Werkzeugen (Power BI, Tableau, Looker) über JDBC- und ODBC-Endpunkte. Der Zugriff wird über Unity Catalog per GRANT SELECT vergeben.

Der system-Catalog ist in Schemas geteilt, die jeweils einen abgegrenzten Analysebereich abdecken. system.billing (u.a. usage, list_prices) zeigt den DBU-Verbrauch pro Workspace, Cluster, Job und SKU sowie die zugehörigen Listenpreise. system.access (u.a. audit) enthält Auditereignisse: Anmeldungen, API-Aufrufe, Berechtigungsänderungen, Tabellen-Zugriffe. system.compute liefert Cluster- und Warehouse-Lebenszyklus samt Node-Timeline. system.query.history protokolliert SQL-Queries mit Laufzeit, Datenmenge und Identität. system.lineage stellt Table- und Column-Lineage als Tabelle bereit. Ergänzt wird das durch system.information_schema (ANSI-Katalog-Metadaten) sowie neuere Schemas für Marketplace-Nutzung und Model-Serving.

Die Aktualisierung erfolgt mit zeitlichem Versatz und zielt auf analytische und forensische Auswertungen. Unmittelbare Security-Reaktion liegt außerhalb dieses Zwecks. Einige Schemas sind per Default aktiv (u.a. billing, information_schema); andere wie access, compute, lineage und query müssen pro Metastore explizit aktiviert werden. Der Begriff existiert, weil operative Daten der Plattform sonst über Export-Pipelines aus Account-Konsole, Cloud-Storage-Audit-Bucket und Cloud-Provider-Billing-Export in separate Reporting-Systeme wandern. System Tables fassen diese Ebenen im selben Analyse- und Berechtigungsmodell zusammen wie die Geschäftsdaten.

Abgrenzung zu Unity-Catalog-Metadaten, Cloud-Logs und Application Logs

System Tables werden häufig mit benachbarten Konzepten verwechselt, weil Metadaten, Cloud-Ereignisse und Anwendungs-Logs teilweise ähnliche Fragen beantworten. Die folgende Übersicht klärt die Grenzen.

Begriff	Was er enthält	Verhältnis zu System Tables
Unity Catalog Metadata / INFORMATION_SCHEMA	Katalog-Objekte: Kataloge, Schemas, Tabellen, Spalten, Privilegien	Katalog-Schema, kein Betriebsdaten-Set; komplementär zu system.access
Cloud-Anbieter-Logs (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs)	API-Aufrufe auf Cloud-Ressourcen: VM-Starts, Storage-Zugriffe, IAM-Änderungen	Cloud-Ebene außerhalb Databricks; für vollständige Audit-Trails kombiniert
Application Logs (Jobs, Notebooks, Streaming)	Stdout/Stderr, Spark-Driver-Ausgaben, Fehler	Landen im Cluster-Log-Delivery, nicht im system-Catalog
Databricks Metastore	Backing-Store des Unity Catalogs mit aktuellem Katalog-Zustand	Zustand der Objekte; System Tables halten den Verlauf der Ereignisse
SIEM (Splunk, Sentinel, Elastic Security)	Realtime-Alerting, Threat-Detection, Incident-Response	Kann System-Tables-Daten konsumieren, ersetzt sie aber nicht

Der system-Catalog beschreibt den Betrieb der Plattform. Das ANSI-INFORMATION_SCHEMA und der Databricks-Metastore beschreiben die Katalog-Objekte selbst und deren aktuellen Zustand. Cloud-Anbieter-Logs liegen eine Ebene tiefer und protokollieren Vorgänge auf der Cloud-Infrastruktur. Application Logs entstehen in den ausgeführten Jobs und werden über das Cluster-Log-Delivery in den Cloud-Storage geschrieben; sie liegen außerhalb des system-Catalogs. Ein SIEM kann System-Tables-Daten weiterverarbeiten, deckt aber Realtime-Alerting und Threat-Detection ab, die außerhalb des Definitionsraums von System Tables liegen.

Beispiel FinOps- und Audit-Report auf einem SQL Warehouse

Ein monatlicher FinOps-Report zieht den DBU-Verbrauch pro Domäne aus system.billing.usage, aggregiert über den Tag domain in usage_metadata.custom_tags und multipliziert das Ergebnis mit den Listenpreisen aus system.billing.list_prices. Das Ergebnis wird als Delta-Tabelle in eine Reporting-Schicht geschrieben und über ein SQL Warehouse an Power BI ausgeliefert. Auf demselben Warehouse joined ein zweiter Report system.access.audit mit system.information_schema.table_privileges, um die Auditfrage nach lesenden Zugriffen der letzten 90 Tagen und den zugehörigen Privilegien direkt in SQL zu beantworten. Beide Reports laufen ohne separate Export-Pipeline und ohne Cloud-Storage-Detour; die Databricks-Plattform ist die Datenquelle über sich selbst.