Unity Catalog External Locations: Cloud-Storage sicher anbinden und Mounts ablösen
Die Kernaussagen auf einen Blick.
- External Locations verbinden Cloud-Storage-Pfade mit Storage Credentials und machen externen Speicher in Unity Catalog berechtigbar, auditierbar und workspace-übergreifend verwaltbar.
- Beim Wechsel von DBFS-Mounts zu External Locations wandert der Zugriff vom Workspace- und Cluster-Modell in den UC-Metastore, wo Owner, , und explizit geregelt werden.
- Entscheidend ist die saubere Abgrenzung der Speicherbereiche: meist nach Umgebung und Datenbereich, statt einen ganzen Storage Account oder Container pauschal freizugeben.
- Empfehlenswert ist der Weg über eine Inventur, ein Zielmodell für External Locations, eine Pilot-Migration und anschließend die Verwaltung über Terraform oder Asset Bundles.
Inhaltsverzeichnis
Mit DBFS-Mounts endet die Governance am Dateisystem
In einem produktiven Databricks-Workspace stehen 30 Mount-Points unter dbfs:/mnt/. Für mehrere dieser Mounts sind Zweck und Verantwortung nicht mehr eindeutig dokumentiert. Die bestehenden Pipelines und Dashboards laufen weiterhin, sodass zunächst kein unmittelbarer Handlungsdruck sichtbar ist. Unity Catalog ist beschlossen, der Metastore steht, die ersten Kataloge sind angelegt. Bei der Migrationsplanung bleibt jedoch häufig unklar, welche Pipelines von den Mounts abhängen und wie sie sich nach der Umstellung verhalten. Eine belastbare Antwort fehlt, solange Pfade, Identitäten und Abhängigkeiten nicht inventarisiert wurden.
Eine ähnliche Ausgangslage findet sich in vielen Databricks-Plattformen, die vor der breiten Einführung von Unity Catalog entstanden sind. Mounts wurden damals als einfacher, workspaceweiter Zugriffsweg auf Cloud-Speicher eingesetzt: einmal in einem Notebook angelegt, vom ganzen Workspace genutzt, mit einer an den Workspace oder Cluster gebundenen Cloud-Identität (Instance Profile auf AWS, Service Principal in Azure). Die Berechtigung lag im Cloud-IAM, die Sichtbarkeit im DBFS-Filesystem, die technische Verantwortung blieb häufig bei der Person, die den Mount ursprünglich eingerichtet hatte.
Unity Catalog verlagert die Steuerung des Speicherzugriffs auf accountweit verwaltete Objekte. Storage-Zugriff wandert aus dem Workspace in den Metastore. Wird dieser Unterschied nicht berücksichtigt, bleiben die bisherigen workspacebezogenen Zugriffs- und Verantwortungsmodelle bestehen. Für eine saubere Migration müssen drei Fragen beantwortet werden.
Wie teilen wir den Storage so auf, dass Berechtigungen vererbbar und überprüfbar bleiben? Welche technischen Identitäten werden benötigt und welche Gruppe verantwortet deren Lebenszyklus? Wie lassen sich die bestehenden Mounts in eine überschaubare und langfristig wartbare UC-Topologie überführen, ohne produktive Pipelines zu brechen?
External Locations unterstützen diese Umstellung, sofern sie als Teil der Storage- und Berechtigungsarchitektur geplant werden. Sie sollten nicht lediglich als Ersatznamen für bestehende Pfade behandelt werden.
Was ist eine External Location in Unity Catalog?
Eine External Location ist ein schützbares Objekt in Unity Catalog. Sie verbindet einen konkreten Cloud-Speicherpfad mit einer technischen Zugriffsidentität. Der Pfad ist eine vollständige URI im jeweiligen Cloud-Schema (abfss://container@account.dfs.core.windows.net/path, s3://bucket/path, gs://bucket/path). Die Storage Credential verwaltet die Cloud-Identität, mit der Databricks auf den Speicher zugreift. Databricks dokumentiert die genaue Abgrenzung zwischen Pfad und Zugriffsidentität.
Storage Credentials und External Locations sind getrennte Unity-Catalog-Objekte mit jeweils eigener Ownership und eigenen Privilegien. Die Storage Credential repräsentiert die jeweilige Cloud-Identität: in Azure eine Managed Identity oder einen Service Principal, in AWS eine IAM Role, in GCP einen Service Account. Sie ist ein Metastore-weites Objekt mit eigenen Privilegien wie CREATE_EXTERNAL_LOCATION und einem eigenen Owner. Die External Location beschränkt die Nutzung dieser Identität auf einen definierten Speicherpfad und trägt selbst Privilegien wie READ_FILES, WRITE_FILES und CREATE_EXTERNAL_TABLE.
Dadurch wird die Zugriffssteuerung accountweit über den Metastore verwaltet. Bei DBFS-Mounts war der Zugriff vor allem durch Cloud-IAM und die Workspace-Konfiguration bestimmt. Im Unity-Catalog-Modell wird der zulässige Zugriff zusätzlich über explizite Objektprivilegien geregelt. Berechtigungsänderungen werden dadurch als nachvollziehbare Grants auf verwalteten Objekten abgebildet, jeder Zugriff hinterlässt eine Audit-Spur in den UC-System-Tabellen, für jedes Objekt ist eine verantwortliche Identität oder Gruppe hinterlegt. Cloud-IAM bleibt weiterhin die technische Grundlage des Speicherzugriffs, die fachliche und plattformseitige Vergabe erfolgt jedoch über Unity Catalog.
| Aspekt | DBFS-Mount | External Location |
|---|---|---|
| Geltungsbereich | Workspace-lokal | Metastore-weit, workspace-übergreifend |
| Zugriffssteuerung | Cloud-IAM und Workspace-/Cluster-Konfiguration | UC-Privilegien (, , ) |
| Cloud-Identität | Instance Profile (AWS) oder Service Principal (Azure), an Workspace oder Cluster gebunden | Storage Credential mit Managed Identity, IAM Role oder Service Account |
| Ownership | meist die anlegende Person, oft undokumentiert | explizit gesetzter Owner auf jedem Objekt |
| Audit | indirekt über Cloud-IAM- und Workspace-Logs | UC-System-Tabellen mit Audit-Spur je Zugriff |
| Berechtigungsvergabe | implizit über IAM-Rollen am Cluster | explizite Grants auf External Location und Storage Credential |
Eine External Location ersetzt nicht die grundlegenden Cloud-IAM-Berechtigungen auf dem Storage Account oder Bucket. Diese Frage bleibt im Cloud-IAM. Die External Location regelt, welche UC-Principals über die hinterlegte Credential Daten lesen, schreiben oder als externe Tabellen registrieren dürfen. Das Modell erfordert deshalb weiterhin eine abgestimmte Konfiguration von Cloud-IAM und Unity Catalog.
Wie External Locations zusammen mit Catalogs, Volumes und Berechtigungen das Metastore-Objektmodell tragen, zeigen wir im Überblick zu Unity Catalog auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Storage Credentials und External Locations: Identität und Speicherpfad sauber trennen
Storage Credential und External Location haben jeweils eine eigene Aufgabe. Die Storage Credential ist der Ausweis von Databricks gegenüber der Cloud: sie beantwortet die Frage, wer da gerade auf den Storage zugreift. Die External Location ist der konkrete Speicherbereich, der über diesen Ausweis nutzbar sein soll, also welcher Container- oder Bucket-Pfad freigegeben wird. Diese Trennung hält das Modell übersichtlich. In den meisten Plattformen reichen wenige Storage Credentials, je eine pro Cloud-Identität, die der Metastore wirklich braucht. Wichtig sind klar benannte Owner und ein definierter Prozess für Rotation und Änderungen. Eine Storage Credential lässt sich anschließend für mehrere External Locations nutzen, die jeweils einen eigenen Datenbereich abdecken.
| Storage-Frage | UC-Mechanismus |
|---|---|
| Zugriff auf den Cloud-Pfad regeln? | External Location + / |
| Cloud-Identität kapseln? | Storage Credential mit Managed Identity, IAM Role oder Service Account |
| Einzelne Dateien strukturiert ansprechen? | Volume auf einer External Location |
| External Table anlegen dürfen? | auf der External Location |
| Fremder Katalog (kein eigener Storage)? | Lakehouse Federation |
Benötigt ein Speicherbereich abweichende Berechtigungen, sollte er durch eine eigene External Location abgegrenzt werden. Ändert sich ausschließlich die technische Cloud-Identität, ist dafür eine separate Storage Credential erforderlich. Bleiben Identität und Berechtigungsmodell gleich, sollte der Pfad möglichst in eine bestehende External Location integriert werden.
Überlappende Speicherpfade gehören zu den häufigsten Planungsfehlern. Eine External Location darf keinen Pfad enthalten, der bereits von einer anderen abgedeckt ist. Liegt abfss://container@account/raw als External Location, kann darunter nicht zusätzlich abfss://container@account/raw/sales als eigene External Location registriert werden. Der Pfadzuschnitt muss deshalb vor der technischen Anlage als Architekturentscheidung festgelegt werden.
Im Rahmen der Migration wird häufig auch das Modell der Cloud-Identitäten modernisiert. AWS-Instance-Profiles werden durch eine IAM Role mit UC-Trust-Policy ersetzt. In Azure tritt die Managed Identity an die Stelle eines Service Principals mit Secret. In GCP wird ein dedizierter Service Account verwendet. Die Anpassung von Cloud-IAM und technischen Identitäten verursacht häufig mehr Aufwand als die reine Anlage der Unity-Catalog-Objekte, weil sie Cloud-IAM-Teams, Sicherheits-Review und produktive Pipelines berührt.
READ_FILES, WRITE_FILES und CREATE_EXTERNAL_TABLE
Auf jeder External Location liegen eigene Rechte, die regeln, wer dort was darf. Drei davon sind im Alltag entscheidend.
READ_FILES
Leserecht auf den Pfad. Jede Pipeline, jeder Job und jedes Volume, das aus diesem Bereich Daten zieht, braucht es.
WRITE_FILES
Schreibrecht für Ergebnisdaten, Checkpoints und Schemazustände. Zu breit zugeschnitten, gilt das Recht versehentlich auch für andere Workloads.
CREATE_EXTERNAL_TABLE
Recht, an diesem Speicherort eine externe Tabelle anzulegen. Lese- oder Änderungsrechte auf die Tabelle selbst werden separat geregelt.
Eine Ebene höher sitzt CREATE_EXTERNAL_LOCATION auf der Storage Credential. Es entscheidet, ob die hinterlegte Cloud-Identität überhaupt für neue External Locations verwendet werden darf, und gehört zu den wirkungsvollsten Rechten im Storage-Modell.
Über allen Rechten steht die Ownership. Der Owner einer External Location bestimmt, wer dort Tabellen oder Volumes anlegen darf. Der Owner einer Storage Credential bestimmt, welche External Locations die Identität überhaupt nutzen dürfen.
Umgebung, Datenbereich und Datenprodukt
Die sinnvolle Aufteilung liegt meist zwischen einer Location pro Schema und einer pauschalen Freigabe des gesamten Storage Accounts. Beide Ansätze führen in größeren Plattformen zu Problemen. Eine Location auf Container-Ebene kann zu weitreichende Zugriffe ermöglichen und die fachliche Trennung der Datenbereiche erschweren. Eine Location für jedes einzelne Schema erhöht dagegen die Zahl der Objekte und den Verwaltungsaufwand erheblich und macht jeden neuen Datenraum zum Cloud-IAM-Ticket.
Drei Zuschnittsmodelle sind in der Praxis besonders verbreitet, jedes mit eigenen Stärken und Schwächen.
| Schnitt-Strategie | Stärke | Schwäche |
|---|---|---|
| pro Datenbereich (raw, curated, sandbox) | Klare Trennung der Berechtigungsbereiche, wenige Objekte | Cloud-Account-Topologie muss passen, sonst Sub-Pfad-Konflikte |
| pro Umgebung (dev, test, prod) | Klare Abgrenzung zwischen Entwicklungs-, Test- und Produktionsdaten, einfache Promotion-Pipelines | Mehr Storage Credentials, wenn Identitäten je Umgebung wechseln |
| pro Datenprodukt (Domain-orientiert) | Die Verantwortung für Datenprodukt und zugehörigen Speicherbereich kann gemeinsam organisiert werden | Kann bei vielen Produkten zur Verwaltungs-Last werden |
Produktive Plattformen kombinieren häufig Umgebung und Datenbereich. Ein mögliches Ausgangsmodell für ein mittelgroßes Lakehouse: vier External Locations je Cloud-Account (raw, curated, sandbox, archive), jeweils pro Umgebung getrennt. Daraus entstehen 12 External Locations für drei Umgebungen, getragen von einer Handvoll Storage Credentials. Dieses Modell bleibt vergleichsweise übersichtlich und unterstützt getrennte Berechtigungs- und Deployment-Prozesse je Umgebung.
Die Häufigkeit neu benötigter External Locations kann auf einen ungeeigneten Zuschnitt hinweisen. Müssen fortlaufend neue Locations angelegt werden, ist das Modell möglicherweise zu kleinteilig. Entsteht trotz stark wachsender Plattform nie eine neue Location, sind die bestehenden Bereiche möglicherweise zu breit geschnitten: Ein wachsender Datenraum steckt unter einer alten Berechtigung.
External Tables und External Volumes auf External Locations
External Locations bilden die technische Grundlage für mehrere weitere Unity-Catalog-Objekte. Am direktesten betrifft das External Tables und External Volumes.
External Tables registrieren eine Tabelle mit LOCATION 'abfss://…' und verweisen damit auf einen Pfad innerhalb einer External Location. Die späteren Tabellenberechtigungen werden unabhängig von den Privilegien der External Location verwaltet, aber sie kann nur dort angelegt werden, wo CREATE_EXTERNAL_TABLE als Privileg sitzt. Die External Location steuert damit, wer an diesem Speicherort neue externe Tabellen registrieren darf. Der Lesezugriff auf die erstellte Tabelle wird anschließend separat vergeben.
Volumes sind das vorgesehene Unity-Catalog-Objekt für dateibasierte Inhalte im Metastore. Ein External Volume verweist auf einen Pfad, der in einer External Location liegt, und stellt Dateien über einen einheitlichen, berechtigbaren Volume-Pfad bereit. Volumes übernehmen für Unity-Catalog-Workloads die Rolle eines zentral verwalteten Dateizugriffs, mit dem Unterschied, dass Berechtigung und Audit über UC laufen. Wie sich der Datei-Securable von der Tabellen-Sicht unterscheidet und wann ein Volume das bessere Werkzeug ist, zeigen wir im Überblick zu Volumes in Unity Catalog.
Auto Loader, Lakeflow und Checkpoints mit External Locations betreiben
Dateibasierte Ingestion ist der Workload, an dem die Migration am häufigsten konkret spürbar wird.
Auto Loader, Lakeflow und andere Streaming-Quellen lesen ihre Eingangsdateien typischerweise aus einem Pfad, der in einer External Location liegt. Für die Pipeline müssen Quell-, Schema- und gegebenenfalls Checkpoint-Pfade auf das neue Zugriffsmodell umgestellt werden. Gleichzeitig wechselt die verwendete Cloud-Identität von der Cluster- oder Workspace-Identität zur Storage Credential, nicht mehr das Instance Profile des Clusters. Das ist häufig der konkrete Punkt, an dem Pipeline-Owner die Migration spüren: Unterschiede bei Pfaden, Privilegien und Cloud-IAM können dazu führen, dass einzelne Pipelines nach der Umstellung fehlschlagen.
Streaming-Pipelines benötigen für Checkpoints und Schemazustände zusätzlich einen kontrollierten Schreibpfad. Wenn der Checkpoint im selben Container liegt wie die Quelldaten, muss die External Location oder eine zweite, dedizierte External Location das WRITE_FILES-Privileg für die Pipeline-Identität tragen. Ein zu breit definierter Speicherbereich kann hier zu unnötig weitreichenden Schreibrechten führen, weil dieselbe Berechtigung versehentlich für andere Pipelines mitgeöffnet wird.
DBFS-Mounts auf External Locations migrieren
Eine Mount-Migration umfasst mehr als den Austausch von Pfadnamen. Sie erfordert einen geplanten Ablauf für Topologie, Identitäten, Codeanpassungen, Tests und Rückfalloptionen und bleibt damit eine Architektur-Aufgabe.
Im Zentrum steht der Topologie-Entwurf. Mehrere historisch entstandene Mounts lassen sich häufig in wenige klar geschnittene External Locations zusammenführen. Die Bündelung folgt den drei Schnitt-Achsen Datenbereich, Umgebung und Datenprodukt. Eine direkte Übernahme jedes Mounts als eigene External Location konserviert meist die historische Struktur, weil diese Pfade historisch gewachsen sind und selten zur neuen Topologie passen. Die Entwicklung des Zielmodells ist häufig der anspruchsvollste Teil der Migration.
Steht das Zielmodell, folgt die Anlage in Code. Storage Credentials und External Locations sollten versioniert und reproduzierbar über Infrastructure as Code verwaltet werden, etwa über Terraform mit dem databricks_external_location-Provider oder in Databricks Asset Bundles, niemals nur in die UI. Der Grund: Jede produktive Plattform muss die Storage-Topologie reproduzieren können, in Dev, Test und Prod, und Änderungen müssen einen Audit-Trail haben. Eine ausschließlich manuelle Anlage erschwert Reproduzierbarkeit, Review und Auditierung.
Bestandsaufnahme der Mounts
Alle bestehenden Mount-Points, ihre Pfade, Owner und abhängigen Pipelines inventarisieren.
Topologie-Entwurf
Zielmodell für External Locations festlegen, geschnitten nach Datenbereich, Umgebung und Datenprodukt.
Anlage in Code
Storage Credentials und External Locations reproduzierbar über Terraform oder Databricks Asset Bundles anlegen.
Pilot-Migration
Eine einzelne Auto-Loader-Pipeline im Parallelbetrieb auf das neue Modell umstellen und beobachten.
Reihen-Migration mit Rollback-Fenster
Verbleibende Pipelines pro Datenbereich migrieren, verwaiste Mounts dokumentiert stilllegen.
External Locations vs Lakehouse Federation
External Locations und Lakehouse Federation werden aufgrund ihres Zugriffs auf externe Daten häufig miteinander verwechselt. Beide regeln Zugriff auf Daten, die nicht als Managed Tables im UC-Storage liegen. Die Abgrenzung lässt sich über die Art der angebundenen Quelle treffen: External Locations steuern den direkten Zugriff auf einen Cloud-Speicherpfad, Lakehouse Federation bindet dagegen Tabellen und Metadaten einer externen Datenplattform ein.
Eine External Location zeigt auf einen Pfad in einem Cloud-Container. Der Speicher liegt typischerweise im eigenen Cloud-Account und wird direkt durch das Plattformteam verwaltet, die Tabellen werden im UC-Metastore registriert. Der Zugriff läuft über die Databricks-Engine, die per Storage Credential auf den Pfad zugreift.
Lakehouse Federation zeigt auf einen fremden Katalog, etwa eine Snowflake-Datenbank, eine BigQuery-Region oder ein Postgres-Schema. Die Daten dort gehören einem anderen System, das eigene Compute betreibt und eigene Berechtigungen verwaltet. Databricks sendet Abfragen an die externe Engine beziehungsweise liest deren bereitgestellte Metadaten, ohne die Daten zu kopieren.
Ein vorhandener Data Lake in S3 oder ADLS, der unter UC laufen soll, braucht eine External Location. Ein Snowflake-Warehouse, das direkt aus Databricks abgefragt werden soll, braucht Federation. In größeren Plattformen können beide Mechanismen für unterschiedliche Quelltypen parallel eingesetzt werden.
External Location nutzen, wenn
- Die Daten liegen im eigenen Cloud-Account (S3, ADLS, GCS)
- Die Tabellen sollen im UC-Metastore registriert werden
- Die Databricks-Engine soll direkt auf die Dateien zugreifen
Lakehouse Federation nutzen, wenn
- Die Daten liegen in einem fremden System mit eigenem Compute (Snowflake, BigQuery, Postgres)
- Nur Metadaten und Abfragen föderiert werden sollen, ohne Daten zu kopieren
- Kein eigener Storage-Zugriff nötig ist, nur die Katalog-Einbindung
Grenzen von Unity Catalog External Locations
External Locations helfen dabei, den Zugriff auf Cloud-Speicher sauberer zu steuern. Sie lösen aber nicht automatisch alle Probleme aus alten Mount-Strukturen.
Schwierig wird es vor allem dann, wenn ein alter Mount sehr unterschiedliche Datenbereiche zusammenfasst. Zum Beispiel: Rohdaten, sensible Kundendaten und Reporting-Daten liegen unter demselben Speicherpfad. Diese Struktur lässt sich nicht immer eins zu eins in Unity Catalog übernehmen.
Dann gibt es meist zwei Möglichkeiten: Entweder der Datenbestand wird neu sortiert, oder der Zugriff wird bewusst neu bewertet. Genau deshalb sollte die Migration nicht nur als technische Umstellung geplant werden. Sie ist auch eine Architekturentscheidung.
Nach der Migration braucht es klare Regeln für den Betrieb: Wer ist für eine External Location verantwortlich? Wann werden Zugriffe geprüft? Wie werden Änderungen am Speicher dokumentiert? Und wie wird sichergestellt, dass neue Datenbereiche nicht wieder unkontrolliert wachsen?
Unity Catalog liefert dafür die Grundlage. Stabil wird das Modell aber erst, wenn Ownership, Zugriffsprüfung und Änderungen am Speicher regelmäßig gepflegt werden.
Fazit
External Locations ersetzen nicht einfach alte Mounts, sondern schaffen eine zentrale Struktur für Zugriff, Verantwortung und Audit.
External Locations werden wichtig, wenn Cloud-Speicher dauerhaft und kontrolliert in Databricks genutzt werden soll. Dadurch lassen sich External Tables, External Volumes und dateibasierte Ingestion unter Unity Catalog sauberer verwalten als mit workspacebezogenen DBFS-Mounts.
Besonders relevant wird das in gewachsenen Data Lakes. Dort gibt es oft mehrere Cloud-Accounts, viele alte Mounts und nicht mehr vollständig dokumentierte Zuständigkeiten. Typische Warnsignale sind:
- viele Mounts im Workspace, teilweise ohne klaren Owner
- Speicherzugriffe, die über IAM-Rollen, Notebooks und Workspace-Konfigurationen verteilt sind
- Auto-Loader- oder Lakeflow-Pipelines, deren Pfade, Identitäten und Checkpoints vor einer Abschaltung nicht vollständig bekannt sind
Bei neuen Plattformen, die direkt mit Unity Catalog starten, ist die Situation einfacher. Storage Credentials und External Locations sollten dort von Anfang an als Code verwaltet werden, zum Beispiel über Terraform oder Databricks Asset Bundles.
Mein Vorschlag: Die Struktur sollte sich zuerst an klaren Datenbereichen orientieren, etwa Raw, Curated, Sandbox und Archive. Zusätzlich braucht es eine saubere Trennung nach Umgebung, zum Beispiel Dev, Test und Prod. Dieses Modell sollte mit der eigenen Datenstruktur abgeglichen werden, bevor die erste Pipeline migriert wird.
Eine belastbare UC-Storage-Architektur erkennt man daran, dass jeder Speicherbereich einen klaren Owner, eine kontrollierte technische Identität und einen nachvollziehbaren Zugriffsweg hat.
Sinnvoll ist eine produktive Pilotstrecke, die für einen definierten Zeitraum parallel läuft. Danach kann die Umstellung schrittweise nach Datenbereichen erfolgen.
FAQ
Eine External Location ist ein Securable im UC-Metastore, das einen Cloud-Storage-Pfad mit einer Storage Credential verbindet. Sie regelt, welche UC-Principals über die hinterlegte Cloud-Identität Daten lesen, schreiben oder als externe Tabellen registrieren dürfen. Damit wird die Berechtigung für externen Storage aus dem Workspace in den Metastore verlagert.
