Zum Inhalt springen

Volumes (Unity Catalog)

Volumes sind Unity-Catalog-Objekte für unstrukturierte Dateien in Databricks. Definition, Managed vs. External Volumes, Abgrenzung zu Tables und DBFS.

Volumes sind Governance-Objekte im Unity Catalog von Databricks für nicht-tabellare, unstrukturierte Dateien wie Bilder, PDFs, JSON-Dokumente oder Modell-Artefakte. Sie liegen im dreistufigen Namensraum catalog.schema.volume parallel zu Tabellen und binden Datei-Zugriffe an dieselben Katalog-Grants, Audit- und Lineage-Ebenen wie strukturierte Daten.

Was sind Volumes?

Volumes sind Katalog-Objekte im Unity Catalog, die Dateien statt Zeilen und Spalten adressieren. Ein Volume sitzt im gleichen Namensraum wie Tabellen (catalog.schema.<name>) und wird über Katalog-Grants berechtigt. Die Files-API, dbutils.fs, Spark-Reader, SQL-Funktionen und externe Tools erreichen den Inhalt über den Katalog-Pfad /Volumes/<catalog>/<schema>/<volume>/… oder über den zugehörigen Cloud-Path (abfss://…, s3://…, gs://…), sobald das Volume registriert ist.

Volumes existieren in zwei Ausprägungen. Ein Managed Volume liegt auf dem Managed Storage des Katalogs oder Schemas; Storage-Pfad, Verzeichnisstruktur und Lebenszyklus verantwortet Databricks. Beim Löschen des Volumes werden die Dateien mitgelöscht. Ein External Volume verweist auf einen vom Kunden kontrollierten Cloud-Storage-Pfad, angebunden über eine External Location und ein Storage Credential. Beim Löschen des Volumes bleiben die Dateien im Cloud-Storage erhalten; Layout und Retention liegen beim Kunden.

Zugriffssteuerung läuft ausschließlich über Unity-Catalog-Grants. Berechtigungen sind READ VOLUME und WRITE VOLUME; Managed Storage und External Location vererben ihre Cloud-nativen Rechte nicht an den Anwender. Zugriffe erscheinen in system.access.audit, Lineage-Bezüge zwischen Volume-Dateien und daraus abgeleiteten Tabellen entstehen automatisch bei SQL- und Spark-Läufen.

Der Begriff wurde 2023 mit der allgemeinen Verfügbarkeit eingeführt und schließt eine Lücke im Governance-Modell des Unity Catalogs. Vor Volumes lagen unstrukturierte Dateien entweder auf DBFS (workspace-lokal, ohne UC-Enforcement) oder direkt auf Cloud-Storage (nur cloud-native ACLs für Service-Prinzipale). Die tabellare Katalog-Governance endete an der Dateigrenze. Volumes ziehen Files unter dieselbe Governance-Ebene wie Tabellen, Views und Modelle.

Abgrenzung zu Tables, DBFS, External Locations und Feature Store

Der Begriff wird häufig mit benachbarten Objekten aus dem Unity-Catalog-Modell und mit dem älteren Datei-Layer verwechselt. Die folgenden Achsen halten die Grenzen sauber.

ObjektKernrolleVerhältnis zu Volumes
TablesStrukturierte Daten in Zeilen/Spalten (Delta, Iceberg, Views)Gleiche Katalog-Ebene, anderer Datentyp. Volumes halten Files, Tabellen halten Datensätze.
DBFS / File-StorageWorkspace-lokaler Datei-Layer ohne Unity-Catalog-EnforcementVorgänger-Layer. Volumes ersetzen DBFS als governance-fähigen Datei-Layer.
External LocationsPfad + Storage Credential im Unity CatalogTrägt External Volumes (und External Tables). Ein External Volume liegt in einer External Location, ist aber selbst der Katalog-Einstiegspunkt für die Files-API.
Feature StoreML-spezifischer Katalog für Feature Tables mit Online-/Offline-SyncFeature Tables sind strukturierte Feature-Sätze. Volumes speichern unstrukturierte Rohdateien (Bilder, Audio, Dokumente), aus denen Features abgeleitet werden.

Tabellen und Volumes leben nebeneinander im Katalog, adressieren aber unterschiedliche Datenarten. Ein Delta-Table beantwortet Fragen per SQL über Zeilen und Spalten; ein Volume liefert die Rohdatei zurück, aus der ein Job Datensätze extrahiert. Managed Tables und Managed Volumes teilen dieselbe Managed-Storage-Logik des Katalogs oder Schemas; External Tables und External Volumes sitzen beide auf External Locations.

DBFS ist der historische Datei-Layer von Databricks. Er ist workspace-lokal, wird nicht durch Unity Catalog berechtigt und kennt weder Grants noch Audit über den system-Catalog. Volumes lösen DBFS als produktiven Datei-Layer ab; DBFS bleibt für Legacy-Pfade lesbar, ist für neue Workloads unter Unity Catalog aber nicht vorgesehen.

External Locations und Volumes werden gelegentlich gleichgesetzt, sind aber verschiedene Objekte. Die External Location trägt den Cloud-Pfad und das Storage Credential; sie ist die Cloud-Storage-Anbindung. Das Volume ist der Katalog-Einstiegspunkt für Anwender und die Files-API. Ein External Volume verweist auf einen Unterpfad einer External Location. Managed Volumes brauchen keine External Location, weil sie auf dem systemverwalteten Managed Storage liegen.

Der Feature Store ist ein ML-spezifisches Objekt für Feature Tables und ihre Online-/Offline-Synchronisation zwischen Trainings- und Serving-Umgebung. Er speichert strukturierte Feature-Sätze und liegt näher an Tabellen als an Volumes. Volumes sind der Speicherort für die Rohdateien, aus denen Features generiert werden: Bilder für Computer-Vision-Features, Audiodateien für Sprachmodelle, PDFs für RAG-Chunks.

Beispiel: RAG-Dokumenten-Repository und Modell-Artefakte

Ein Data-Team betreibt einen RAG-Assistenten auf einer Databricks-Umgebung. Die Rohdokumente (PDFs, Markdown-Dateien, HTML-Exporte) landen in einem Managed Volume prod.rag.documents. Ein Chunking-Job liest die Dateien über die Files-API, zerlegt sie in Passagen und schreibt die Chunks in eine Delta-Tabelle prod.rag.chunks mit einem Vector-Search-Index. Rechte werden per SQL vergeben:

sql
GRANT READ VOLUME ON VOLUME prod.rag.documents TO `rag_indexer`;
GRANT WRITE VOLUME ON VOLUME prod.rag.documents TO `rag_ingest`;
GRANT SELECT ON TABLE prod.rag.chunks TO `rag_reader`;

Parallel liegt ein External Volume prod.ml.model_artifacts auf einem S3-Bucket, den ein bestehender ML-Prozess bereits nutzt. Serialisierte Modelle und Trainings-Checkpoints landen dort neben der MLflow-Registrierung. Beim Deployment eines Modells liest der Model-Serving-Endpoint das Artefakt über den Katalog-Pfad /Volumes/prod/ml/model_artifacts/<version>/. Zugriffe auf die Rohdokumente und die Modell-Dateien erscheinen in system.access.audit neben den Tabellen-Zugriffen; Lineage-Views zeigen den Weg von der PDF-Datei über die Chunks-Tabelle bis zur beantworteten Anfrage im Assistenten.

Volumes (Unity Catalog) im eigenen Unternehmen umsetzen?

Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.

Gespräch vereinbaren