Unity Catalog Volumes: Dateien in Databricks sicher verwalten
Die Kernaussagen auf einen Blick.
- Unity Catalog Volumes bringen Dateien in dasselbe Governance-Modell wie Tabellen. Zugriffe auf PDFs, Bilder, Rohdateien, Modell-Artefakte oder RAG-Quellen lassen sich damit zentral berechtigen und nachvollziehbarer steuern.
- Managed Volumes sind der Standard für neue Dateien, die nur in Databricks genutzt werden. External Volumes sind sinnvoll, wenn bestehende Speicherpfade weiter genutzt werden oder andere Systeme denselben Cloud-Speicher lesen oder schreiben müssen.
- Die wichtigste Entscheidung lautet: Soll Unity Catalog den Speicher und Lebenszyklus der Dateien verwalten, oder bleibt der Speicher bewusst außerhalb von Databricks organisiert?
- Neue Dateizugriffe sollten grundsätzlich über laufen. DBFS Root und Workspace Mounts sollten nicht weiter ausgebaut, sondern schrittweise aus bestehenden Jobs und Pipelines entfernt werden.
Inhaltsverzeichnis
Was im Cloud Storage liegt, sieht Unity Catalog nicht
Tabellen werden bereits strukturiert über Unity Catalog verwaltet, mit Catalog, Schema, Eigentümer und GRANT pro Spalte. Gleichzeitig greifen Notebooks weiterhin über DBFS-Mounts auf Dateien zu, etwa aus dbfs:/mnt/sap-export/. Modellartefakte werden von ML-Teams teilweise direkt im Cloud-Speicher abgelegt, und die Audit-Stelle fragt regelmäßig, wer welche PDFs aus der Schadensbearbeitung gelesen hat. Eine zentrale und belastbare Auskunft ist dadurch nur schwer möglich. Die Dateizugriffe liegen damit außerhalb der Governance von Unity Catalog.
Diese Situation tritt häufig auf, sobald mehrere Workspaces oder Geschäftsbereiche onboarden. Die Plattform-Verantwortung deckt Tabellen und liest Audit-Logs aus den System Tables. Dateizugriffe werden dagegen weiterhin separat verwaltet, weil sie über Workspace-Mounts oder direkte ABFSS-Pfade laufen, deren Berechtigungen direkt über Rollen und Richtlinien des Cloud-Anbieters gesteuert werden.
Welche Dateien liegen in welchen Speicherorten, und wer hat darauf Zugriff? Wer hat im letzten Quartal welche Modell-Artefakte gelesen, kopiert, überschrieben? Welche Notebooks und Jobs hängen noch von veralteten Speicherpfaden ab, wenn der DBFS-Root abgeschaltet wird? Welche Dateien dürfen für RAG-, Trainings- oder Inference-Anwendungen verwendet werden und welche nicht?
Solange diese Fragen aus IAM-Rollen, Workspace-Mounts und Storage-Account-Logs zusammengesucht werden müssen, bleibt eine einheitliche Governance für Dateien schwer umsetzbar. Unity Catalog Volumes integrieren diese Dateien in das zentrale Governance-Modell. Dateibestände werden dadurch als reguläre Objekte im Catalog verwaltet, mit definierter Ownership, Berechtigungen und nachvollziehbaren Abhängigkeiten, im selben Modell wie eine Tabelle.
Was sind Unity Catalog Volumes?
Ein Volume ist ein Unity-Catalog-Objekt für Dateien. Es liegt innerhalb eines Schemas und ist über einen festen Pfad erreichbar: /Volumes/<catalog>/<schema>/<volume>/.... Databricks Volumes und Unity Catalog Volumes bezeichnen dasselbe Objekt; „Databricks Volumes“ ist nur die produktbezogene Kurzform.
Darüber können Notebooks, Jobs und Databricks-Dienste auf Dateien zugreifen, ohne direkt mit Cloud-Pfaden wie S3, ADLS oder GCS arbeiten zu müssen. Typische Inhalte sind Rohdateien, PDFs, Bilder, Modellartefakte, Bibliotheken oder andere Dateien, die nicht als Tabelle verwaltet werden. Databricks dokumentiert Volumes als Catalog-Objekte für Nicht-Tabellen-Daten.
Ein Volume dient dabei als zentraler Knoten für mehrere dateibasierte Workloads: Data Engineering und Ingestion, Data Science und ML, Data Sharing, UNIX-artiger Dateizugriff sowie Logging und Checkpointing greifen alle auf denselben Speicherort zu.
Es gibt zwei Arten von Volumes:
- Managed Volumes: Unity Catalog verwaltet Speicherort und Lifecycle.
- External Volumes: Das Volume zeigt auf einen bestehenden Cloud-Speicherpfad innerhalb einer External Location.
Für Nutzer und Anwendungen fühlt sich beides gleich an. Der Unterschied liegt vor allem darin, wer den Speicher und den Lifecycle darunter verantwortet.
Volumes ersetzen in vielen Fällen ältere Zugriffsmuster wie DBFS Root, Workspace Mounts oder direkte Zugriffe auf Cloud-Pfade aus Notebooks. External Locations bleiben weiterhin wichtig, aber eher als technische Verbindung zwischen Unity Catalog und dem Cloud-Speicher. Der eigentliche Zugriff aus Databricks sollte über Volumes laufen.
Der Vorteil: Dateien werden wie andere Unity-Catalog-Objekte berechtigt, auffindbar und auditierbar. Der Zugriff läuft über einen stabilen Catalog-Pfad, während Berechtigungen und Governance zentral über Unity Catalog gesteuert werden.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Variante passt wann?
Die wichtigste Frage ist: Soll Databricks den Speicher vollständig verwalten, oder liegt der Datei-Lifecycle weiterhin außerhalb von Databricks?
| Frage | Managed Volume | External Volume |
|---|---|---|
| Wo liegen die Dateien? | Im von Unity Catalog verwalteten Speicher | In einem bestehenden Cloud-Speicherpfad |
| Wer verwaltet den Lifecycle? | Unity Catalog | Das Plattform- oder Storage-Team |
| Was passiert bei DROP? | Volume und Daten werden entfernt | Nur das Catalog-Objekt wird entfernt, die Dateien bleiben im Speicher |
| Zugriff durch andere Systeme? | Eher nicht vorgesehen | Möglich, weil der Pfad im Cloud-Speicher sichtbar bleibt |
| Typischer Einsatz | Neue Dateibestände in Databricks | Bestehende oder gemeinsam genutzte Speicherpfade |
Managed Volume wählen, wenn
- Neue Dateien werden ausschließlich in Databricks genutzt: RAG-Quellen, PDFs, Bilder, Modellartefakte, SharePoint-Exporte, AI-Function-Eingaben
- Speicherort, Berechtigungen und Lifecycle sollen zentral über Unity Catalog laufen
- Kein Bedarf an separaten Cloud-Pfaden, Mounts oder eigenen Storage-Berechtigungen
External Volume wählen, wenn
- Der Speicherpfad bleibt außerhalb von Databricks wichtig, etwa SAP-Exporte, externe ETL-Prozesse oder Lieferanten-Dateien
- Andere Systeme müssen denselben Cloud-Speicherpfad lesen oder schreiben
- Bestehende Daten sollen nicht sofort migriert werden, External Volume funktioniert auch als Übergangslösung
- Der Storage-Bereich hat eigene Aufbewahrungsregeln im Cloud-Konto
Wenn es keinen klaren Grund für ein External Volume gibt, ist ein Managed Volume meist die einfachere Wahl. External Volumes bringen zusätzliche Verantwortung für Cloud-Speicher, Berechtigungen und Lifecycle mit und sollten deshalb bewusst eingesetzt werden.
READ VOLUME, WRITE VOLUME und Vererbung
Der Zugriff auf Volumes wird über Unity Catalog gesteuert. Das Prinzip ist ähnlich wie bei Tabellen: Nutzer oder Gruppen brauchen die passenden Rechte auf Catalog, Schema und Volume.
Wichtig sind vor allem drei Berechtigungen:
READ VOLUME
Erlaubt das Lesen von Dateien im Volume.
WRITE VOLUME
Erlaubt das Erstellen, Ändern und Löschen von Dateien.
USE CATALOG / USE SCHEMA
Zusätzlich nötig, damit Nutzer das Volume im jeweiligen Catalog und Schema überhaupt erreichen können.
Berechtigungen können vom Catalog über das Schema bis zum Volume vererbt werden. Ein Recht auf Schema-Ebene kann also für alle Volumes in diesem Schema gelten. Einzelne Volumes können bei Bedarf aber auch gezielt enger berechtigt werden.
Der Vorteil: Dateien und Tabellen lassen sich im selben Governance-Modell verwalten. Eine Gruppe kann zum Beispiel Zugriff auf bestimmte Tabellen und die dazugehörigen Dateien erhalten, ohne dass separate Cloud-IAM- oder Storage-Regeln gepflegt werden müssen. Zugriffe lassen sich außerdem über Unity-Catalog-System-Tables nachvollziehen.
Wichtig ist die Grenze: Innerhalb eines Volumes lassen sich keine eigenen Berechtigungen pro Unterordner oder Datei vergeben. Wenn unterschiedliche Gruppen unterschiedliche Dateien sehen dürfen, sollten dafür getrennte Volumes angelegt werden. Ein gemeinsames Volume für mehrere Schutzbedarfe wird sonst schnell unübersichtlich.
Unity Catalog Volumes vs DBFS, Workspace Mounts und direkte Cloud-Pfade
Vor Unity Catalog Volumes wurden Dateien in Databricks häufig über DBFS Root, Workspace Mounts oder direkte Cloud-Pfade wie ABFSS, S3 oder GCS gelesen. Das Problem: Diese Zugriffe laufen nicht sauber über Unity Catalog, sondern über Workspace-Rechte oder Cloud-IAM. Damit liegen Dateien außerhalb des Berechtigungsmodells, das für Tabellen bereits etabliert ist.
| Zugriffsweg | Berechtigung | Audit | Einordnung |
|---|---|---|---|
| DBFS Root | workspace-weit, wenig granular | nicht sauber im Catalog | ablösen |
| Workspace Mount | Cloud-IAM hinter dem Mount | vor allem im Storage-Log | ablösen |
| Direkter Cloud-Pfad | Cloud-IAM, am Catalog vorbei | vor allem im Storage-Log | vermeiden |
| Unity Catalog Volume | GRANT auf Catalog, Schema, Volume | über Unity Catalog nachvollziehbar | Standard |
DBFS Root ist zu grob, weil Dateien workspace-weit im selben Namensraum liegen. Workspace Mounts verstecken Cloud-Berechtigungen hinter einem Pfad-Alias. Direkte Cloud-Pfade umgehen die Databricks-Governance weitgehend. In allen drei Fällen ist schwerer nachvollziehbar, wer über Databricks auf welche Dateien zugreifen darf.
Volumes lösen das sauberer: Dateien bekommen ein benanntes Objekt im Unity Catalog, Berechtigungen werden über GRANTs vergeben und Zugriffe lassen sich im Databricks-Governance-Modell nachvollziehen.
Die konkrete Ablösung bestehender Pfade behandeln die nächsten Abschnitte.
External Volumes und External Locations richtig abgrenzen
External Location und External Volume werden oft verwechselt. Beide beziehen sich auf Cloud-Speicher, erfüllen aber unterschiedliche Aufgaben.
Eine External Location verbindet Unity Catalog mit einem Cloud-Speicherpfad. Sie legt fest, welcher Speicher genutzt wird und mit welcher Storage Credential darauf zugegriffen werden darf. Sie ist damit die technische Verbindung zwischen Unity Catalog und dem Cloud Storage.
Ein External Volume nutzt einen Teil dieses Speicherpfads und stellt ihn als normales Unity-Catalog-Objekt bereit. Anwendungen greifen anschließend über den bekannten Pfad /Volumes/<catalog>/<schema>/<volume>/... auf die Dateien zu, ohne den eigentlichen Cloud-Pfad kennen zu müssen. Wie External Locations funktionieren und welche Berechtigungen sie verwalten, erklären wir im Überblick zu External Locations im Unity Catalog.
Kurz gesagt: Die External Location stellt die Verbindung zum Cloud-Speicher her, das External Volume ist der Zugriffspunkt für Nutzer und Anwendungen. Direkte Zugriffe auf ABFSS-, S3- oder GCS-Pfade sollten vermieden werden, weil sie das Berechtigungsmodell von Unity Catalog umgehen.
Volumes für RAG, ML-Artefakte, AI Functions und Model Serving
Volumes sind nicht nur für alte Speicherpfade relevant. Sie sind auch der saubere Standard für KI- und ML-Workloads, die mit Dateien arbeiten.
RAG-Quellen
PDFs, Markdown-Dateien oder SharePoint-Exporte für Wissensassistenten sollten in einem klar zugeordneten Volume liegen. So ist nachvollziehbar, welche Dateien genutzt werden und wer darauf zugreifen darf.
Modell-Artefakte
Modelle, Checkpoints, Tokenizer oder Custom-Code können in Volumes mit klarer Ownership und geregelten Schreibrechten abgelegt werden. Training und Serving greifen dadurch auf dasselbe Berechtigungsmodell zurück.
AI Functions, Model Serving, AutoLoader
Volume-Pfade wie /Volumes/... lassen sich direkt in diesen Workloads nutzen. ML-Teams pflegen dadurch keine eigenen Speicher- und Berechtigungswege neben Unity Catalog.
SAP, SharePoint, externe Quellen
CSVs, Excel-Dateien, ZIPs oder Exporte von Lieferanten sollten möglichst direkt in ein vorgesehenes Volume übernommen werden. Dann gelten Berechtigungen und Zuständigkeiten schon ab dem Eingang.
Bilder, Audio und Logs
Auch nicht-tabellarische Daten lassen sich über Volumes sauber bereitstellen, bevor sie später verarbeitet oder in Tabellen überführt werden.
Vertiefend: AI Functions, Model Serving und AutoLoader.
Der Vorteil ist immer derselbe: Dateien bekommen einen festen Ort im Unity Catalog, klare Berechtigungen und eine nachvollziehbare Ownership.
DBFS und Workspace Mounts auf Volumes migrieren
DBFS Root und Workspace Mounts gehören zum älteren Databricks-Dateimodell und sind von Databricks als deprecated dokumentiert. Für neue Plattformstandards sollten sie nicht mehr verwendet werden. Der Zielpfad für Dateien in Unity-Catalog-Umgebungen sind Volumes.
Die Migration sollte schrittweise erfolgen, damit bestehende Jobs, Notebooks und Pipelines nicht unbeabsichtigt brechen.
Bestehende Pfade inventarisieren
Zuerst muss klar sein, wo heute noch dbfs:/, /dbfs/ oder dbfs:/mnt/... genutzt wird. Dazu gehören Jobs, Notebooks, Pipelines, Konfigurationen, Asset Bundles und Bibliotheken. Besonders wichtig sind selten laufende Jobs, die nur monatlich oder quartalsweise ausgeführt werden.
Zielmodell festlegen
Für jeden alten Pfad sollte ein klares Ziel definiert werden: Catalog, Schema und Volume. Neue und ausschließlich in Databricks genutzte Dateien gehören meist in Managed Volumes. External Volumes sind sinnvoll, wenn bestehende Cloud-Pfade nicht verschoben werden sollen oder auch andere Systeme darauf zugreifen.
Neue Workloads direkt auf Volumes setzen
Neue Implementierungen sollten ab sofort nur noch /Volumes/... verwenden. So entstehen keine weiteren Abhängigkeiten von DBFS Root oder Workspace Mounts.
Bestandsjobs einzeln umstellen
Bestehende Jobs sollten Schritt für Schritt migriert werden. Dabei werden hartkodierte Pfade in Code, Configs, Spark-Properties oder Deployment-Artefakten angepasst.
Alte Zugriffe abschalten
Wenn die relevanten Workloads migriert sind, sollten DBFS Root und Workspace Mounts technisch und organisatorisch unterbunden werden. Dazu gehört auch, nicht mehr benötigte Mounts und zugehörige Cloud-IAM-Rollen zu entfernen.
Das Ziel ist ein einheitliches Dateizugriffsmodell: Dateien werden über Volumes bereitgestellt, Berechtigungen laufen über Unity Catalog, und alte Sonderwege über DBFS oder Mounts verschwinden aus der Plattform.
Was Volumes nicht lösen
Volumes bringen Dateizugriffe in das Governance-Modell von Unity Catalog. Sie regeln, wer Dateien in einem Volume lesen oder schreiben darf. Sie erklären aber nicht automatisch, was diese Dateien fachlich bedeuten, wie sensibel sie sind oder wer inhaltlich dafür verantwortlich ist.
Klassifikation, Datenschutz und Ownership müssen deshalb weiterhin separat geregelt werden, zum Beispiel über Tags, klare Verantwortlichkeiten und ein sauberes GRANT-Modell auf Catalog-, Schema- und Volume-Ebene. Wie Tag-basierte Klassifizierung auch für Volumes genutzt werden kann, ordnen wir im Überblick zu Tags im Unity Catalog ein. Das passende Berechtigungsmodell behandeln wir unter Permissions im Unity Catalog.
Wichtig sind vor allem diese Grenzen:
Keine Berechtigungen pro Datei oder Unterordner
Unity Catalog berechtigt das Volume, nicht einzelne Dateien darin. Unterschiedliche Schutzbedarfe sollten deshalb über getrennte Volumes oder eine Anwendungsschicht abgebildet werden.
Keine automatische Klassifikation der Inhalte
Ein Volume macht Dateien auffindbar und berechtigbar. Ob darin PII, vertrauliche Dokumente oder öffentliche Dateien liegen, muss über Klassifikation und Governance-Prozesse geregelt werden.
Kein File-Level-Audit
Der Zugriff auf das Volume ist nachvollziehbar. Welche einzelne Datei innerhalb des Volumes gelesen wurde, ist im Catalog-Audit nicht in derselben Tiefe sichtbar.
Keine Cross-Region-Replikation
Volumes übernehmen keine regionsübergreifende Spiegelung von Dateien. Dafür bleiben Cloud-Storage-Funktionen oder eigene Datenprozesse zuständig.
Viele kleine Dateien bleiben ein Performance-Thema
Volumes liegen auf Cloud Object Storage. Millionen kleiner Dateien können Verarbeitung und Verzeichnisoperationen verlangsamen. In solchen Fällen sollte geprüft werden, ob eine tabellarische Speicherung besser passt.
External Volumes hängen an der Cloud-Konfiguration
Bei External Volumes muss die darunterliegende External Location sauber begrenzt sein. Wenn Storage Credentials oder Cloud-Rollen zu weit gefasst sind, kann das Berechtigungsmodell außerhalb von Unity Catalog zu breit bleiben.
Workspace Files bleiben für Code
Notebooks, SQL-Dateien und Entwicklungsartefakte gehören weiterhin in Workspace Files. Volumes sind für Daten, Dateien, Bibliotheken und Artefakte gedacht, die von Workloads genutzt werden.
Volumes sind also kein Ersatz für Klassifikation, Datenmodellierung oder fachliche Governance. Sie lösen ein konkretes Problem: Dateien bekommen einen festen Ort im Unity Catalog, klare Berechtigungen und eine nachvollziehbare Ownership. Alles, was die Bedeutung, Schutzklasse oder fachliche Nutzung dieser Dateien betrifft, muss weiterhin bewusst modelliert werden.
Fazit
Volumes sind der richtige Standard, wenn Dateien in Databricks genutzt werden, aber noch außerhalb von Unity Catalog verwaltet werden.
Das betrifft vor allem RAG-Quellen, ML-Artefakte, Rohdateien, SharePoint-Exporte, Lieferanten-Dateien oder andere nicht-tabellarische Daten, die heute über DBFS, Workspace Mounts oder direkte Cloud-Pfade gelesen werden.
Typische Anzeichen dafür, dass Volumes sinnvoll sind:
- RAG- oder KI-Workloads nutzen Dateien, die keinem Catalog-Objekt zugeordnet sind.
- ML-Teams lesen Modell-Artefakte aus alten Mounts oder unklar verantworteten Speicherpfaden.
- File-Zugriffe müssen für Audits nachvollziehbarer werden.
- DBFS Root oder Workspace Mounts werden noch in produktiven Jobs verwendet.
- Bestehende Cloud-Speicherpfade sollen unter Unity-Catalog-Governance kommen, ohne Dateien sofort physisch zu verschieben.
Wenn solche Fälle keine Rolle spielen und alle produktiven Workloads sauber über Tabellen laufen, kann die Einführung von Volumes niedriger priorisiert werden.
Mein Vorschlag: Dateizugriffe aus Databricks sollten grundsätzlich über Volumes laufen. Managed Volumes sind der Standard für neue, Databricks-interne Dateibestände. External Volumes passen, wenn bestehende Speicherpfade weiter genutzt werden müssen oder andere Systeme ebenfalls darauf zugreifen. DBFS Root und Workspace Mounts sollten nicht mehr für neue Workloads verwendet und schrittweise abgelöst werden. Wie Volumes in das größere Governance-Modell passen, ordnen wir im Überblick zu Unity Catalog ein.
Prüft als Erstes, welche produktiven Jobs heute noch über DBFS Root oder Workspace Mounts laufen, und legt für jeden Pfad ein Ziel-Volume mit Catalog und Schema fest.
FAQ
Volumes sind Unity-Catalog-Objekte für Files unterhalb eines Schemas, adressiert als . Sie liefern einen logischen Speicher-Container und stellen ihren Inhalt über einen POSIX-ähnlichen Pfad bereit. Berechtigungen werden über GRANT geregelt, identisch zur Tabellen-Welt. Files laufen damit im selben Governance-Modell wie Tabellen.
