Unity Catalogとは？Databricksのデータガバナンス

Unity Catalogは、Databricksが提供するアカウントレベルの統合データガバナンスレイヤーです。 テーブル・ビュー・関数・MLモデル・ファイル（Volumes）といったすべてのデータアセットに対し、 複数ワークスペースを横断した一元的なアクセス制御・監査ログ・データリネージを実現します。 従来のHive Metastoreではワークスペースごとに分断されていたメタデータ管理を、catalog.schema.table の3レベル名前空間で統一し、 SQL標準のGRANT/REVOKEによる権限管理をワークスペース横断で一元化しました。

この記事では、Unity Catalogの階層構造・権限モデル・External Location・OpenSharing（旧Delta Sharing）連携・Hive Metastoreとの違いまでを網羅的に解説します。Data Engineer Associate（DEA）試験のGovernance and Securityセクション（出題比率15%）を中心に、認定試験で問われるポイントもあわせて整理しています。

Unity Catalogの階層構造

Unity Catalogは、Metastoreを頂点とする4階層のオブジェクトモデルを採用しています。すべてのデータアセットはこの階層ツリーに配置され、CatalogやSchemaに付与した権限は配下へ継承されます（Metastoreに付与した権限は、READ METADATAを除いて配下に継承されません）。

Metastore（リージョンごとに1つ）
 ├── Catalog: production
 │    ├── Schema: sales
 │    │    ├── Table: orders
 │    │    ├── Table: customers
 │    │    ├── View: daily_summary
 │    │    └── Function: calc_tax()
 │    ├── Schema: marketing
 │    │    ├── Table: campaigns
 │    │    └── Volume: raw_files
 │    └── Schema: information_schema（自動生成）
 ├── Catalog: development
 │    └── Schema: sandbox
 │         └── Table: test_orders
 ├── External Location: s3://data-lake/external/
 └── Storage Credential: aws_s3_role

データアセットを参照するときは、常に catalog.schema.object の3レベル名前空間を使います。これにより「どの環境の、どのドメインの、どのテーブルか」が名前だけで一意に特定できます。

-- 3レベル名前空間でのアクセス
SELECT * FROM production.sales.orders;
--            ^^^^^^^^^^  ^^^^^  ^^^^^^
--            Catalog     Schema Table

-- デフォルトのCatalog/Schemaを設定
USE CATALOG production;
USE SCHEMA sales;

-- 上記の設定後は短縮形でアクセス可能
SELECT * FROM orders;

各レベルの役割と設計パターン

Catalog・Schemaの作成

Unity Catalogでデータアセットを格納するには、まずCatalogとSchemaを作成します。CatalogはMetastore Admin（またはCREATE CATALOG権限を持つユーザー）が、SchemaはCatalog所有者（またはそのCatalogのCREATE SCHEMAとUSE CATALOGを持つユーザー）が作成できます。

-- Catalogの作成
CREATE CATALOG IF NOT EXISTS production
COMMENT 'Production environment catalog';

-- Schemaの作成
CREATE SCHEMA IF NOT EXISTS production.sales
COMMENT 'Sales domain tables';

-- Managed Tableの作成（LOCATIONなし → Unity Catalog管理ストレージに格納）
CREATE TABLE production.sales.orders (
  order_id     BIGINT       GENERATED ALWAYS AS IDENTITY,
  customer_id  BIGINT       NOT NULL,
  amount       DECIMAL(12,2) NOT NULL,
  order_date   DATE         NOT NULL,
  status       STRING       DEFAULT 'pending'
)
COMMENT 'Customer order records'
TBLPROPERTIES ('quality' = 'gold');

-- External Tableの作成（LOCATIONあり → 外部ストレージのデータを参照）
CREATE TABLE production.sales.external_logs (
  log_id    BIGINT,
  message   STRING,
  timestamp TIMESTAMP
)
LOCATION 's3://data-lake/external/sales/logs/';

権限管理（GRANT / REVOKE）

Unity CatalogはSQL標準のGRANT/REVOKE構文でアクセス制御を行います。権限はSecurable Object（Catalog、Schema、Table、View、Function、Volume、External Location、Storage Credentialなど）に対して付与し、ユーザー・サービスプリンシパル・グループ（プリンシパル）に紐づけます。初期状態のユーザーはデータにアクセスできず、操作には権限を明示的に付与する必要があります。DEA試験ガイドのセクション7はGRANT・REVOKE・DENYの適用を挙げていますが、DENY文はhive_metastore専用で、Unity Catalogでは使えません。Unity Catalogで明示的に拒否する仕組みはABACのDENYポリシー（ベータ）で、拒否できるのはMANAGE ACCESS CONTROL（権限の付与・取り消しや所有権の移譲など、アクセス管理の操作）だけです。SELECTのようなデータの権限は、DENYポリシーでは拒否できません。

主な権限タイプ

権限付与のSQL例

-- ステップ1: Catalogの使用を許可する（廊下を通す）
GRANT USE CATALOG ON CATALOG production TO analysts;

-- ステップ2: Schemaの使用を許可する
GRANT USE SCHEMA ON SCHEMA production.sales TO analysts;

-- ステップ3: テーブルのSELECT権限を付与（部屋に入れる）
GRANT SELECT ON SCHEMA production.sales TO analysts;
-- ↑ Schema配下の現在と将来の全テーブルにSELECTが適用される

-- 特定のテーブルだけに限定する場合
GRANT SELECT ON TABLE production.sales.orders TO analysts;

-- データ変更権限の付与
GRANT MODIFY ON TABLE production.sales.orders TO etl_service;

-- Schema内にテーブルを作れる権限
GRANT CREATE TABLE ON SCHEMA production.sales TO data_engineers;

-- 権限の確認
SHOW GRANTS ON SCHEMA production.sales;
SHOW GRANTS analysts ON SCHEMA production.sales;  -- analystsグループの分だけ表示

-- 権限の取り消し
REVOKE SELECT ON SCHEMA production.sales FROM analysts;

権限の継承モデル

Unity Catalogの権限は上位オブジェクトから下位に継承されます。 たとえば、CatalogにSELECTを付与すると、そのCatalog配下の現在と将来のすべてのテーブルに SELECTが適用されます。ただし、SELECTだけではデータを読めません。 CatalogへのUSE CATALOGとSchemaへのUSE SCHEMAも必要です。USE SCHEMAも継承されるのでCatalogに付与すれば配下の全Schemaに効きますが、 USE CATALOGはCatalog自体に付与します。

権限の継承イメージ:

GRANT SELECT ON CATALOG production TO analysts;
 → production配下の現在と将来の全TableにSELECTが継承

ただし使用権限が必要:
 Catalog: production  → USE CATALOGが必要 ✓
   Schema: sales      → USE SCHEMAが必要 ✓（Catalogに付与しても可）
     Table: orders    → SELECTで読み取り可能 ✓

USE CATALOGが欠けている場合:
 Catalog: production  → USE CATALOGなし ✗
   Schema: sales      → USE SCHEMAあり
     Table: orders    → SELECTあり → でもアクセス不可 ✗

Managed Table と External Table

Unity Catalogに登録するテーブルは、データの保存場所によって主にManaged TableとExternal Tableに分類されます（ほかにLakehouse Federationで外部のシステムを参照するフォーリンテーブルもあります）。DROP時の挙動が根本的に異なるため、設計時に正しく選択する必要があります。

試験ガイドのポイント: 第7セクションは、マネージドテーブルと外部テーブルの区別と、作成・変更・削除・相互変換を挙げています。DROP TABLEでは、Managed Tableはデータファイルも（リカバリ期間の後に）消え、External Tableはメタデータだけが消えます。外部テーブルからマネージドテーブルへの変換にはALTER TABLE ... SET MANAGEDを使います。

External Location と Storage Credential

External Tableを作成するには、Unity Catalogが外部ストレージにアクセスするための認証情報を登録する必要があります。この仕組みはStorage CredentialとExternal Locationの2段階で構成されます。

[Storage Credential]          クラウドの認証情報を登録
        │                     （IAMロール / Service Principal / Service Account）
        ▼
[External Location]           認証情報と許可パスを紐づけ
  url: s3://bucket/path/      「この認証情報で、このパス範囲にアクセスOK」
        │
        ▼
[External Table]              LOCATION句で外部パスを指定してテーブル作成
  production.sales.ext_logs
  LOCATION 's3://bucket/path/logs/'

設定の流れ（手順2以降はSQL）

-- 1. Storage Credentialの作成
--    SQLではなく、Catalog Explorer（[Connect] > [Credentials]）や
--    Databricks CLI、Terraformで作成する。
--    CREATE STORAGE CREDENTIAL権限が必要
--    （メタストア管理者とアカウント管理者は既定で持つ）。
--    ここでは、IAMロール（arn:aws:iam::123456789012:role/unity-catalog-role）を
--    登録したaws_s3_credentialを作成済みとする。

-- 2. External Locationの作成
--    （MetastoreとStorage CredentialのCREATE EXTERNAL LOCATION権限が必要）
CREATE EXTERNAL LOCATION s3_data_lake
URL 's3://my-data-lake/production/'
WITH (STORAGE CREDENTIAL aws_s3_credential)
COMMENT 'Production data lake on S3';

-- 3. External Locationの権限を付与
GRANT CREATE EXTERNAL TABLE ON EXTERNAL LOCATION s3_data_lake
TO data_engineers;

-- 4. External Tableの作成
CREATE TABLE production.sales.external_events (
  event_id   BIGINT,
  event_type STRING,
  payload    STRING,
  created_at TIMESTAMP
)
LOCATION 's3://my-data-lake/production/events/';

Storage Credentialは複数のExternal Locationで再利用できます。 たとえば1つのIAMロールで s3://bucket/sales/ と s3://bucket/marketing/の2つのExternal Locationを作成し、チームごとにアクセス範囲を分離するといった設計が可能です。

Hive Metastoreとの比較

Unity Catalogは、従来のHive Metastoreが抱えていたガバナンスの課題を解決するために設計されました。移行を検討する際は以下の違いを理解しておく必要があります。

Unity CatalogとOpenSharing（旧Delta Sharing）

OpenSharing（旧Delta Sharing）は、組織の境界を超えてデータを安全に共有するためのオープンプロトコルです。 Unity CatalogはOpenSharingのプロバイダーとして機能し、外部組織のDatabricks環境や 非Databricks環境（Apache Spark、pandas、Power BIなど）に対してデータを共有できます。

-- 共有（Share）の作成
CREATE SHARE customer_analytics;

-- Shareにテーブルを追加
ALTER SHARE customer_analytics
ADD TABLE production.sales.orders;

-- 受信者（Recipient）の作成
CREATE RECIPIENT partner_company
USING ID 'partner-sharing-identifier';

-- 受信者にShareへのアクセスを付与
GRANT SELECT ON SHARE customer_analytics TO RECIPIENT partner_company;

• データのコピーは発生しない（プロバイダーのストレージから直接読み取り）
• テーブル単位・パーティション単位で共有範囲を制御可能
• 受信者はDatabricksユーザーでなくてもよい（オープンプロトコル）
• 共有したデータへのアクセスログはプロバイダー側の監査ログに記録される

Volumes（ファイルガバナンス）

Volumesは、テーブル以外のファイル（CSV、JSON、画像、モデルアーティファクト、設定ファイルなど）をUnity Catalogの権限モデルで管理するための機能です。従来のDBFS（Databricks File System）のルートはワークスペースの全ユーザーがアクセスでき、DBFSの監査イベントもDBFS REST API経由の操作とマウントの作成・削除に限られます（DBFSルートとマウントは現在非推奨）。VolumeはCatalog/Schema配下に作成されるため、GRANT/REVOKEで権限制御ができ、監査ログにも記録されます。

-- Managed Volumeの作成（Unity Catalog管理ストレージに保存）
CREATE VOLUME production.raw.landing_files;

-- External Volumeの作成（外部パスを参照）
CREATE EXTERNAL VOLUME production.raw.s3_landing
LOCATION 's3://my-bucket/landing/';

-- ファイルの一覧表示
LIST '/Volumes/production/raw/landing_files/';

-- SQLからファイルを読み取り
SELECT * FROM csv.`/Volumes/production/raw/landing_files/2026-03/data.csv`;

-- PythonからVolume内のファイルを読み取り
-- df = spark.read.csv("/Volumes/production/raw/landing_files/2026-03/data.csv")

データリネージと監査

Unity Catalogは、ノートブックやジョブで実行されたSparkクエリを自動的に解析し、テーブル間・カラム間のデータフロー（リネージ）を記録します。手動での設定や有効化は不要で、Unity Catalogが有効な環境では自動的に動作します。

• テーブルレベルリネージ: テーブルAのデータがテーブルBに流れたことを追跡
• カラムレベルリネージ: 特定カラムがどのソースカラムから派生したかを追跡
• 影響分析: 「このテーブルのスキーマを変更したら、どの下流テーブルが影響を受けるか」を事前確認
• コンプライアンス: PIIデータがどのテーブルに伝播したかを追跡し、GDPR等の規制対応に活用

監査ログは system.access.audit テーブル（System Tables）に記録されます。誰がいつどのオブジェクトに対してどの操作を行ったかを、SQLで直接クエリして分析できます。

-- 直近24時間のUnity Catalogの監査イベントを確認
-- （GRANT / REVOKEはupdatePermissionsとして記録される）
SELECT
  event_time,
  user_identity.email AS user_email,
  action_name,
  COALESCE(request_params.full_name_arg,
           request_params.securable_full_name) AS object_name
FROM system.access.audit
WHERE service_name = 'unityCatalog'
  AND event_time > current_timestamp() - INTERVAL 24 HOURS
  AND action_name IN ('getTable', 'deleteTable', 'updatePermissions')
ORDER BY event_time DESC;

試験で問われるポイント（DEA 15%）

Data Engineer Associate（DEA）試験の現行版（2026年5月4日改訂）では、Governance and Security（ガバナンスとセキュリティ）セクションが15%の出題比率を占めます。Unity Catalogはこのセクションの中核トピックです。以下の項目は確実に押さえてください。

サンプル問題

よくある質問（FAQ）