Databricks Unity Catalog: So wird aus Tool-Wildwuchs eine belastbare Governance
Die Kernaussagen auf einen Blick.
- Unity Catalog bündelt Governance für Daten und KI in Databricks an einer zentralen Stelle. Berechtigungen, Datenkatalog, Lineage und Audit müssen dadurch nicht mehr über mehrere Werkzeuge gepflegt werden.
- Der eigentliche Mehrwert entsteht nicht durch einzelne Funktionen, sondern durch ein einheitliches Governance-Modell für Tabellen, Dateien, Modelle und weitere Datenobjekte.
- Vor der Einführung sollten drei Fragen geklärt werden: Wie wird die Plattform strukturiert? Wie werden Berechtigungen vergeben? Und wer verantwortet Daten, Tags und Richtlinien?
- Unity Catalog ist die technische Grundlage für Governance. Damit sie im Alltag funktioniert, braucht es zusätzlich klare Verantwortlichkeiten, ein einfaches Berechtigungsmodell und gepflegte Metadaten.
Inhaltsverzeichnis
Governance ist mehr als ein Katalog
Eine typische Audit-Frage klingt zunächst einfach: Welche Daten sind in ein bestimmtes Modell eingeflossen? Wer hatte Zugriff auf die zugrunde liegenden Kundeninformationen? Und wer ist für die Tabelle verantwortlich, aus der eine regulatorische Auswertung erstellt wurde?
In vielen gewachsenen Datenplattformen lässt sich das nicht ohne Weiteres beantworten. Die Metadaten liegen beispielsweise in Collibra, ein Fachbereich pflegt zusätzlich einen eigenen Katalog und das Compliance-Team führt eine separate Excel-Liste. Berechtigungen verteilen sich gleichzeitig auf Workspace-ACLs, Cloud-IAM-Rollen und individuell gepflegte Tabellen.
Jedes dieser Werkzeuge kann für sich sinnvoll sein. Es fehlt die Gesamtsicht. Genau dieses Muster sehen wir in gewachsenen Databricks-Umgebungen: ein Hive Metastore aus der Anfangszeit, mehrere Workspaces für Data Engineering, Data Science und BI, Lineage in Confluence, Klassifikationen in Excel. Bei einer Audit-Anfrage müssen Informationen aus mehreren Systemen zusammengetragen und manuell dokumentiert werden; der Nachweis besteht am Ende aus Screenshots, Stichproben und dem Wissen Einzelner.
Isolierte Workspaces, oder eine gemeinsame Governance-Schicht.
Ohne Unity Catalog verwaltet jeder Workspace User Management, Metastore und Access Control für sich. Mit Unity Catalog teilen sich alle Workspaces dieselbe Governance-Schicht.
Spätestens wenn mehrere Teams, Workloads und externe Datenquellen zusammenkommen, wird das unübersichtlich: Audit-Anfragen dauern zu lange, Änderungen an Tabellen haben schwer abschätzbare Folgen und sensible Daten können in Reports landen, deren Berechtigungslogik niemand vollständig nachvollzieht.
In Plattform- und Governance-Projekten stellen sich deshalb meist vier Fragen:
- Welche Tabellen, Volumes und Modelle sollen zentral verwaltet werden?
- Welches Berechtigungsmodell deckt regulatorische Vorgaben und interne Mandantentrennungen ab?
- Wer ist für Tags, Klassifikationen und Maskierungsregeln verantwortlich?
- Welche bestehenden Datenkataloge bleiben notwendig und welche Funktionen können durch Unity Catalog übernommen werden?
Unsere These: Das eigentliche Problem ist selten ein fehlendes Werkzeug. Meist sind Berechtigungen, Metadaten und Audit-Informationen auf zu viele Systeme verteilt.
Unity Catalog setzt genau dort an. Tabellen, Volumes, Modelle, Functions und angebundene Datenquellen können unter einem gemeinsamen Berechtigungs-, Klassifikations- und Audit-Modell verwaltet werden. Die folgenden Abschnitte zeigen, wie diese Governance aufgebaut ist und wo ihre Grenzen liegen.
Was ist Databricks Unity Catalog?
Unity Catalog ist die native Governance-Schicht des Databricks Lakehouse. Sie verwaltet Berechtigungen, Klassifikation, Lineage und Audit für Tabellen, Views, Volumes, Functions und Modelle in einem gemeinsamen Namensraum, statt diese Aufgaben über mehrere Werkzeuge zu verteilen.
Plattform-Governance bedeutet dabei nicht, eine weitere Liste zu pflegen, in der steht, wer welchen Bericht öffnen darf.
Es geht darum, jedes relevante Datenobjekt eindeutig zu verwalten. Eine Tabelle, View, Function, ein Volume oder ein Modell sollte einen klaren Namen, einen verantwortlichen Owner, nachvollziehbare Zugriffsrechte, eine Klassifikation und eine dokumentierte Herkunft haben.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Ein Catalog für alle Asset-Typen.
Unity Catalog verwaltet nicht nur Tabellen, sondern den kompletten Asset-Zoo eines modernen Lakehouses. Strukturierte Daten, AI-Assets und Unstrukturiertes liegen unter denselben Permissions, derselben Lineage.
Catalog
Damit beantwortet die Governance nicht nur die Frage, ob eine Tabelle existiert. Sie beantwortet auch:
- Wer darf darauf zugreifen?
- Welche Daten enthält sie?
- Woher kommen diese Daten?
- Für welchen Zweck sind sie freigegeben?
- Wer ist bei Problemen oder Änderungen verantwortlich?
Unity Catalog ist dabei enger auf Databricks ausgerichtet als ein klassischer Enterprise-Datenkatalog, gleichzeitig aber tiefer in die Plattform integriert.
Werkzeuge wie Collibra, Alation oder Atlan helfen vor allem bei unternehmensweiter Suche, Dokumentation und Stewardship, setzen Zugriffsrechte aber meist nicht selbst durch; Policy-Plattformen wie Immuta oder Privacera setzen Regeln über mehrere Plattformen hinweg durch. Unity Catalog verbindet diese Aufgaben direkt mit dem Databricks Lakehouse: Berechtigungen, Klassifikation, Lineage und Audit sind Teil der Plattform und werden dort durchgesetzt, wo die Daten verarbeitet und abgefragt werden.
Der praktische Vorteil: Für viele Fragen muss nicht mehr in mehreren Werkzeugen gesucht werden. Zugriffsrechte, Ownership, Lineage und Audit-Informationen lassen sich direkt am jeweiligen Datenobjekt nachvollziehen.
Unity Catalog löst damit allerdings nicht jedes Governance-Problem. Fachliche Definitionen, Datenqualitätsregeln und die unternehmensweite Katalogisierung von SAP-, Mainframe- oder CRM-Daten bleiben eigene Aufgaben. Unity Catalog liefert die technische Grundlage, ersetzt aber keine Governance-Organisation.
Die vier Bausteine einer belastbaren Governance
Eine funktionierende Governance mit Unity Catalog lässt sich in vier Bereiche unterteilen:
- Identität und Namespace
- Berechtigungen
- Klassifikation und fachliche Bedeutung
- Audit und Lineage
Jeder Bereich beantwortet eine andere Frage.
| Bereich | Zentrale Frage | Wichtige Komponenten | Ergebnis |
|---|---|---|---|
| Identität und Namespace | Welche Datenobjekte werden zentral verwaltet? | Catalogs, Schemas, Volumes, External Locations, Federation | Ein eindeutiger Namensraum für Daten und Dateien |
| Berechtigungen | Wer darf unter welchen Bedingungen auf Daten zugreifen? | Grants, RBAC, ABAC, Row Filters, Column Masks, Dynamic Views | Zentral durchsetzbare Zugriffsregeln |
| Klassifikation und Bedeutung | Was enthält ein Objekt und wer ist dafür verantwortlich? | Tags, Kommentare, fachliche Metadaten, Discovery | Bessere Suche, klare Verantwortung und Grundlage für Policies |
| Audit und Lineage | Wer hat was getan und woher stammen die Daten? | Lineage, Audit Logs, System Tables | Nachvollziehbarkeit und bessere Impact-Analysen |
Diese Bereiche hängen zusammen: Eine ABAC-Regel braucht verlässliche Tags, eine Lineage-Auswertung sauber benannte Tabellen und Quellen. Für die Einführung ist deshalb eine Reihenfolge sinnvoll: zuerst der Namensraum, dann das Berechtigungsmodell, darauf Klassifikation, Richtlinien und Audit. Audit-Logs sollten von Anfang an erfasst werden, aussagekräftig werden sie aber erst mit konsistent organisierten Objekten und Berechtigungen.
Namespace, Zugriff und Lineage: in einem Governance-Modell.
Catalogs bündeln Namespace und Zugriffsmodelle, eine eigene Access-Control-Ebene trägt RBAC, ABAC und Row-/Column-Regeln, darunter fassen Lineage und Compliance die Nachvollziehbarkeit zusammen.
Catalogs, Volumes, External Locations und Federation richtig einordnen
Am Anfang steht eine grundlegende Entscheidung: Welche Datenobjekte sollen über Unity Catalog verwaltet werden und wie werden sie organisiert?
Dafür stellt Unity Catalog mehrere Bausteine bereit:
- Catalogs strukturieren die oberste Ebene des Namensraums.
- Volumes verwalten Dateien wie PDFs, Bilder, Logs oder Modellartefakte.
- External Locations regeln den Zugriff auf selbst verwalteten Cloud-Speicher.
- Lakehouse Federation bindet externe Datenbanken ein, ohne deren Daten zunächst kopieren zu müssen.
Das Catalog-Design entscheidet über die spätere Komplexität
Die wichtigste Architekturentscheidung ist der Aufbau der Catalogs.
Ein einziger Catalog für die gesamte Plattform funktioniert häufig nur in kleinen Pilotumgebungen. Sobald mehrere Fachbereiche, Umgebungen oder Mandanten hinzukommen, werden Berechtigungen und Verantwortlichkeiten schnell unübersichtlich.
Das andere Extrem (ein eigener Catalog für nahezu jede Tabelle oder jedes Team) erzeugt unnötigen Verwaltungsaufwand.
In vielen Plattformen hat sich deshalb eine Struktur bewährt, die Umgebung und fachliche Domäne kombiniert. Ergänzend können eigene Sandbox-Catalogs für explorative Arbeit und Foreign Catalogs für externe Datenquellen eingerichtet werden.
Beispielsweise:
- prod_sales
- prod_finance
- prod_operations
- dev_sales
- dev_finance
- sandbox_team_a
Drei Ebenen: Metastore, Catalog, Schema.
Jedes Datenobjekt hängt eindeutig an einem Catalog und einem Schema. Diese Drei-Ebenen-Struktur ist die Grundlage für Berechtigungen, Discovery und Lineage.
Volumes und External Locations
Nicht alle relevanten Daten liegen in Tabellen. PDFs, Bilder, Konfigurationsdateien, Machine-Learning-Artefakte und andere Dateien müssen ebenfalls kontrolliert zugänglich sein.
Volumes nehmen diese Dateien in den Unity-Catalog-Namensraum auf. Dadurch lassen sie sich mit denselben grundlegenden Governance-Prinzipien verwalten wie Tabellen.
External Locations regeln wiederum, auf welche Bereiche des Cloud-Speichers Databricks zugreifen darf. Die Zugriffssteuerung erfolgt damit nicht ausschließlich über AWS IAM oder Azure-Rollen, sondern kann gezielt in Unity Catalog eingebunden werden.
Federation verbindet externe Systeme mit Unity Catalog
Mit Lakehouse Federation können externe Systeme wie PostgreSQL, Snowflake, BigQuery oder ein bestehender Hive Metastore als Foreign Catalog eingebunden werden.
Das eignet sich vor allem für:
- Discovery und Inventarisierung,
- erste Analysen über mehrere Quellen,
- schrittweise Migrationen,
- ausgewählte Abfragen ohne vorherige Replikation.
Wichtig ist die Abgrenzung: Federation kopiert die Daten nicht automatisch in das Lakehouse. Die Abfrage läuft weiterhin gegen das Quellsystem. Damit bleiben dort auch Rechenlast, Lizenzkosten und technische Einschränkungen bestehen.
Federation ist deshalb vor allem ein Anschluss an die Governance- und Discovery-Welt von Databricks. Für häufige oder besonders rechenintensive Workloads ist eine gezielte Replikation in das Lakehouse meist die robustere Lösung.
Berechtigungen mit RBAC, ABAC und Row-Level Security
Unity Catalog bündelt die Zugriffssteuerung für Tabellen, Views, Volumes, Functions und weitere Objekte. Die Grundlage bilden Access Control sowie Permissions und Grants, die möglichst über Gruppen und übergeordnete Ebenen vergeben werden sollten.
In der Praxis kommen vor allem zwei Berechtigungsmodelle zum Einsatz: RBAC und ABAC.
RBAC für Rollen und typische Aufgaben
Role-Based Access Control ordnet Berechtigungen anhand von Rollen beziehungsweise Gruppen zu.
Ein Data-Engineering-Team erhält beispielsweise Schreibrechte auf bestimmte Schemas, während ein BI-Team nur freigegebene Tabellen lesen darf. Einzelne Personen werden den passenden Gruppen zugeordnet, statt individuelle Berechtigungen zu erhalten.
Das erleichtert:
- Onboarding und Offboarding,
- regelmäßige Berechtigungsprüfungen,
- die Dokumentation im Audit,
- die einheitliche Verwaltung über mehrere Catalogs und Schemas.
RBAC sollte für den Großteil der normalen Zugriffsregeln ausreichen.
ABAC für datenabhängige Regeln
Attribute-Based Access Control ergänzt dieses Modell. Dabei hängt eine Berechtigung nicht nur von der Rolle eines Nutzers ab, sondern auch von Eigenschaften der Daten.
Eine Regel kann beispielsweise festlegen:
- Daten mit dem Tag sensitivity = restricted dürfen nur bestimmte Gruppen sehen.
- Nutzer dürfen ausschließlich Daten ihres Mandanten abrufen.
- Personenbezogene Spalten werden außerhalb eines definierten Teams maskiert.
- Daten dürfen nur innerhalb einer bestimmten Region genutzt werden.
ABAC ist besonders hilfreich, wenn klassische Rollen zu grob werden oder zu viele Sonderrollen entstehen würden.
RBAC und ABAC sind daher keine konkurrierenden Ansätze. RBAC bildet die organisatorische Grundstruktur. ABAC ergänzt sie dort, wo Datenklassifikation, Mandant, Region oder Sensibilität in die Entscheidung einfließen müssen.
Row-Level Security und Column Masking
Berechtigungen auf Tabellenebene reichen nicht immer aus. Eine Tabelle kann beispielsweise Daten mehrerer Mandanten oder Regionen enthalten.
Mit Row-Level Security und Column Masking lässt sich steuern, welche Zeilen ein Nutzer sehen darf und welche Spalten vollständig, teilweise oder gar nicht angezeigt werden.
Damit kann eine gemeinsame Tabelle für mehrere Nutzergruppen verwendet werden, ohne für jede Gruppe eine eigene Kopie oder View pflegen zu müssen.
Wann Dynamic Views sinnvoll sind
Dynamic Views eignen sich, wenn Zugriffslogik und zusätzliche Transformationen in einer klar definierten Konsumentensicht zusammengefasst werden sollen.
Die Entscheidung hängt vom Anwendungsfall ab:
- Tabellennahe Maskierungen sind sinnvoll, wenn eine Regel unabhängig vom Zugriffsweg gelten soll.
- Dynamic Views passen besser, wenn Nutzer bewusst über eine kuratierte Sicht auf die Daten zugreifen sollen.
Für ein wartbares Berechtigungsmodell gelten einige einfache Grundregeln:
- Berechtigungen an Gruppen statt an Einzelpersonen vergeben.
- Rechte möglichst auf Catalog- oder Schemaebene vererben.
- Sonderfälle nicht durch immer neue Rollen abbilden.
- Tags und ABAC nur mit klaren Verantwortlichkeiten einführen.
- Row Filters und Maskierungen zentral testen und dokumentieren.
Wer dagegen für jede einzelne Tabelle manuell Grants verteilt, baut mit der Zeit eine Berechtigungsstruktur auf, die kaum noch vollständig nachvollziehbar ist.
Daten verständlich machen
Zugriffsrechte allein reichen für eine funktionierende Governance nicht aus. Nutzer müssen auch verstehen können, was ein Datenobjekt enthält, zu welcher Domäne es gehört und wer dafür verantwortlich ist.
In Unity Catalog übernehmen vor allem drei Bereiche diese Aufgabe:
- Tags klassifizieren Datenobjekte.
- Business Semantics ergänzen fachliche Begriffe und Definitionen.
- Discovery hilft Nutzern, geeignete Daten zu finden.
Tags als Grundlage für Klassifikation und Policies
Tags klassifizieren Datenobjekte über wenige kontrollierte Dimensionen. In vielen Organisationen reichen zunächst:
- Sensibilität: public, internal, confidential, restricted
- Fachliche Domäne: sales, finance, claims
- Owner beziehungsweise verantwortlicher Bereich
- Lebenszyklus: draft, certified, deprecated
- gegebenenfalls Mandant oder Region
Diese Informationen verbessern nicht nur die Suche, sie lassen sich auch direkt für ABAC-Regeln verwenden. Das Modell sollte bewusst klein beginnen.
Fachliche Begriffe mit technischen Objekten verbinden
Business Semantics verbinden Tabellen und Spalten mit fachlichen Definitionen.
So kann beispielsweise dokumentiert werden:
- Was genau ist ein aktiver Kunde?
- Wie wird der Nettoumsatz berechnet?
- Welches Feld ist die führende Kundennummer?
- Wer darf eine Kennzahl fachlich freigeben?
- Welche Tabelle ist für einen bestimmten Bericht verbindlich?
Diese Informationen sollten möglichst nah am Datenobjekt gepflegt werden. Andernfalls entstehen parallele Dokumentationen, die sich mit der Zeit auseinanderentwickeln.
Unity Catalog kann diese Aufgabe innerhalb der Databricks-Welt gut unterstützen. Für ein unternehmensweites Glossar über SAP, Mainframe, CRM und weitere Plattformen kann trotzdem ein externer Enterprise-Datenkatalog sinnvoll bleiben.
Discovery funktioniert nur mit gepflegten Metadaten
Nutzer suchen Daten selten anhand eines vollständigen Three-Part-Names. Sie suchen nach Begriffen wie „Kundenumsatz“, „Schadenquote“, „vertraulich“ oder nach dem zuständigen Fachbereich.
Damit diese Suche funktioniert, müssen Tags, Beschreibungen und Ownership-Informationen aktuell sein.
Die Technik stellt die Discovery-Suchfunktion bereit. Ob sie im Alltag tatsächlich hilft, hängt jedoch von der Qualität der Metadaten und den Pflegeprozessen ab.
Datenherkunft nachvollziehen
Für Audits und regulatorische Nachweise sind zwei Fragen entscheidend:
- Woher stammen die Daten?
- Wer hat wann darauf zugegriffen oder sie verändert?
Unity Catalog beantwortet diese Fragen über Lineage und System Tables.
Lineage zeigt Herkunft und Abhängigkeiten
Lineage dokumentiert, wie Daten zwischen Tabellen, Views, Notebooks, Jobs und weiteren Objekten weitergegeben werden.
Das hilft unter anderem bei folgenden Fragen:
- Aus welchen Quellen wurde eine Tabelle aufgebaut?
- Welche Reports verwenden eine bestimmte Spalte?
- Welche nachgelagerten Prozesse sind von einer Schemaänderung betroffen?
- In welche Modelle oder Features sind bestimmte Daten eingeflossen?
- Welche Auswertungen könnten von einem Datenqualitätsproblem betroffen sein?
Damit ist Lineage nicht nur eine grafische Dokumentation. Sie unterstützt die Impact-Analyse bei Änderungen und liefert wichtige Informationen für regulatorische Nachweise.
Im Zusammenhang mit KI-Systemen kann beispielsweise nachvollzogen werden, welche Datenquellen für Features oder Trainingsdatensätze verwendet wurden. Im Banken- und Versicherungsumfeld hilft Lineage dabei, die Entstehung regulatorischer Kennzahlen und Modelle zu dokumentieren.
System Tables liefern die Audit-Daten
System Tables stellen Informationen zu Zugriffen, Berechtigungen, Jobs, Workloads und Kosten in strukturierter Form bereit.
Diese Daten können mit SQL ausgewertet und in Dashboards oder Audit-Datenprodukte übernommen werden.
So lassen sich beispielsweise Fragen beantworten wie:
- Wer hat in den vergangenen 90 Tagen auf eine bestimmte Tabelle zugegriffen?
- Über welchen Job oder welches Notebook erfolgte der Zugriff?
- Welche Berechtigungen waren zu diesem Zeitpunkt aktiv?
- Welche Workloads verursachten besonders hohe Kosten?
- Welche Änderungen wurden an sicherheitsrelevanten Objekten vorgenommen?
Der Vorteil gegenüber verteilten Logdateien liegt in der zentralen und strukturierten Auswertung.
System Tables sind jedoch keine fertige Compliance-Anwendung. Sie liefern die Rohdaten. Die Aufbereitung für BaFin-, EU-AI-Act-, Datenschutz- oder interne Audit-Berichte muss als eigener Prozess oder als eigenes Datenprodukt aufgebaut werden.
Unity Catalog vs Collibra, Alation und Atlan
In vielen Plattformprojekten stellt sich früher oder später die Frage, ob Unity Catalog einen bestehenden Datenkatalog ersetzen kann.
Die Antwort ist selten ein einfaches Ja oder Nein. Entscheidend sind drei Kriterien:
- Wie viele unterschiedliche Datenplattformen müssen abgedeckt werden?
- Wie tief müssen Berechtigungen technisch durchgesetzt werden?
- Welche Prozesse und Investitionen bestehen bereits?
Reichweite über Databricks hinaus
Wenn Databricks die zentrale Datenplattform ist und der Großteil der relevanten Daten dort verarbeitet wird, kann Unity Catalog einen großen Teil der technischen Governance und Discovery übernehmen.
Anders sieht es aus, wenn wichtige Datenbestände weiterhin in SAP, Mainframe-Systemen, Salesforce, Oracle-Datenbanken, Snowflake oder anderen Plattformen liegen.
Ein Enterprise-Datenkatalog wie Collibra, Alation oder Atlan kann dann als übergreifende Discovery- und Stewardship-Schicht sinnvoll bleiben. Unity Catalog liefert in diesem Modell die Metadaten und Governance-Informationen für die Databricks-Plattform, während der externe Katalog die unternehmensweite Sicht bereitstellt.
Gartner führt im Magic Quadrant für Metadata-Management-Solutions regelmäßig Collibra, Alation, Atlan und Informatica in dieser Rolle.
Technische Durchsetzung von Berechtigungen
Unity Catalog hat einen entscheidenden Vorteil innerhalb von Databricks: Berechtigungen und Richtlinien werden direkt bei der Datenverarbeitung und Abfrage durchgesetzt.
Ein externer Datenkatalog dokumentiert häufig, welche Berechtigungen in einem Quellsystem bestehen. Er ist aber nicht automatisch Teil des Query-Pfads.
Spezialisierte Policy-Plattformen wie Immuta oder Privacera können Richtlinien über mehrere Engines hinweg durchsetzen. Das ist insbesondere dann interessant, wenn Databricks, Snowflake, BigQuery oder weitere Plattformen dauerhaft parallel betrieben werden.
In einer weitgehend auf Databricks konzentrierten Architektur lässt sich ein großer Teil dieser Anforderungen direkt mit Unity Catalog abbilden.
Bestehende Prozesse und Investitionen
Ein seit Jahren etabliertes Collibra- oder Alation-Setup sollte nicht allein deshalb abgelöst werden, weil Unity Catalog ähnliche Funktionen anbietet.
Oft hängen daran:
- eingespielte Stewardship-Prozesse,
- fachliche Glossare,
- Freigabe-Workflows,
- Issue-Management,
- regulatorische Reports,
- zahlreiche Quellsystem-Connectoren.
In solchen Fällen ist eine hybride Architektur häufig sinnvoll: Unity Catalog übernimmt die operative Governance auf Databricks, der Enterprise-Katalog bleibt die übergreifende Discovery- und Stewardship-Plattform, und die Zuständigkeiten und Schnittstellen zwischen beiden Systemen werden klar definiert.
Von Tool-Wildwuchs zu einer Governance-Plattform
Governance bleibt nur dann verlässlich, wenn sie als fester Bestandteil der Plattform betrieben wird.
Manuell gepflegte Berechtigungen, Excel-Listen und Confluence-Diagramme sind oft zu Beginn ausreichend. Mit mehr Teams, Datenquellen und Workloads werden sie jedoch schnell unvollständig. Berechtigungen ändern sich, Tabellen werden umgebaut und neue Datenprodukte entstehen, ohne dass die Dokumentation konsequent nachgezogen wird.
Eine belastbare Governance unterscheidet sich in drei Punkten von einer Sammlung einzelner Tools:
- Regeln sind wiederholbar. Berechtigungen werden nach einem einheitlichen Modell und möglichst als Code verwaltet, etwa über Terraform oder Databricks Asset Bundles. So bleibt nachvollziehbar, welche Regel gilt, wer sie geändert hat und ob Entwicklung und Produktion voneinander abweichen.
- Verantwortlichkeiten sind eindeutig. Catalogs, Tag-Modelle, Datenprodukte und Maskierungsregeln haben benannte Owner, nicht nur als Metadatum, sondern zuständig für Freigaben, Änderungen und regelmäßige Prüfungen.
- Audit-Daten werden aktiv genutzt. System Tables und Lineage werden nicht erst bei einer Audit-Anfrage betrachtet, sondern regelmäßig für Compliance, Berechtigungsprüfung, Kostensteuerung und Impact-Analysen ausgewertet.
Damit wird Governance zu einem laufenden Plattformprozess statt zu einer einmaligen Konfiguration.
Drei Reifegrade für Unity Catalog
Getrennte Tools und lokale Berechtigungen
Mehrere Hive-Metastore- oder Workspace-Inseln, individuell gepflegte Berechtigungen, Tags und Ownership-Informationen in Excel, manuelle Lineage-Dokumentation und parallele Datenkataloge ohne klare Zuständigkeit. Audit-Anfragen erfordern viel Abstimmung und manuelle Recherche.
Unity Catalog als gemeinsame Grundlage
Catalogs und Schemas folgen einer definierten Struktur. Berechtigungen werden über Gruppen vergeben, produktive Pipelines liefern Lineage-Informationen. Erste Tags und Ownership-Regeln sind etabliert, RBAC deckt die normalen Zugriffe ab, während ABAC und feinere Maskierungen schrittweise eingeführt werden.
Governance als fester Plattformprozess
Berechtigungen und Policies werden versioniert und automatisiert ausgerollt. Tags und fachliche Metadaten haben klare Owner. System Tables bilden die Grundlage für Audit-, Compliance- und FinOps-Auswertungen. Externe Datenkataloge werden nur noch dort eingesetzt, wo sie einen klaren zusätzlichen Nutzen über Databricks hinaus liefern.
Die entscheidenden Fragen lauten:
- Wer verantwortet die Catalog-Struktur?
- Wer definiert und pflegt das Tag-Modell?
- Wer genehmigt sensible Zugriffsregeln?
- Wer betreibt die Audit-Auswertungen?
- Wie werden Änderungen getestet und ausgerollt?
Unity Catalog verbindet dabei die unterschiedlichen Workloads der Plattform. Data Engineering stellt Daten bereit, Business Intelligence nutzt freigegebene Datenprodukte und Artificial Intelligence greift auf nachvollziehbare Features, Trainingsdaten und Modelle zu.
Ohne eine gemeinsame Governance entwickelt jeder dieser Bereiche eigene Regeln und Prozesse. Das erhöht nicht nur den Aufwand, sondern erschwert auch die Nachvollziehbarkeit über den gesamten Datenlebenszyklus.
Grenzen von Unity Catalog
Unity Catalog deckt viele technische Governance-Aufgaben auf Databricks ab. Es ersetzt aber weder eine Governance-Organisation noch alle spezialisierten Werkzeuge:
Keine fachliche Data Stewardship
Tags, Berechtigungen und Owner lassen sich technisch verwalten. Was ein fachlicher Begriff bedeutet (wann ein Kunde als aktiv gilt, wie eine Kennzahl berechnet wird, wer Definitionen freigibt), entscheidet Unity Catalog nicht. Dafür braucht es Fachverantwortliche und verbindliche Stewardship-Prozesse.
ABAC braucht ein belastbares Metadatenmodell
ABAC vereinfacht komplexe Berechtigungsfälle, funktioniert aber nur mit konsistent gepflegten Tags; fehlende oder falsche Tags führen unmittelbar zu falschen Zugriffsentscheidungen. In dauerhaft heterogenen Multi-Engine-Architekturen können spezialisierte Plattformen wie Immuta oder Privacera weiterhin Vorteile bieten.
Federation passt nicht für jedes Lastprofil
Federation-Abfragen laufen im Quellsystem, dort bleiben Last, Lizenz- und Compute-Kosten sowie die Abhängigkeit von dessen Verfügbarkeit. Für Discovery, Migrationen und ausgewählte Abfragen ist das vertretbar; für häufige oder rechenintensive Workloads ist eine Replikation in das Lakehouse meist robuster.
Enterprise-Datenkataloge bieten mehr Stewardship-Workflows
Collibra, Alation und Atlan gehen über die technische Databricks-Governance hinaus (unternehmensweite Glossare, Freigabe- und Zertifizierungsprozesse, Workflow-Management, Connectoren für heterogene Quellen). Wer sie produktiv nutzt, ersetzt sie nicht durch Unity Catalog. Hier ist die Kombination beider Plattformen meist sinnvoller.
Die Hive-Metastore-Migration ist kein reines Technikprojekt
Tabellen lassen sich technisch überführen; der größere Aufwand liegt daneben: Berechtigungen inventarisieren, Gruppen und Rollen bereinigen, Catalogs und Schemas neu strukturieren, Owner festlegen, Tags definieren, Abhängigkeiten identifizieren, Anwendungen und Pipelines umstellen. Die organisatorische Klärung braucht meist mehr Zeit als die Umstellung selbst.
Fazit
Der größte Nutzen von Unity Catalog entsteht nicht durch ein weiteres Tool, sondern durch die Zusammenführung von Namensräumen, Berechtigungen, Klassifikation, Lineage und Audit in einem Modell.
Der größte Nutzen von Unity Catalog entsteht nicht durch ein weiteres Tool, sondern dadurch, dass bisher verteilte Namensräume, Berechtigungen, Klassifikation, Lineage und Audit konsistent zusammengeführt werden.
Dafür braucht es vier Grundlagen:
- eine nachvollziehbare Catalog- und Schema-Struktur,
- ein gruppenbasiertes Berechtigungsmodell,
- wenige, klar definierte Tags und Verantwortlichkeiten,
- einen festen Prozess für Audit, Lineage und regelmäßige Kontrollen.
Unity Catalog eignet sich besonders für Unternehmen, die Databricks als zentrale Daten- und AI-Plattform betreiben und Zugriffsrechte, Herkunft und Nutzung ihrer Daten zuverlässig nachweisen müssen.
Es ersetzt jedoch keine fachliche Data Stewardship und nicht automatisch jeden bestehenden Enterprise-Datenkatalog. In heterogenen Systemlandschaften ist häufig eine Kombination sinnvoll: Unity Catalog übernimmt die operative Governance auf Databricks, während ein übergreifender Katalog die unternehmensweite Discovery und fachliche Zusammenarbeit unterstützt.
Der sinnvollste Einstieg ist deshalb keine Feature-Liste, sondern eine Bestandsaufnahme:
- Welche Datenobjekte liegen heute noch außerhalb von Unity Catalog?
- Wo werden Berechtigungen aktuell verwaltet?
- Welche Gruppen, Rollen und Einzelberechtigungen bestehen?
- Welche Tags und Owner sind tatsächlich gepflegt?
- Wie lange dauert es heute, eine typische Audit-Frage zu beantworten?
Aus diesen Antworten ergibt sich meist recht klar, was als Nächstes priorisiert werden sollte: der Catalog-Zuschnitt, die Berechtigungsbereinigung, das Klassifikationsmodell oder die Integration eines bestehenden Datenkatalogs.
Trägt Unity Catalog bei euch als zentrale Governance-Schicht?
Ob Unity Catalog bei euch als zentrale Governance-Schicht tragen kann und wo der nächste Investitionsschritt sitzt, lässt sich in einem ersten Data-Governance-Assessment gut einordnen.
- welche Datenobjekte heute schon plattformfähig sind und wo das Hive-Metastore-Erbe bleibt
- welche externen Kataloge eine echte Investitionsschutz-Rolle haben und welche ablösbar sind
- welcher Reifegradpfad von Tool-Inseln zu Unity-Catalog-getragener Governance trägt
FAQ
Unity Catalog ist die native Governance-Schicht des Databricks-Lakehouse. Sie verwaltet Berechtigungen, Klassifikation, Lineage und Audit für Tabellen, Views, Volumes, Functions und Modelle in einem gemeinsamen Namespace. Damit ersetzt sie verteilte Berechtigungs-, Katalog- und Dokumentationsansätze durch ein konsolidiertes Modell, das in einem einzigen System abfragbar und auditierbar bleibt.
