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.
DatabricksUnity Catalog überschritt die GrenzeMehr als 1 Million SKD-Downloads pro MonatDieDie Adoption an sich ist eindeutig nicht das Problem. Was nach der Adoption passiert, ist es.
Die meisten Organisationen migrieren zu Unity Catalog und behandeln es wie Hive Metastore mit besseren Berechtigungen. Spoiler-Alarm: Das ist es nicht.Unity Catalog ist nicht Hive Metastore 2.0.
Hive Metastore war ein Metadatenspeicher mit arbeitsbereichsbezogenen Zugriffskontrollen.Unity Catalog ist grundlegend andersEs handelt sich um eine kontozentrierte, identitätsbasierte Governance-Plattform, die die Daten-Governance von der Recheninfrastruktur entkoppelt. Diese Unterscheidung ist wichtiger, als den meisten Teams bewusst ist, bis Migrationen fehlschlagen.
Die Anerkennung des Unity Catalog beruht auf seinen Governance-Funktionen –Herkunftsverfolgung, Prüfung, Verschlagwortung und AuffindbarkeitDieWas wir aber immer wieder beobachten, ist Folgendes: Teams implementieren Zugriffskontrollen und nennen das dann „Governance abgeschlossen“.Sie konzentrieren sich ausschließlich darauf, wer worauf Zugriff hat, und wundern sich dann, warum Analysten immer noch Schwierigkeiten haben, Daten zu finden, warum die Akzeptanz stagniert und warum sich Governance eher wie ein Hindernis als wie ein Wegbereiter anfühlt.
Das fehlende Teil ist fast immer dasselbeMetadaten wurden eher als nachträglicher Gedanke denn als Migrationsvoraussetzung behandelt. Standardisierte Tabellen- und Spaltenbeschreibungen. Einheitliche Kennzeichnung von Vertraulichkeit, Geschäftsbereich und Datentyp. Herkunftsnachweis wird nach der Migration validiert und offengelegt. 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 jedoch nicht der Fall. Wie Fred Aboud, Solutions Architect bei Databricks, sagte:kürzliches Gespräch mit Polestar Analytics:
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 Muster, das immer wieder funktioniert: Übergang 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 ausführen:Zuerst die Finanzabteilung migrieren, Zugriffsberechtigungen und Leistung überprüfen, die Funktionsfähigkeit der nachgelagerten Abhängigkeiten bestätigen und dann zum Produktbereich übergehen.
| ✓ Erfolgsmuster | ||
| 📊 Domänenorientierte Migration | ||
|
||
| 📈 ERGEBNIS | ||
| 📉 Verringerte 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 des 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 Voraus Gruppen zu – Analysten erhalten SELECT-Berechtigungen für Goldschemas, Entwickler vollen Zugriff auf Rohdaten und kuratierte Daten, Data Scientists dedizierte experimentelle Kataloge. Berechtigungen werden auf Katalog- und Schemaebene vergeben, nicht tabellenweise. Berechtigungen auf Schemaebene gelten automatisch für neue Tabellen innerhalb dieses Schemas.
Konfigurieren Sie die Dienstprinzipale vor der Migration, nicht danach.Produktionspipelines laufen als Dienstprinzipale, nicht als Benutzerkonten. Die Entdeckung dieses Fehlers nach der Migration bedeutet, dass Jobs in der Produktion korrigiert werden müssen.
| ✓ Erfolgsmuster | ||
| 📊 Barrierefreies Design | ||
|
||
| 📈 ERGEBNIS | ||
| 📉 Reduzierter Betriebsaufwand 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.Die Teams entdecken dies und verwalten Berechtigungen sofort bis ins kleinste Detail.— Das Marketing sieht die Kampagnen-ID, aber nicht die E-Mail-Adresse, die Finanzabteilung sieht den Umsatz, aber nicht den Kundennamen. Für jede Tabelle gibt es benutzerdefinierte Regeln.Es mag den Anschein gründlicher Regierungsführung erwecken. Ist es aber nicht.
Die Komplexitätssteuer summiert sich schnell:
Standardmäßig hierarchisch, nur in Ausnahmefällen detailliert.Kataloge sind Geschäftsbereichen zugeordnet. Schemata sind dem Datenreifegrad zugeordnet. Tabellen werden automatisch vererbt.Databricks-Blog: „Kataloge spiegeln oft Organisationseinheiten oder den Umfang des Softwareentwicklungszyklus wider.“Die Komplexität der Governance skaliert jetzt 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 bedarf einer dokumentierten Begründung und regelmäßigen Überprüfung.Eine hohe Anzahl von Ausnahmen deutet darauf hin, dass Ihr hierarchisches Modell überarbeitet werden muss.— nicht, dass Ihre Sicherheitsvorkehrungen umfassend wären.
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 den Umfang 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 Betriebsaufwand 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).Denn jedes Tool, jedes Skript, jede Pipeline und jede Integration, die Ihre Daten berührt, ist betroffen.
Verbraucherkompatibilität sollte als oberste Priorität gelten.Vor der Migration sollten alle Nutzer erfasst werden – BI-Tools, Berichte, Skripte und Integrationen. Es wird eine Abstraktionsschicht erstellt, deren Ansichten in HMS-Speicherorten auf UC-Tabellen umgeleitet werden. Die Nutzer arbeiten weiter, während die Teams die Migration im Hintergrund durchführen. BI-Tools sollten parallel zu den Daten migriert werden, nicht erst danach. Unterschiedliche Tools haben unterschiedliche Migrationspfade – daher ist eine frühzeitige Validierung ratsam, anstatt von Einheitlichkeit auszugehen.
| ✓ Erfolgsmuster | ||
| 📊 Verbraucherorientierte Migration | ||
|
||
| 📈 ERGEBNIS | ||
| 🛡️ Keine oder minimale Beeinträchtigung der 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 angewendet (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 Fehler in einem Bereich erleichtert den nächsten Schritt.
Die Unternehmen, denen das gelingt, tun es nicht allein.Polestar Analytics ist ein zertifizierter Databricks-Beratungspartner, der Unternehmen bei der Konzeption und Implementierung produktionsreifer Daten-, KI- und Governance-Lösungen auf Databricks unterstützt.
Als Databricks-Partner bringen wir die technische Expertise und die Implementierungsdisziplin mit, die erforderlich sind, um Unity Catalog-Migrationen über die Plattform hinaus zum Erfolg zu führen – und zwar über Datenarchitektur, Governance, Betriebsmodelle und organisatorische Bereitschaft hinaus.
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
Nitin Kumar
Aishwarya Saran