Bablu ChakrabortySenior Vizepräsident – Kompetenzentwicklung
Aishwarya SaranInformationsalchemist
Melden Sie sich an, um die neuesten Einblicke und Updates zu Technologie, KI & Datenanalyse, Data Science und Innovationen von Polestar Analytics zu erhalten.
Fassen Sie diesen Blogbeitrag wie folgt zusammen:Databricks Unity Catalog-Migrationen scheitern nicht aufgrund von Zugriffskontrollen bei großem Umfang. Sie scheitern vielmehr dann, wenn Teams Schemas, Berechtigungen und Benutzer migrieren – ohne dabei Domänen, Metadaten und Betriebsmodelle zu migrieren.
Der Databricks Unity Catalog verzeichnete über 1 Million monatliche SKD-Downloads . Die Akzeptanz ist eindeutig nicht das Problem. Was nach der Akzeptanz passiert, ist es.
Die meisten Unternehmen migrieren zu Unity Catalog und behandeln es wie Hive Metastore mit erweiterten Berechtigungen. Spoiler-Alarm: Das stimmt nicht. Unity Catalog ist nicht Hive Metastore 2.0.
Hive Metastore war ein Metadatenspeicher mit arbeitsbereichsbezogenen Zugriffskontrollen. Unity Catalog ist grundlegend anders – es ist eine kontozentrierte, identitätsbasierte Governance-Plattform, die die Datenverwaltung von der Recheninfrastruktur entkoppelt. Dieser Unterschied ist wichtiger, als den meisten Teams bewusst ist, bis Migrationen fehlschlagen.
Unity Catalog ist aufgrund seiner Governance-Funktionen – Nachverfolgung, Auditierung, Tagging und Auffindbarkeit – bekannt. Doch wir beobachten immer wieder Folgendes: Teams implementieren Zugriffskontrollen und bezeichnen dies als „abgeschlossene Governance“. Sie konzentrieren sich ausschließlich darauf, wer worauf zugreifen darf, und wundern sich dann, warum Analysten weiterhin Schwierigkeiten haben, Daten zu finden, warum die Akzeptanz stagniert und warum Governance eher ein Hindernis als ein Wegbereiter ist.
Das fehlende Puzzleteil ist fast immer dasselbe: Metadaten werden als nachträglicher Gedanke und nicht als Migrationsvoraussetzung behandelt. Standardisierte Tabellen- und Spaltenbeschreibungen. Einheitliche Kennzeichnung für Vertraulichkeit, Geschäftsbereich und Datentyp. Validierung und Offenlegung der Datenherkunft nach der Migration. Ohne diese Elemente haben Sie ein Berechtigungssystem geschaffen. Mit ihnen haben Sie eine Governance-Plattform geschaffen, die tatsächlich genutzt wird.
Hier ist eine Liste der Dinge, die immer wieder kaputtgehen – und was tatsächlich funktioniert.
Die meisten Teams synchronisieren Datenbanken 1:1 von HMS zu UC – sie führen Migrationstools aus, kopieren Schemas, richten Notebooks neu aus und aktualisieren Verbindungszeichenfolgen. Die Annahme: UC ist ein aktualisierter Hive Metastore, daher sollten Datenbankstrukturen direkt übertragen werden. Das ist aber nicht der Fall. Wie Fred Aboud, Solutions Architect bei Databricks, kürzlich in einem Gespräch mit Polestar Analytics erklärte:
Diese Benutzeranalysedatenbank mit Rohdaten, bereinigten Dimensionen und aggregierten Geschäftsdaten – alles durcheinander? In HMS machten arbeitsbereichsbezogene Berechtigungen das erträglich. In UC fragmentiert sie sich: Jede Zugriffsentscheidung erfordert nun explizite Berechtigungen auf Kontoebene, und was für fünf Entwickler funktionierte, lässt sich nicht auf drei Geschäftsbereiche skalieren.
Ein bewährtes Muster: der Wechsel von einer datenbankzentrierten zu einer domänenorientierten Migration. Anstatt finance_raw, finance_clean und finance_reporting als separate Schemata zu verwenden, sollte ein einziger Finanzkatalog erstellt werden, der nach Datenreife strukturiert ist.
Finanzen/
Rohdaten/ ←Nur Datenerfassung, technischer Zugriff
Kuratierte / ← Validierte Daten, Engineering + Analytik
Business/ ←Aggregierter, umfassender Lesezugriff .
Benötigt jemand Finanzdaten, beantragt er Zugriff auf den Finanzkatalog und erhält automatisch die entsprechenden Berechtigungen auf Schemaebene. Ein einziger Domäneninhaber genehmigt den Zugriff.
Schrittweise vorgehen: Zuerst die Finanzabteilung migrieren, Zugriffsberechtigungen und Leistung überprüfen, die Funktionsfähigkeit der nachgelagerten Abhängigkeiten bestätigen und dann zur Produktabteilung übergehen.
| ✓ Erfolgsmuster | ||
| 📊 Domänenorientierte Migration | ||
| ||
| 📈 ERGEBNIS | ||
| 📉 Reduzierte Migrationsreibung | ||
|
Doch die Domänenstruktur allein löst das daraus unweigerlich folgende Berechtigungschaos nicht. Selbst bei perfekter Katalogorganisation stoßen Teams an die Grenzen der Identitätsverwaltung…
Hier ist das reaktive Vorgehen, das wir ständig beobachten: Zuerst werden die Tabellen migriert, dann werden die Berechtigungen basierend auf den Beschwerden angepasst. Das erscheint pragmatisch – warum sollte man überkomplizieren, bevor man die tatsächlichen Nutzungsmuster versteht?
Die Architektur von Unity Catalog macht dies unmöglich.Unity Catalog hat arbeitsbereichsbezogene Berechtigungen vollständig abgeschafft . Der Zugriff erfolgt nun auf Kontoebene und identitätsbasiert. Der Cluster vergibt keine Berechtigungen mehr – der Benutzer, der die Abfrage ausführt, oder der Dienstprinzipal, der den Auftrag ausführt, benötigt explizite Berechtigungen.
Wenn dies nicht von vornherein geplant wird, verläuft alles immer gleich: Dashboards fallen aus, Entwickler verlieren den Zugriff auf ihre Daten, und es werden weitreichende Berechtigungen erteilt, um die Arbeit schnell wieder in Gang zu bringen. Fragt die Sicherheitsabteilung dann: „Wer hat Zugriff auf personenbezogene Kundendaten?“, kann niemand antworten, ohne das System abzufragen und den Zugriffsgraphen manuell zu rekonstruieren. So sieht ein Berechtigungsmodell aus, das auf der Reaktion auf akute Probleme basiert.
Entwerfen Sie das Zugriffsmodell vor der Datenmigration . Ordnen Sie Personas im Vorfeld Gruppen zu – Analysten erhalten SELECT-Berechtigungen für Goldschemas, Entwickler vollen Zugriff auf Rohdaten und kuratierte Daten, Data Scientists dedizierte experimentelle Kataloge. Vergeben Sie Berechtigungen auf Katalog- und Schemaebene, nicht tabellenweise. Berechtigungen auf Schemaebene gelten automatisch für neue Tabellen innerhalb dieses Schemas.
Konfigurieren Sie Dienstprinzipale vor der Migration, nicht danach . Produktionspipelines laufen als Dienstprinzipale, nicht als Benutzerkonten. Wird dies erst nach der Migration festgestellt, müssen Jobs in der Produktion korrigiert werden.
| ✓ Erfolgsmuster | ||
| 📊 Barrierefreies Design | ||
| ||
| 📈 ERGEBNIS | ||
| 📉 Reduzierter operativer Aufwand für Unity Catalog | ||
|
Selbst wenn die Zugriffsrechte geklärt sind, gibt es ein Skalierungsproblem, das die meisten Teams erst zu spät erkennen. Und es rührt von einer verlockenden UC-Funktion her…
Unity Catalog unterstützt die Zugriffskontrolle auf Spaltenebene. Teams entdecken diese Funktion und können Berechtigungen sofort bis ins kleinste Detail verwalten – das Marketing sieht beispielsweise die Kampagnen-ID, aber nicht die E-Mail-Adresse, die Finanzabteilung den Umsatz, aber nicht den Kundennamen. Jede Tabelle erhält benutzerdefinierte Regeln. Das wirkt wie eine umfassende Governance. Ist es aber nicht.
Die Komplexitätssteuer summiert sich schnell:
Standardmäßig hierarchisch, in Ausnahmefällen granular. Kataloge entsprechen Geschäftsbereichen. Schemata entsprechen dem Reifegrad der Daten. Tabellen werden automatisch vererbt. ImDatabricks-Blog heißt es: „Kataloge spiegeln oft Organisationseinheiten oder den Umfang des Softwareentwicklungszyklus wider.“ Die Komplexität der Governance skaliert nun mit Ihrem Unternehmen, nicht mit Ihren Metadaten.
Für besonders sensible personenbezogene Daten oder regulierte Datensätze, die einen spezifischen Prüfpfad erfordern, sollten Tabellen- oder Spaltenberechtigungen reserviert werden. Jede Ausnahme muss dokumentiert und regelmäßig überprüft werden. Eine hohe Anzahl von Ausnahmen deutet darauf hin, dass Ihr hierarchisches Datenmodell überarbeitet werden muss – nicht, dass Ihre Sicherheitsvorkehrungen ausreichend sind.
Die Databricks-Dokumentation erklärt : „Kataloge dienen der Organisation Ihrer Datenbestände und werden typischerweise als oberste Ebene in Ihrem Datenisolationsschema verwendet. Kataloge spiegeln oft Organisationseinheiten oder Bereiche des Softwareentwicklungslebenszyklus wider.“
Das bedeutet, den Zugriff auf deutlich weniger Ebenen anstatt auf Hunderten von einzelnen Tabellenkonfigurationen zu verwalten. Die Komplexität der Governance skaliert mit den Geschäftsbereichen, nicht mit der Anzahl der Tabellen.
| ✓ Erfolgsmuster | ||
| 📊 Standardmäßig hierarchisch | ||
| ||
| 📈 ERGEBNIS | ||
| 📉 Reduzierter operativer Aufwand für Unity Catalog | ||
|
Man kann die Domänenstruktur optimal gestalten. Man kann die Zugriffsrechte perfekt definieren. Man kann die Berechtigungen hierarchisch verwalten. Und trotzdem kann ein einziger Fehler – der die nachgelagerten Nutzer am härtesten trifft – das Vertrauen zerstören.
Die Migration ist abgeschlossen. Alle Tabellen sind im Unity-Katalog vorhanden, Berechtigungen konfiguriert und Governance validiert. Doch dann sind die BI-Dashboards nicht mehr erreichbar. Berichte, die jahrelang zuverlässig liefen, funktionieren nicht mehr. Python-Skripte finden die Tabellen nicht. Der ETL-Prozess schlägt fehl.
Und das alles aus einem einzigen Grund: HMS verwendete zweiteilige Namen (Datenbank.Tabelle), UC benötigt dreiteilige Namen (Katalog.Schema.Tabelle) für jedes Tool, Skript, jede Pipeline und jede Integration, die Ihre Daten berührt.
Behandeln Sie die Kompatibilität mit den Endnutzern als oberste Priorität. Erfassen Sie alle Endnutzer vor der Migration – BI-Tools, Berichte, Skripte und Integrationen. Erstellen Sie eine Abstraktionsschicht mit Ansichten in HMS-Speicherorten, die auf UC-Tabellen umleiten. Die Endnutzer arbeiten weiter, während die Teams die Migration im Hintergrund durchführen. Migrieren Sie BI-Tools parallel zu den Daten, nicht erst danach. Unterschiedliche Tools haben unterschiedliche Migrationspfade – validieren Sie diese frühzeitig und gehen Sie nicht von Einheitlichkeit aus.
| ✓ Erfolgsmuster | ||
| 📊 Verbraucherorientierte Migration | ||
| ||
| 📈 ERGEBNIS | ||
| 🛡️ Keine oder nur minimale Beeinträchtigungen für die Verbraucher | ||
|
Im Kontext des Mesh-Modells implementierte ein weltweit führender Hersteller alkoholischer Getränke eine Daten-Mesh-Architektur mit Unity Catalog und harmonisierte so die Governance über mehr als 15 Geschäftsbereiche und regionale regulatorische Anforderungen hinweg – hierarchische Berechtigungen waren der einzige Ansatz, der skalierbar war.
Den vollständigen Ansatz finden Sie im Unity-Katalog.Die Plattform wird ausgeliefert. Technisch funktioniert alles. Doch dann beginnt das eigentliche Scheitern.
Ingenieure fordern Zugriffsmuster an, die nicht mehr existieren. Analysten stoßen auf Berechtigungsfehler und greifen auf Workarounds zurück. Wenn die Rechenleistung nicht UC-kompatibel ist, wird der Nicht-UC-Cluster zum einfachsten Weg. Jeder Workaround normalisiert die Umgehung der Governance. Eine Governance-Plattform, die umgangen werden muss, ist letztendlich nur teure Infrastruktur.
Die Ursache ist immer dieselbe: Unified Communications (UC) ändert nicht nur den Datenzugriff, sondern auch, wer Zugriffsentscheidungen trifft, Anfragen genehmigt und im Fehlerfall die Verantwortung trägt. Die Einführung der Plattform ohne Anpassung dieser Arbeitsabläufe führt zwangsläufig zu dem oben beschriebenen Fehler.
Governance wird als Weiterentwicklung des Betriebsmodells betrachtet, nicht als Softwarebereitstellung.
Die Vorbereitung der IT-Systeme und das Änderungsmanagement sind keine aufeinanderfolgenden Schritte, die erst nach der Migration erfolgen. Sie sind vielmehr Voraussetzungen, die darüber entscheiden, ob die Migration tatsächlich erfolgreich ist.
| ✓ Erfolgsmuster | ||
| 📊 Transformation des Betriebsmodells | ||
| ||
| 📈 ERGEBNIS | ||
| 🤝 Governance wird übernommen (nicht vermieden) | ||
|
Jedes Muster baut auf dem vorherigen auf. Die Domänenstruktur macht das Identitätsdesign offensichtlich. Das Identitätsdesign ermöglicht die Verwaltung hierarchischer Berechtigungen. Ein Fehler in einem Bereich wirkt sich nach sich und nachteilig auf die nachfolgenden Bereiche aus. Ein gelungener Schritt erleichtert den nächsten.
Die Plattform selbst ist der einfache Teil. Entscheidend für den Erfolg oder Misserfolg von Migrationen ist, wie Ihre Organisation mit Eigentumsrechten, Verantwortlichkeiten und Befähigung umgeht.
Die Unternehmen, denen das gelingt, tun es nicht allein – und als Databricks Select Partner ist das genau die Arbeit, die wir bei Polestar Analytics leisten.
Denn Einigkeit macht stark – insbesondere dann, wenn technische Präzision auf organisatorische Bereitschaft trifft.
PS -
Durch die Migration gelangen Ihre Daten in den Unity Catalog. Was Sie als Nächstes entwickeln, entscheidet darüber, ob Sie eine Governance-Plattform oder lediglich ein teures Berechtigungssystem erhalten.
Sehen Sie, was tatsächlich nach der Migration geschieht.Bis zum nächsten Mal!
Über den Autor
Senior Vizepräsident – Kompetenzentwicklung
Informationsalchemist
Verwandter Blog
Ali Kidwai
