External Locations

Eine External Location ist im Unity Catalog (dem Berechtigungs- und Katalog-System von Databricks) ein benannter Eintrag, der zwei Dinge zusammenführt: einen Ordner in einem Cloud-Speicher (Azure Data Lake Storage Gen2, Amazon S3 oder Google Cloud Storage) und ein Storage Credential (die hinterlegte Cloud-Identität, mit der Databricks auf diesen Ordner zugreifen darf). Über diesen Eintrag vergibt Unity Catalog Lese- und Schreibrechte an dem Ordner zentral, statt sie in der Cloud verstreut zu verwalten. External Locations sind damit die Brücke zwischen dem Cloud-Speicher und dem Databricks-Katalog und Voraussetzung für externe Tabellen, externe Volumes und direkte Pfad-Zugriffe unter Unity-Catalog-Governance.

Was ist eine External Location?

Eine External Location ist ein Eintrag im Databricks-Katalog, der genau zwei Bestandteile zusammenführt: einen Ordner-Pfad im Cloud-Speicher und ein Storage Credential (die Cloud-Identität für den Zugriff). Der Pfad zeigt auf einen Bereich in einem Cloud-Speicher-Konto: typische Adressen sind abfss://<container>@<account>.dfs.core.windows.net/<pfad> für Azure Data Lake Storage Gen2 (kurz ADLS Gen2), s3://<bucket>/<pfad> für Amazon S3 und gs://<bucket>/<pfad> für Google Cloud Storage (kurz GCS). Das Storage Credential wiederum ist die technische Identität, mit der Unity Catalog gegenüber der Cloud auftritt: in Azure eine Managed Identity oder ein Service Principal, in Amazon Web Services (AWS) eine IAM Role und in der Google Cloud Platform (GCP) ein Service Account.

Die Rolle der External Location im Unity Catalog besteht darin, Storage-Berechtigungen aus der Cloud-Konfiguration in das Katalog-Objektmodell zu heben. Berechtigungen wie READ FILES, WRITE FILES, CREATE EXTERNAL TABLE und CREATE EXTERNAL VOLUME werden auf einer External Location vergeben und gelten für alle Pfade darunter. Ohne diesen Zwischenschritt läge die Autorisierung ausschließlich in den Cloud-nativen Berechtigungssystemen (Azure RBAC, AWS IAM, GCP IAM); mit External Locations wandert sie in dieselbe Governance-Ebene wie Tabellen, Views und Volumes.

Der Begriff wurde 2022 mit der allgemeinen Verfügbarkeit des Unity Catalog eingeführt und ist bewusst getrennt von den Storage Credentials. Ein Storage Credential kann von mehreren External Locations verwendet werden; die Location fügt Pfad-Scope und Katalog-Grants hinzu. Umgekehrt kann eine External Location zu einem Zeitpunkt nur genau ein Storage Credential referenzieren. Unity Catalog erlaubt zudem keine überlappenden External Locations: Der Pfad-Baum muss disjunkt aufgeteilt sein. Ein Bucket- oder Container-Pfad kann nur genau einer External Location zugeordnet werden, für Unterpfade können separate Locations mit engerem Scope angelegt werden.

External Locations sind zusätzlich der einzige unter Unity Catalog unterstützte Weg für pfadbasierte Zugriffe. Ein direkter Zugriff über SELECT * FROM 'abfss://…' in Databricks SQL oder ein Spark-Read auf einen beliebigen Cloud-Pfad ohne registrierte External Location wird von Unity Catalog abgelehnt. Managed Tables und Managed Volumes umgehen diesen Weg, weil sie auf dem Managed Storage von Metastore, Catalog oder Schema liegen, der intern über ein systemverwaltetes Storage Credential angebunden ist.

Abgrenzung gegen Storage Credentials, Managed Storage, Volumes und External Tables

Die häufigsten Verwechslungen betreffen benachbarte Objekte im Unity-Catalog-Objektmodell. Eine External Location ist keines dieser Objekte, sondern nimmt eine klar definierte Position dazwischen ein.

Ein Storage Credential ist die reine Identitätsschicht; ohne den Pfad-Anker einer External Location entstehen keine Katalog-Grants und keine Path-Governance. Ein Managed Storage ist ein von Databricks verwalteter Cloud-Pfad, den Unity Catalog automatisch mit einem systemverwalteten Credential anspricht; Layout und Löschung liegen dort in der Katalog-Logik, während bei External Locations der Kunde Herr über die Ordnerstruktur bleibt. Ein Volume ist ein Katalog-Einstiegspunkt für die Files-API und dbutils.fs; External Volumes setzen zwingend eine External Location voraus, Managed Volumes dagegen nicht. Eine External Table schließlich verlangt die passende External Location als Pfad-Container: Ihre LOCATION-Klausel muss innerhalb einer registrierten External Location liegen, sonst wird die Erstellung abgelehnt.

Beispiel: Bronze-Landing-Zone auf ADLS Gen2

Ein Data-Engineering-Team betreibt eine Bronze-Landing-Zone auf Azure Data Lake Storage Gen2. Der Storage-Account heißt acmestorage, der Container landing. Für die Bronze-Rohdaten wird der Unterpfad bronze/ reserviert. Die Anbindung an Unity Catalog erfolgt in drei Schritten:

1. Ein Storage Credential uc-bronze-mi wird registriert und mit einer Azure Managed Identity verknüpft, die auf dem Storage-Account acmestorage die Rolle „Storage Blob Data Contributor" besitzt.
2. Eine External Location bronze_landing wird auf den Pfad abfss://landing@acmestorage.dfs.core.windows.net/bronze/ angelegt und referenziert das Credential uc-bronze-mi.
3. Auf bronze_landing erhält die Gruppe data-engineering die Berechtigungen READ FILES und WRITE FILES; die Gruppe analytics erhält nur READ FILES.

Sobald die External Location eingerichtet ist, kann ein externes Fremdsystem Rohdateien direkt in den ADLS-Pfad schreiben; darauf liegen ein External Volume bronze_landing_files für die Files-API sowie External Tables als Delta-Bronze-Layer. Alle Zugriffe laufen über die auf der External Location vergebenen Berechtigungen, unabhängig davon, ob der lesende Prozess ein Databricks-SQL-Warehouse, ein Job-Cluster oder ein Notebook ist. Die Cloud-native Autorisierung bleibt für die technischen Prinzipale der External Location konfiguriert; das darüberliegende Berechtigungsmodell für Anwender wird ausschließlich in Unity Catalog gepflegt.