テーマ切替
Associate 学習教材 ⑤ ガバナンス・セキュリティ（Unity Catalog）
Databricks 公式ドキュメント（日本語版）の内容を、重要用語・概念を漏らさずまとめた自習用教材です。 参照した公式ページ:
- Unity Catalog とは: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/
- Azure Databricks のカタログとは: https://learn.microsoft.com/ja-jp/azure/databricks/catalogs/
- Unity カタログを始めよう（get-started）: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/get-started
- Unity Catalog のボリュームとは: https://learn.microsoft.com/ja-jp/azure/databricks/volumes/
- （補足参照）セキュリティ保護可能なオブジェクトのリファレンス: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/securable-objects
- （補足参照）特権の管理（GRANT/REVOKE）: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/manage-privileges/
- （補足参照）特権リファレンス: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/access-control/privileges-reference
- （補足参照）マネージド資産と外部資産の比較: https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/managed-versus-external
- （補足参照）Unity カタログを使用してクラウド ストレージに接続する: https://learn.microsoft.com/ja-jp/azure/databricks/connect/unity-catalog/cloud-storage/
1. このセクションの概要
Unity Catalog（ユニティ カタログ） は、Azure Databricks に組み込まれた「データと AI の統合ガバナンス レイヤー（unified governance layer for data and AI）」です。ワークスペースで有効にすると、Unity Catalog はワークスペース内のすべてのデータ操作・AI 操作の基盤として自動的に動作し、次の 4 つを一元的に提供します。
- 一元的なアクセス制御（centralized access control） … テーブルへのクエリやモデル呼び出し時にアクセス制御を適用する。
- データ系列 / リネージ（data lineage） … データや AI 資産が使われたときに、どのように流れ・接続されるかを自動追跡する。
- 監査（audit） … 監査のためにアクティビティをログに記録する。
- データ検出（data discovery） … 登録されている資産を発見・管理できる。
重要ポイント:
- Unity Catalog が管理するオブジェクトは、Catalog Explorer（カタログ エクスプローラー）、SQL、Databricks CLI、REST API で操作する。
- Unity Catalog は 2023 年 11 月 9 日以降に作成されたすべての Azure Databricks ワークスペースで自動的に有効になる。それより前に作成されたワークスペースはアップグレードが必要。
- Unity Catalog はオープンソース実装としても提供されている（Unity Catalog GitHub リポジトリ）。
- データは 3 レベル（3 階層）の名前空間
catalog.schema.objectで整理される。
この試験セクションで押さえるべき中心テーマは、オブジェクト階層（メタストア → カタログ → スキーマ → テーブル/ビュー/ボリューム/関数/モデル）、3 階層ネームスペース、権限モデル（GRANT / REVOKE と特権の継承）、マネージドと外部の違い、ボリューム、ストレージ資格情報・外部ロケーションです。
2. 重要用語集
| 用語（日本語） | English | 説明 |
|---|---|---|
| Unity カタログ | Unity Catalog | Azure Databricks に組み込まれたデータと AI の統合ガバナンス レイヤー。アクセス制御・リネージ・監査・検出を一元的に提供する。 |
| セキュリティ保護可能なオブジェクト | Securable object | ユーザー・サービスプリンシパル・グループに権限を付与できるオブジェクトの総称。Unity Catalog の全資産はこれとしてモデル化される。 |
| メタストア | Metastore | Unity Catalog 階層の最上位のセキュリティ保護可能オブジェクト。1 つのクラウドリージョンに登録された全オブジェクトを含む。Databricks アカウントにはリージョンごとに 1 つのメタストアを持つ。 |
| カタログ | Catalog | データ組織の主要単位。3 階層ネームスペースの第 1 レイヤー。スキーマを含むコンテナー オブジェクト。 |
| スキーマ（データベース） | Schema (Database) | カタログ内の第 2 レイヤー。テーブル・ビュー・ボリューム・関数・モデルを含むコンテナー オブジェクト。「データベース」とも呼ぶ。 |
| テーブル | Table | 行と列で構成される構造化データのコレクション。3 階層ネームスペースの第 3 レイヤーの代表。 |
| ビュー | View | 1 つ以上のテーブル/ビューに対して保存された読み取り専用の SQL クエリ。クエリ結果を毎回再計算する。 |
| マテリアライズド ビュー | Materialized view | クエリ結果を事前計算して格納するビュー。REFRESH で更新をトリガーできる。 |
| ボリューム | Volume | 表形式でない（非構造化・半構造化）データを管理する Unity Catalog オブジェクト。クラウド ストレージの論理ボリュームを表す。 |
| 関数 | Function | 再利用可能な実行ロジック。UDF・ストアドプロシージャ・登録済みモデルを含む。 |
| モデル | Model | Unity Catalog に登録された（MLflow）AI モデル。実装上は「関数の一種」として扱われる。 |
| 3 階層ネームスペース | Three-level namespace | catalog.schema.object（例: catalog.schema.table）でオブジェクトを参照する仕組み。 |
| マネージド（管理） | Managed | Unity Catalog がガバナンスと基盤ファイルストレージのライフサイクル（配置・最適化・削除）の両方を管理する方式。テーブルとボリュームに適用。 |
| 外部（External） | External | Unity Catalog がガバナンスのみを管理し、ファイルストレージのライフサイクルはユーザー/外部システムが管理する方式。テーブルとボリュームに適用。 |
| GRANT / REVOKE | GRANT / REVOKE | 特権を付与（GRANT）・取り消す（REVOKE）SQL コマンド。SHOW GRANTS で確認できる。 |
| 特権 | Privilege | オブジェクトに対して実行できる操作の権限（例: SELECT, MODIFY, USE CATALOG）。 |
| 特権の継承 | Privilege inheritance | カタログ/スキーマなど親オブジェクトに付与した特権が、現在および将来の子オブジェクトに自動的に適用される仕組み。 |
| 使用特権 | Usage privileges | USE CATALOG / USE SCHEMA。オブジェクトを操作する「入り口」となる特権。単独ではデータにアクセスできない。 |
| 所有者 / 所有権 | Owner / Ownership | 各セキュリティ保護可能オブジェクトに 1 つ存在する。所有者はそのオブジェクトの全権限を持ち、他者に権限付与できる。 |
| プリンシパル | Principal | 権限を付与する相手。ユーザー（user）・グループ（group）・サービスプリンシパル（service principal, applicationId で表す）。 |
| データ系列 / リネージ | Data lineage | データや AI 資産のフローを列レベルまで自動追跡する機能。 |
| 監査ログ | Audit log | すべてのデータアクセスとシステム活動を記録する。監査ログ システム テーブルで参照する。 |
| ストレージ資格情報 | Storage credential | クラウド ストレージにアクセスするための認証情報（Azure マネージド ID / サービスプリンシパルなど）を表すオブジェクト。 |
| 外部ロケーション | External location | クラウド ストレージ パス + ストレージ資格情報を組み合わせたオブジェクト。特定パスへのアクセスを制御する。 |
| マネージド ストレージの場所 | Managed storage location | マネージド テーブル/ボリュームのデータファイルを格納するクラウド上の指定パス。メタストア/カタログ/スキーマ レベルで設定可能。 |
| メタストア管理者 | Metastore admin | 任意のロール。メタストア内全オブジェクトの所有権取得やワークスペース割り当て管理などができる。 |
| ワークスペース カタログ | Workspace catalog | 新規ワークスペース作成時に自動プロビジョニングされる既定カタログ。 |
hive_metastore | hive_metastore catalog | レガシ Hive メタストア管理下のデータを表すカタログ。非推奨で Unity Catalog への移行が推奨される。 |
| ワークスペース-カタログ バインド | Workspace-catalog binding | カタログのアクセスを特定ワークスペース境界に制限する仕組み。 |
3. 詳細解説
3-1. Unity Catalog とは（統合ガバナンス・自動アクセス制御・リネージ・監査）
Unity Catalog は Azure Databricks に組み込まれたデータと AI の統合ガバナンス レイヤーです。ワークスペースに対して有効化すると、以下がすべてのデータ/AI 操作の下で自動的に動作します。
- アクセス制御の適用 … テーブルへのクエリやモデル呼び出しのたびにアクセス制御をチェックする。
- 系列（lineage）の追跡 … データ/AI 資産が使われたときにフローを記録する。
- 監査ログの記録 … 監査目的でアクティビティをログに残す。
主な機能領域（公式の機能一覧）:
| 機能 | 内容 |
|---|---|
| アクセスの制御（Access control） | 特権、属性ベースのポリシー（ABAC）、行フィルター・列マスク、ワークスペース バインドでアクセスを管理。 |
| 検出（Discovery） | Catalog Explorer で登録済みのデータ/AI 資産を発見・管理。 |
| 系列（Lineage） | ソースデータからモデル・サービス・ダッシュボードまで、資産の流れと接続を自動追跡。 |
| 監査（Auditing） | 監査ログ システム テーブルで全データアクセスとシステム活動の完全な記録を保持。 |
| データの分類（Data classification） | カタログ内の機密データ（PII・財務情報・資格情報など）を自動分類・タグ付け。AI エージェントがスキャンする。 |
| データ品質の監視 | 組み込みのプロファイリングとアラートで異常を検出。異常検出とテーブルレベルのデータプロファイリング。 |
| データ共有（Data sharing） | オープンな OpenSharing プロトコルで組織・クラウド間の安全なライブ共有。 |
| AI ガバナンス | Unity AI Gateway で AI 資産・AI トラフィックを管理。LLM エンドポイント・エージェント・MCP サーバーにアクセス制御/監査/可観測性を適用。 |
高度なガバナンス機能（get-started ページの「拡張」）:
- 属性ベースのアクセス制御（ABAC: Attribute-Based Access Control） … データの属性とアクセスするユーザーに基づいて、動的できめ細かいポリシーを定義。行レベル フィルターと列マスクを自動適用（例: 特定リージョン外のユーザーに機密列を非表示、PII をマスク）。
- データ分類（Data classification） … 分類後のタグを ABAC ポリシーに直接統合でき、「オブジェクトごと」ではなく「データの中身」に基づいて制御を適用できる。
- データ品質の監視 … 過去パターンを使い鮮度・完全性を自動監視。
- データ系列（Data lineage） … テーブル・ノートブック・ジョブ・パイプライン間のデータフローを列レベルまで自動キャプチャ。
- Unity AI Gateway … Unity Catalog ガバナンスを AI に拡張。
3-2. オブジェクト階層（メタストア > カタログ > スキーマ > テーブル/ビュー/ボリューム/関数/モデル）
Unity Catalog の全資産はセキュリティ保護可能なオブジェクト（securable object）としてモデル化されます。これは「ユーザー・サービスプリンシパル・グループに権限を付与できるオブジェクト」です。オブジェクトは階層構造をとり、この階層がアクセス制御の基礎になります。
データ資産の階層（3 レベル ネームスペース）:
メタストア (Metastore) ← 最上位。リージョンごとに 1 つ
└─ カタログ (Catalog) … 第 1 レイヤー
└─ スキーマ (Schema/Database) … 第 2 レイヤー
├─ テーブル (Table) … 第 3 レイヤー
├─ ビュー (View)
├─ ボリューム (Volume)
├─ 関数 (Function)
├─ モデル (Model)
├─ サービス (Service: Model serving / MCP)
└─ シークレット (Secret)各オブジェクトの定義:
- メタストア（Metastore） … 最上位のセキュリティ保護可能オブジェクト。1 つのクラウド リージョンをスコープとし、そのリージョンの Unity Catalog に登録された全オブジェクトを含む。1 つのメタストアを同一リージョン内の複数のワークスペースにアタッチできる。メタストアで付与した権限は、そのメタストアにアタッチされたすべてのワークスペースに適用される。
- カタログ（Catalog） … データ資産の最上位レイヤー。組織単位やソフトウェア開発ライフサイクル（開発/本番など）でデータを整理する単位。コンテナー オブジェクト。
- スキーマ（Schema / Database） … カタログ内の第 2 レイヤー。単一のユースケース・プロジェクト・チームサンドボックスを表すことが多い。コンテナー オブジェクト。
- テーブル（Table） … 行と列で構成される構造化データ。
SELECT（読み取り）/MODIFY（書き込み: 挿入・更新・削除）で制御。 - ビュー（View） … テーブル/ビューに対する保存済み読み取り専用クエリ。ビューのクエリ元テーブルへの権限は不要で、ビュー所有者の権限で基盤テーブルを解決する（行/列アクセス制限に有用）。
- マテリアライズド ビュー / メトリック ビュー … 事前計算結果を格納するビュー / 再利用可能なメトリック定義。
- ボリューム（Volume） … クラウド ストレージ内の非構造化データ。ファイルレベルの読み書きを提供（SQL クエリ操作は不可）。
READ VOLUME/WRITE VOLUMEで制御。 - 関数（Function） … 再利用可能な実行ロジック。UDF・ストアドプロシージャ・登録済みモデルを含む。
EXECUTEで実行。 - モデル（Model） … Unity Catalog に登録されたバージョン管理される AI モデル（MLflow）。複数のモデル バージョンを保持するコンテナー。関数の一種として実装される。
- サービス（Service） … 管理可能な AI 資産（モデルサービング/MCP サービス）。ベータ。
- シークレット（Secret） … 資格情報や API トークンなどの機密値。3 階層ネームスペース
catalog.schema.secretの一部。
メタストアのすぐ下に配置される（データ以外の）オブジェクト:
これらは 3 階層ネームスペースには入らず、メタストア直下に存在します。
- ストレージ資格情報（Storage credential） … クラウド ストレージへのアクセスに必要な認証情報。
- 外部ロケーション / 外部の場所（External location） … クラウド ストレージの特定パス + それにアクセスするストレージ資格情報への参照。
- 外部メタデータ（External metadata） … 外部システムのカスタム系列関係を定義。
- サービス資格情報（Service credential） … 外部クラウドサービスにアクセスする認証情報（ストレージ資格情報とは別物）。
- 接続（Connection） … 外部データベースシステムへの接続（Lakehouse Federation 用）。
- 共有 / プロバイダー / 受信者（Share / Provider / Recipient） … OpenSharing で組織間データ共有を管理。
- クリーン ルーム（Clean room） … 基盤データを公開せず他組織と共同作業する安全な環境。
重要: マネージド/外部の区別はテーブルとボリュームにのみ適用され、ビュー・モデル・関数などには「マネージド版/外部版」は存在しない。
3-3. 3階層ネームスペース catalog.schema.object
Unity Catalog のデータは「3 レベルの名前空間（three-level namespace）」catalog.schema.object（代表的には catalog.schema.table）で参照します。
- 第 1 レイヤー = カタログ（catalog）
- 第 2 レイヤー = スキーマ（schema）
- 第 3 レイヤー = オブジェクト（table / view / volume / function / model など）
これは、レガシ Hive メタストア時代の 2 レベル（schema.table = database.table）と対比される、Unity Catalog の大きな特徴です。
既定カタログ（default catalog）による省略:
- Unity Catalog 有効なワークスペースごとに**既定のカタログ（default catalog）**が構成される。
- データ操作時に最上位のカタログ名を省略すると、既定カタログが使われる。
- 自動有効化されたワークスペースでは、事前プロビジョニングされたワークスペース カタログが既定カタログに指定される（ワークスペース管理者が変更可能）。
ボリュームのパスも 3 階層に対応:
/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>/<catalog>/<schema>/<volume> の部分が 3 つの Unity Catalog オブジェクト名にマップされる。
3-4. 権限モデル（GRANT/REVOKE、privilege の種類、継承）
初期状態と誰が権限を管理できるか
- 初期状態では、ユーザーはメタストア内のデータに一切アクセスできない。
- 既定の管理特権を持つのは、アカウント管理者（account admin）、ワークスペース管理者（workspace admin）、メタストア管理者（metastore admin）。
- 特権を付与できるのは、次のいずれか。
- オブジェクトの所有者（owner）
- オブジェクトを含むカタログまたはスキーマの所有者
- オブジェクトに対する
MANAGE特権を持つユーザー - メタストア管理者
- （メタストアで直接付与する場合はアカウント管理者）
所有権（ownership）
- Unity Catalog のすべてのセキュリティ保護可能オブジェクトには所有者が 1 つ存在する。
- 所有者は、そのオブジェクトに対するすべての権限（他者への権限付与を含む）を持つ。
- 所有者は他ユーザーに
MANAGE特権を付与できる（＝所有者にならずに権限管理を可能にする）。 - 所有権の移転（
ALTER ... OWNER TO）には、現所有者・メタストア管理者・親コンテナーの所有者・MANAGE保持者のいずれかである必要がある。特権エスカレーション防止のため、ビュー/関数/モデルの所有権を任意のプリンシパルへ移せるのはメタストア管理者のみ。
プリンシパル（principal）
権限付与の相手は、ユーザー（user）、サービスプリンシパル（service principal, applicationId で表す）、グループ（group）。特殊文字を含む名前はバッククォート ` で囲む。
使用特権（usage privileges）— 継承されない「入り口」
USE CATALOG… カタログ内の任意オブジェクトを操作するために必要。これ自体はデータへのアクセスを許可しない。USE SCHEMA… スキーマ内の任意オブジェクトを操作するために必要。これ自体はデータアクセスを許可しない。- 例: テーブルを読むには「テーブルへの
SELECT」＋「親スキーマへのUSE SCHEMA」＋「親カタログへのUSE CATALOG」の3 つすべてが必要。 - これはアクセス制御の境界として機能する。テーブル所有者が
SELECTを付与しても、対象ユーザーが親カタログへのUSE CATALOGを持たなければアクセスできない。USE CATALOGを付与できるのはカタログ所有者/MANAGE保持者だけなので、カタログ所有者が全体を制御できる。
特権の継承（privilege inheritance）
- カタログ/スキーマに付与した権限は、その中の現在および将来のすべての子オブジェクトに自動適用される。
- 例: カタログに
SELECTを付与 → そのカタログ内の任意テーブルを読める（適切なUSE CATALOG/USE SCHEMA前提）。 - 例: カタログに
CREATE TABLEを付与 → カタログ内の任意スキーマにテーブル作成可。
- 例: カタログに
- 重要な例外: メタストア レベルで付与した特権は子オブジェクトに継承されない。 例えば
CREATE CATALOGはメタストア レベルの操作を許可するだけで、カタログ内データへのアクセスは付与しない。 - 継承のため、カタログ/スキーマ レベルの特権は「広範」になる。付与時は最小特権の原則（principle of least privilege）に注意。
主要な特権（privilege）の種類
| 特権 | 適用対象（代表） | できること |
|---|---|---|
ALL PRIVILEGES | カタログ, スキーマ, テーブル, ビュー, ボリューム等 | そのオブジェクトと子に対する全機能。ただし EXTERNAL USE SCHEMA / EXTERNAL USE LOCATION / MANAGE は含まない。 |
USE CATALOG | カタログ | カタログ内オブジェクトを操作する入り口（使用特権）。単独ではデータアクセス不可。 |
USE SCHEMA | スキーマ | スキーマ内オブジェクトを操作する入り口（使用特権）。単独ではデータアクセス不可。 |
SELECT | テーブル, ビュー, マテビュー, 共有 | データを照会（読み取り）する。 |
MODIFY | テーブル | テーブルのデータを挿入・更新・削除（書き込み）。外部テーブル（foreign table）は読み取り専用のため不可。 |
CREATE CATALOG | メタストア | メタストアにカタログを作成。 |
CREATE SCHEMA | カタログ | カタログにスキーマを作成。 |
CREATE TABLE | スキーマ, カタログ | スキーマにテーブルまたはビューを作成。 |
CREATE VOLUME | スキーマ, カタログ | スキーマにボリュームを作成。 |
CREATE FUNCTION | スキーマ, カタログ | スキーマに関数を作成。 |
CREATE MODEL | スキーマ, カタログ | スキーマに MLflow 登録済みモデルを作成。 |
CREATE MATERIALIZED VIEW | スキーマ, カタログ | マテリアライズド ビューを作成。 |
READ VOLUME | ボリューム, スキーマ, カタログ | ボリューム内のファイル/ディレクトリを読み取る。 |
WRITE VOLUME | ボリューム, スキーマ, カタログ | ボリューム内のファイルを追加・変更・削除する。 |
EXECUTE | 関数, モデル, スキーマ, カタログ | 関数を呼び出す / 登録済みモデルを推論用にロードする。 |
READ FILES | 外部ロケーション, ストレージ資格情報 | クラウド ストレージ パスからファイルを直接読み取る。書き込み操作にも必要。 |
WRITE FILES | 外部ロケーション, ストレージ資格情報 | クラウド ストレージ パスにファイルを直接書き込む（同一外部ロケーションの READ FILES も必要）。 |
BROWSE | カタログ, 外部ロケーション等 | USE CATALOG/USE SCHEMA なしで、データにアクセスせずメタデータを発見・表示・アクセス要求できる。カタログレベルで付与。All account users グループへの付与推奨。 |
MANAGE | 多数（テーブル, ボリューム, スキーマ, カタログ等） | 所有者でなくても、権限の管理・所有権の譲渡・名前変更・削除ができる。ALL PRIVILEGES には含まれない。コンテナーに付与すると子にも MANAGE が及ぶ。 |
APPLY TAG | テーブル, ビュー, ボリューム, モデル等 | オブジェクトにタグを追加/編集。テーブル/ビューは列タグ付け、登録済みモデルはバージョンタグ付けも有効化。 |
REFRESH | マテリアライズド ビュー | マテビューの更新を手動でトリガー。 |
CREATE STORAGE CREDENTIAL | メタストア | ストレージ資格情報を作成。 |
CREATE EXTERNAL LOCATION | メタストア + ストレージ資格情報 | 外部ロケーションを作成（両方に必要）。 |
CREATE EXTERNAL TABLE | 外部ロケーション/ストレージ資格情報 | クラウド パスに外部テーブルを作成。 |
CREATE EXTERNAL VOLUME | 外部ロケーション | 外部ボリュームを作成。 |
CREATE MANAGED STORAGE | 外部ロケーション | カタログ/スキーマにマネージド ストレージの場所を設定。 |
CREATE CONNECTION | メタストア（+ サービス資格情報） | 外部データベースへの接続を作成。 |
ALL PRIVILEGES の注意点:
- 各オブジェクト型に適用可能なすべての特権を「暗黙的に」意味する特別な特権。個別特権は明示的に付与されない。
- テーブルなら
SELECT+MODIFY+APPLY TAGを意味する。ボリュームならREAD VOLUME+WRITE VOLUME+APPLY TAG。 EXTERNAL USE SCHEMA・EXTERNAL USE LOCATION・MANAGEは含まれない（意図しないデータ流出・特権エスカレーション防止）。
ワークスペース カタログの既定権限
自動有効化されたワークスペースでは、すべてのワークスペース ユーザーが、ワークスペース カタログへの USE CATALOG と、既定スキーマ（default）への USE SCHEMA / CREATE TABLE / CREATE VOLUME / CREATE MODEL / CREATE FUNCTION / CREATE MATERIALIZED VIEW を受け取る（気軽に試せる場所として提供）。
3-5. ボリューム（表形式でないデータの管理）
ボリューム（Volume） は、表形式でない（non-tabular）データセットのガバナンスを可能にする Unity Catalog オブジェクトです。クラウド オブジェクト ストレージ上のストレージの論理ボリュームを表し、ファイルのアクセス・格納・管理・整理の機能を提供します。
- テーブル vs ボリューム: テーブルは表形式データを管理、ボリュームは構造化/半構造化/非構造化を問わず表形式以外のデータを管理する。
- Databricks は表形式でない全データのアクセス管理にボリュームを使うことを推奨。
- ボリュームは 3 階層ネームスペースの第 3 レベル（
catalog.schema.volume）に位置する。
重要な制約:
- ボリューム内のファイルを Unity Catalog のテーブルとして登録することはできない。 ボリュームはパスベースのデータアクセス専用。表形式データを扱うならテーブルを使う。
2 種類のボリューム:
| 特徴 | マネージド ボリューム（Managed volume） | 外部ボリューム（External volume） |
|---|---|---|
| 保存先 | スキーマの UC マネージド ストレージ内に作成 | 既存のクラウド オブジェクト ストレージ パスに対して登録 |
| データのライフサイクル | UC がレイアウトと削除を管理 | ボリューム削除後もデータはクラウド ストレージに残る |
| アクセス制御 | すべてのアクセスが UC 経由 | UC がアクセスを管理するが、外部ツールは直接 URI を利用可能 |
| 移行の要否 | 不要 | 不要（既存ストレージ パスをそのまま利用） |
| 典型的ユースケース | Databricks 専用ワークロードの最も簡単な選択 | Databricks と外部システムのアクセス混在 |
- マネージド ボリュームを使う理由: Databricks ワークロードの既定の選択肢。クラウド資格情報やストレージ パスを手動管理する必要がない。最も簡単。
- 外部ボリュームを使う理由: 既存クラウド ストレージ ディレクトリに UC ガバナンスを追加（データコピー不要）。Databricks 以外のシステムが読み書きするファイルの管理。ただし外部システムは UC ガバナンスをバイパスできるため、Unity Catalog からの短命資格情報の発行（credential vending）やクラウドネイティブなアクセス制御（IAM ポリシー等）で追加のガバナンスが必要。
ボリュームのユースケース:
- 外部システムが生成した生データのランディング領域。
- インジェスト用のステージング場所（Auto Loader、
COPY INTO、CTASCREATE TABLE AS）。 - データサイエンティスト/アナリスト/ML エンジニアの探索的データ分析用ファイル ストレージ。
- 画像・音声・動画・PDF などの非構造化データや、JAR / Python ホイールなどライブラリファイルへのアクセス。
- ログやチェックポイントなど運用データの格納。
アクセス パス:
/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>- Apache Spark 使用時は任意で
dbfs:/スキームも可:dbfs:/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name> /<catalog>/<schema>/<volume>のディレクトリは読み取り専用で UC が自動管理。ファイルシステム コマンドでの作成/削除は不可。- 外部ボリュームはクラウド ストレージ URI でのアクセスも可能。
予約済みパス: dbfs:/Volumes、/Volumes（および入力ミスを考慮した /volumes, /Volume, /volume 等）。/dbfs/Volumes も予約済みだがボリュームアクセスには使えない。
コンピューティング要件と制限:
- ボリュームは Databricks Runtime 13.3 LTS 以降でサポート。SQL ウェアハウス、または 13.3 LTS 以上のクラスターが必要（Catalog Explorer などの UI 利用時を除く）。
- Unity Catalog 対応コンピューティングが必要。
dbutils.fsのエグゼキュータ配布は非対応。UC UDF からのボリュームパス アクセス不可。RDD からアクセス不可。JAR での従来spark-submitタスク不可（JAR タスクを使う）。%sh mvによるボリューム間ファイル移動は不可（dbutils.fs.mvか%sh cpを使う）。/Volumes/<catalog>や/Volumes/<catalog>/<schema>パターンでのオブジェクト一覧は不可。ボリューム名まで含む完全修飾パスが必要。- FedRAMP 準拠の Azure Government リージョン/ワークスペースでは利用不可。
補足: カタログ/スキーマ/ボリュームを作らずに個人用ファイルを保存するには、ユーザーごとのボリューム My Files（ベータ） を使える。
3-6. ストレージ資格情報・外部ロケーション（マネージド/外部テーブルとの関係）
Databricks は、クラウド オブジェクト ストレージ上の全データへのアクセスを Unity Catalog で管理することを推奨します。その中核となるオブジェクトがストレージ資格情報と外部ロケーションです。
ストレージ資格情報（Storage credential）
- クラウド ストレージにアクセスするための認証・承認メカニズムを表すオブジェクト。
- Azure では Azure マネージド ID（managed identity） またはサービスプリンシパル、AWS では IAM ロール、GCP ではサービスアカウント、Cloudflare R2 では R2 API トークン。
- 作成には、メタストアに対する
CREATE STORAGE CREDENTIAL特権が必要。 - 単独で外部テーブルを作成することもできるが、通常は外部ロケーションの構成要素として使う。
- ストレージ資格情報を作成/使用する権限は、外部ロケーションを作る必要があるユーザーにのみ付与すべき。
外部ロケーション / 外部の場所（External location）
- クラウド ストレージ パス ＋ そのパスへのアクセスを承認するストレージ資格情報を組み合わせたオブジェクト。
- 複数の外部ロケーションが同じストレージ資格情報を参照できる。
- 作成には、メタストアに対する
CREATE EXTERNAL LOCATION特権が必要（メタストアとストレージ資格情報の両方に必要）。 - 外部ロケーションに対する
READ FILES（読み取り）/WRITE FILES（書き込み）で直接パスアクセスを制御。ただし Databricks は、直接のREAD FILES/WRITE FILESよりもボリューム +READ VOLUME/WRITE VOLUMEによるアクセス管理を推奨。
Unity Catalog がクラウド ストレージを使う 2 つの方法
- マネージド ストレージの場所（managed storage location） … マネージド テーブル/ボリュームの既定の格納先。メタストア/カタログ/スキーマ レベルで定義。ライフサイクルは UC が完全管理。
- 外部テーブル/外部ボリュームの格納先 … Databricks からのアクセスは UC 管理下だが、データのライフサイクルとファイルレイアウトはクラウド プロバイダーや他プラットフォームが管理。
マネージド vs 外部（テーブル/ボリューム）
| プロパティ | マネージド（Managed） | 外部（External） |
|---|---|---|
| ストレージの場所 | Unity Catalog が設定（クラウド アカウント内） | ユーザーが設定 |
| ファイル ライフサイクル管理 | UC が管理（最適化・整理・削除） | ユーザーが管理 |
| ドロップ（削除）時の動作 | データファイルは保持期間後に完全削除される | データファイルはそのまま残る |
| データ所有権 | あり（データは常にクラウド アカウントに残る） | あり |
- 管理資産（managed asset）: UC がガバナンス（アクセス制御・監査・系列）と基盤ファイルストレージのライフサイクル（最適化・整理・削除）の両方を制御。
- 外部資産（external asset）: UC はガバナンスのみを制御。ファイルストレージのライフサイクルはユーザー/外部システムが制御。
- マネージド/外部の区別はテーブルとボリュームにのみ適用。ビュー・モデル・関数には適用されない。
- マネージド テーブル: 格納場所は UC が決定。形式は Delta または Apache Iceberg。ドロップするとデータファイルも削除される。
- 外部テーブル: 格納場所を指定。ドロップするとメタデータのみ削除、データは残る。形式は Delta、CSV、JSON、Avro、Parquet、ORC など複数対応。
- マネージド テーブルも外部テーブルも、Unity REST API や Iceberg REST Catalog (IRC) 等のオープン API で外部エンジンからアクセス可能（ベンダーロックインなし）。
- マネージド ボリューム: 格納場所は UC が決定、ドロップでデータも削除。外部ボリューム: 格納場所（＝外部ロケーションに対応するパス）を指定、ドロップでデータは残る。
重要な警告: Unity Catalog 以外の ID に、UC マネージド テーブル/ボリュームへのストレージ レベルの直接アクセスを付与してはならない。 これは UC をバイパスし、データのセキュリティとガバナンスを損なう。UC マネージド テーブルは直接ストレージ アクセスをサポートしない。
「manage」という語の使い分け（混同注意）
| 用語 | 意味 | 適用対象 |
|---|---|---|
| 「Unity Catalog によって管理される」 | UC がオブジェクトのアクセス・監査・系列を管理 | 外部テーブル/ボリュームを含む全登録オブジェクト |
| マネージド テーブル / マネージド ボリューム | UC が基盤ストレージの場所とデータ ライフサイクルも制御 | テーブルとボリュームのみ |
| マネージド ストレージの場所 | マネージド テーブル/ボリュームのデータファイルを置く指定パス | テーブルとボリュームのみ |
MANAGE 特権 | 所有者でなくても権限割当・取消・所有権譲渡・削除ができる特権 | 全セキュリティ保護可能オブジェクト |
4. 構文・コード例
権限の表示（SHOW GRANTS）
sql
-- セキュリティ保護可能オブジェクトに対する全許可を表示
SHOW GRANTS ON <securable-type> <securable-name>;
-- 例: main.default スキーマの全許可を表示
SHOW GRANTS ON SCHEMA main.default;
-- 特定プリンシパルの許可のみ表示
SHOW GRANTS `user@example.com` ON TABLE main.default.orders;
-- メタストアに対する許可を表示（メタストア名は指定しない）
SHOW GRANTS ON METASTORE;SHOW GRANTS ON SCHEMA main.default; の出力例:
principal actionType objectType objectKey
------------- ------------- ---------- ------------
finance-team CREATE TABLE SCHEMA main.default
finance-team USE SCHEMA SCHEMA main.default権限の付与（GRANT）
sql
GRANT <privilege-type> ON <securable-type> <securable-name> TO <principal>;テーブル読み取りに必要な 3 レベルの権限をまとめて付与する例（使用特権 + データ特権）:
sql
-- finance-team グループが main.default にテーブルを作成し、読み書きできるようにする
GRANT USE CATALOG ON CATALOG main TO `finance-team`;
GRANT USE SCHEMA ON SCHEMA main.default TO `finance-team`;
GRANT CREATE TABLE ON SCHEMA main.default TO `finance-team`;
-- テーブルの読み取り／書き込み
GRANT SELECT ON TABLE main.default.orders TO `analyst@example.com`;
GRANT MODIFY ON TABLE main.default.orders TO `etl-service`;
-- ボリュームの読み書き
GRANT READ VOLUME ON VOLUME main.default.landing TO `analyst@example.com`;
GRANT WRITE VOLUME ON VOLUME main.default.landing TO `etl-service`;
-- 登録済みモデルは「関数の一種」なので GRANT ON FUNCTION を使う
GRANT EXECUTE ON FUNCTION prod.ml_team.iris_model TO `ml-team-acme`;
-- メタストアレベルの特権（メタストア名は書かない）
GRANT CREATE CATALOG ON METASTORE TO `data-platform-admins`;権限の取り消し（REVOKE）
sql
REVOKE <privilege-type> ON <securable-type> <securable-name> FROM <principal>;
-- 例
REVOKE CREATE TABLE ON SCHEMA main.default FROM `finance-team`;
REVOKEは、その特権が元々付与されていなくても成功する（結果として「特権が存在しない」ことを保証する）。
所有権の確認と移転
sql
-- 所有者を確認
DESCRIBE <securable-type> EXTENDED <catalog>.<schema>.<securable-name>;
-- 所有権を移転
ALTER <securable-type> <securable-name> OWNER TO <principal>;
-- 例: orders テーブルの所有権を accounting グループへ
ALTER TABLE mycatalog.myschema.orders OWNER TO `accounting`;3 階層ネームスペースでのオブジェクト参照
sql
-- 完全修飾（catalog.schema.table）
SELECT * FROM main.default.orders;
-- 既定カタログが main の場合、カタログ名を省略できる
SELECT * FROM default.orders;
-- ボリュームのファイルにパスでアクセス
-- /Volumes/<catalog>/<schema>/<volume>/<path>/<file>python
# ボリューム内のファイル一覧（完全修飾パスが必要）
dbutils.fs.ls("/Volumes/MyCatalog/MySchema/MyVolume")5. 試験で問われるポイント
- Unity Catalog の役割: データと AI の統合ガバナンス。1 つで「アクセス制御・リネージ（系列）・監査・データ検出」を提供する。
- オブジェクト階層の順序:
メタストア > カタログ > スキーマ > テーブル/ビュー/ボリューム/関数/モデル。メタストアが最上位、カタログが 3 レベル ネームスペースの第 1 レイヤー。 - 3 階層ネームスペース
catalog.schema.object: 従来の Hive（2 階層schema.table）との違いを問われやすい。 - メタストアはリージョンごとに 1 つ。同一リージョン内の複数ワークスペースにアタッチでき、メタストアで付与した権限は全アタッチ ワークスペースに及ぶ。
- 使用特権
USE CATALOG/USE SCHEMAが必須:SELECTだけではテーブルにアクセスできない。「テーブルへのSELECT+USE SCHEMA+USE CATALOG」の 3 点セット。 - 特権の継承: カタログ/スキーマに付与 → 現在・将来の子に自動適用。ただしメタストア レベルの特権は継承されない。
SELECT= 読み取り、MODIFY= 書き込み（挿入/更新/削除）、READ VOLUME/WRITE VOLUME= ボリュームのファイル読み書き、EXECUTE= 関数/モデル実行。- GRANT / REVOKE / SHOW GRANTS の基本構文。プリンシパル = ユーザー/グループ/サービスプリンシパル。
- 所有者はそのオブジェクトの全権限を持つ。所有権継承のためカタログ所有者は非常に強力。
MANAGEは所有者でなくても権限管理・削除・所有権移転を可能にする。 - マネージド vs 外部（テーブル/ボリュームのみ）:
- マネージド = 場所も UC が決定、ドロップでデータも削除、テーブルは Delta/Iceberg。
- 外部 = 場所を指定、ドロップしてもデータは残る、テーブルは Delta/CSV/JSON/Parquet 等多形式。
- ボリューム = 表形式でないデータ（非構造化ファイル）。テーブル = 表形式データ。ボリューム内ファイルをテーブルとして登録することはできない（パスベース アクセス専用）。ボリュームは 13.3 LTS 以降。
- **ストレージ資格情報（認証情報）＋外部ロケーション（パス + 資格情報）**の関係。外部テーブル/外部ボリュームは外部ロケーションのパスを参照して作成する。
- 既定カタログでカタログ名を省略できる。自動有効化ワークスペースではワークスペース カタログが既定。
- hive_metastore カタログはレガシ（非推奨）。
__databricks_internalは予約カタログで直接操作しない。 - 管理者ロールの階層: アカウント管理者 / ワークスペース管理者 / メタストア管理者。初期状態ではユーザーはデータにアクセスできない。
6. 理解度チェックリスト
- [ ] Unity Catalog が提供する 4 つの主な機能（アクセス制御・系列/リネージ・監査・データ検出）を挙げられる
- [ ] オブジェクト階層「メタストア > カタログ > スキーマ > テーブル/ビュー/ボリューム/関数/モデル」を正しい順で書ける
- [ ] 3 階層ネームスペース
catalog.schema.objectの各レイヤーが何かを説明できる - [ ] メタストアが「リージョンごとに 1 つ」で複数ワークスペースにアタッチ可能だと説明できる
- [ ]
USE CATALOG/USE SCHEMA（使用特権）がなぜ必要かを説明できる - [ ] テーブル読み取りに必要な特権 3 点セット（
SELECT+USE SCHEMA+USE CATALOG）を説明できる - [ ]
SELECTとMODIFY、READ VOLUMEとWRITE VOLUME、EXECUTEの違いを説明できる - [ ] 特権の継承がカタログ/スキーマで働き、メタストア レベルでは継承されないことを説明できる
- [ ]
GRANT/REVOKE/SHOW GRANTSの SQL 構文を書ける - [ ] プリンシパル（ユーザー・グループ・サービスプリンシパル）と所有者・
MANAGEの違いを説明できる - [ ] マネージド テーブルと外部テーブルの「ドロップ時の挙動」の違いを説明できる
- [ ] マネージド/外部の区別がテーブルとボリュームにのみ適用されることを知っている
- [ ] ボリューム（非構造化データ）とテーブル（表形式データ）の使い分けを説明できる
- [ ] ボリュームのアクセスパス
/Volumes/<catalog>/<schema>/<volume>/...を書ける - [ ] マネージド ボリュームと外部ボリュームの違い（保存先・ライフサイクル・削除時挙動）を説明できる
- [ ] ストレージ資格情報と外部ロケーションの役割の違いと関係を説明できる
- [ ] 外部テーブル/外部ボリュームが外部ロケーションのパスを参照して作られることを説明できる
- [ ] 既定カタログ、ワークスペース カタログ、hive_metastore カタログの役割を区別できる
- [ ] アカウント管理者・ワークスペース管理者・メタストア管理者の役割を区別できる
- [ ] 初期状態ではユーザーがデータにアクセスできないこと（明示的な GRANT が必要）を理解している