Unity Catalog ボリュームとは

ボリュームは、表形式以外のデータセットに対するガバナンスを可能にする Unity Catalog オブジェクトです。 ボリュームは、クラウド・オブジェクト・ストレージ・ロケーション内のストレージの論理ボリュームを表します。 ボリュームは、ファイルへのアクセス、保存、管理、および整理の機能を提供します。

テーブルは表形式データを管理しますが、ボリュームは構造化、半構造化、非構造化など、あらゆる形式の非表形式データを管理します。

Databricks では、ボリュームを使用して、すべての非表形式データへのアクセスを管理することをお勧めします。ボリュームには、次の 2 つのタイプがあります。

• 管理対象ボリューム: シンプルな Databricks マネージド ストレージ用。
• 外部ボリューム: 既存のクラウド・オブジェクト・ストレージの場所にガバナンスを追加します。

ボリュームの使用例

ボリュームの使用例は次のとおりです。

• 外部システムによって生成された生データのランディングエリアを登録して、ETLパイプラインやその他のデータエンジニアリング活動の初期段階での処理をサポートします。
• 登録する インジェストのステージング場所。 たとえば、Auto Loader、 COPY INTO、または CTAS (CREATE TABLE AS) ステートメントを使用します。
• data scientists、データアナリスト、機械学習エンジニアが探索的データ分析やその他のデータサイエンス タスクの一部として使用するためのファイル ストレージの場所を提供します。
• Databricks ユーザーに、他のシステムによって生成およびクラウド ストレージに格納された任意のファイルへのアクセスを許可します。たとえば、監視システムやIoTデバイスによってキャプチャされた非構造化データ(画像、オーディオ、ビデオ、PDFファイルなど)の大規模なコレクションや、ローカルの依存関係管理システムやCI/CDパイプラインからエクスポートされたライブラリファイル(JARファイルやPython wheelファイル)などです。
• ログ記録ファイルやチェックポイント設定ファイルなどの運用データを格納します。

ボリュームの操作のデモについては、「 Unity Catalog ボリュームを使用したファイル、イメージ、およびデータの取得の簡略化」を参照してください。

important

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

管理ボリュームと外部ボリューム

マネージドボリュームと外部ボリュームは、 Databricks ツール、UI、および APIsを使用する場合に、ほぼ同じエクスペリエンスを提供します。 主な違いは、保管場所、ライフサイクル、および制御に関連しています。

機能	管理対象ボリューム	外部ボリューム
ストレージロケーション	スキーマの UC 管理ストレージ内に作成されます。	既存のクラウド・オブジェクト・ストレージ・パスに対して登録されている
データライフサイクル	UC はレイアウトと削除を管理します (削除時に 7 日間保持)	ボリュームを削除しても、データはクラウドストレージに残ります
アクセス制御	すべてのアクセスはUCを経由します	UC はアクセスを管理しますが、外部ツールは直接 URI を使用できます
移行が必要ですか?	No	いいえ:既存のストレージ・パスをそのまま使用します
一般的な使用例	Databricks のみのワークロードの最も簡単なオプション	Databricks と外部システム アクセスの混在

管理対象ボリュームを使用する理由

管理対象ボリュームには、次の利点があります。

• Databricksワークロードのデフォルト選択。
• クラウド認証情報やストレージパスを手動で管理する必要はありません。
• 管理されたストレージの場所を迅速に作成するための最も簡単なオプション。

外部ボリュームを使用する理由

外部ボリュームを使用すると、Unity Catalog データガバナンスを既存のクラウドオブジェクトストレージディレクトリに追加できます。 外部ボリュームの使用例には、次のようなものがあります。

• データのコピーを必要とせずに、データが既に存在する場所にガバナンスを追加します。
• Databricks によって取り込まれるかアクセスする必要がある他のシステムによって生成されたファイルを管理します。
• 他のシステムからクラウドオブジェクトストレージから直接アクセスする必要がある Databricks によって生成されたデータを管理します。

Databricks では、外部ボリュームを使用して、Databricks に加えて外部システムによって読み書きされる非表形式データ ファイルを格納することをお勧めします。Unity Catalog は、外部システムからのクラウドオブジェクトストレージに対して直接実行される読み取りと書き込みを管理しないため、データガバナンスポリシーが外部 Databricksで尊重されるように、クラウドアカウントで追加のポリシーと資格情報を構成する必要があります。

ボリューム内のファイルにアクセスするためのパス

ボリュームは、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

注記

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

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

important

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

コンピュートの要件

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

制限

Unity CatalogUnity Catalogボリュームを操作するには、対応コンピュートを使用する必要があります。

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

Databricks Runtimeのバージョン	制限事項
サポートされているすべての Databricks Runtime バージョン	ボリュームは、エグゼキューターに配布される dbutils.fs コマンドをサポートしていません。 Unity Catalog UDF では、ボリューム ファイル パスへのアクセスはサポートされていません。 RDD からボリュームにアクセスすることはできません。 ボリュームに格納されている JAR では、従来の spark-submit タスクを使用することはできません。代わりに、 JAR タスクを使用してください。 ジョブのタスク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") %sh mv は、ボリューム間でのファイル移動はサポートされていません。 代わりに dbutils.fs.mv または %sh cp を使用してください。 ボリュームを使用してカスタム Hadoop ファイルシステムを作成することはできません。たとえば、 new Path("dbfs:/Volumes/main/default/test-volume/file.txt") を使用して org.apache.hadoop.fs.path オブジェクトを作成しても機能しません。
14.3 LTS以上	専用アクセスモード (以前のシングルユーザーアクセスモード) を使用するコンピュートでは、 Scalaのスレッドおよびサブプロセスからボリュームにアクセスできません。
14.2 以下	標準アクセス モード (以前の共有アクセス モード) で構成されたコンピュートでは、UDF を使用してボリュームにアクセスすることはできません。 Python と Scala はどちらもドライバーから FUSE にアクセスできますが、エグゼキューターからはアクセスできません。 I/O 操作を実行する Scala コードは、ドライバーでは実行できますが、エグゼキューターでは実行できません。 専用アクセスモードで構成されたコンピュートでは、 Scalaでの FUSE、ボリュームパスを使用してデータにアクセスする Scala IO コード、または Scala UDF はサポートされていません。 Python UDF は、専用アクセスモードでサポートされています。

次のステップ

次の記事では、ボリュームの操作に関する詳細情報を提供します。

• Unity Catalog ボリュームを作成および管理します。
• ボリューム内のファイルを管理します。
• ストレージを探索し、データファイルを見つけます。
• 管理対象ボリュームと外部ボリューム。
• Unity Catalog ボリュームの特権。