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

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

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

Unity Catalogの階層構造

Unity Catalogは、Metastoreを頂点とする4階層のオブジェクトモデルを採用しています。すべてのデータアセットはこの階層ツリーに配置され、権限は上位から下位へ継承されます。

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所有者（またはCREATE SCHEMA権限を持つユーザー）が作成できます。

-- 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）に対して付与し、ユーザーまたはグループ（プリンシパル）に紐づけます。

主な権限タイプ

権限付与のSQL例

-- ステップ1: Catalogへのアクセスを開く（廊下を通す）
GRANT USAGE ON CATALOG production TO analysts;

-- ステップ2: SchemaへのUSAGEを開く
GRANT USAGE 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 TO analysts;

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

権限の継承モデル

Unity Catalogの権限は上位オブジェクトから下位に継承されます。 たとえば、CatalogにSELECTを付与すると、そのCatalog配下のすべてのSchemaとテーブルに SELECTが適用されます。ただし、USAGEは自動継承されません。 上位のCatalogとSchemaの両方にUSAGEを明示的に付与しない限り、 配下のテーブルにSELECT権限があってもデータにアクセスできません。

権限の継承イメージ:

GRANT SELECT ON CATALOG production TO analysts;
 → production配下の全Schema・全Tableに SELECT が継承

ただし USAGE が必要:
 Catalog: production  → USAGE が必要 ✓
   Schema: sales      → USAGE が必要 ✓
     Table: orders    → SELECT で読み取り可能 ✓

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

Managed Table と External Table

Unity Catalogに登録するテーブルは、データの保存場所によってManaged TableとExternal Tableに分類されます。DROP時の挙動が根本的に異なるため、設計時に正しく選択する必要があります。

試験頻出: 「DROP TABLE実行後にデータファイルはどうなるか？」 → Managed Tableはデータも消える、External Tableはメタデータだけ消える。

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/'

設定の流れ（SQL）

-- 1. Storage Credentialの作成（Metastore Admin権限が必要）
CREATE STORAGE CREDENTIAL aws_s3_credential
WITH (
  AWS_IAM_ROLE = 'arn:aws:iam::123456789012:role/unity-catalog-role'
);

-- 2. 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とDelta Sharing

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

-- 共有（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）にはガバナンス機能がなく、「誰がどのファイルにアクセスしたか」を追跡できませんでした。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時間の監査イベントを確認
SELECT
  event_time,
  user_identity.email AS user_email,
  action_name,
  request_params.full_name_arg AS object_name
FROM system.access.audit
WHERE event_time > current_timestamp() - INTERVAL 24 HOURS
  AND action_name IN ('getTable', 'createTable', 'grantPermission')
ORDER BY event_time DESC;

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

Data Engineer Associate（DEA）試験では、Data Governanceドメインが約17%の出題比率を占めます。Unity Catalogはこのドメインの中核トピックです。以下の項目は確実に押さえてください。

サンプル問題

よくある質問（FAQ）