Unity Catalog Migration: Trade-Offs, Erfahrungen & Empfehlungen

Erstmalig vorgestellt im Mai 2021, mit allgemeiner Verfügbarkeit seit August 2022 und stetiger Weiterentwicklung ist der Unity Catalog nun ein zentraler Bestandteil in Databricks. Dieser verspricht eine zentrale Governance von Datenobjekten wie Tabellen und Views, aber auch Machine-Learning Modellen, und bietet eine Suchfunktionalität und Lineage für Datenflüsse. Vor allem die zentral verwaltete Zugriffskontrolle und das Teilen von Daten innerhalb, aber auch über eine Organisation hinaus steht im Mittelpunkt. Auf technischer Ebene stehen die Ablösung des Hive-Metastores sowie die Verlagerung von administrativen Tätigkeiten in die Databricks Account Konsole im Fokus.

Aufgrund der teilweise tiefgreifenden Veränderungen, neuer Features und Produkte stellt sich die Frage, welche Funktionalitäten wegfallen, welche Features noch nicht in der „neuen Welt“ vorhanden sind und welcher Aufwand hinter einer Migration steht. Besonders davon betroffen sind verteilte Setups mit mehreren Workspaces, wo es bislang aufwendig war eine übergreifende Metadatenschicht und Berechtigungsmodell zu etablieren.

Dieser Blogpost beleuchtet jene Fragen und gibt Empfehlungen für den Umstieg. Zunächst beschrieben wir kurz, wie der Unity Catalog aktiviert wird, mit dem Fokus auf möglichen Stolpersteinen. Danach gehen wir auf die wichtigsten Neuerungen im Vorher-/Nachher Vergleich ein. Im zweiten Teil teilen wir Erfahrungen und Empfehlungen im Hinblick auf eine Migration zum Unity Catalog und zur Frage, in welchen Fällen von dessen Einsatz derzeit abzuraten ist bzw. mit welchen Einschränkungen (noch) zu rechnen ist.

Der Fokus liegt dabei auf Problemen und Erfahrungen sowie Entscheidungs- und Lösungsszenarien, die bei der Umstellung auf Unity Catalog auftreten können, und nicht darauf, eine Anleitung zur konkreten Implementierung zu geben. Im Mittelpunkt steht die kritische Auseinandersetzung mit der Thematik und dem Ziel, eine Entscheidungsgrundlage zu schaffen, ob und in welcher Ausprägung Unity Catalog eingesetzt werden soll. Für die konkreten technischen Schritte sei auf die offizielle Dokumentation verwiesen.

Alle beschriebenen Vorgänge in diesem Blogpost basieren auf dem Verhalten von Databricks in der Microsoft Azure Cloud. Der Feature-Stand sowie die Konfiguration und verwendete Infrastruktur-Service-Komponenten können sich im Vergleich zu Databricks auf AWS und GCP unterscheiden. Unserer Erfahrung nach sind neue Features zuerst auf AWS verfügbar und als letztes auf GCP. Die meisten der angesprochenen Limitierungen treffen auf alle Cloud-Umgebungen zu.

Initialer Setup

Der Ausgangspunkt der Unity-Catalog-Installation ist das Erstellen eines Metastores, der den zentralen, logischen Container für alle Objekte (Tabellen, Views, aber auch externe Storage Locations oder Data Shares) bildet und Berechtigungen auf diese steuert.

Die Erstellung erfordert bereits bestimmte Voraussetzungen, die Implikationen mit sich bringen:

1. Azure Databricks mit Premium Plan

2. Azure Databricks Account Admin Berechtigung

Initial ist ein Azure Active Directory Global Administrator entsprechend berechtigt und kann die Databricks Account Admin Berechtigung vergeben. Der Zugriff liegt vor, wenn der Aufruf von https://accounts.azuredatabricks.net nicht eine Übersicht der Workspaces des angemeldeten Nutzers zeigt.

Sicherheitsbedenken:
Als Databricks Account Admin ist es theoretisch möglich, sich Zugang zu allen Databricks Workspaces eines Tenants zu verschaffen. Die Notwendigkeit der Rolle kann aber u.U. auf die Erstellung des Metastores zeitlich limitiert werden. Gruppenverwaltung innerhalb Databricks (externe Active Directory (AD) Gruppen können via SCIM synchronisiert werden) bleibt aber nur Accounts Admins vorbehalten.

3. Azure Data Lake Storage Gen2 (ADLS) Account mit aktiviertem hierarchischen Namespace

Dieser Storage ist der Ort für die Speicherung von Databricks Managed Tabellen. Hier gilt es zu bedenken, dass jegliche erstellen Tabellen an diesem Ort gespeichert werden, egal in welchem Workspace sie angelegt werden. D.h. es können Sicherheitsbedenken bzgl. Datenzugriff auftreten und die Verantwortlichkeiten für diesen Storage müssen klar geregelt sein. Je nach potenziellen Datenvolumen und Nutzervolumen können Skalierungsgrenzen erreicht werden.

Empfehlung:
Die Verwendung von Managed Tabellen für produktive Daten sollte hinterfragt werden. Sie haben zwar den Vorteil des deutlich geringeren Verwaltungsaufwandes, sorgen aber auch für eine gewissen Lock-in auf Databricks. Die erstellten Dateien sind zwar weiterhin über den hinterlegten Storage verfügbar, aber die Pfade sind automatisch generiert und Tabellennamen werden durch UUIDS ersetzt. Ein praktikabler Zugriff ist nur noch über den Unity Catalog möglich.

Im Fall des Verzichts auf Managed Tabellen stellen sich geringere Anforderungen an die Verwaltung des dem Metastore zugewiesenen Storage Accounts; er existiert dann, weil es fest Voraussetzung ist, wird jedoch nicht verwendet.

Falls die Verwendung von Managed Tabellen gewünscht ist, ist auf jeden Fall eine weitere Konfiguration des Ortes von managed Tabellen auf Catalog– oder Schema-Ebene (es wird immer die Konfiguration der tiefsten Schicht verwendet) empfohlen. Voraussetzung dafür ist die Einbindung der alternativen Storage Accounts als External Location. Dies ist z.B. relevant für Szenarien, wo die Daten auf Storages einzelner Verwaltungsgruppen (bspw. Fachabteilungen) voneinander abgegrenzt werden müssen.

4. Berechtigung zur Anlage von system-assigned Managed Identities

Konkret bedeutet dies die Anlage des Databricks Access Connector, welcher als managed identity agiert und worüber die Berechtigungen auf Storage Ressourcen gesetzt werden.

Empfehlung:
Anlage in selber Ressourcen-Gruppe/Subscription wie Storage aus Punkt 3.

All die genannten Objekte und Konfigurationen dieses und teilweise des nächsten Abschnittes können auch mittels Terraform aufgesetzt und verwaltet werden.

Ebenfalls existiert eine CRUD API über welche die verschiedenen Elemente des Unity Catalogs, u.a. Permissions und Delta Shares, verwaltet werden können. Ein vollständige Evaluierung dieser steht aber noch aus.

Signifikante Unterschiede

Nach der initialen Einrichtung stehen neue Features zur Verfügung, die wichtigsten stellen wir im Folgenden kurz vor und bewerten sie.

Gruppen & User Administration

Bisher:
Die Verwaltung der Gruppen und User Accounts erfolgt pro Workspace. Es existiert eine Azure AD Enterprise Application für den Sync der Gruppen mit Azure AD, die auch pro Workspace einzurichten ist. Damit ist eine effiziente Verwaltung von mehreren Workspaces nur mit einer eigenen Automatisierungslösung möglich.

Mit Unity Catalog:
Mit dem Identity Federation Feature ist Unity Catalog in der Lage, die Definition der Gruppen zentral zu verwalten und an angeschlossene Workspaces zu verteilen. Die Einrichtung und Pflege einer Synchronisierung mit dem Azure AD ist damit nur einmalig notwendig.

Einschränkung:
Verschachtelte Gruppen und Service Principals werden nicht synchronisiert. Verwendung von verschachtelten Gruppen erfordert eigene Lösungen über Terraform oder Skripte und SCIM API, um die gewünschte Struktur der Gruppen in der Admin Console abzubilden.

Wenn ein Nutzer aus einer Gruppe entfernt wird und somit auch auch nicht mehr Teil der Synchronisierung ist, werden all seine persönlichen Ressourcen wie z.B. Notebooks aus den Workspaces entfernt.

Empfehlung:
Zur Zeit ist genau ein Unity Catalog Account pro Azure Tenant vorgesehen. Im Gegensatz zu vorher können damit verschiedene Unternehmenseinheiten nicht unabhängig voneinander Databricks nutzen. Die Verwaltung des Databricks Accounts muss damit von einem zentralen Team erfolgen. Dieses Team sorgt für zentrale Konfiguration der Metastores und die Verwaltung der physikalischen Zugänge zum Azure Datalake Storage.

Als allgemeine Autorisierungs Good Practice sollten Dateiberechtigungen stets an Gruppen gebunden sein, anstatt an einzelne User.

Datenautorisierung

Bisher:
Mit ADLS Passthrough und Table ACLs standen dem Administrator zwei unterschiedliche Autorisierungsmöglichkeiten zur Verfügung. Das Table ACL Feature ermöglichte feingranulare Autorisierung auf Ebene der SQL Objekte, musste allerdings in jedem Workspace einzeln gepflegt werden. Die ADLS-Passthrough-Methode verlagerte Autorisierung auf dem Storage Layer und war somit zentral, allerdings lediglich grobgranular auf Ebene von Dateien.

Mit UC:
Unity Catalog verwaltet Autorisierungen auf Daten (Tabellen, Views, Schemata, Catalogs) und weiteren Entitäten wie Machine Learning Modellen oder externen Pfaden (sprich: externer Storage). Cluster und SQL Warehouses der angeschlossenen Workspaces erhalten die Autorisierung für den Zugriff auf die Storage Accounts durch den Unity Catalog.

Einschränkung:
Das feingranulare Autorisierungsregelwerk verbleibt im Unity Catalog. Es existiert eine REST API, die eine Abfrage ermöglicht; es ist aber keine direkte Verwendung aus umliegenden Komponenten möglich. Databricks-Partner wie Immuta ermöglichen externe Verwaltung der Berechtigungen.

Empfehlung:
Wie in der Zeit vor Unity Catalog empfehlen wir die Verwaltung von Berechtigungen mittels CI/CD zu versionieren und zu automatisieren. Der von Databricks bereitgestellte Terraform Provider beinhaltet bereits alle notwendigen Ressourcen und wird kontinuierlich weiter ausgebaut.

Lineage

Bisher:
Nicht möglich, nur über externe Tools wie zum Beispiel Datahub oder Amundsen.

Mit Unity Catalog:
Übersichtliche Darstellung der kompletten Lineage über alle Objekte, welche Databricks bekannt sind. Dies sind Tabellen und Notebooks, aber auch Workflows, Dashboards, Queries und Dateipfade. Es kann zwischen einer Up- und Downstream Ansicht unterschieden werden.

Einschränkung:
Für einen vollständigen Überblick sei auf die offizielle Dokumentation verwiesen. Wie bereits erwähnt, ist die Ansicht auf Objekte innerhalb von Databricks beschränkt, mögliche vorangehende oder anschließende Schritte des Datenflusses können nicht dargestellt werden. Dafür müsste wiederum auf externe Tools zurückgegriffen werden. Lineage-Informationen können mittels API als JSON abgegriffen werden. Diese Information dann auch darzustellen bedarf weiterer Implementation.

Da alle Objekte gescannt werden, kann es in Workspaces mit viel aktiver Entwicklung, sprich: Erstellung von Notebooks und Queries, zu Unübersichtlichkeiten kommen.

Empfehlung:
Funktionalität kommt on-top, es muss nichts extra eingerichtet werden. Falls ein bestehendes externes Tool vorliegt, ist zu überprüfen, ob dieses die neuen Informationen ebenfalls integrieren kann.

Delta Share

Bisher:
Das Teilen von Daten, im Allgemeinen sind das in Databricks aufbereitete Tabellen oder Analyseergebnisse, mit anderen Services oder Konsumenten ist möglich über entsprechende Connectoren und Protokolle, wie z.B. ODBC. Dies setzt normalerweise einen Zugriff auf den Workspace über ein persönliches Access Token voraus.

Sollen Dateien direkt aus dem Storage geteilt werden, muss ein geeignetes Interface zum Zugriff auf ADLS entwickelt werden, die konsumierende Partei muss ADLS als Endpunkt unterstützen.
Beim Teilen außerhalb der Organisation ergeben sich zusätzliche Aufwände für die Sicherstellung der Autorisierung, die das Szenario sehr aufwändig zum Umsetzen machen.

Mit Unity Catalog:
Unity Catalog bietet unter dem Namen Delta Sharing zwei Möglichkeiten, um Daten außerhalb der zugeordneten Workspaces Nutzern zugänglich zu machen.

Mittels Databricks-to-Databricks Sharing können Daten mit Usern anderer Databricks Workspaces mit aktivem Unity Catalog geteilt werden, dabei ist es egal, ob sich der User im selben Tenant befindet oder sogar derselben Cloud (gilt für AWS & Azure).

Mit Open Delta Sharing kann der Zugriff auch beliebigen Nutzer:innen außerhalb des Databricks Universums gewährt werden, solange der Zugriff über das Delta-Protokoll stattfindet. Für Client-Anwendungen stehen SDKs für bekannte Technologien bereit, viele Anwendungen (z.B. PowerBI) weisen aber bereits einen integrierten Connector auf.

Über das Konzept von Data Shares kann genau festgelegt werden, welche Tabellen und Partitionen am Ende geteilt werden.

Einschränkung:
Derzeit ist es nur möglich, Delta-Tabellen zu teilen, keine Views oder andere Objekte wie Machine Learning Modelle. Durch die Einschränkung von Views ist es somit auch nicht möglich, nur bestimmte Subsets (Row-Level-Security) auszuwählen, es muss eine extra Tabelle angelegt werden.

Empfehlung:
In den Szenarien, dass Daten mit externen Partnern oder getrennten Parteien innerhalb einer Organisation geteilt werden sollen, wird nun erstmals eine Möglichkeit geboten, dies direkt in Databricks abzubilden.

Delta Sharing kann dazu verwendet werden, Daten zwischen zwei Regionen zu teilen (es ist nur ein Metastore pro Region erlaubt).

Allgemein empfiehlt es sich, mögliche anfallende Transfer-Kosten des Cloud Providers im Blick zu behalten.

Seitens der Autoren hat noch keine tiefergehende technische Evaluation stattgefunden, es sei auf das Open Source Projekt als möglicher weiterer Einstiegspunkt verwiesen.

Metadatenkatalog

Bisher:
Mit den SQL Warehouses bot Databricks bereits ein elegantes User Interface, um Metadaten einzusehen. Zum einen erforderte dieses Feature laufendes Compute und verursachte damit Kosten und zum anderen war keine Suche eingebaut.

Mit UC:
Die Metadaten werden nun von der Databricks Control Plane (von Databricks bereitgestellte und gemanagte Ressourcen fürs Bereitstellen des Dienstes) bereitgestellt und können betrachtet werden, ohne dass ein Cluster oder SQL Warehouse im eigenen Workspace läuft.

Weiterhin steht mit information_schema ein dediziertes Schema zur Verfügung, um Metadaten per SQL direkt zugänglich zu machen. Dieses Feature hat sich in relationalen Datenbanken bewährt und vereinfacht nun das Management von Data Lakes.

Die bereits bekannte Suchfunktion erfasst mit dem Unity Catalog auch Metadaten wie Kommentare und durchsucht Tabellen und Spaltendefinitionen. Die Suche berücksichtigt die Autorisierung des Users.

Einschränkung:
Aktuell ist die Pflege der Metadaten auf die aus Hive bekannten Kommentare auf Schema-, Tabellen- und Spaltenebene begrenzt.

Es wird in Zukunft eine Unterstützung weiterer Elemente wie Modele (Model Registry & Feature Store) sowie von Dateisystemen geben. Auch eine Erweiterung von Tagging- und Dokumentationsmöglichkeiten ist vorgesehen.

Empfehlung:
Falls unternehmensweit noch kein Datenkatalog vorhanden ist, kann man auf Unity Catalog zurückgreifen, um grundlegende Funktionalitäten zur Verfügung zu stellen.

Weitere Features

Neben den oben beschriebenen Verbesserungen stellt Unity Catalog eine Voraussetzung für weitere Features der Plattform dar, wie beispielsweise:

• serverless SQL warehouses
• ACLs für Machine Learning Modelle
• deskriptive Constraints bei Delta-Tabellen wie primary key und foreign key
• Job Scheduling Features für Delta-Tabellen
• Row-Level Security Erweiterung in native SQL

Limitierungen

Databricks selbst gibt eine lange Liste an aktuellen Limitierungen an. Es ist davon auszugehen, dass viele der Punkte durch kommende Releases wegfallen. Einige der Limitierungen können den Umstieg derzeit schwierig gestalten, für andere kann es je nach Use Case Workarounds geben. Am Ende können natürlich trotzdem die positiven Neuerungen das ausschlaggebende sein, um einen Umstieg in Angriff zu nehmen.

An dieser Stelle sollen die Limitierungen einerseits nochmal konsolidiert dargestellt, aber auch bewertet bzw. Empfehlungen zur Verwendung gegeben werden.

Cluster

Ein großer Teil von Limitierungen offenbart sich bei den Möglichkeiten der Verwendung von Clustern. Es ist wichtig zu betonen, dass SQL Warehouses nicht betroffen sind. Diese weisen grundsätzlich keine Einschränkungen mit Unity Catalog auf, sie sind lediglich durch ihr konkretes Einsatzgebiet, vergleichbar mit einem klassischen SQL Data Warehouse, beschränkt.

Wir empfehlen für Unity Catalog nur Cluster mit Databricks Runtime 11.3 LTS oder neuer zu verwenden, ansonsten können weitere Einschränkungen auftreten. Mit Version 13.1 und 13.2 fallen weiter Einschränkungen weg.

Es zeigt sich, dass v.a. Shared Workloads betroffen sind. Andererseits ist es durch Unity Catalog auch erstmals möglich, Zugriffskontrolle bei Machine Learning Workloads sicherzustellen.

Für Shared-Workload-Szenarien ergeben sich folgende Überlegungen:

• Wenn ausschließlich SQL verwendet wird, wie es es bei den meisten traditionellen BI-Analyse Szenarien der Fall ist, können SQL Warehouses den Use-Case bereits vollständig abdecken
• Job-Cluster-Funktionalität bleibt unverändert
• Wenn shared Cluster hauptsächlich zum Lesen von Daten verwendet werden und z.B. nicht zur Entwicklung mit Libraries, kommt man kaum mit den Limitierungen in Kontakt
• Für Softwareentwicklung werden dedizierte Cluster für Entwickler notwendig, was u.U. erhöhten Kosten- und Administrationsaufwand bedeutet
• Der Fokus von Databricks liegt darauf Einschränkungen in Verbindung mit Python zu beseitigen, wie es bereits bei einigen der Fall ist wenn die neueste Databricks Runtime benutzt wird

Insgesamt wird man aber die gemeinsame Arbeit auf einem Cluster früher oder später in bestimmten Aspekten als eingeschränkt wahrnehmen.

Da Dynamic Views verwendet werden um Data Masking und Row Level Security abzubilden, die nur auf Shared Clustern verfügbar sind, können Nutzer:innen auf Single User Clustern in ihrer Sicht auf die Inhalte einer Tabelle nicht beschränkt werden. Es ist eine verbesserte Möglichkeit um Row & Column Level Security umzusetzen angekündigt.

Weitere Einschränkungen

Relevante Einschränkungen liegen noch bei der Partitionierung vor, wenn es sich nicht um Delta-Tabellen (z.B. auf JSON oder CSV Dateien basierend) handelt. Ein Überschreiben der Daten im Filesystem (Dataframe overwrite) ist nicht möglich. Auch können nur Tabellen ausgelesen werden, die einer „directory-style“ Partitionierung folgen, nicht aber benutzerdefinierter Partitionierungsschemata.

Zur Vollständigkeit sind hier noch kurz weitere Einschränkungen genannt, die aber nur spezifische Anwendung finden:

• keine shallow clones als Quelle oder Ziel im Unity Catalog (ab Version 13.1 nur für Managed Tabellen)
• kein Support von Bucketing bei Abfragen aus Unity Catalog Tabellen
• kein Support von standard Scala thread pools bei Abfragen
• Einsatz der neuen Query Federation Features, angekündigt für Public Preview in Juli 2023

Für Einschränkungen bei Streaming sei auf die offizielle Dokumentation verwiesen.

Wann umsteigen

Bei einer Neueinführung von Databricks liegt es nahe, sich von Anfang an am Unity Catalog auszurichten. In Anbetracht der aufgeführten Einschränkungen ist der Umstieg möglich bzw. sollte er aufgrund der Verfügbarkeit von neuen Features in Betracht gezogen werden, wenn folgende Punkte in einem bestehen Databricks Setup zutreffen:

• Daten/Tabellen liegen im Delta-Format vor
• Verwendung von SQL und Python
• Organisatorische Hürden für Account Console Administration inkl. Gruppenverwaltung können ausgeschlossen werden, z.B. ein Team kann die Administration für den Tenant übernehmen
• Workspaces liegen in einer Region (für Sharing zwischen Regionen ist Delta Sharing möglich)
• Langfristiges Commitment auf Unity Catalog ist geplant und Akzeptanz von Parallelbetrieb mit lokalen Hive-Metastore ist vertretbar
• Vorrangiges Ziel ist die Zugriffssteuerung und das Teilen von aufbereiteten Tabellen, die sich eher am Ende einer Datenpipeline befinden.
• Databricks als primäre Engine und Plattform

Wenn einer der folgenden Punkte zutrifft ist ein Umstieg und notwendige Migrationen genauer zu prüfen:

• Scala- & Java-Projekte
• Streaming-Projekte
• Machine-Learning-Projekte
• Intensive Verwendung von 3rd Party Libraries und init-Skripten
• Arbeitsweise sieht zeitgleiche Zusammenarbeit auf einem Cluster vor
• Lakehouse-Architektur, die auch Nutzung durch andere Azure Tools (AzureML, Azure Functions) auf dem Data Lake und ein weiteres Zugriffskonzept der Verwaltung außerhalb von Databricks vorsieht. Definierte Autorisierungen sind zwar über eine API verfügbar aber nicht ohne weiteres mit anderen Tools nutzbar. In Zukunft kann dieser Punkt durch die kürzlich angekündigte Open Apache Hive Metastore API gänzlich wegfallen. Diese soll eine Schnittstelle zu anderen Platformen, wie Apache Spark, Presto, Trino etc. bereitstellen und eine einheitliche Gouvernance über jene gewährleisten, befindet sich derzeit aber noch in Private Preview.

Parallelbetrieb

Grundsätzlich bietet sich ein Parallelbetrieb an, um neue Features zu evaluieren, nötige Umstellungen festzustellen und Hürden zu identifizieren. Dabei gibt es zwei Möglichkeiten:

1. Parallelbetrieb in neuem Workspace

• keine Einschränkungen für bestehendes Setup
• Verzicht auf Upgrade-Möglichkeiten (z.B. Umwandlung von Hive-Tabellen)
• zusätzlicher infrastruktureller Aufwand

2. Parallelbetrieb in existierendem Workspace

• Unity Catalog Rollout grundsätzlich on top möglich
• Hive-Metastore bleibt zugänglich
• Wichtige Einschränkung: Benutzerverwaltung nur noch über UC & Account Console möglich. Bestehende Workspace Gruppen & ACLs bleiben zwar erhalten, aber es können keine Neuen angelegt werden.
• Unity Catalog prüft Verwendung externer Pfade und unterbindet das Anlegen von mehreren externen Tabellen, die den selben Pfad referenzieren

Fazit

Mit Unity Catalog macht Databricks einen großen Schritt hin zur zentralen Verwaltung der Metadaten und Autorisierungen, die vor allem im Enterprise-Umfeld eine Voraussetzung darstellt, konsolidierte Unternehmensdaten für unterschiedliche Use Cases zugänglich zu machen. Aufgrund der Komplexität und Vielzahl der abgedeckten Aspekte kommt der Unity Catalog mit einigen Einschränkungen, sodass eine Einführung derzeit genau evaluiert werden sollte. Die aktuell öffentlich angekündigten Features von Databricks machen die Einführung des Unity Catalogs langfristig unumgänglich, wenn Databricks als Core-Komponente zum Einsatz kommt.

In diesem Artikel haben wir den aktuellen Stand zum Unity Catalog zusammengefasst und blicken gespannt in die Zukunft, ob Databricks als Datenplattform so offen bleiben wird wie bisher oder den Weg in Richtung der geschlossenen Plattformen wie Snowflake einschlägt.