Teilen über

Was sind Unity Catalog-Volumes?

Volumes sind Unity Catalog-Objekte, die Governance über nicht tabellarische Datasets ermöglichen. Volumes stellen ein logisches Speichervolume an einem Cloudobjektspeicherort dar. Volumes bieten Funktionen zum Zugreifen auf Dateien sowie zum Speichern, Verwalten und Organisieren von Dateien.

Tabellen steuern zwar tabellarische Daten, volumes steuern jedoch nicht tabellarische Daten eines beliebigen Formats, einschließlich strukturierter, halbstrukturierter oder unstrukturierter Daten.

Databricks empfiehlt die Verwendung von Volumes zum Verwalten des Zugriffs auf alle Nicht-Tabellendaten. Volumes sind in zwei Typen verfügbar:

  • Verwaltete Volumes: Für einfachen databricks-verwalteten Speicher.
  • Externe Volumes: Zum Hinzufügen von Governance zu vorhandenen Cloudobjektspeicherorten.

Anwendungsfälle für Volumes

Anwendungsfälle für Volumes umfassen:

  • Registrieren von Zielbereichen für Rohdaten, die von externen Systemen generiert werden, um die Verarbeitung in frühen Phasen von ETL-Pipelines und anderen Datentechnikaktivitäten zu unterstützen.
  • Registrieren von Stagingspeicherorten für die Aufnahme. Verwenden Sie z. B. Auto Loader-, COPY INTOoder CTAS(CREATE TABLE AS)-Anweisungen.
  • Stellen Sie Dateispeicherorte für Datenwissenschaftler, Datenanalysten und Machine Learning-Ingenieure bereit, die als Teil ihrer explorativen Datenanalyse und anderen Data Science-Aufgaben verwendet werden können.
  • Gewähren Sie Azure Databricks-Benutzern Zugriff auf beliebige Dateien, die von anderen Systemen im Cloudspeicher erzeugt und gespeichert wurden. Beispielsweise große Sammlungen von unstrukturierten Daten (z. B. Bild-, Audio-, Video- und PDF-Dateien), die von Überwachungssystemen oder IoT-Geräten erfasst werden, oder Bibliotheksdateien (JARs und Python-Raddateien), die aus lokalen Abhängigkeitsverwaltungssystemen oder CI/CD-Pipelines exportiert werden.
  • Speichern Sie Betriebsdaten, z. B. Protokollierungs- oder Prüfpunktdateien.

Eine Demo zum Arbeiten mit Volumes finden Sie unter Vereinfachen von Datei-, Bild- und Datenabrufen mit Unity-Katalogvolumes.

Important

Sie können Dateien in Volumes nicht als Tabellen im Unity-Katalog registrieren. Volumes sind nur für den pfadbasierten Datenzugriff vorgesehen. Verwenden Sie Tabellen, wenn Sie im Unity Catalog mit Tabellendaten arbeiten möchten.

Verwaltete und externe Volumes

Verwaltete und externe Volumes bieten nahezu identische Erfahrungen bei verwendung von Azure Databricks-Tools, UIs und APIs. Die wichtigsten Unterschiede beziehen sich auf Speicherort, Lebenszyklus und Kontrolle:

Merkmal Verwaltete Volumes Externe Volumes
Lagerort Erstellt im UC-verwalteten Speicher für das Schema Registriert für einen vorhandenen Cloudobjektspeicherpfad
Datenlebenszyklus UC verwaltet Layout und Löschung (7-Tage-Aufbewahrung beim Löschen) Daten verbleiben im Cloudspeicher, wenn Sie das Volume ablegen
Zugriffskontrolle Der gesamte Zugriff erfolgt über UC UC steuert den Zugriff, aber externe Tools können direkte URIs verwenden
Migration erforderlich? Nein Nein – Vorhandene Speicherpfade as-is verwenden
Typischer Anwendungsfall Einfachste Option für nur Databricks-Workloads Gemischter Databricks- und externer Systemzugriff

Warum verwaltete Volumes verwenden?

Verwaltete Volumes haben die folgenden Vorteile:

  • Standardauswahl für Databricks-Workloads.
  • Sie müssen keine Cloudanmeldeinformationen oder Speicherpfade manuell verwalten.
  • Die einfachste Option zum schnellen Erstellen geregelter Speicherorte.

Gründe für die Verwendung externer Volumes

Mit externen Volumes können Sie Unity Catalog Data Governance zu vorhandenen Cloudobjektspeicherverzeichnissen hinzufügen. Einige Anwendungsfälle für externe Volumes umfassen Folgendes:

  • Hinzufügen von Governance, bei denen sich daten bereits befinden, ohne dass Daten kopiert werden müssen.
  • Verwalten von Dateien, die von anderen Systemen erstellt werden, die von Azure Databricks aufgenommen oder darauf zugegriffen werden müssen.
  • Verwalten von Daten, die von Azure Databricks erstellt werden, auf die direkt über den Cloudobjektspeicher von anderen Systemen zugegriffen werden muss.

Databricks empfiehlt die Verwendung externer Volumes zum Speichern nicht tabellarischer Datendateien, die von externen Systemen zusätzlich zu Azure Databricks gelesen oder geschrieben werden. Unity Catalog steuert keine Lese- und Schreibvorgänge, die direkt gegen cloudobjektspeicher von externen Systemen ausgeführt werden. Daher müssen Sie zusätzliche Richtlinien und Anmeldeinformationen in Ihrem Cloudkonto konfigurieren, damit Datengovernancerichtlinien außerhalb von Azure Databricks beachtet werden.

Pfad für den Zugriff auf Dateien in einem Volume

Volumes befinden sich auf der dritten Ebene des Namespace mit drei Ebenen in Unity Catalog (catalog.schema.volume):

Objektmodell-Diagramm von Unity Catalog mit Fokus auf Volumes

Der Pfad für den Zugriff auf Volumes ist identisch, unabhängig davon, ob Sie Apache Spark, SQL, Python oder andere Sprachen und Bibliotheken verwenden. Dies unterscheidet sich von älteren Zugriffsmustern für Dateien im Objektspeicher, der an einen Azure Databricks-Arbeitsbereich gebunden ist.

Der Pfad für den Zugriff auf Dateien in Volumes verwendet das folgende Format:

/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>

Azure Databricks unterstützt außerdem ein optionales dbfs:/-Schema bei der Arbeit mit Apache Spark, sodass der folgende Pfad ebenfalls funktioniert:

dbfs:/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>

Der /<catalog>/<schema>/<volume> Teil des Pfads ist den drei Unity Catalog-Objektnamen für die Datei zugeordnet. Diese Verzeichnisse sind schreibgeschützt und werden automatisch vom Unity-Katalog verwaltet. Sie können sie nicht mit Dateisystembefehlen erstellen oder löschen.

Note

Sie können auch auf Daten in externen Volumes zugreifen, indem Sie Cloudspeicher-URIs verwenden.

Reservierte Pfade für Volumes

Volumes führen die folgenden reservierten Pfade ein, die für den Zugriff auf Volumes verwendet werden:

  • dbfs:/Volumes
  • /Volumes

Note

Pfade sind auch für potenzielle Tippfehler für diese Pfade aus Apache Spark-APIs und dbutils, einschließlich /volumes, /Volume, /volume reserviert, unabhängig davon, ob ihnen dbfs:/ vorangestellt ist. Der Pfad /dbfs/Volumes ist auch reserviert, kann jedoch nicht für den Zugriff auf Volumes verwendet werden.

Volumes werden erst ab Databricks Runtime 13.3 LTS unterstützt. In Databricks Runtime 12.2 LTS und darunter können Vorgänge mit /Volumes Pfaden erfolgreich sein, sie können jedoch nur Daten in kurzlebige Speicherdatenträger schreiben, die an Computecluster angefügt sind, anstatt Daten wie erwartet auf Unity-Katalogvolumes zu speichern.

Important

Wenn Sie bereits vorhandene Daten in einem reservierten Pfad im DBFS-Stamm gespeichert haben, speichern Sie ein Supportticket, um temporären Zugriff auf diese Daten zu erhalten, um sie an einen anderen Speicherort zu verschieben.

Computeanforderungen

Wenn Sie mit Volumes arbeiten, müssen Sie ein SQL Warehouse oder einen Cluster verwenden, in dem Databricks Runtime 13.3 LTS oder höher ausgeführt wird, es sei denn, Sie verwenden Azure Databricks-UIs wie den Katalog-Explorer.

Limitations

Um mit Unity Catalog-Volumes zu interagieren, müssen Sie Unity Catalog-fähiges Compute verwenden.

In der folgenden Tabelle sind die Volumeneinschränkungen des Unity-Katalogs basierend auf der Version von Databricks Runtime aufgeführt:

Databricks Runtime-Version Limitations
Alle unterstützten Databricks Runtime-Versionen
  • Volumes unterstützen dbutils.fs keine Befehle, die an Executoren verteilt werden.
  • Unity Catalog UDFs unterstützen nicht den Zugriff auf Volumedateipfade.
  • Sie können nicht über RDDs auf Volumes zugreifen.
  • Sie können die Legacy-Spark-Submit-Aufgabe nicht mit in einem Volume gespeicherten JARs verwenden. Verwenden Sie stattdessen die JAR-Aufgabe. Siehe JAR-Task für Aufträge.
  • Sie können keine Abhängigkeiten für andere Bibliotheken definieren, auf die über Volumepfade innerhalb eines Rads oder einer JAR-Datei zugegriffen wird.
  • Sie können Unity Catalog-Objekte nicht mit den /Volumes/<catalog-name> Mustern oder /Volumes/<catalog-name>/<schema-name> Mustern auflisten. Sie müssen einen vollständig qualifizierten Pfad verwenden, der einen Volume-Name im Formular Volumes/<catalog-name>/<schema-name>/<volume-name> enthält. Beispiel: dbutils.fs.ls("/Volumes/MyCatalog/MySchema/MyVolume")
  • %sh mv wird für das Verschieben von Dateien zwischen Volumes nicht unterstützt. Verwenden Sie stattdessen dbutils.fs.mv oder %sh cp.
  • Sie können kein benutzerdefiniertes Hadoop-Dateisystem mit Volumes erstellen. Die Verwendung new Path("dbfs:/Volumes/main/default/test-volume/file.txt") zum Erstellen eines org.apache.hadoop.fs.path Objekts funktioniert beispielsweise nicht.
  • Volumes sind in Azure-Government-Regionen oder Arbeitsbereichen mit FedRAMP-Konformität nicht verfügbar.
  • Sie müssen das Pfadformat mit einem dbfs:/-Schema im Konfigurationsbereich der Azure Data Factory-Bibliothek verwenden, z. B. dbfs:/Volumes/<catalog-name>/<schema-name>/<volume-name>/file.
14.3 LTS und höher
  • Bei der Berechnung mit dediziertem Zugriffsmodus (vormals Einzelbenutzerzugriffsmodus) können Sie nicht von Threads und Unterprozessen in Scala auf Volumes zugreifen.
14.2 und darunter
  • Bei einem Rechner, der mit dem Standardzugriffsmodus (früher freigegebener Zugriffsmodus) konfiguriert ist, können Sie UDFs nicht verwenden, um auf Volumes zuzugreifen.
    • Sowohl Python als auch Scala haben Zugriff auf FUSE über den Treiber, aber nicht über Executors.
    • Scala-Code, der E/A-Vorgänge ausführt, kann auf dem Treiber ausgeführt werden, aber nicht auf den Executors.
  • Bei der Berechnung, die mit dediziertem Zugriffsmodus konfiguriert ist, gibt es keine Unterstützung für FUSE in Scala, Scala IO-Code, der auf Daten mithilfe von Volumepfaden oder Scala UDFs zugreift. Python UDFs werden im dedizierten Zugriffsmodus unterstützt.

Nächste Schritte

Die folgenden Artikel enthalten weitere Informationen zur Arbeit mit Volumes:

  • Last updated on