Unity Catalog Catalogs: Warum die richtige Aufteilung später viel Aufwand spart
Die Kernaussagen auf einen Blick.
- Catalogs sind die oberste Ebene in Unity Catalog und bestimmen deutlich mehr als nur den Tabellennamen. Sie beeinflussen, welche Workspaces etwas sehen, wie Berechtigungen vererbt werden, wo Managed Tables liegen, wie Sharing abgegrenzt wird und wie aufwendig spätere Migrationen werden.
- Ein einzelner zentraler Catalog reicht oft nur am Anfang oder in sehr kleinen Setups. Sobald mehrere Umgebungen, Domänen, Workspaces, Mandanten oder Sharing-Anforderungen dazukommen, werden Berechtigungen und Migrationen schnell unübersichtlich.
- Für viele Plattformen ist ein Modell nach Umgebung und Domäne sinnvoll, zum Beispiel , , , ergänzt um Sandbox-Catalogs und Catalogs für externe Quellen.
- Mein Vorschlag: Catalogs, Workspace Bindings, Managed Locations, External Locations und Berechtigungen von Beginn an als Code verwalten, idealerweise über Terraform. Eine spätere Umbenennung oder Neuaufteilung wird schnell teuer, weil Catalog-Namen in Jobs, Reports, Views und SQL-Abfragen stecken.
Inhaltsverzeichnis
Erst die Catalog-Struktur, dann die Rechte
Bei Unity Catalog geht es in Gesprächen oft zuerst um Berechtigungen, Lineage oder Discovery. Eine wichtige Entscheidung liegt aber eine Ebene darüber. Sie wird in vielen Projekten zu früh oder ohne klares Zielbild getroffen: Wie viele Catalogs brauchen wir, und wonach trennen wir sie?
In gewachsenen Plattformen sieht man häufig dasselbe Muster. Ein zentraler Catalog enthält viele Schemas und wird von mehreren Workspaces genutzt. Berechtigungen wurden mal auf Catalog-, mal auf Schema-Ebene vergeben. Bei der Hive-Migration fehlt dann die klare Entscheidung, ob Catalogs nach Umgebung, Domäne oder beidem geschnitten werden sollen. Eine Tochtergesellschaft soll Daten bekommen und Delta Sharing lässt sich nur schwer sauber abgrenzen, da Datenbereiche mit unterschiedlichen Empfängern gemeinsam in einem Catalog organisiert sind.
Catalogs sind mehr als Ordner für Schemas. Sie können Grenzen zwischen Umgebungen, Domänen und Mandanten abbilden, Workspace-Sichtbarkeit, Default-Storage und Sharing-Grenzen festlegen. Ihre Aufteilung entscheidet wesentlich mit, ob das Berechtigungsmodell langfristig verständlich bleibt. Das Bild wiederholt sich überall dort, wenn Unity Catalog nur als Berechtigungswerkzeug eingeführt wurde und nicht als Teil der Plattformstruktur.
Was ist ein Catalog in Unity Catalog?
Ein Catalog ist die oberste Ebene in Unity Catalog. Er bündelt Schemas, Tabellen, Views, Volumes, Funktionen und Modelle und übernimmt mehrere strukturelle Aufgaben. Vier Eigenschaften sind dabei besonders relevant. Diese Punkte beeinflussen Speicher, Sichtbarkeit und Berechtigungen der darunterliegenden Objekte. Berechtigungen vererben sich von Catalog zu Schema zu Objekt, Ownership wird auf jeder Ebene separat verwaltet. Als Orientierung gilt: Berechtigungen auf Catalog-Ebene können auf darunterliegende Schemas und Objekte vererbt werden.
Standard-Speicherort für Managed Tables
Cloud-Speicherbereich, in dem verwaltete Tabellen des Catalogs physisch als Delta-Dateien liegen.
External Locations für bestehende Speicherpfade
Verweis auf bereits vorhandene oder bewusst extern verwaltete Speicherpfade außerhalb des Managed-Bereichs.
Bindung an Workspaces
Legt fest, welche Workspaces den Catalog überhaupt sehen und nutzen dürfen.
Catalog-Typ
Bestimmt Speicherverhalten, Sharing-Modell und ob der Catalog Managed Tables aufnehmen kann.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Catalog, Schema und Object richtig einordnen
Unity Catalog nutzt den dreiteiligen Namen catalog.schema.object. Der Catalog ist die oberste Ebene. Darunter liegen Schemas, darunter Tabellen, Views, Volumes, Funktionen und Modelle. Tabellen und andere Objekte werden über diesen vollständigen Namen adressiert, etwa sales_prd.orders.fact_invoice. Der Catalog steckt damit in jeder vollständigen Objektadresse.
Unity Catalog unterscheidet mehrere Catalog-Typen. Sie legen unter anderem fest, wie Daten gespeichert, verwaltet und geteilt werden. Die Wahl des richtigen Catalog-Typs ist deshalb eine grundlegende Architekturentscheidung.
| Catalog-Typ | Zweck | Speicherbindung | Sharing | Typischer Einsatz |
|---|---|---|---|---|
| Standard | Standardcontainer für verwaltete Datenobjekte | Managed Location pro Catalog/Schema/Tabelle | Weitergabe nur über Delta Sharing | Datenprodukte, Umgebungen, Mandanten |
| Foreign (Federation) | lesender Zugriff auf externe Quellen | keine Managed Tables, nur Metadaten | über Lakehouse Federation lesend | Snowflake, BigQuery, Postgres, MySQL, Hive |
| Shared | Über Delta Sharing bereitgestellter Catalog | Storage liegt beim Provider | nur konsumierend (Weitergabe gesperrt) | eingehende Datenfreigaben von Partnern |
| System / Reserved | Von Databricks bereitgestellte und verwaltete Catalogs | systemseitig | nicht änderbar | , , |
Standard Catalogs enthalten die regulären Datenprodukte und Analyseobjekte. Sie haben einen Standard-Speicherort für Managed Tables und können Schemas, Tabellen, Views, Volumes und Funktionen enthalten. Auf ihnen stehen die zentralen Funktionen von Unity Catalog vollständig zur Verfügung.
Foreign Catalogs machen externe Quellsysteme als lesbare Catalogs in Unity Catalog sichtbar. Über Lakehouse Federation erscheinen Snowflake-, BigQuery-, Postgres- oder MySQL-Tabellen im dreiteiligen Namen catalog.schema.object und lassen sich abfragen, ohne die Daten vorher ins Lakehouse zu kopieren. Das kann eine Alternative zu eigens gebauten Ingestion-Pipelines sein, wenn das Quellsystem weiterhin führend bleibt. Sie dienen ausschließlich dem lesenden Zugriff und können keine Managed Tables aufnehmen.
Shared Catalogs entstehen beim Empfang von Daten über Delta Sharing. Sie zeigen Daten, die ein Partner explizit geteilt hat, lokal als Catalog an. Konsumierende Workspaces sehen die Daten wie einen lokalen Catalog. Eine erneute Weitergabe dieser Daten ist nicht vorgesehen.
System Catalogs sind reserviert. system enthält Audit-Logs, Lineage- und Billing-Daten als System Tables. samples enthält Demo-Daten. __databricks_internal ist für Zugriff gesperrt. Diese Catalogs lassen sich nicht löschen oder umbenennen und sollten im Betriebs-, Kosten- und Auditmodell berücksichtigt werden.
Wo die Managed Tables liegen
Die Zuordnung zum Cloud-Speicher ist ein wichtiger Teil der Catalog-Struktur. Sie legt fest, wo Managed Tables liegen und wer auf die Speicherpfade schreiben darf. Sie beeinflusst auch, wie sauber Umgebungen oder Datenbereiche auf Speicherebene getrennt sind.
Für Standard Catalogs sind zwei Speicherzuordnungen wichtig. Der Standard-Speicherort für Managed Tables ist ein Cloud-Speicherbereich (ADLS Gen2, S3, GCS), in dem die verwalteten Tabellen des Catalogs physisch als Delta-Dateien gespeichert werden. Er wird deklarativ einmal beim Anlegen gesetzt und sollte je nach Isolationsanforderung als eigener Container oder klar abgegrenzter Pfad umgesetzt werden. Überlappende Speicherpfade schwächen die Trennung zwischen Catalogs an der Storage-Ebene wieder ab.
External Locations verweisen auf bestehende Storage-Pfade, an denen bestehende oder bewusst extern verwaltete Dateien liegen: Bronze-Bereiche, Drittsysteme, fertige Exporte. Auf einer External Location gelten separate Privilegien für Datei- und Objektzugriffe (READ FILES, WRITE FILES), die unabhängig von Catalog-Berechtigungen vergeben werden. Die zugrundeliegende Authentifizierung läuft über Storage Credentials (Managed Identity, IAM Role).
Als Ausgangspunkt gilt: ein klar abgegrenzter Speicherbereich pro Catalog für Managed Tables; External Locations für bestehende oder bewusst extern verwaltete Speicherpfade. Wie External Locations dabei mit Berechtigungen und Storage-Credentials zusammenspielen, klären wir im Überblick zu External Locations.
Catalogs gezielt Workspaces zuordnen
Mit Catalog Binding lässt sich festlegen, welche Workspaces einen Catalog sehen dürfen. So kann ein produktiver Finance-Catalog zum Beispiel im Finance-Workspace vollständig genutzt werden, in einem Analyse-Workspace nur lesend verfügbar sein und in der Dev-Umgebung gar nicht erscheinen.
Ohne Binding ist ein Catalog grundsätzlich in allen angebundenen Workspaces sichtbar. Mit Binding wird diese Sichtbarkeit bewusst eingeschränkt. Das ist vor allem wichtig, wenn Workspaces nach Umgebung, Team oder Domäne getrennt sind. Die Einstellung ist in der Databricks-Dokumentation zu Catalog Binding beschrieben und lässt sich auch als Code verwalten, zum Beispiel über Terraform oder Databricks Asset Bundles.
Catalog Binding steuert aber nur, wo ein Catalog sichtbar ist. Welche Nutzer darin tatsächlich Daten sehen oder ändern dürfen, regeln weiterhin die Berechtigungen und Owner in Unity Catalog. Wie diese Rechtevererbung funktioniert und welche Owner-Konventionen sinnvoll sind, klären wir im Überblick zu Permissions in Unity Catalog.
Wie viele Catalogs braucht eine Databricks-Plattform?
Der größte Gestaltungsspielraum liegt in der Catalog-Aufteilung. Meist wird nicht nach einem einzigen Muster strukturiert, sondern nach einer Kombination aus Umgebung, Domäne, Mandant und Sandbox. Wichtig ist deshalb: Welche Trennung muss von Anfang an sauber stehen, und was kann später ergänzt werden?
| Trennung nach | Beispiele | Vorteil | Risiko |
|---|---|---|---|
| Umgebung | , , | Entwicklungs-, Test- und Produktivdaten sind klar getrennt. | Es entstehen viele Catalogs; Namenskonventionen müssen sauber sein. |
| Domäne oder Datenprodukt | , , | Berechtigungen und Ownership folgen der fachlichen Verantwortung. | Schnittstellen zwischen Domänen müssen bewusst geplant werden. |
| Mandant | , | Mandanten lassen sich organisatorisch und technisch stark trennen. | Das funktioniert nur mit sauberer Automatisierung. |
| Sandbox | , | Teams können außerhalb produktiver Bereiche explorieren. | Laufzeit, Löschung und Verantwortung müssen geregelt sein. |
Als Orientierung: Wenn Entwicklungs-, Test- und Produktivumgebungen getrennt sind, sollte die Umgebung im Catalog-Namen sichtbar sein. Wenn mehrere fachliche Domänen eigene Verantwortung tragen, lohnt sich eine Domänenstruktur. Häufig ist eine Kombination aus beidem sinnvoll, zum Beispiel prd_finance oder dev_sales. Für Self-Service und Exploration können zusätzlich Sandbox-Catalogs eingesetzt werden, aber nur mit klaren Regeln für Laufzeit, Kosten und Löschung.
Catalog-Struktur nach Umgebung, Domäne, Mandant und Sandbox
Ein häufig sinnvoller Ausgangspunkt für die meisten Plattformen ist eine Kombination aus Umgebung und Domäne: prd_sales, prd_finance, tst_sales, dev_sales und so weiter. Sie verbindet zwei Trennungen, die gut zu Verantwortlichkeiten und Deployment-Prozessen passen. Ergänzend können separate Sandbox-Catalogs für Exploration vorgesehen werden. Mandanten-Catalogs kommen dazu, wenn regulatorische oder vertragliche Anforderungen eine stärkere Trennung verlangen, typischerweise in Multi-Mandanten-SaaS oder bei regulatorischer Trennung.
ein Default-Catalog, Team-Catalogs und Schema-Präfixe
Einige Catalog-Strukturen wirken am Anfang einfach, werden aber mit mehr Workspaces, Domänen und Use Cases schnell schwer zu pflegen.
Ein Default-Catalog für alles
Reicht für kleine Plattformen. Sobald Umgebungen, Mandanten oder Sharing dazukommen, müssen Berechtigungen zunehmend auf Schema- und Tabellenebene gepflegt werden. Fehler in einzelnen GRANTs wirken sich dann schneller größer aus.
Ein Catalog pro Team oder Abteilung
Passt am Anfang gut zum Organigramm, bis sich Teams reorganisieren. Technische Umzüge ändern dann vollständige Objektnamen. Reports, Notebooks und Jobs können brechen.
Dev/Test/Prod nur über Schema-Präfixe
Reduziert die Zahl der Catalogs, schwächt aber die Trennung der Umgebungen. Workspace Bindings können Dev, Test und Prod dann nicht mehr sauber unterscheiden.
Die Databricks-Übersicht zu Catalogs in Unity Catalog zeigt die technischen Grenzen für Catalogs. In den meisten Plattformen gibt es genug Spielraum für eine saubere Aufteilung. Entscheidend ist deshalb weniger die technische Grenze, sondern ein klares Strukturmodell.
Zielmodell zuerst
Eine Migration vom Hive Metastore zu Unity Catalog sollte nicht als reine Eins-zu-eins-Übernahme geplant werden. Hive arbeitet mit zweiteiligen Namen wie database.table. Unity Catalog ergänzt diese Struktur um eine zusätzliche Ebene: catalog.schema.table. Ohne Zielmodell landen bisherige Hive-Datenbanken schnell einfach als Schemas in einem zentralen Catalog. Dann ist die alte Struktur nur in Unity Catalog verschoben, aber nicht verbessert.
Databricks bietet dafür verschiedene Hilfen. Mit SYNC lassen sich einzelne Hive-Datenbanken nach Unity Catalog übernehmen. Für größere Migrationen unterstützt UCX von Databricks Labs bei Inventur, Mapping und technischer Umsetzung. Dazu gehören die Erfassung bestehender Hive-Objekte, die Zuordnung in eine neue Catalog-Struktur und die Erstellung eines Migrationsplans. Entscheidend ist aber: Beide Wege brauchen vorher ein klares Zielmodell für Catalogs und Schemas.
Für Nutzer, Jobs und BI-Reports ändert sich vor allem der Namensraum. Aus database.table wird catalog.schema.table. Notebooks, Jobs und BI-Tools müssen auf diese dreiteiligen Namen umgestellt werden. Auch unvollständig qualifizierte Abfragen sollten geprüft werden, weil sie abhängig vom Default Catalog künftig andere Objekte treffen können.
Praktisch heißt das: Die Hive-Migration ist ein guter Zeitpunkt, die neue Struktur nach Umgebung und Domäne sauber aufzubauen. Nach der Umstellung werden spätere Catalog-Änderungen deutlich aufwendiger, weil bereits neue Abhängigkeiten in Jobs, Reports und Notebooks entstanden sind.
Terraform, Bindings, Grants und Naming
Mit wachsender Plattform sollte die Catalog-Struktur nicht mehr manuell gepflegt werden. Spätestens wenn mehrere Umgebungen synchron bleiben sollen oder die Zahl der Catalogs wächst, werden Klicks in der Oberfläche schnell fehleranfällig und schwer nachvollziehbar.
Üblich ist deshalb ein Modell als Code. Der Terraform Databricks Provider eignet sich besonders für zentrale Plattform- und Governance-Ressourcen: Catalogs, Catalog Bindings, Managed Locations, External Locations und Berechtigungen. Die gewünschte Struktur liegt im Repository, Änderungen laufen über Pull Requests und können reproduzierbar ausgerollt werden.
Databricks Asset Bundles sind der Databricks-native Weg, um Workloads, Jobs und Deployments zu beschreiben. Für zentrale Account- und Governance-Strukturen ist Terraform meist die vollständigere Wahl. In vielen Plattformen ergänzen sich beide Ansätze: Terraform für die Plattformbasis, Asset Bundles für Workloads.
Auch Namenskonventionen sollten früh feststehen. Catalog-Namen sind Teil jedes vollständigen Objektnamens, zum Beispiel catalog.schema.table. Deshalb wirken sich inkonsistente Namen direkt auf SQL-Abfragen, Jobs, Reports und Automatisierung aus. Bewährt haben sich kurze, einheitliche Namen mit Umgebung und Domäne, etwa prd_sales oder dev_finance. Mischformen wie sales-prod, vertrieb_produktion oder spätere Anhänge wie sales_v2 werden langfristig schnell unübersichtlich.
Grenzen
Eine gute Catalog-Aufteilung schafft die technische Grundlage, ersetzt aber kein Datenprodukt- und Governance-Modell. Und auch technisch gibt es Grenzen, die früh in die Entscheidung gehören.
Kein Ersatz für ein Datenprodukt-Modell
Datenprodukte brauchen zusätzlich Ownership, Qualitätsregeln, Service Levels und gepflegte Metadaten. Das leistet die Catalog-Struktur allein nicht.
Wirkt auf Sharing-Fähigkeit zurück
Unterschiedliche Sharing-Anforderungen können zusätzliche Catalogs oder Views erforderlich machen. Delta-Sharing-Anwendungsfälle sollten früh in die Zielstruktur einfließen.
Umbenennung ist migrationsintensiv
Catalog-Namen sind in zahlreichen Abfragen, Jobs und Berichten fest hinterlegt. Eine Umbenennung erfordert meist eine geplante Übergangs- und Migrationsstrategie.
Lakehouse Federation reift je Quellsystem unterschiedlich
Die Konnektoren sind je Quellsystem unterschiedlich weit. Der aktuelle Stand sollte für jede relevante Quelle geprüft werden.
Workspace Bindings haben Workload-Grenzen
Manche kombinierten Workload-Typen oder verbundene Funktionen setzen volle Catalog-Sichtbarkeit voraus, vor dem produktiven Setup pro Workload prüfen.
Fazit
Die Catalog-Aufteilung ist eine der wichtigsten Architekturentscheidungen in Unity Catalog: Sie bestimmt Sichtbarkeit, Speicherstruktur, Sharing und die Vererbung von Berechtigungen.
Ein einzelner zentraler Catalog reduziert zunächst den Einrichtungsaufwand. Mit mehreren Umgebungen, Workspaces, Domänen oder Sharing-Anforderungen wird er aber zunehmend schwer wartbar, etwa bei der Hive-Migration, beim ersten Multi-Workspace-Setup oder bei den ersten systematischen Sharing-Anforderungen.
Der richtige Zeitpunkt für diese Entscheidung ist vor allem dann, wenn die Plattform gerade aufgebaut wird, eine Migration aus Hive Metastore ansteht oder eine gewachsene Landschaft konsolidiert werden soll. In diesen Phasen lässt sich die Zielstruktur noch mit vergleichsweise wenigen bestehenden Abhängigkeiten umsetzen. Spätere Änderungen erfordern dagegen die Anpassung zahlreicher Konsumenten.
Bei wenigen Schemas, einem Workspace und ohne getrennte Umgebungen kann ein einzelner Catalog zunächst reichen. Sie sollte aber bewusst gewählt sein und nicht nur entstehen, weil die Architekturentscheidung vertagt wurde.
Mein Vorschlag: Als Ausgangspunkt ein Modell nach Umgebung und fachlicher Domäne definieren, separate Sandbox-Catalogs mit klaren Lösch- und Verantwortungsregeln für Exploration vorsehen, externe Quellen bei passendem Zugriffsprofil über eigene Foreign Catalogs anbinden. Catalogs, Bindings, Speicherzuordnungen und Berechtigungen sollten vollständig als Code verwaltet werden über den Terraform Databricks Provider von Anfang an. Eine stabile Catalog-Struktur erleichtert spätere Erweiterungen und reduziert Migrationsaufwand. Sie sollte deshalb als fester Bestandteil der Plattformarchitektur versioniert und regelmäßig überprüft werden.
Prüft eure aktuelle Catalog-Struktur gegen ein Modell nach Umgebung und Domäne, bevor die nächste Hive-Migration oder das nächste Multi-Workspace-Setup ansteht.
FAQ
Ein Catalog ist die oberste Ebene im dreiteiligen Namensraum . Er bündelt Schemas, Tabellen, Views, Volumes, Funktionen und Modelle und legt Default-Storage, Workspace-Sichtbarkeit, Sharing-Verhalten und Berechtigungs-Vererbung fest. Damit ist der Catalog die wichtige Struktur für Mandanten, Umgebungen und Governance.
