Databricks Unity Catalog: Leitfaden zur Data Governance

Unity Catalog ist die einheitliche Governance von Databricks für Daten- und KI-Bestände im gesamten Lakehouse. Er führt Zugriffskontrolle, Audit, Lineage und Discovery für Tabellen, Sichten, Dateien, ML-Modelle und KI-Bestände an einer Stelle zusammen, über Workspaces, Regionen und Clouds hinweg. Ursprünglich 2022 gestartet und von 2024 bis 2026 durch Beiträge aus dem Open-Source-Bereich stark erweitert, ist Unity Catalog zur üblichen Governance-Ebene für Organisationen geworden, die Databricks in großem Maßstab betreiben.

Dieser Leitfaden erklärt, was Unity Catalog ist, wie sein Modell arbeitet und wo er in der weiteren Governance-Landschaft eines Unternehmens steht.

Was ist Unity Catalog?

Vor Unity Catalog hieß Governance auf Databricks, ACLs über den alten Hive-Metastore in jedem Workspace zu vervielfachen, Anmeldedaten für den Speicher von Hand zu verwalten und die Lineage im Nachhinein aus Protokollen zusammenzusetzen. Jeder Workspace war seine eigene Insel.

Unity Catalog ersetzt dieses zersplitterte Modell durch einen einzigen Dienst auf Kontoebene, der:

• die Metadaten jedes Catalog, Schema, jeder Table, View, Function, jedes Model und Volume hält,
• ein einheitliches Berechtigungsmodell mit den üblichen SQL-Grants durchsetzt,
• die Lineage automatisch erfasst, während Abfragen laufen,
• jeden Lesezugriff, Schreibzugriff, jede Schemaänderung und jeden Grant für das Audit protokolliert,
• alle gesteuerten Bestände über einen durchsuchbaren Catalog Explorer sichtbar macht.

Entscheidend ist: Unity Catalog ist kein Nebendienst, der an Databricks angeschraubt wurde. Er ist die voreingestellte Governance-Ebene jedes neuen Databricks-Workspace und der einzige Weg zu Funktionen wie Delta Sharing, Lakehouse Federation und dem Databricks Marketplace.

Kernbegriffe

Unity Catalog ordnet die Governance um mehrere Grundbausteine:

• Metastore: der oberste Behälter, je Databricks-Konto auf eine Cloud-Region begrenzt. Ein Metastore fasst alle gesteuerten Bestände dieser Region zusammen. Eine Organisation betreibt meist einen oder wenige Metastores.
• Catalog: die erste Stufe des Namensraums. Catalogs bilden meist ein Fachgebiet, eine Umgebung oder eine Geschäftseinheit ab (finance, marketing, prod, dev).
• Schema: die zweite Stufe (in der Sprache von Spark SQL früher Database genannt). Schemas gruppieren zusammengehörige Tabellen und Sichten.
• Table: verwaltete oder externe Delta-Tabellen, dazu Tabellen in anderen Formaten (Parquet, CSV, Iceberg über UniForm).
• View: gespeicherte SQL-Abfragen, auch dynamische Sichten mit Filtern auf Zeilen- und Spaltenebene.
• Volume: ein gesteuerter Speicherort für nicht tabellarische Dateien (PDFs, Bilder, Audio, Artefakte von ML-Modellen, rohe Datendateien).
• Function: registrierte benutzerdefinierte Funktionen in SQL oder Python.
• Model: registrierte MLflow-Modelle, gesteuert zusammen mit den Daten, die sie verbrauchen und erzeugen.
• Storage credential und External location: die von Unity Catalog verwaltete Anmeldung an externem Cloud-Speicher. Anmeldedaten müssen nie in den Code der Nutzer eingebettet werden.

Dreistufiger Namensraum

Das Kennzeichen von Unity Catalog ist der dreistufige Namensraum: Jedes Objekt wird als catalog.schema.object angesprochen. Das ist ein bewusster Bruch mit dem alten zweistufigen Modell von Spark (database.table).

Die dritte Stufe zählt, weil Catalogs verwaltungstechnisch bedeutsam sind. Sie bilden Teams, Umgebungen oder Fachgebiete ab und sind die natürliche Einheit für Governance-Entscheidungen auf oberster Ebene: Wer verantwortet diese Daten, in welcher Region liegen sie, welcher Berechtigungsbereich gilt?

Einige Beispiele für Verweise:

• finance.raw.invoices: rohe Rechnungsdaten im Catalog finance
• marketing.gold.attribution_daily: die produktive Attributionstabelle
• main.mlmodels.churn_v3: ein registriertes ML-Modell

Zugriffskontrolle

Unity Catalog verwendet die üblichen ANSI-SQL-Grants. Dieselbe Syntax wirkt im SQL Editor, in Notebooks, in Jobs und über die API:

GRANT SELECT ON finance.gold.revenue_daily TO `data-analysts`;
GRANT MODIFY ON marketing.events.campaigns TO `marketing-engineers`;
GRANT USE CATALOG ON finance TO `finance-domain`;

Zugriff lässt sich auf jeder Ebene erteilen: Metastore, Catalog, Schema, Tabelle, Spalte. Berechtigungen reichen nach unten durch: Ein Grant auf einen Catalog gilt für alle seine Schemas und Tabellen. Übliche Berechtigungen sind SELECT, MODIFY, USE CATALOG, USE SCHEMA, EXECUTE (auf Funktionen) sowie READ VOLUME und WRITE VOLUME.

Sicherheit auf Zeilen- und Spaltenebene

Über Grants auf Tabellenebene hinaus setzt Unity Catalog Zeilenfilter und Spaltenmasken über SQL-Funktionen durch. Ein Zeilenfilter ist eine Funktion, die einen Wahrheitswert zurückgibt; eine Spaltenmaske ist eine Funktion, die einen Wert umformt. Beide hängen an einer Tabelle und werden bei jeder Abfrage automatisch ausgewertet, auch bei Abfragen aus BI-Werkzeugen.

CREATE FUNCTION mask_pii(email STRING)
RETURN CASE WHEN is_member('analysts') THEN email
            ELSE 'REDACTED' END;

ALTER TABLE finance.raw.customers
SET COLUMN MASK email USING mask_pii(email);

Föderierte Identitäten

Unity Catalog unterstützt föderierte Identitäten mit Microsoft Entra ID, Okta und weiteren Anbietern nach SAML oder SCIM. Nutzer und Gruppen, die im Identitätsanbieter festgelegt sind, bilden unmittelbar auf Prinzipale in Unity Catalog ab, ohne Schattenlisten von Nutzern.

Data Lineage

Unity Catalog erfasst die Lineage auf Spaltenebene automatisch für jede Abfrage, die über die Plattform läuft: Spark SQL, Notebooks, Jobs, Dashboards, das Training von ML-Modellen. Es gibt nichts einzuschalten: Solange die Tabelle von Unity Catalog gesteuert wird, wird die Lineage festgehalten.

Die Lineage deckt Tabellen, Sichten, Dashboards, ML-Modelle und, seit 2024, KI-Arbeitsabläufe ab. Der Catalog Explorer zeigt sie als interaktiven Graphen; dieselbe Lineage lässt sich für eigene Auswertungen über die Systemtabellen (system.access.table_lineage und system.access.column_lineage) abfragen. Zum weiteren Zusammenhang siehe Data Lineage und Lineage auf Spaltenebene.

Audit und Discovery

Jede Handlung an einem Objekt in Unity Catalog wird protokolliert: Abfragen, Schemaänderungen, Grants, Löschungen. Die Audit-Protokolle erscheinen in system.access.audit und lassen sich unmittelbar abfragen oder über die Protokollauslieferung der Cloud an ein SIEM übergeben (CloudWatch, Azure Monitor, Stackdriver).

Der Catalog Explorer ist die Oberfläche für die Discovery: ein durchsuchbarer, filterbarer Browser über jeden gesteuerten Bestand, mit Beschreibungen, Tags, Lineage, verantwortlichen Personen und Vorschauen. Tags lassen sich auf jeder Ebene setzen und reichen an die Kinder weiter, was übliche Muster der Governance wie pii=true oder domain=finance trägt.

Volumes für unstrukturierte Daten

Volumes erweitern die Governance von Unity Catalog auf nicht tabellarische Dateien: Dokumente, Bilder, Audio, Video, Artefakte von ML-Modellen, rohe Nutzlasten. Volumes werden an bekannten Pfaden eingehängt (/Volumes/<catalog>/<schema>/<volume>/...) und über dasselbe System von SQL-Grants angesprochen, das Tabellen steuert.

Am meisten zählt das für KI-Lasten. Die meiste KI im Unternehmen braucht sowohl strukturierte Tabellen als auch unstrukturierte Dokumente, und vor den Volumes verlangte es zwei verschiedene Systeme, beides sauber zu steuern. Mit Volumes kann eine RAG-Pipeline PDFs lesen, sie einbetten und die entstehenden Vektoren in eine Tabelle zurückschreiben, alles unter einem einheitlichen Berechtigungsmodell.

Unity Catalog als Open Source

Im Juni 2024 hat Databricks Unity Catalog unter der Linux Foundation quelloffen gestellt. Das Open-Source-Projekt ist in der Governance-API mit dem von Databricks verwalteten Dienst verträglich und hat ein wachsendes Umfeld an Anbindungen, darunter Apache Spark, Trino, Apache Iceberg und DuckDB. Es ist kein unmittelbarer Ersatz für den verwalteten Dienst, denn Funktionen wie die verwaltete Lineage und die Oberfläche des Catalog Explorer gibt es nur im kommerziellen Produkt. Der offene Kern stellt aber sicher, dass die Metadaten von Unity Catalog auch außerhalb von Databricks gelesen und beachtet werden können.

Wie Dawiso Unity Catalog ergänzt

Unity Catalog steuert das Lakehouse ausgesprochen gut. Er steuert von sich aus nicht den Rest des Unternehmens: die operativen Systeme, die ihn speisen, die BI-Werkzeuge, die ihn verbrauchen, das Business Glossary, das festlegt, was „Umsatz“ bedeutet, und die menschlichen Abläufe der Stewardship, die entscheiden, wer was verantwortet.

Dawiso bindet Unity Catalog über dessen Metadaten-API an und übernimmt Katalogstruktur, Lineage, Klassifizierungen und Tags. Dann reichert Dawiso dieses Bild um den fachlichen Kontext an, den Unity Catalog nicht erfasst: Definitionen im Business Glossary, Zuordnungen der Stewardship, Regeln zur Datenqualität und eine durchgängige Lineage, die Databricks, Quellsysteme und nachgelagerte BI überspannt. Das Ergebnis ist ein einziges Bild der Governance: technische Tiefe aus Unity Catalog, fachliche Semantik und menschlicher Ablauf aus Dawiso.