Databricks Unity Catalog System Tables: Die Metadaten, für die du schon bezahlst

System Tables im Unity Catalog von Databricks gehören zu den am meisten unterschätzten Ressourcen, die mir auf Databricks-Plattformen begegnen. Die meisten Unternehmen beschäftigen sich mit dem Aufbau von Pipelines, Dashboards oder dem Betreiben von ML-Modellen - Metadaten über all diese Vorgänge stehen selten im Fokus.

Dabei sind die Metadaten in den System Tables sehr wertvoll. Sie helfen dir, kritische Fragen über den gesamten Datenbetrieb des Unternehmens zu beantworten:

• Welche Teams, Projekte oder Jobs verbrauchen die meisten DBUs - und ist dieser Aufwand gerechtfertigt?
• Welche Jobs laufen täglich, obwohl seit drei Monaten niemand die Ergebnisse downstream abfragt?
• Was kostet uns eine Pipeline, eine Domain oder ein Geschäftsbereich?
• Für welche Tabellen zahlen wir, obwohl niemand mehr darauf zugreift?
• Wer sind die Power User unserer Plattform?

Wenn du als Data Engineer, Platform-Team oder FinOps-Analyst einen Databricks-Account verwaltest, sind diese Tabellen dein schnellster Weg, Kosten-, Governance- und Performance-Fragen zu beantworten - ohne zusätzliche Infrastruktur aufzubauen.

In diesem Artikel schauen wir uns an, wie Unity Catalog System Tables diese Fragen beantworten und wie sie deiner Organisation helfen, die operative Effizienz zu verbessern.

Was sind Databricks Unity Catalog System Tables?

Unity Catalog System Tables sind eingebaute, schreibgeschützte Tabellen in Databricks, die Observability- und Governance-Daten über deine Lakehouse-Umgebung bereitstellen.

Sie legen eine Audit- und Metadatenschicht über alles, was in deinem Account passiert - abfragbar per einfachem SQL. Sie leben unter dem system-Katalog und sind nach Domain in Schemas organisiert:

Wichtige Eigenschaften

Ein paar Eigenschaften lohnt es sich zu kennen, bevor du anfängst abzufragen:

• Schreibgeschützt und Databricks-gehostet. Die Daten liegen in Databricks-verwaltetem Speicher in der Region deines Metastores und werden dir via Delta Sharing zur Verfügung gestellt. Du kannst sie nicht verändern, und Databricks rät davon ab, sie von der Plattform zu exportieren.
• Account-weiter Scope. System Tables enthalten operative Daten aus allen Workspaces deines Accounts in derselben Cloud-Region (einige Tabellen, wie Billing, sind global) - auch Workspaces ohne Unity Catalog. Das macht sie zur einzigen Quelle, die dir eine konsolidierte Sicht über alle Workspaces gibt.
• Kostenlose Aufbewahrungsfristen. Die meisten Tabellen behalten 365 Tage History kostenlos; einige (wie node_timeline) behalten 90 Tage. Die Billing- und Pricing-Tabellen selbst kosten nichts abzufragen - abgesehen vom Compute, den du dafür nutzt.
• Nicht Echtzeit. Die Daten werden über den Tag verteilt aktualisiert, nicht sofort. Gut für Kostenreports und Audits, kein Ersatz für Live-Monitoring.
• Schema kann wachsen. Databricks kann jederzeit Spalten hinzufügen. Vermeide SELECT * in nachgelagerte Tabellen, solange du keine Schema Evolution aktiviert hast.

So aktivierst du Databricks System Tables

Wenn dein Workspace auf Unity Catalog läuft, existiert der system-Katalog in deinem Metastore bereits - es gibt keine Infrastruktur, die du deployen musst. Was du brauchst:

1. Ein Unity Catalog-fähiger Workspace. System Tables sind nur von dort aus zugänglich, und dein Metastore muss auf Privilege Model 1.0 laufen.
2. Grants. Account-Admins und Metastore-Admins haben standardmäßig Zugriff. Für alle anderen erteilt ein Admin USE CATALOG auf system sowie USE SCHEMA und SELECT auf die relevanten Schemas:

GRANT USE CATALOG ON CATALOG system TO `finops-team`;
GRANT USE SCHEMA ON SCHEMA system.billing TO `finops-team`;
GRANT SELECT ON SCHEMA system.billing TO `finops-team`;

Das war’s. Öffne einen SQL-Editor und führe SHOW SCHEMAS IN system aus, um zu sehen, was in deinem Account verfügbar ist.

Use Cases für Unity Catalog System Tables

FinOps

Das ist der Use Case, der die meisten Leute zum Einstieg bringt. system.billing.usage erfasst jede abrechenbare Einheit, die in deinem Account verbraucht wird, mit Workspace, SKU und - entscheidend - usage_metadata, das den Aufwand dem konkreten Job, Cluster, Warehouse oder der Pipeline zuordnet, die ihn verursacht hat. Join gegen system.billing.list_prices und du hast Kosten in Dollar, nicht nur in DBUs.

Da Compute-Ressourcen Custom Tags tragen, kannst du Kosten auf die Dimension herunterbrechen, in der deine Organisation denkt: Team, Projekt, Domain, Geschäftsbereich. Ein team-Tag auf jedem Cluster und Job ist die wichtigste Einzelmaßnahme, bevor du die Queries unten ausführst - es verwandelt workspace_id in ein benanntes Cost Center. Showback und Chargeback hören auf, eine vierteljährliche Spreadsheet-Übung zu sein, und werden zu einem Dashboard.

Wenn du Cloud-Infrastrukturkosten außerhalb von Databricks managst, gilt dieselbe Tagging-Disziplin auf AWS-Ebene - wie das zusammenhängt, zeigt der Artikel AWS Cost Optimization: Wie du deine Rechnungen unter Kontrolle bringst.

Security Auditing

system.access.audit erfasst Audit-Events über alle deine Workspaces: Wer hat sich eingeloggt, wer hat welche Tabelle gelesen, wer hat Berechtigungen geändert, wer hat Ergebnisse heruntergeladen. Statt Audit-Log-Delivery in Cloud-Speicher zu konfigurieren und eine Parsing-Pipeline zu bauen, stellst du einfach eine Abfrage.

Typische Fragen: Wer hat in den letzten 90 Tagen auf diese PII-Tabelle zugegriffen? Welche Service Principals hatten fehlgeschlagene Autorisierungsversuche? Hat jemand Grants auf Produktionskataloge außerhalb eines Deployment-Fensters geändert?

system.access.column_lineage erweitert das auf Spaltenebene - nützlich, wenn du einem Datenschutzbeauftragten genau nachweisen musst, welche nachgelagerten Tabellen oder Reports eine bestimmte PII-Spalte konsumieren.

Compute-Optimierung

system.compute.node_timeline gibt dir CPU- und Speicherauslastung pro Node für deine Cluster. Join mit system.compute.clusters (die vollständige Konfigurationshistorie jedes Clusters) und du findest die Cluster, die überdimensioniert sind, das All-Purpose Compute, das eigentlich Jobs Compute sein sollte, und die Warehouses, die das gesamte Wochenende leer laufen. Hier verstecken sich die meisten schnellen Kosteneinsparungen - nicht in exotischem Query-Tuning, sondern in Compute, das schlicht größer oder länger läuft, als der Workload es erfordert.

Pipeline-Zuverlässigkeit

system.lakeflow.job_run_timeline erfasst jeden Job-Run mit Startzeit, Endzeit und Ergebnisstatus. Aggregiert ergibt das ein Reliability-Dashboard: Success Rate pro Job, p95-Laufzeit, Jobs, deren durchschnittliche Laufzeit sich im letzten Monat verdoppelt hat. Kombiniert mit system.billing.usage kannst du beantworten, ob ein Job, der langsamer geworden ist, auch teurer wird - und um wie viel.

Das ist besonders nützlich für Spark Structured Streaming Jobs, bei denen Degradation oft schleichend verläuft und erst auffällt, wenn eine Pipeline deutlich im Rückstand ist.

Query-Optimierung

system.query.history erfasst jede Query, die auf SQL Warehouses und Serverless Compute ausgeführt wurde, mit Laufzeit, gelesenen Bytes, produzierten Zeilen und dem ausführenden Nutzer. Sortiert nach Gesamtlaufzeit erhältst du einen priorisierten Optimierungsrückstand. Es beantwortet auch Adoptionsfragen: Wer sind die Power User, welche Dashboards werden tatsächlich genutzt, welche Tabellen erhalten die meisten Abfragen?

Kombiniert mit Lineage (system.access.table_lineage) kannst du die unbequemere Frage beantworten: Welche Tabellen aktualisieren wir jede Nacht, die seit Monaten niemand mehr gelesen hat?

Beispiel-Queries

Kosten pro Workspace und SKU, letzte 30 Tage, in Dollar:

Das ist dein Einstiegspunkt für jedes Kostengespräch. Ersetze GROUP BY 1, 2 durch GROUP BY u.workspace_id, u.usage_metadata.job_id, um von SKU-Ebene auf Job-Ebene zu wechseln.

SELECT
  u.workspace_id,
  u.sku_name,
  ROUND(SUM(u.usage_quantity * p.pricing.effective_list.default), 2) AS cost_usd
FROM system.billing.usage u
JOIN system.billing.list_prices p
  ON u.sku_name = p.sku_name
  AND u.cloud = p.cloud
  AND u.usage_start_time >= p.price_start_time
  AND (p.price_end_time IS NULL OR u.usage_start_time < p.price_end_time)
WHERE u.usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY 1, 2
ORDER BY cost_usd DESC;

Teuerste Jobs mit Namen:

Dieser Schema-übergreifende Join zwischen billing und lakeflow ist der schnellste Weg zu einem Kosten-pro-Job-Report. Die obersten Einträge sind deine Optimierungskandidaten - prüfe, ob sie auf dem richtigen Compute-Typ laufen und ob ihr Output überhaupt downstream konsumiert wird.

SELECT
  j.name AS job_name,
  ROUND(SUM(u.usage_quantity * p.pricing.effective_list.default), 2) AS cost_usd
FROM system.billing.usage u
JOIN system.billing.list_prices p
  ON u.sku_name = p.sku_name
  AND u.cloud = p.cloud
  AND u.usage_start_time >= p.price_start_time
  AND (p.price_end_time IS NULL OR u.usage_start_time < p.price_end_time)
JOIN system.lakeflow.jobs j
  ON u.usage_metadata.job_id = j.job_id
  AND u.workspace_id = j.workspace_id
WHERE u.usage_date >= current_date() - INTERVAL 30 DAYS
  AND u.usage_metadata.job_id IS NOT NULL
GROUP BY 1
ORDER BY cost_usd DESC
LIMIT 20;

Tabellen, in die geschrieben wird, aber die niemand liest (letzte 90 Tage):

Jede Tabelle, die diese Query zurückgibt, ist ein Kandidat zur Stilllegung - du bezahlst für das Compute, das sie aktualisiert, und den Speicher, der sie hält, für null Konsumenten. Vergleiche die Einträge mit dem Job-Kosten-Query oben, um die mögliche Ersparnis abzuschätzen.

WITH writes AS (
  SELECT DISTINCT target_table_full_name AS table_name
  FROM system.access.table_lineage
  WHERE event_time >= current_date() - INTERVAL 90 DAYS
    AND target_table_full_name IS NOT NULL
),
reads AS (
  SELECT DISTINCT source_table_full_name AS table_name
  FROM system.access.table_lineage
  WHERE event_time >= current_date() - INTERVAL 90 DAYS
    AND source_table_full_name IS NOT NULL
)
SELECT w.table_name
FROM writes w
LEFT ANTI JOIN reads r ON w.table_name = r.table_name;

Wer hat auf eine sensible Tabelle zugegriffen:

Ersetze prod.hr.salaries durch den vollqualifizierten Namen der Tabelle, die du auditieren möchtest. Das Ergebnis ist ein zeitgestempeltes Log jedes Nutzers, der einen getTable-Aufruf ausgelöst hat - nützlich für Access Reviews und Compliance-Berichte.

SELECT
  event_time,
  user_identity.email,
  action_name,
  request_params.full_name_arg AS table_name
FROM system.access.audit
WHERE service_name = 'unityCatalog'
  AND action_name = 'getTable'
  AND request_params.full_name_arg = 'prod.hr.salaries'
  AND event_date >= current_date() - INTERVAL 90 DAYS
ORDER BY event_time DESC;

Job-Zuverlässigkeit der letzten 30 Tage:

Liefert Success Rate und durchschnittliche Laufzeit pro Job. Jobs mit einer Success Rate unter 0,95 oder einer stark wachsenden Durchschnittslaufzeit sind die ersten Kandidaten zur Untersuchung.

SELECT
  j.name AS job_name,
  COUNT(*) AS total_runs,
  ROUND(SUM(CASE WHEN r.result_state = 'SUCCEEDED' THEN 1 ELSE 0 END) / COUNT(*), 3) AS success_rate,
  ROUND(AVG(r.run_duration_seconds) / 60, 1) AS avg_duration_min
FROM system.lakeflow.job_run_timeline r
JOIN system.lakeflow.jobs j
  ON r.job_id = j.job_id
  AND r.workspace_id = j.workspace_id
WHERE r.period_start_time >= current_date() - INTERVAL 30 DAYS
  AND r.result_state IS NOT NULL
GROUP BY 1
ORDER BY success_rate ASC, total_runs DESC
LIMIT 20;

Platform-Power-User nach Query-Volumen:

Nützlich sowohl für Adoption-Reporting als auch um zu entscheiden, wessen Queries zuerst optimiert werden sollten - Nutzer mit dem höchsten Query-Volumen profitieren am stärksten von Verbesserungen.

SELECT
  executed_by,
  COUNT(*) AS query_count,
  ROUND(SUM(total_duration_ms) / 1000 / 3600, 1) AS total_hours
FROM system.query.history
WHERE start_time >= current_date() - INTERVAL 30 DAYS
GROUP BY 1
ORDER BY query_count DESC
LIMIT 20;

Fazit

Das Muster zieht sich durch alle diese Use Cases: Fragen, die früher Log-Exporte, REST-API-Aufrufe oder Schätzungen erforderten, sind jetzt eine SQL-Abfrage entfernt. Die System Tables sind bereits vorhanden, bereits befüllt und größtenteils kostenlos abzufragen - das einzige fehlende Zutate ist jemand, der beschließt, hinzuschauen.

Mein Vorschlag: Fang mit system.billing.usage an. Baue ein Dashboard, das Kosten pro Team oder pro Job zeigt. Wenn es das erste Mal einen vergessenen Cluster oder einen nächtlichen Job zu Tage fördert, der eine Tabelle befüllt, die niemand mehr liest, wird der Rest der Organisation anfangen, nach mehr zu fragen.

Die vollständige Referenz mit allen verfügbaren Tabellen, Schemas und Aufbewahrungsfristen findest du in der Databricks System Tables Dokumentation.

Frequently Asked Questions

Was kosten Databricks Unity Catalog System Tables?

Die Billing- und Pricing-Tabellen sind kostenlos nutzbar, und Tabellen in der Public Preview sind während der Preview kostenlos. Du zahlst für das Compute, das du für die Abfragen nutzt - wie bei jeder anderen Tabelle.

Sind Databricks System Tables Echtzeit?

Nein. Die Daten werden über den Tag verteilt aktualisiert. Wenn ein aktuelles Ereignis noch nicht erscheint, schau in ein paar Stunden noch einmal nach.

Decken System Tables alle Databricks Workspaces meines Accounts ab?

Ja - alle Workspaces in derselben Cloud-Region, einschließlich Workspaces ohne Unity Catalog. Billing- und Pricing-Daten sind global. Du brauchst nur einen UC-fähigen Workspace, von dem aus du abfragst.

Wie lange speichert Databricks System Table-Daten?

Das variiert je nach Tabelle. Die meisten Tabellen behalten 365 Tage kostenlos; node_timeline behält 90 Tage; Pricing- und Node-Typ-Daten werden unbegrenzt aufbewahrt. Wenn du eine längere History benötigst, streame die Tabellen in deinen eigenen Speicher (setze dabei skipChangeCommits auf true).

Kann ich Databricks System Tables verändern oder beschreiben?

Nein, sie sind schreibgeschützt. Wenn du die Daten anreichern oder aufbewahren möchtest, kopiere sie in deinen eigenen Katalog.

Werden sich Databricks System Table Schemas verändern?

Spalten können jederzeit hinzugefügt werden, aber bestehende Spalten werden nicht geändert oder entfernt. Aktiviere Schema Evolution in allen nachgelagerten Tabellen, in die du System-Table-Daten schreibst.