Unity Catalogのボリュームとは

ボリュームは、非表形式のデータセットの管理を可能にするUnity Catalogオブジェクトです。ボリュームは、クラウドオブジェクトストレージの場所にあるストレージの論理ボリュームを表します。ボリュームは、ファイルへのアクセス、保存、管理、および整理のための機能を提供します。

テーブルは表形式のデータセットに対するガバナンスを提供しますが、ボリュームは非表形式のデータセットに対するガバナンスを追加します。ボリュームを使用して、構造化データ、半構造化データ、非構造化データなど、任意の形式のファイルを格納し、アクセスすることができます。

Databricks では、すべての非表形式データへのアクセスを管理するためにボリュームを使用することを推奨しています。テーブルと同様に、ボリュームはマネージドまたは外部にすることができます。

重要

ボリュームをテーブルの場所として使用することはできません。ボリュームは、パス・ベースのデータ・アクセスのみを目的としています。 Unity Catalog で表形式のデータを操作する場合は、テーブルを使用します。

ボリュームの操作に関する詳細情報については、次の記事を参照してください。

注：

ボリュームを操作する場合は、カタログエクスプローラーなどのDatabricksのUI を使用していない限り、SQLウェアハウスあるいはDatabricks Runtime LTS13.3 以上を実行しているクラスターを使用する必要があります。

マネージドボリュームとは

マネージドボリュームは、含まれているスキーマのマネージドストレージロケーション内に作成された、Unity Catalog によって管理されるストレージボリュームです。Unity Catalog でマネージドストレージロケーションを指定するを参照してください。

マネージドボリュームを使用すると、外部ロケーションやストレージ資格情報のオーバーヘッドなしに、ファイルを操作するためのマネージドストレージを作成できます。マネージドボリュームの作成時に場所を指定する必要はなく、マネージドボリューム内のデータに対するすべてのファイルアクセスは、Unity Catalog によって管理されるパスを介して行われます。

外部ボリュームとは

外部ボリュームは、 Unity Catalog管理のストレージ資格情報を使用して外部ロケーション内のディレクトリに対して登録された、Unity Catalog管理のストレージボリュームです。

Unity Catalog は、外部ボリューム内のファイルのライフサイクルとレイアウトを管理しません。外部ボリュームを削除しても、Unity Catalog は基になるデータを削除しません。

ボリューム内のファイルへのアクセスに使用されるパスは何か

ボリュームは、 Unity Catalogの 3 レベルの名前空間 (catalog.schema.volume) の 3 番目のレベルにあります。

ボリュームにアクセスするためのパスは、Apache Spark、SQL、Python、その他の言語やライブラリを使用する場合でも同じです。これは、Databricks ワークスペースにバインドされたオブジェクトストレージ内のファイルに対する従来のアクセスパターンとは異なります。

ボリューム内のファイルにアクセスするためのパスは、次の形式を使用します。

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

Databricks は、Apache Spark を使用する場合にオプションのdbfs:/スキームもサポートしているため、次のパスも機能します。

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

パス内のシーケンス/<catalog>/<schema>/<volume>は、ファイルに関連付けられた 3 つの Unity Catalog オブジェクト名に対応します。これらのパス要素は読み取り専用であり、ユーザーが直接書き込むことができないため、ファイルシステム操作を使用してこれらのディレクトリを作成または削除することはできません。これらは自動的に管理され、対応するUnity Catalogエンティティと同期されます。

注：

クラウドストレージ URI を使用して外部ボリューム内のデータにアクセスすることもできます。

ボリュームの予約済みパス

ボリュームでは、ボリュームへのアクセスに使用される次の予約済みパスが導入されています。

dbfs:/Volumes
/Volumes

注：

パスは、 Apache Spark APIsおよび dbutils からのこれらのパスの潜在的なタイポのために予約されており、dbfs:/ が先行するかどうかに関係なく、/volumes、/Volume、/volume が含まれます。パス /dbfs/Volumes も予約されていますが、ボリュームへのアクセスには使用できません。

ボリュームは、Databricks Runtime 13.3 LTS 以降でのみサポートされます。 Databricks Runtime 12.2 LTS 以前では、/Volumes パスに対する操作は成功する可能性がありますが、コンピュートクラスターにアタッチされたエフェメラルストレージディスクにのみデータを書き込むことができ、期待どおりにデータを Unity Catalog ボリュームに永続化することはできません。

重要

DBFSルートの予約済みパスに既存のデータが保存されている場合は、サポートチケットを提出してこのデータに一時的にアクセスし、別の場所に移動することができます。

制限事項

Unity Catalogボリュームと対話するには、 Unity Catalog対応のコンピュートを使用する必要があります。ボリュームは、すべてのワークロードをサポートしているわけではありません。

次の表は、Databricks Runtime のバージョンに基づく Unity Catalog のボリューム制限の概要を示しています。

Databricks Runtimeのバージョン	制限事項
14.3 LTS以上	シングル・ユーザー・クラスタリングでは、 Scalaのスレッドおよびサブプロセスからボリュームにアクセスすることはできません。
14.2 以下	共有アクセスモードで構成されたコンピュートでは、UDF を使用してボリュームにアクセスすることはできません。 Python と Scala はどちらもドライバーから FUSE にアクセスできますが、エグゼキューターからはアクセスできません。 I/O 操作を実行する Scala コードはドライバー上では実行できますが、エグゼキューター上では実行できません。シングルユーザーアクセスモードで構成されたコンピュートでは、 Scalaの FUSE、ボリュームパスを使用してデータにアクセスするScala IO コード、またはScala UDF はサポートされません。 Python UDF はシングルユーザーアクセスモードでサポートされます。
サポートされているすべての Databricks Runtime バージョン	ボリュームは、エグゼキューターに配布された`dbutils.fs`コマンドをサポートしていません。 Unity Catalog UDF はボリュームファイルパスへのアクセスをサポートしていません。 RDD からボリュームにアクセスすることはできません。 spark-submit は、ボリュームに格納されている JAR では使用できません。ホイールまたは JAR ファイル内のボリュームパスを介してアクセスされる他のライブラリへの依存関係を定義することはできません。 `/Volumes/<catalog-name>` パターンや `/Volumes/<catalog-name>/<schema-name>` パターンを使用して Unity Catalog オブジェクトを一覧表示することはできません。ボリューム名を含む完全修飾パス ( `Volumes/<catalog-name>/<schema-name>/<volume-name>`の形式) を使用する必要があります。例えば `dbutils.fs.ls("/Volumes/MyCatalog/MySchema/MyVolume")` REST API の DBFS エンドポイントはボリュームパスをサポートしていません。クラスターログ配信の宛先としてボリュームを指定することはできません。 `%sh mv` は、ボリューム間でのファイルの移動ではサポートされていません。代わりに `dbutils.fs.mv` または `%sh cp` を使用してください。ボリュームを持つカスタム Hadoop ファイルシステムは作成できません。たとえば、 `new Path("dbfs:/Volumes/main/default/test-volume/file.txt")` を使用して `org.apache.hadoop.fs.path` オブジェクトを作成することはできません。