Unity Catalog: Definition, Aufbau, Rechte und Abgrenzung

Unity Catalog ist der einheitliche Governance-Layer von Databricks für Daten- und AI-Assets über Workspaces und Clouds hinweg. Er verbindet eine dreistufige Namensraum-Hierarchie (Catalog → Schema → Objekt) mit Zugriffssteuerung, Lineage, Discovery und Auditing in einem gemeinsamen Metastore.

Was ist Unity Catalog?

Unity Catalog ist der Nachfolger des workspace-lokalen Hive Metastore in Databricks. Er wurde 2022 allgemein verfügbar und wird seither als Default-Katalog für neue Workspaces ausgerollt. Ein Metastore existiert pro Databricks-Konto und Region und klammert alle Workspaces dieser Region zu einem gemeinsamen Governance-Raum. Bestehende Hive-Metastore-Kataloge bleiben unter dem reservierten Namen hive_metastore sichtbar und lassen sich per Hive-Metastore-Federation unter Unity-Catalog-Berechtigungen bringen.

Der Namensraum ist dreistufig: catalog.schema.object. Der Catalog bildet die oberste Grenze, typischerweise nach Umgebung (prod, dev), Domäne (finance, sales) oder Zweck (analytics, ml) geschnitten. Ein Schema bündelt fachlich zusammengehörige Objekte innerhalb des Catalogs. Als Objekte verwaltet Unity Catalog Delta- und Iceberg-Tabellen, Views, Volumes (nicht-tabellare Daten wie CSV, PDF, Modell-Artefakte, Bilder), ML-Models der Model Registry, Feature Tables, Functions (SQL- und Python-UDFs) sowie External Locations und Storage Credentials für Cloud-Objektspeicher.

Zugriffssteuerung läuft über ANSI-SQL-Grants (GRANT SELECT ON TABLE prod.finance.orders TO group finance_readers). Ergänzend stehen Row Filters (Row-Level Security als SQL-UDF), Column Masks (spaltenweise Maskierung, Hashing oder Redaktion) und Dynamic Views zur Verfügung. Identität kommt aus dem Cloud-Identity-Provider (Microsoft Entra ID, Okta, AWS IAM Identity Center) und wird per SCIM in den Databricks-Account synchronisiert. Column- und Table-Lineage entstehen automatisch aus SQL-, PySpark- und dbt-Läufen und sind über REST-API und die System-Tabellen system.access.table_lineage beziehungsweise system.access.column_lineage abfragbar.

Der Begriff existiert, weil klassische Metastores (Hive Metastore, AWS Glue Data Catalog) auf Workspace- oder Cloud-Anbieter-Ebene enden und weder Row/Column-Filter noch automatische Lineage über Workspaces hinweg leisten. Unity Catalog konsolidiert diese Aufgaben in einer Instanz: Katalog, Berechtigung, Lineage, Discovery, Audit und Cross-Workspace-Sharing (Delta Sharing) sitzen im selben Objektmodell. Parallel existiert Unity Catalog OSS unter Apache 2.0 als offener REST-Katalog für Delta Lake, Apache Iceberg und Apache Hudi; der OSS-Stand deckt Katalog- und Berechtigungs-Basics ab. Row Filter, Column Masks und automatische Lineage der Databricks-Ausprägung fehlen im OSS-Umfang.

Abgrenzung gegen Hive Metastore, Data Catalog, Data Governance und Glue Data Catalog

Der Begriff wird häufig mit benachbarten Konzepten aus der Katalog- und Governance-Welt verwechselt. Die folgenden Achsen halten die Grenzen sauber.

Begriff	Achse	Kernunterschied
Hive Metastore	Vorgänger	Zweistufiger Namensraum (database.table), workspace-lokal. Row- und Column-Filter fehlen; Lineage entsteht nicht automatisch; Cross-Workspace-Governance ist im Design nicht vorgesehen. Unity Catalog löst den HMS als primären Katalog ab; er bleibt als hive_metastore unter UC lesbar.
Data Catalog (Oberbegriff)	Kategorie	Metadaten- und Discovery-Plattformen wie Collibra, Alation, Atlan oder Microsoft Purview inventarisieren Datenbestände plattform-übergreifend. Zugriffsrechte auf die Daten werden dort typischerweise nicht durchgesetzt. Unity Catalog vereint Katalog und Enforcement in einer Instanz.
Data Governance	Prozess-Ebene	Organisatorischer Rahmen aus Rollen, Policies, Standards und Verantwortlichkeiten. Unity Catalog ist die technische Umsetzungsschicht innerhalb dieses Rahmens; das Governance-Modell selbst liegt außerhalb des Systems.
AWS Glue Data Catalog	Cloud-Kataloge	Serverless-Metastore mit HMS-kompatibler API, IAM-Integration und AWS-Services wie Athena, EMR, Redshift Spectrum. Zweistufiger Namensraum; Row-Level Security, ML-Model-Registry und Cross-Cloud-Governance fehlen.

Der Hive Metastore ist die Vorgänger-Generation: rein tabellenzentriert, ohne Ownership-Modell im Katalog selbst, mit ACLs über Hadoop Ranger oder cloud-native IAM. Unity Catalog erweitert das Modell um einen Catalog-Layer, integrierte Berechtigungen, Lineage und feingranulare Filter.

Ein Data Catalog im fachlichen Sinn (Collibra, Alation, Atlan, Purview) beantwortet die Frage „Welche Daten gibt es und was bedeuten sie?". Er ist Discovery- und Ownership-Layer und liegt logisch über Query-Engines und Katalogen. Unity Catalog ist demgegenüber ein technischer Katalog mit Enforcement und Lineage, der Business-Glossare, Tags und Semantik-Modelle mittlerweile mitbringt, aber nicht plattform-übergreifend inventarisiert.

Data Governance ist der Prozess-Oberbegriff und beschreibt das Betriebsmodell (Data Owner, Steward, Policies, Klassifikationen, Auditverfahren). Unity Catalog liefert dazu die Kontrollpunkte im System (Grants, Filter, Audit-Log, Lineage), ersetzt aber nicht die Regeln und Rollen der Organisation.

AWS Glue Data Catalog ist funktional dem Hive Metastore näher als dem Unity Catalog. Er ist AWS-spezifisch, HMS-kompatibel und über IAM und Lake Formation berechtigt, kennt aber weder Volumes, ML-Models, Feature Tables noch Cross-Cloud-Metastores.

Beispiel: Drei Workspaces auf Azure unter einem Metastore

Ein Databricks-Konto in Azure Westeuropa hält drei Workspaces (dev, stg, prod) unter einem gemeinsamen Unity-Catalog-Metastore. Kataloge sind nach Umgebung geschnitten (dev, stg, prod), Schemas nach Fachbereich (finance, sales, hr). Storage Credentials referenzieren einen Managed Identity auf ADLS Gen2, External Locations bilden die Container-Pfade ab.

Ein Steward vergibt Rechte per SQL:

sql

GRANT USE CATALOG ON CATALOG prod TO `finance_readers`;
GRANT USE SCHEMA ON SCHEMA prod.finance TO `finance_readers`;
GRANT SELECT ON TABLE prod.finance.orders TO `finance_readers`;

Ein Row Filter beschränkt Zeilen pro Region, ein Column Mask hasht die IBAN-Spalte für alle Rollen außerhalb finance_admins:

sql

CREATE FUNCTION prod.finance.region_filter(region STRING)
RETURN region = current_user_region();

ALTER TABLE prod.finance.orders
SET ROW FILTER prod.finance.region_filter ON (region);

ALTER TABLE prod.finance.orders
ALTER COLUMN iban SET MASK prod.finance.iban_hash;

Ein Modell landet über MLflow in prod.ml.churn_model, ein Volume prod.finance.reports speichert PDF-Berichte. Table- und Column-Lineage entsteht automatisch beim Job-Lauf; system.access.audit protokolliert Zugriffe. Der Auditbericht joined system.access.audit mit system.access.table_lineage, um lesende Zugriffe der letzten 90 Tage samt Upstream-Quellen in einer SQL-Abfrage nachzuweisen.