Catalogs in Unity Catalog: Definition und Abgrenzung

Ein Catalog in Unity Catalog ist die oberste Sortier-Ebene für Tabellen, Modelle und Dateien in Databricks, vergleichbar mit einem Ordner, der Schemas (die wiederum Tabellen enthalten) bündelt und den Zugriff darauf steuert. Er trennt in der Regel Umgebungen (Entwicklung, Test, Produktion), Fachbereiche oder Mandanten und ist Grundlage für Berechtigungen, Herkunftsnachweis (Lineage) und Suchbarkeit.

Was sind Catalogs in Unity Catalog?

Ein Catalog ist die oberste der drei Ebenen im Unity-Catalog-Namensraum catalog.schema.object. Über dem Catalog liegt der Metastore (der zentrale Metadaten-Speicher pro Databricks-Konto und Region); unter dem Catalog liegen Schemas (früher „Databases" im Hive-Metastore), und unter den Schemas liegen die eigentlichen Datenobjekte: Delta- und Iceberg-Tabellen, Views, Volumes (Ordner für Dateien wie PDFs, Bilder oder Modell-Dateien), Machine-Learning-Modelle, Feature Tables und Functions. Eine Tabelle wird vollständig als <catalog>.<schema>.<table> adressiert, etwa prod.finance.orders.

Der Catalog übernimmt in dieser Hierarchie mehrere Aufgaben zugleich. Er ist der oberste Berechtigungscontainer: Rechte, die auf Catalog-Ebene vergeben werden (USE CATALOG, SELECT, MODIFY, MANAGE, BROWSE, ALL PRIVILEGES), vererben sich nach unten auf alle enthaltenen Schemas und Objekte. Er bindet einen Default-Cloud-Storage-Pfad (Managed Location) an seine Managed Tables und Managed Volumes; Daten aus diesen Objekten landen automatisch auf dem konfigurierten Speicherbereich (ADLS Gen2, Amazon S3, Google Cloud Storage). Und er kann optional an bestimmte Workspaces gebunden werden (Workspace Binding), sodass ein Catalog dev nur im Entwicklungs-Workspace sichtbar ist, ein Catalog prod nur im Produktions-Workspace.

Der Zuschnitt eines Catalogs folgt üblicherweise einer der drei Achsen: Umgebung (dev, stg, prod), Domäne (finance, sales, hr) oder Mandant (tenant_a, tenant_b). Kombinationen wie prd_sales sind verbreitet, wenn ein Databricks-Konto mehrere Fachbereiche und Umgebungen zugleich abbildet. Reserviert sind drei Sonder-Catalogs: hive_metastore als Legacy-Namespace für Tabellen aus dem klassischen Hive-Metastore, system als Read-Only-Katalog für System-Tabellen (Audit, Billing, Lineage) und samples mit Beispieldaten von Databricks.

Der Begriff wurde 2022 mit der allgemeinen Verfügbarkeit von Unity Catalog eingeführt. Vor Unity Catalog kannte Databricks nur den zweistufigen Namensraum database.table des Hive-Metastores; Umgebungen und Fachbereiche wurden über Workspaces und Namenspräfixe getrennt. Die Catalog-Ebene ist der strukturelle Kern des dreistufigen Modells und die Grundlage dafür, dass Berechtigungen, Managed Storage, Sichtbarkeit und Sharing zentral definiert werden können.

Abgrenzung zu Schemas, Metastore, Data Catalog und Hive-Metastore-Datenbank

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

Begriff	Achse	Kernunterschied
Schemas	Ebene darunter	Ein Schema ist eine logische Gruppe innerhalb eines Catalogs (früher „Database"). Es enthält Tabellen, Views, Volumes, Modelle und Functions. Grants am Catalog vererben sich auf alle Schemas darunter, Grants am Schema gelten nur für dessen Objekte.
Metastore	Ebene darüber	Der Metastore ist der Metadaten-Speicher pro Databricks-Konto und Region und klammert alle Catalogs dieser Region. Ein Catalog gehört zu genau einem Metastore, ein Metastore enthält in der Regel viele Catalogs. Der Metastore verwaltet zusätzlich Storage Credentials, External Locations, Shares und Recipients.
Data Catalog (Sammelbegriff)	Kategorie	Ein Data Catalog wie Collibra, Alation, Atlan oder Microsoft Purview ist eine plattform-übergreifende Metadaten- und Discovery-Plattform mit Ownership, Business Glossary und Klassifikation. Ein Unity-Catalog-Catalog ist demgegenüber ein technischer Container mit direkter Berechtigungsdurchsetzung, kein plattform-übergreifender Discovery-Layer.
Hive-Metastore-Datenbank	Legacy-Namespace	Zweistufiger Namensraum database.table ohne Catalog-Ebene, workspace-lokal, ohne Cross-Workspace-Governance, ohne Volumes/Models. Der Bestand bleibt unter Unity Catalog als reservierter Katalog hive_metastore lesbar.

Schemas sind die Ebene direkt unter dem Catalog. Ein GRANT SELECT ON SCHEMA prod.finance TO group finance_readers bewirkt Leserechte auf alle Tabellen und Views in diesem Schema, aber nicht auf prod.sales. Ein GRANT USE CATALOG ON CATALOG prod TO group finance_readers erlaubt lediglich, dass das Schema überhaupt referenziert werden darf; der eigentliche Lesezugriff braucht zusätzlich Rechte am Schema oder Objekt.

Der Metastore ist die Ebene über den Catalogs und wird pro Region angelegt. Ein Databricks-Konto in Azure mit Workloads in Westeuropa und Nordamerika hat üblicherweise zwei Metastores; ein einzelner Catalog gehört immer nur einem davon. Storage Credentials und External Locations werden am Metastore verwaltet und stehen allen Catalogs zur Verfügung, denen sie explizit zugewiesen wurden.

Ein Data Catalog im fachlichen Sinn (Collibra, Alation, Atlan, Purview) beantwortet die Frage „Welche Daten gibt es im Unternehmen und was bedeuten sie?" über Plattformgrenzen hinweg. Er sammelt Metadaten aus vielen Quellsystemen, setzt aber typischerweise keine Zugriffsrechte auf die Daten selbst durch. Unity-Catalog-Catalogs sind technische Container mit direktem Enforcement für Databricks-Assets.

Die Hive-Metastore-Datenbank ist der Vorgänger-Namespace: eine relationale Datenbank hinter dem Hive Metastore Service (HMS), zweistufig aufgebaut (database.table), workspace-lokal, ohne integrierte Berechtigungsebene und ohne Lineage. Unter Unity Catalog bleibt der Bestand unter dem reservierten Namen hive_metastore sichtbar und kann per Hive-Metastore-Federation als Foreign Catalog unter Unity-Catalog-Berechtigungen gebracht werden.

Innerhalb von Unity Catalog existieren zusätzlich zum Standard-Catalog zwei weitere Typen. Ein Managed Catalog verwaltet Storage, Verzeichnisstruktur und Lebenszyklus über die Managed Location; das ist der Default. Ein Foreign Catalog (Federation) bildet ein externes System (MySQL, PostgreSQL, Snowflake, BigQuery, Redshift, MongoDB, Salesforce, Hive Metastore) als eigenen Catalog im Unity Catalog ab, ohne die Daten zu kopieren. Ein Shared Catalog stellt eine Delta-Sharing-Freigabe eines externen Providers als eigenen Katalog im Metastore dar.

Beispiel: Vier Catalogs auf einem Azure-Metastore

Ein Databricks-Konto in Azure Westeuropa hält einen Metastore mit vier Managed Catalogs und einem Foreign Catalog. Die Umgebungs-Catalogs dev, stg und prod trennen Entwicklungs-, Test- und Produktionsdaten; ein zusätzlicher Sandbox-Catalog explore hält kurzlebige Ad-hoc-Datenbestände. Der Foreign Catalog crm_snowflake bindet eine bestehende Snowflake-Instanz mit CRM-Daten per Lakehouse Federation an, ohne die Daten zu duplizieren. Schemas trennen die Fachbereiche: prod.finance, prod.sales, prod.hr.

Die Managed Location des Catalogs prod liegt auf einem eigenen ADLS-Gen2-Container. Managed Tables in prod.finance landen automatisch dort; Storage Credentials und External Locations sind zentral am Metastore hinterlegt und dem Catalog zugewiesen. 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`;
GRANT BROWSE ON CATALOG prod TO `data_stewards`;

Ein Workspace Binding beschränkt den Catalog prod auf den Produktions-Workspace; der Entwicklungs-Workspace sieht nur dev und explore. Beim Zugriff auf crm_snowflake.public.accounts reicht Unity Catalog die Query an die angebundene Snowflake-Instanz weiter, prüft aber die Rechte auf Unity-Catalog-Seite. Zugriffe erscheinen in system.access.audit, Column- und Table-Lineage entsteht automatisch beim Job-Lauf und ist über system.access.table_lineage abfragbar.