Unity Catalog Volumesで実現する非テーブルファイル管理｜Managed/External・権限・操作

Delta Lakeのテーブルとして構造化できないファイル（CSV/JSON/Parquetの生ファイル、画像、 MLモデルのアーティファクト、設定ファイルなど）をガバナンス下で管理するのが Unity Catalog Volumesです。従来はDBFSやクラウドストレージの直接マウントで管理していた 非テーブルファイルに対して、UCの権限制御・監査・リネージを適用できます。

この記事では、Volumesの概要、Managed/Externalの違い、作成・操作のSQL/Python例、 DBFSとの比較、権限モデル、そして試験で問われるポイントを整理します。

Volumes概要

VolumeはUnity Catalogの名前空間（Catalog → Schema → Volume）に属するオブジェクトで、 ファイルのコンテナです。テーブルが「行と列」の構造化データを管理するのに対し、 Volumeは「ファイルとディレクトリ」を管理します。

• パス形式: /Volumes/<catalog>/<schema>/<volume>/<path>
• アクセス方式: Spark API / dbutils / SQL / REST API / Unity Catalog UI
• 権限制御: READ VOLUME（読み取り）/ WRITE VOLUME（書き込み）
• 監査: すべてのファイル操作が監査ログに記録される

Managed Volume と External Volume

CREATE VOLUME構文

-- Managed Volume の作成
CREATE VOLUME prod.raw.landing_files
COMMENT 'CSVやJSONの着地ファイルを管理するManaged Volume';

-- External Volume の作成
-- External LocationとStorage Credentialが事前に必要
CREATE EXTERNAL VOLUME prod.raw.external_landing
LOCATION 's3://my-bucket/landing/'
COMMENT '既存S3バケットを参照するExternal Volume';

-- Volume の確認
SHOW VOLUMES IN prod.raw;

-- Volume の詳細
DESCRIBE VOLUME prod.raw.landing_files;

-- Volume の削除
DROP VOLUME prod.raw.landing_files;

ファイル操作

Volume内のファイルはSQL、dbutils、Python APIで操作します。

-- SQL: ファイル一覧の取得
LIST '/Volumes/prod/raw/landing_files/2026/03/';

-- SQL: ファイルのアップロード（ノートブックから）
PUT '/Volumes/prod/raw/landing_files/config.json'
  OVERWRITE;

-- SQL: ファイルの削除
REMOVE '/Volumes/prod/raw/landing_files/old_data.csv';

# Python / dbutils: ファイル一覧
files = dbutils.fs.ls("/Volumes/prod/raw/landing_files/")
for f in files:
    print(f.name, f.size)

# Python: ファイルの読み込み
df = spark.read.csv(
    "/Volumes/prod/raw/landing_files/sales_2026.csv",
    header=True,
    inferSchema=True
)

# Python: ファイルの書き出し
df.write.mode("overwrite").parquet(
    "/Volumes/prod/raw/landing_files/output/"
)

# Python: ファイルのコピー
dbutils.fs.cp(
    "/Volumes/prod/raw/landing_files/config.json",
    "/Volumes/prod/raw/landing_files/backup/config.json"
)

DBFSとの比較

Volumes の権限モデル

Volumeに対する権限は、ボリュームレベルで付与します。 ファイル個別の権限は設定できず、ボリューム単位でのREAD/WRITEが最小粒度です。

-- 読み取り権限の付与
GRANT READ VOLUME ON VOLUME prod.raw.landing_files TO `data-analysts`;

-- 書き込み権限の付与
GRANT WRITE VOLUME ON VOLUME prod.raw.landing_files TO `data-engineers`;

-- Volume作成権限の付与（スキーマレベル）
GRANT CREATE VOLUME ON SCHEMA prod.raw TO `data-engineers`;

-- 権限の確認
SHOW GRANTS ON VOLUME prod.raw.landing_files;

READ VOLUMEはファイルの読み取り・一覧取得を許可し、WRITE VOLUMEはファイルの書き込み・削除を許可します。 なお、テーブルのSELECT権限とは独立しているため、Volume経由でファイルを読むにはREAD VOLUMEが、 テーブルをクエリするにはSELECTがそれぞれ必要です。

実務のユースケース

• ランディングゾーン: 外部システムからのCSV/JSONファイルをVolumeに受け取り、Auto Loaderで取り込む
• MLアーティファクト: 学習済みモデルやスコアリング結果のファイルをVolume に保存
• 設定ファイル: ETLパイプラインのパラメータファイル（YAML/JSON）を一元管理
• 画像/PDF: 非構造化データをUC管理下でチーム間共有

試験で問われるポイント

• Managed VolumeとExternal VolumeのDROP時の挙動の違い
• VolumeのパスがDBFSパスと異なること（/Volumes/...）
• READ VOLUMEとWRITE VOLUMEの権限の粒度（ボリューム単位）
• External VolumeにはExternal Locationの事前作成が必要なこと
• DBFSではなくVolumesが推奨される理由（ガバナンス・監査・ワークスペース横断）

問題で確認

よくある質問