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 über die Workspaces eines Databricks-Kontos hinweg an einer Stelle zusammen. Unity Catalog ist seit August 2022 allgemein verfügbar, wird für jeden nach dem 8. November 2023 erstellten Databricks-Workspace automatisch aktiviert und wurde im Juni 2024 quelloffen gestellt.

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,
• Datenzugriffe und Systemaktivität in einer Audit-Systemtabelle festhält,
• alle gesteuerten Bestände über einen durchsuchbaren Catalog Explorer sichtbar macht.

Unity Catalog ist als voreingestellte Governance-Ebene in die Plattform eingebaut. Er ist außerdem Voraussetzung für Lakehouse Federation, für das Veröffentlichen von Angeboten im Databricks Marketplace und für das Teilen von Daten über den von Databricks betriebenen Server für Delta Sharing (inzwischen als OpenSharing dokumentiert).

Kernbegriffe

Unity Catalog ordnet die Governance um mehrere Grundbausteine:

• Metastore: der oberste Behälter, auf eine Cloud-Region begrenzt. Databricks verlangt einen Metastore für jede Region, in der eine Organisation Databricks betreibt, und Workspaces werden an den Metastore ihrer Region angebunden.
• 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 Tabellen (standardmäßig Delta Lake, alternativ Apache Iceberg), deren Speicher und Lebenszyklus Unity Catalog übernimmt, und externe Tabellen (Delta, CSV, JSON, Avro, Parquet, ORC oder Text), deren Dateien beim Löschen der Tabelle in Ihrem Cloud-Speicher bleiben.
• View: gespeicherte SQL-Abfragen, auch dynamische Sichten mit Filtern auf Zeilen- und Spaltenebene, dazu Metric Views, die fachliche Kennzahlen einmal in YAML festlegen.
• 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 SQL-Befehle GRANT und REVOKE. 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 den Metastore, einen Catalog, ein Schema oder eine einzelne Tabelle, Sicht, ein Volume, eine Funktion oder ein Modell erteilen; Spalten werden mit Masken statt mit Grants geschützt. Berechtigungen reichen nach unten durch: Ein Grant auf einen Catalog oder ein Schema gilt für alle aktuellen und künftigen untergeordneten Objekte. Ü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. Die dokumentierte Syntax bindet eine Maske an eine Spalte:

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

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

Für viele Tabellen zugleich lassen sich Richtlinien der attributbasierten Zugriffskontrolle (ABAC) auf Catalog-, Schema- oder Tabellenebene anhängen; sie wenden Zeilenfilter und Spaltenmasken automatisch auf Objekte an, die die gesteuerten Tags tragen, auf die eine Richtlinie zielt.

Föderierte Identitäten

Nutzer, Gruppen und Service Principals werden auf Ebene des Databricks-Kontos verwaltet und lassen sich über SCIM aus einem Identitätsanbieter wie Microsoft Entra ID, Okta oder OneLogin bereitstellen. Die Identitätsföderation lässt Workspaces diese kontoweiten Identitäten nutzen, sodass ein Grant in jedem Workspace denselben Prinzipal meint, ohne Schattenlisten von Nutzern.

Data Lineage in Unity Catalog

Unity Catalog erfasst die Lineage automatisch für Abfragen, die über Databricks SQL oder die Spark-DataFrame-Schnittstellen auf Databricks laufen, bis auf die Spaltenebene, wenn Quelle und Ziel über den Tabellennamen angesprochen werden. Eine Einrichtung pro Tabelle entfällt: Die Tabelle muss nur in einem Metastore von Unity Catalog registriert sein.

Die Knoten der Lineage umfassen Tabellen und Sichten, Versionen von ML-Modellen, externe Bestände und Dateipfade; Jobs und Dashboards, die eine Tabelle lesen, erscheinen als ihre Verbraucher. Der Catalog Explorer zeigt die Lineage als interaktiven Graphen; dieselbe Lineage lässt sich über die Systemtabellen (system.access.table_lineage und system.access.column_lineage) abfragen, die ein rollierendes Fenster von einem Jahr vorhalten. Zum weiteren Zusammenhang siehe Data Lineage und Lineage auf Spaltenebene.

Audit und Discovery

Datenzugriffe und Systemaktivität, etwa Lesezugriffe, Schemaänderungen, Grants und Löschungen, werden in der Systemtabelle system.access.audit festgehalten. Databricks empfiehlt, diese Tabelle abzufragen; auf AWS lassen sich die Audit-Protokolle zusätzlich als JSON-Dateien in einen Amazon-S3-Bucket ausliefern.

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 an Catalogs, Schemas, Tabellen, Spalten, Sichten, Volumes, Funktionen und Modelle setzen, was übliche Muster der Governance wie pii=true oder domain=finance trägt. Tags auf Catalogs und Schemas gehen nur bei der Auswertung von ABAC-Richtlinien auf untergeordnete Objekte über, und nie bis auf Spalten.

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

Am 13. Juni 2024 hat Databricks Unity Catalog quelloffen gestellt, unter der Lizenz Apache 2.0 und getragen von LF AI & Data, der Stiftung der Linux Foundation für KI und Daten. Der Open-Source-Server implementiert die Iceberg REST Catalog API und ist mit der API des Hive-Metastores kompatibel, sodass Engines außerhalb von Databricks die katalogisierten Tabellen lesen können; Databricks nannte DuckDB unter den Unterstützern zum Start. Das Open-Source-Projekt und der von Databricks verwaltete Dienst sind getrennte Implementierungen: Funktionen aus diesem Leitfaden, etwa die automatische Erfassung der Lineage und die Systemtabellen, sind für den verwalteten Dienst dokumentiert.

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.

Der Databricks-Konnektor von Dawiso liest Unity Catalog über dessen Systemtabellen und REST API. Er übernimmt Catalogs, Schemas, Tabellen, Sichten, Metric Views, Spalten, Volumes, Funktionen und ML-Modelle, dazu verantwortliche Personen, Tags, Spaltenmasken, Zeilenfilter und Datenklassifizierungen. Die Lineage von Spalte zu Spalte stammt aus system.access.column_lineage, für Aktivität innerhalb eines konfigurierbaren Lineage-Fensters (standardmäßig 30 Tage), dazu kommt eine deterministische Lineage für Metric Views (aus deren YAML) und für Datasets von Dashboards (aus deren SQL).

Dann ergänzt Dawiso, was außerhalb der Plattform liegt: Definitionen im Business Glossary, die automatisch verlinkt werden, wo sie in Objektbeschreibungen vorkommen, Zuordnungen der Stewardship, dokumentierte Prüfungen der Datenqualität zusammen mit der externen Engine, die sie ausführt, und eine Lineage über Databricks hinaus, die sich erweitern lässt, indem man Beziehungen manuell definiert oder importiert. Das Ergebnis ist ein einziges Bild der Governance: technische Tiefe aus Unity Catalog, fachliche Semantik und Abläufe der Stewardship aus Dawiso.

Quellen

• Databricks, What is Unity Catalog?
• Databricks, Unity Catalog GA release note, 25. August 2022.
• Databricks Blog, Open Sourcing Unity Catalog, 13. Juni 2024.
• Databricks, Create a Unity Catalog metastore.
• Databricks, Unity Catalog managed tables for Delta Lake and Apache Iceberg.
• Databricks, Work with external tables.
• Databricks, Unity Catalog metric views.
• Databricks, Unity Catalog privileges reference.
• Databricks, Manually apply row filters and column masks.
• Databricks, Attribute-based access control in Unity Catalog.
• Databricks, Sync users and groups from your identity provider using SCIM.
• Databricks, Lineage in Unity Catalog.
• Databricks, Configure audit log delivery.
• Databricks, Apply tags to Unity Catalog securable objects.
• Databricks, Connect to external databases and catalogs.
• Databricks, What is OpenSharing?
• Databricks, What is Databricks Marketplace?
• Dawiso Help, Databricks.
• Dawiso Help, Business Glossary.
• Dawiso Help, Sources of data lineage.
• Dawiso Help, Data quality and SLAs.