Zenn
🏛️

【Databricks】Unity Catalogによるデータガバナンス - エンタープライズレベルの権限管理とデータ統制

に公開
Security
Databricks
dataengineering
DataGovernance
Unity Catalog
tech

はじめに

Unity Catalogは、Databricksが提供する統一データガバナンスソリューションです。従来のHive Metastoreでは実現困難だった、きめ細かい権限管理、データリネージの追跡、データ発見機能などを統合的に提供します。

エンタープライズ環境では、「誰がどのデータにアクセスできるか」「データがどこから来てどう変換されたか」「機密データは適切に保護されているか」といったガバナンス要件が不可欠です。Unity Catalogは、これらの課題を体系的に解決します。

この記事では、Unity Catalogの基本概念から実際の権限設定まで、実践的なガバナンス実装方法を詳しく解説します。

Unity Catalogとは

基本概念

Unity Catalogは、Databricks Lakehouse Platform全体でデータとAIアセットを管理する統一ガバナンスソリューションです。データベース、テーブル、ビュー、ボリューム（ファイル）、機械学習モデル、関数まで、あらゆるデータアセットを一元管理できます。

従来のHive Metastoreとの違い

Hive Metastore（従来）の課題

  • ワークスペース単位の管理: 各ワークスペースで個別にメタデータを管理
  • 権限管理の限界: テーブルレベルでの細かい権限制御が困難
  • リネージの欠如: データの変換履歴や依存関係が追跡不可能
  • クロスクラウド対応不足: 異なるクラウド間でのデータ共有が複雑

Unity Catalogの解決策

  • アカウントレベルの統一管理: 複数ワークスペースでメタデータを共有
  • 細粒度の権限制御: カラムレベルまでの詳細な権限管理
  • 自動リネージ追跡: データの変換フローを自動で可視化
  • クロスクラウドサポート: AWS、Azure、GCP間でのシームレスなデータ共有

Unity Catalogの3層構造

Unity Catalogは以下の階層構造でデータを管理します：

Account (アカウント)
└── Catalog (カタログ)
    └── Schema (スキーマ)
        └── Table/View/Volume/Function (テーブル/ビュー/ボリューム/関数)

1. Account（アカウント）

  • 最上位レベル
  • 複数のワークスペースを包含
  • 組織全体のガバナンスポリシーを定義

2. Catalog（カタログ）

  • データの大分類（部門、プロジェクト、環境など）
  • 例：prod_catalog, dev_catalog, finance_catalog

3. Schema（スキーマ）

  • カタログ内でのデータグループ化
  • 例：sales, marketing, hr

4. Table/View/Volume/Function

  • 実際のデータオブジェクト
  • 例：sales.customers, marketing.campaigns

データガバナンスの基本要素

1. Identity and Access Management (IAM)

Unity Catalogでは、以下の主体に対して権限を設定できます：

プリンシパル（Principal）の種類

  • User: 個別のユーザーアカウント
  • Service Principal: アプリケーションやサービス用のアカウント
  • Group: ユーザーをまとめたグループ
-- ユーザーの作成（管理者権限が必要）
CREATE USER 'john.doe@company.com';

-- グループの作成
CREATE GROUP 'data_analysts';
CREATE GROUP 'data_engineers';
CREATE GROUP 'finance_team';

-- グループにユーザーを追加
ALTER GROUP 'data_analysts' ADD USER 'john.doe@company.com';
ALTER GROUP 'data_engineers' ADD USER 'jane.smith@company.com';

サービスプリンシパルの活用

アプリケーションやETLジョブ用には、個人アカウントではなくサービスプリンシパルを使用します：

-- サービスプリンシパルの作成
CREATE SERVICE PRINCIPAL 'etl-service-prod';
CREATE SERVICE PRINCIPAL 'analytics-app';

-- サービスプリンシパルをグループに追加
ALTER GROUP 'data_engineers' ADD SERVICE PRINCIPAL 'etl-service-prod';

2. 権限モデル

Unity Catalogでは、以下の権限を細かく制御できます：

オブジェクトレベルの権限

  • USAGE: オブジェクトの存在を知り、基本情報にアクセス
  • SELECT: データの読み取り
  • MODIFY: データの変更（INSERT、UPDATE、DELETE）
  • CREATE: 新しいオブジェクトの作成
  • ALL PRIVILEGES: すべての権限

セキュアブルオブジェクトの階層

権限は階層的に継承されます：

-- カタログレベルの権限設定
GRANT USAGE ON CATALOG prod_catalog TO GROUP 'data_analysts';

-- スキーマレベルの権限設定（カタログのUSAGEが前提）
GRANT USAGE ON SCHEMA prod_catalog.sales TO GROUP 'sales_team';
GRANT SELECT ON SCHEMA prod_catalog.sales TO GROUP 'sales_team';

-- テーブルレベルの詳細な権限設定
GRANT SELECT ON TABLE prod_catalog.sales.customers TO GROUP 'data_analysts';
GRANT MODIFY ON TABLE prod_catalog.sales.orders TO GROUP 'data_engineers';

実践的な権限設定例

シナリオ：多部門企業でのガバナンス設計

以下のような組織構造を想定した権限設計を実装してみましょう：

  • データエンジニアチーム: 全データの読み書き権限
  • データアナリストチーム: 分析用データの読み取り権限
  • 営業チーム: 営業関連データのみアクセス
  • 財務チーム: 財務データの読み取り権限、他部門データへの制限アクセス
  • 経営陣: 集計済みダッシュボードデータのみアクセス

1. 基本構造の作成

-- カタログの作成
CREATE CATALOG IF NOT EXISTS prod_data;
CREATE CATALOG IF NOT EXISTS dev_data;
CREATE CATALOG IF NOT EXISTS analytics_mart;

-- スキーマの作成
-- 生産データ用
CREATE SCHEMA IF NOT EXISTS prod_data.raw_data;
CREATE SCHEMA IF NOT EXISTS prod_data.clean_data;
CREATE SCHEMA IF NOT EXISTS prod_data.business_data;

-- 部門別データ用
CREATE SCHEMA IF NOT EXISTS analytics_mart.sales;
CREATE SCHEMA IF NOT EXISTS analytics_mart.finance;
CREATE SCHEMA IF NOT EXISTS analytics_mart.marketing;
CREATE SCHEMA IF NOT EXISTS analytics_mart.executive;

-- 開発環境用
CREATE SCHEMA IF NOT EXISTS dev_data.sandbox;
CREATE SCHEMA IF NOT EXISTS dev_data.testing;

2. グループ別権限設定

データエンジニアチーム（最高権限）

-- データエンジニア用のグループ作成
CREATE GROUP IF NOT EXISTS 'data_engineers';

-- 生産環境への完全アクセス
GRANT ALL PRIVILEGES ON CATALOG prod_data TO GROUP 'data_engineers';
GRANT ALL PRIVILEGES ON CATALOG analytics_mart TO GROUP 'data_engineers';

-- 開発環境への完全アクセス
GRANT ALL PRIVILEGES ON CATALOG dev_data TO GROUP 'data_engineers';

-- システム関数へのアクセス
GRANT USAGE ON CATALOG system TO GROUP 'data_engineers';

データアナリストチーム（分析用データの読み取り）

-- データアナリスト用のグループ作成
CREATE GROUP IF NOT EXISTS 'data_analysts';

-- 分析マートへの読み取りアクセス
GRANT USAGE ON CATALOG analytics_mart TO GROUP 'data_analysts';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.sales TO GROUP 'data_analysts';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.marketing TO GROUP 'data_analysts';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.finance TO GROUP 'data_analysts';

-- クリーンデータへの読み取りアクセス
GRANT USAGE ON CATALOG prod_data TO GROUP 'data_analysts';
GRANT USAGE, SELECT ON SCHEMA prod_data.clean_data TO GROUP 'data_analysts';

-- 開発環境での実験用アクセス
GRANT USAGE ON CATALOG dev_data TO GROUP 'data_analysts';
GRANT ALL PRIVILEGES ON SCHEMA dev_data.sandbox TO GROUP 'data_analysts';

営業チーム（営業データのみ）

-- 営業チーム用のグループ作成
CREATE GROUP IF NOT EXISTS 'sales_team';

-- 営業関連データのみアクセス
GRANT USAGE ON CATALOG analytics_mart TO GROUP 'sales_team';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.sales TO GROUP 'sales_team';

-- 特定テーブルへの制限付きアクセス
-- 顧客データは参照可能だが、収益詳細は不可
GRANT SELECT ON TABLE analytics_mart.sales.customers TO GROUP 'sales_team';
GRANT SELECT ON TABLE analytics_mart.sales.opportunities TO GROUP 'sales_team';
GRANT SELECT ON TABLE analytics_mart.sales.activities TO GROUP 'sales_team';
-- 注意：sales.revenue_details テーブルには権限を付与しない

財務チーム（財務データ重点、他制限）

-- 財務チーム用のグループ作成
CREATE GROUP IF NOT EXISTS 'finance_team';

-- 財務データへの完全アクセス
GRANT USAGE ON CATALOG analytics_mart TO GROUP 'finance_team';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.finance TO GROUP 'finance_team';

-- 他部門データへの制限付きアクセス
GRANT USAGE, SELECT ON SCHEMA analytics_mart.sales TO GROUP 'finance_team';
-- ただし、顧客の個人情報は除外（後述のRow/Column Level Securityで制御）

-- 経営指標データへのアクセス
GRANT USAGE, SELECT ON SCHEMA analytics_mart.executive TO GROUP 'finance_team';

経営陣（集計データのみ）

-- 経営陣用のグループ作成
CREATE GROUP IF NOT EXISTS 'executives';

-- 経営ダッシュボード用データのみアクセス
GRANT USAGE ON CATALOG analytics_mart TO GROUP 'executives';
GRANT USAGE, SELECT ON SCHEMA analytics_mart.executive TO GROUP 'executives';

-- 高レベル集計データのみアクセス可能
-- 個別取引や個人情報は参照不可

3. Row Level Security (RLS) の実装

特定の行のみアクセス可能にする行レベルセキュリティを設定します：

-- 地域別の営業担当者が自分の地域のデータのみ参照可能
CREATE OR REPLACE FUNCTION analytics_mart.sales.current_user_region()
RETURNS STRING
RETURN (
  CASE 
    WHEN current_user() = 'john.doe@company.com' THEN 'East'
    WHEN current_user() = 'jane.smith@company.com' THEN 'West'
    WHEN current_user() = 'bob.johnson@company.com' THEN 'North'
    ELSE NULL
  END
);

-- 顧客テーブルにRow Level Securityを適用
CREATE OR REPLACE TABLE analytics_mart.sales.customers_secure (
  customer_id BIGINT,
  customer_name STRING,
  region STRING,
  revenue DECIMAL(12,2),
  personal_info STRING
) 
USING DELTA
TBLPROPERTIES (
  'delta.enableRowLevelSecurity' = 'true'
);

-- RLSポリシーの設定
ALTER TABLE analytics_mart.sales.customers_secure 
SET ROW FILTER current_user_region() = region ON (region);

4. Column Level Security (CLS) の実装

機密カラムへのアクセスを制御します：

-- 機密情報マスキング関数の作成
CREATE OR REPLACE FUNCTION mask_personal_info(data STRING)
RETURNS STRING
RETURN (
  CASE 
    WHEN is_member('finance_team') OR is_member('data_engineers') THEN data
    ELSE 'MASKED'
  END
);

-- カラムレベルでのマスキング適用
CREATE OR REPLACE TABLE analytics_mart.sales.customers_with_masking (
  customer_id BIGINT,
  customer_name STRING,
  email STRING MASK mask_personal_info,
  phone STRING MASK mask_personal_info,
  credit_score INT MASK mask_personal_info,
  revenue DECIMAL(12,2)
) 
USING DELTA;

データ発見とカタログ管理

メタデータの充実

Unity Catalogでは、データの発見性を高めるためのメタデータ管理が重要です：

-- テーブルにコメントとタグを追加
ALTER TABLE analytics_mart.sales.customers 
SET TBLPROPERTIES (
  'comment' = '顧客マスターデータ。営業活動とマーケティング施策で使用',
  'data_classification' = 'confidential',
  'data_owner' = 'sales_team',
  'refresh_frequency' = 'daily',
  'data_source' = 'CRM_system',
  'created_by' = 'data_engineering',
  'business_glossary' = 'customer_360'
);

-- カラムレベルのコメント追加
ALTER TABLE analytics_mart.sales.customers 
ALTER COLUMN customer_id COMMENT '一意の顧客識別子';
ALTER TABLE analytics_mart.sales.customers 
ALTER COLUMN email COMMENT '顧客のメールアドレス（PII）';
ALTER TABLE analytics_mart.sales.customers 
ALTER COLUMN credit_score COMMENT '信用スコア（機密情報）';

タグベースの分類

-- システムタグの作成と適用
CREATE TAG IF NOT EXISTS data_classification;
CREATE TAG IF NOT EXISTS pii_level;
CREATE TAG IF NOT EXISTS retention_period;

-- テーブルにタグを適用
ALTER TABLE analytics_mart.sales.customers 
SET TAGS (
  'data_classification' = 'confidential',
  'pii_level' = 'high',
  'retention_period' = '7_years'
);

-- カラムレベルでのタグ適用
ALTER TABLE analytics_mart.sales.customers 
ALTER COLUMN email SET TAGS ('pii_level' = 'high');
ALTER TABLE analytics_mart.sales.customers 
ALTER COLUMN phone SET TAGS ('pii_level' = 'high');

データリネージの活用

Unity Catalogは、データの変換フローを自動的に追跡します。これにより、以下が可能になります：

1. データの影響範囲分析

-- 特定テーブルの変更が他にどう影響するかを確認
-- Unity CatalogのUIまたはAPIで確認可能

-- データリネージの確認例（疑似SQL）
SHOW LINEAGE FOR TABLE analytics_mart.sales.customer_summary;
-- 結果：prod_data.raw_data.customers → prod_data.clean_data.customers → analytics_mart.sales.customer_summary

2. データ品質の追跡

-- データ品質メトリクスを含むリネージテーブル
CREATE OR REPLACE TABLE system.lineage.data_quality_tracking (
  table_name STRING,
  upstream_table STRING,
  transformation_type STRING,
  quality_score DECIMAL(5,2),
  record_count BIGINT,
  processing_timestamp TIMESTAMP
) USING DELTA;

-- ETL処理時にリネージ情報を記録
INSERT INTO system.lineage.data_quality_tracking VALUES
('analytics_mart.sales.customer_summary', 
 'prod_data.clean_data.customers', 
 'aggregation', 
 98.5, 
 150000, 
 current_timestamp());

監査とコンプライアンス

アクセスログの確認

Unity Catalogでは、すべてのデータアクセスが自動的にログ記録されます：

-- アクセス監査ログの確認
SELECT 
  user_identity.email as user_email,
  request_params.full_name_arg as table_name,
  action_name,
  event_time,
  source_ip_address
FROM system.access.audit
WHERE action_name IN ('SELECT', 'UPDATE', 'DELETE', 'INSERT')
  AND event_time >= current_timestamp() - INTERVAL 24 HOURS
  AND request_params.full_name_arg LIKE '%customer%'
ORDER BY event_time DESC;

データ使用状況の分析

-- データ使用頻度の分析
CREATE OR REPLACE TABLE analytics_mart.governance.data_usage_summary
AS SELECT 
  request_params.full_name_arg as table_name,
  COUNT(*) as access_count,
  COUNT(DISTINCT user_identity.email) as unique_users,
  DATE(event_time) as access_date
FROM system.access.audit
WHERE action_name = 'SELECT'
  AND event_time >= current_date() - INTERVAL 30 DAYS
GROUP BY request_params.full_name_arg, DATE(event_time)
ORDER BY access_count DESC;

運用のベストプラクティス

1. 権限設計の原則

最小権限の原則

-- ❌ 悪い例：過剰な権限付与
GRANT ALL PRIVILEGES ON CATALOG prod_data TO GROUP 'analysts';

-- ✅ 良い例：必要最小限の権限
GRANT USAGE ON CATALOG prod_data TO GROUP 'analysts';
GRANT USAGE, SELECT ON SCHEMA prod_data.clean_data TO GROUP 'analysts';

職務分離の実装

-- データエンジニア：データ作成・変更権限
GRANT CREATE, MODIFY ON SCHEMA prod_data.clean_data TO GROUP 'data_engineers';

-- データアナリスト：読み取り専用
GRANT SELECT ON SCHEMA prod_data.clean_data TO GROUP 'data_analysts';

-- 監査担当：監査ログへの読み取り専用アクセス
GRANT SELECT ON SCHEMA system.access TO GROUP 'audit_team';

2. 環境分離

-- 環境別のカタログ設計
-- 開発環境：自由度高め
CREATE CATALOG dev_data;
GRANT ALL PRIVILEGES ON CATALOG dev_data TO GROUP 'developers';

-- ステージング環境：制限あり
CREATE CATALOG staging_data;
GRANT USAGE, SELECT ON CATALOG staging_data TO GROUP 'developers';
GRANT ALL PRIVILEGES ON CATALOG staging_data TO GROUP 'data_engineers';

-- 本番環境：厳格な制御
CREATE CATALOG prod_data;
GRANT ALL PRIVILEGES ON CATALOG prod_data TO GROUP 'data_engineers';
GRANT USAGE, SELECT ON CATALOG prod_data TO GROUP 'data_analysts';

3. 定期的な権限レビュー

-- 権限レビュー用のクエリ
CREATE OR REPLACE VIEW analytics_mart.governance.permission_review AS
SELECT 
  grantee,
  object_type,
  object_key,
  privilege_type,
  inherited_from
FROM system.information_schema.effective_privileges
WHERE grantee NOT LIKE '%service%'  -- サービスアカウント除外
ORDER BY grantee, object_key;

-- 未使用の権限を特定
CREATE OR REPLACE VIEW analytics_mart.governance.unused_permissions AS
SELECT DISTINCT
  p.grantee,
  p.object_key as table_name,
  p.privilege_type
FROM system.information_schema.effective_privileges p
LEFT JOIN system.access.audit a 
  ON p.grantee = a.user_identity.email 
  AND p.object_key = a.request_params.full_name_arg
  AND a.event_time >= current_date() - INTERVAL 90 DAYS
WHERE a.user_identity.email IS NULL
  AND p.privilege_type = 'SELECT'
  AND p.object_type = 'TABLE';

トラブルシューティング

よくある問題と解決法

1. 権限エラー

問題: Permission denied エラーが発生

診断方法:

-- ユーザーの権限を確認
SHOW GRANTS ON TABLE analytics_mart.sales.customers TO 'user@company.com';

-- 有効な権限を確認
SELECT * FROM system.information_schema.effective_privileges
WHERE grantee = 'user@company.com'
  AND object_key = 'analytics_mart.sales.customers';

解決法:

-- 不足している権限を付与
GRANT USAGE ON CATALOG analytics_mart TO 'user@company.com';
GRANT USAGE ON SCHEMA analytics_mart.sales TO 'user@company.com';
GRANT SELECT ON TABLE analytics_mart.sales.customers TO 'user@company.com';

2. パフォーマンス問題

問題: 大量の権限チェックによる処理遅延

解決法:

-- 権限キャッシュの最適化
ALTER CATALOG analytics_mart SET TBLPROPERTIES (
  'delta.enableChangeDataFeed' = 'false'  -- 不要な場合は無効化
);

-- グループベースの権限管理を優先
-- 個別ユーザーではなくグループに権限を付与
GRANT SELECT ON SCHEMA analytics_mart.sales TO GROUP 'sales_team';

3. メタデータ同期問題

問題: 権限変更が反映されない

解決法:

-- メタデータを手動で更新
REFRESH TABLE analytics_mart.sales.customers;

-- Unity Catalogメタストアの同期確認
DESCRIBE EXTENDED analytics_mart.sales.customers;

まとめ

Unity Catalogによるデータガバナンスは、下記要素で構成されます。

🏛️ 統合的なガバナンス

1. 権限管理の統一
2. メタデータ管理の充実
3. 自動リネージ追跡
4. 監査とコンプライアンス

Unity Catalogは、適切に設計・運用することで、データの安全性、発見性、追跡可能性を大幅に向上させることができます。

Discussion