Zenn
🌏

【Databricks】Unity Catalog：8つの機Databricks

に公開
Databricks
DataGovernance
Lakehouse
Unity Catalog
データ共有と外部連携
tech

本記事は 「Databricksではじめるデータ基盤ガイド：はじめてのデータウェアハウス」 を読んで理解した内容を纏めています。こちらの本（以降、本書という）には「Unity Catalog」以外の技術要素についても記載がありますので、ご興味あればご購入してみて下さい。

以前私が記載したRBACの記事についてもリンクを張っておきます。
Databricks RBAC（Role-Based Access Control）の技術解説

第1章　Unity Catalogとは何か

1.1 はじめに

データ活用が進むにつれて、多くの組織は共通の課題に直面します。
「誰がどのデータにアクセスできるのか？」「データは信頼できるのか？」「AIモデルやファイルも含めて一元的に管理できるのか？」
これらに応えるのが Databricks が提供する Unity Catalog（UC） です。

1.2 Unity Catalogの位置づけ

Unity Catalogは、Databricksの レイクハウス・アーキテクチャ における データとAI資産のガバナンスレイヤー です。

  • レイクハウスとは？
    従来のDWH（データウェアハウス）の厳格な管理と、データレイクの柔軟性を統合した仕組み。
    Databricksでは、このレイクハウス上でBI分析からAI/MLまでを一気通貫で扱えます。
  • UCの役割
    このレイクハウス全体を横断的に管理する “OS的な存在” がUnity Catalog。
    データベース的な「格納庫」ではなく、アクセス制御・監査・発見性・連携といった機能を統合する「管理基盤」です。

1.3 Unity Catalogでできること（8つの柱）

本書では、UCで提供される機能が8つに整理されています。
この記事でも、この8機能を今後の章立ての中心に据えて解説します。

1. 構造化データの管理（テーブル／ビューの統制）
2. 非構造化データの管理（ファイル／フォルダをUC配下で扱う Volumes）
3. AIモデルの管理（Model Registryの統合、ライフサイクル管理）
4. データ・AI資産のディスカバリー（タグ付け、検索、カタログ探索）
5. データ品質のモニタリング（統計・メタデータによる品質検知）
6. 監査（アクセス履歴、権限、リネージの可視化）
7. Lakehouse Federation（外部DBを仮想的に統合）
8. Delta Sharing（クロスクラウド・クロスワークスペースでのデータ共有）

👉 記事全体では、3章・4章でこの8つをグループごとに解説していきます。

1.4 Unity Catalogが必要とされる背景

1. 権限管理の複雑化

データソースが増えるにつれ、「誰がどこにアクセスできるか」をサービスごとに管理するとスケールしません。

2. データの信頼性と重複

部門ごとにコピーされたExcelやParquetファイルが乱立 → どれが「正」か分からない問題。

3. コンプライアンスと監査対応

アクセスログや利用経路（リネージ）の証跡を残すことが必須に。

4. AI・非構造化データの急増

これまでは構造化データ中心だったが、IoTログ・PDF・画像・AIモデルも「統治対象」となった。

Unity Catalogは、こうした「多様な資産をセキュアに管理しつつ利用可能にする」ために設計されていると私は理解しています。

第2章　Unity Catalogのアーキテクチャ基礎

Unity Catalog (UC) を理解するためには、まず アーキテクチャ（内部構造） を押さえる必要があります。
UCの全体像を知ることで、次章以降に紹介する「8つの機能」がどのように実現されているかが見えてきます。

2.1 Unity Catalogの階層構造

UCでは、データや資産を 4階層のネームスペース で管理します。

  1. Metastore
    • UC全体の最上位。
    • テナントごとに1つ作成され、すべてのカタログ・権限・監査ログを統括する。
  2. Catalog
    • データ管理の単位。
    • ドメイン／事業部／機密区分などの「境界」を定義するのに適している。
  3. Schema（データベース）
    • カタログ内の論理的グループ。
    • raw, staging, mart など用途ごとに分けることが多い。
  4. Object（Table, View, Function, Volume, Model …）
    • 実際のデータ資産。
    • テーブルやビューに加え、非構造化ファイル（Volume）、機械学習モデル（Model）も対象。

👉 この構造により、「データ＋AI資産を統一的に扱える」 のがUCの特徴です。

Unity Catalog オブジェクトモデル図

2.2 権限継承とアクセス制御

UCのもう一つの柱は 権限継承モデル です。

  • カタログに付与した権限はスキーマ・テーブルに継承される
    例：sales_catalog に SELECT を与えると、配下の全テーブルが対象に。
  • 例外は下位で上書き可能
    特定テーブルだけアクセス制御を厳しくすることも可能。
  • 細粒度制御
    • Row Filter（返す行を制限）
    • Column Mask（返すカラム値をマスク）
    • ABAC（タグや属性による動的ポリシー）

本書でも、Row Filter / Column Mask の仕組みが具体的に説明されており、これらがUCのセキュリティ基盤であることが示されています。

2.3 メタデータ管理とシステムテーブル

UCでは、データや操作履歴に関する情報を システムテーブル として管理しています。

  • 情報例
    • テーブルのリネージ（どの処理から生成されたか）
    • ユーザーアクセスログ
    • クエリ実行履歴
      これにより、「誰が・いつ・どのデータを利用したか」 を追跡可能。
      本書でも、監査やリネージを支える仕組みとしてこの考え方が登場しています

2.4 外部連携を可能にする仕組み

UCのアーキテクチャは、Databricks内部のデータ管理だけでなく、外部との接続も想定しています。

  • Lakehouse Federation
    外部データベース（Snowflake、BigQuery、Redshiftなど）を「外部カタログ」として登録し、UC配下から直接クエリ可能。
  • Delta Sharing / Clean Rooms
    UCの権限モデルをそのまま活用して、安全にデータを外部組織と共有。

👉 これらの外部連携も、「カタログ階層」「権限継承」「システムテーブル」 という基盤の上に成り立っています。

2.5 まとめ

  • UCは 4階層（Metastore → Catalog → Schema → Object） でデータ・AI資産を管理する。
  • 権限は 上位から下位へ継承し、必要に応じて上書き可能。
  • Row Filter／Column Mask／ABAC で細粒度な制御を実現。
  • システムテーブルで監査・リネージ・アクセスログを一元管理。
  • これらの基盤があるからこそ、次章以降で紹介する「8つの機能」が成り立っている。

第3章　UCでできること①〜④（データとAI資産の管理・探索）

Unity Catalog (UC) の強みは、単なるテーブル管理に留まらず、非構造化データやAIモデルを含めた資産全体をガバナンス対象にできることです。

3.1 構造化データの管理（①）

役割

  • テーブルやビューといった 構造化データを階層的に整理 し、権限を付与できる。
  • Row Filter / Column Mask による 細粒度制御 が可能。

ユースケース

  • sales カタログ配下に raw/staging/mart スキーマを置き、部門別のテーブルを格納。
  • マーケティング部門は SELECT 権限のみ、データエンジニアは INSERT/UPDATE も許可。

基本機能

機能 内容
権限 - Unity Calalogではカタログ、スキーマ、テーブル、ボリューム、AIモデル、関数のアクセス制御を行うことができる。
- カタログ配下の権限は継承される。つまり、カタログまたはスキーマに対する特権を付与すると、そのカタログまたはスキーマ内の現在および将来のすべてのオブジェクトに特権が自動的に付与される。
履歴 - Deltaテーブルの場合は、テーブルに対してオペレーションが発行されるたびに自動で履歴が記録される。
依存関係
（リネージュ）		 - Databricksでクエリ間のデータリネージをキャプチャできる。
- 列レベルまでキャプチャされる。
洞察
（インサイト）		 - 頻繁に使用されるクエリ、ダッシュボード、ノートブック、結合テーブルを表示できる。
品質
（データ品質）		 レイクハウスモニタリングを用いることで、データ品質チェックを実施することができる。

※ 本書にはより詳細な内容が記述されています。

3.2 非構造化データの管理（Volumes）（②）

役割

  • 画像・動画・PDF・IoTログなど、ファイルベースのデータもUCで一元管理。
  • CREATE VOLUME により外部ストレージをUCに紐付け、権限制御や監査が可能。

ユースケース

  • 製造業での 検査画像データ を Volumes で管理し、品質部門は閲覧のみ許可。
  • AI学習用の テキストコーパス を統制下に置き、利用履歴を監査可能に。

ボリュームに格納されたデータへのアクセス

ボリュームに格納されたデータは/Volumes/から始まるパスでアクセス可能。

pdf= pd.read_csv("/Volumes/ktksk_catalog_demo/db_loan_status/volume_csv/lending_club.csv",header=0)
pdf.head()

3.3 AIモデルの管理（Models in UC）（③）

役割

  • MLflow Model Registry が UC に統合され、モデルも「データ資産」として管理可能。
  • バージョン管理、ステージング（Staging/Production）切り替え、権限付与、リネージ追跡が可能。

ユースケース

  • 顧客離反予測モデルを UC に登録し、マーケティングと営業が同じモデルを共有利用。

  • モデルのトレーニングデータ → ノートブック → モデル → ダッシュボード までリネージを追跡し、再現性を保証。

  • 最新動向（2025）

  • Workspace Model Registry は徐々に非推奨化され、UC Model Registry への移行が推奨されている。

  • クロスワークスペース配布や、AIガバナンス機能（モデルカード、説明可能性情報の付与）が強化されつつある。

3.4 データ・AI資産のディスカバリー（④）

役割

  • LLMを用いたメタデータの自動付与
  • Catalog Explorer を使って、テーブル／ビュー／モデル／Volumes を横断検索。
  • タグや属性（例：地域=JP、機密度=高）を付与し、探索性を高める。
  • Databricks Assistant や AIクエリ補助で、自然言語から資産を検索可能。

ユースケース

  • 「顧客データ」と入力すると、関連するテーブルやモデルが一覧で表示される。
  • データサイエンティストが、利用可能な特徴量テーブルや既存モデルを素早く発見。

第4章　UCでできること⑤〜⑧（品質・監査・外部連携）

4.1 データ品質のモニタリング（⑤）

データ品質のモニタリングは、データ分析に基づいて意思決定を行う企業にとって極めて重要です。Unity Catalogではレイクハウスモニタリングを用いることでデータ品質/AIモデルの監視を実施することができる。

役割

  • UCはデータの統計情報（カラムごとの min/max 値、null数など）を管理し、品質チェックに活用できる。
  • Unity Catalogの システムテーブル と組み合わせることで、SLO（サービスレベル目標）管理 の基盤を提供。

ユースケース

  • センサーデータで「異常に多い null 値」を自動検知し、データパイプラインをアラート。
  • ゴールドテーブル更新が遅延している場合、SLO違反を検出し通知。

4.2 監査（Audit）（⑥）

役割

  • UCはすべてのアクセスや操作を 監査ログ／システムテーブル に記録する。
  • 「誰が・いつ・どのデータに・どんな操作をしたか」を可視化可能。

ユースケース

  • 規制対応（金融・医療など）で「顧客データに誰がアクセスしたか」を即座に報告。
  • データ流出の調査時に「対象テーブルへの直近30日のアクセス履歴」を抽出。

システムテーブルについては以下を参考にして下さい。
システムテーブルでアカウントアクティビティを監視する

4.3 Lakehouse Federation（外部DBのミラーリング）（⑦）

「クエリフェデレーション」という用語は、すべてのデータを単一の統合システムに格納することなく、ユーザとシステムが複数のデータベースに分散配置されたデータに対してクエリを実行できるようにする機能を意味している。

役割

  • UCは 外部データベース（Snowflake, BigQuery, Redshift, SQL Serverなど） を「外部カタログ」として登録可能。
  • Databricksのクエリから直接外部データにアクセスできる。

メリット

  • データ移動不要（ETLレス）で外部DBに接続可能。
  • セキュリティはUCの権限モデルに統合。

ユースケース

  • マーケティングデータはBigQueryに、顧客マスタはSnowflakeにある → UC配下から単一クエリで参照。
  • 外部DBを「ミラー」として参照しつつ、段階的にレイクハウスへ移行。

4.4 Delta Sharing（データ共有）（⑧）

役割

  • Databricks同士、あるいは他プラットフォームと オープンプロトコル でデータ共有。
  • 受け手は「共有されたカタログ」を直接参照できる。

最新動向（2025）

  • Clean Rooms が登場し、共有データをそのまま渡すのではなく「制限付きクエリ実行環境」で安全に共同分析可能に。
  • EUや金融領域では、Clean Roomsを用いたセキュアなコラボレーションが進んでいる。

ユースケース

  • パートナー企業と購買データを共有し、Clean Room内でジョイント分析。
  • 複数の子会社がそれぞれの売上データを共有し、親会社が統合分析。

第5章　アーキテクチャと8機能のつながり

第3章・第4章で紹介した「UCでできること8つ」は、それぞれ独立した機能のように見えますが、実際には 共通のアーキテクチャ基盤 の上に成り立っています。

5.1 UCアーキテクチャの基本要素

UCの全機能を支えているのは、大きく分けて以下の要素です。

  • 階層構造（Metastore → Catalog → Schema → Object）
  • 権限継承モデル（カタログ単位で付与し、下位に継承）
  • システムテーブル（アクセスログ・クエリ履歴・リネージ）
  • 外部連携コンポーネント（Federation／Delta Sharing／Clean Rooms）

これらを「基盤」として見たとき、8機能はその上に「用途別に展開したアプリケーションレイヤー」として成り立っています。

5.2 機能①〜⑧と基盤の関係

  1. 構造化データの管理：①
    → 階層構造と権限継承モデルにより実現。
    → Row Filter / Column Mask が追加の細粒度制御を補完。

  2. 非構造化データの管理：②
    → Volumes と外部ロケーションを UC 階層の中に統合。
    → 権限モデルをそのまま適用できるのがポイント。

  3. AIモデルの管理：③
    → Object として「Model」を追加し、UCの権限／リネージの枠組みを再利用。
    → システムテーブルにより「学習データ ↔ モデル ↔ 推論ジョブ」の依存関係を追跡。

  4. データ・AI資産のディスカバリー：④
    → Catalog Explorer（UI）とシステムテーブル（API）が基盤。
    → タグ／属性を利用して検索性を高める。

  5. データ品質のモニタリング
    → システムテーブルが提供する統計情報・エラー記録を活用。
    → 権限モデルにより「誰が品質メトリクスを見られるか」も制御可能。

  6. 監査
    → システムテーブル／監査ログが基盤。
    → 「誰が・いつ・どのデータを利用したか」を統合的に保持。

  7. Lakehouse Federation
    → 外部カタログを「仮想的にUC配下に置く」仕組み。
    → アーキテクチャ的には 外部メタデータをUCメタストアに統合 する位置づけ。

  8. Delta Sharing
    → UCの権限管理と監査ログを活かして、安全な共有を提供。
    → Clean Roomsは「外部にデータを渡さずにクエリだけ許可する」新しい実行レイヤー。

5.3 繋がりをイメージ化

以下のように整理すると、理解しやすいと思います。

[基盤]
 ├─ 階層構造 (Metastore/Catalog/Schema/Object)
 ├─ 権限継承モデル
 ├─ システムテーブル / リネージ / ログ
 └─ 外部連携コンポーネント

   ↓ この基盤上で展開される8機能 ↓

 ① 構造化データ管理       → 階層構造＋権限
 ② 非構造化データ管理     → Volumes＋権限
 ③ AIモデル管理           → Object拡張＋リネージ
 ④ ディスカバリー         → システムテーブル＋タグ
 ⑤ データ品質モニタリング → システムテーブル
 ⑥ 監査                   → システムテーブル＋ログ
 ⑦ Federation            → 外部カタログ統合
 ⑧ Delta Sharing         → 権限＋外部共有プロトコル

5.4 まとめ

  • Unity Catalogの8機能は、共通のアーキテクチャ基盤の上に成り立っている。
  • 階層構造・権限継承・システムテーブル・外部連携コンポーネントがすべての機能の支柱。
  • 機能を個別に見るだけでなく、「どの基盤要素が支えているか」を理解すると、設計や運用の最適化に繋がる。
  • 「アーキテクチャ理解が機能理解につながる」という視点が重要。

第6章　設計と運用のベストプラクティス

Unity Catalog (UC) の導入において最も重要なのは、最初の設計と日々の運用をどう行うかです。本書では、カタログ階層や移行方法が解説されており、UCを効果的に使うにはベストプラクティスを押さえることが欠かせません。

6.1 カタログの設計指針

境界は「責任単位」で切る

  • 推奨：ドメイン／事業部／規制境界／外部共有単位ごとにカタログを作成
  • 避けるべき：ユーザー単位や環境単位（dev/stg/prod）だけで細かく分けること（複雑化の元）

👉 本書でも、カタログがUCの最上位単位であり「セキュリティ・責任の境界」として設計することが示されています。

命名規則のベストプラクティス

  • catalog.schema.table の3階層を前提に、統一感を持たせる
  • 例：sales_prod.raw_orders, sales_prod.mart_customer
  • 命名で「環境」「部門」「用途」を一目で分かるようにする

6.2 スキーマとテーブルの整理

  • スキーマ：用途別に（例：raw, staging, mart, sandbox）
  • テーブル：更新方式（Append型、Upsert型、SCD Type2など）を統一ルールで設計
  • ビュー：ビジネスロジックを隠蔽し、データ利用者に安定したインターフェースを提供

6.3 権限とポリシー設計

最小権限の原則 (PoLP)

  • まずは Catalog単位でRead-Onlyを付与
  • 書込み／管理権限は最小限のグループにのみ付与

細粒度制御（Row Filter / Column Mask / ABAC）

  • 個人情報／地域制御が必要な場合はRow Filter・Column Maskで制御
  • 複雑な条件は ABAC（属性ベースアクセス制御） で整理（タグ設計を先に行うのがポイント）

6.4 データ品質と監査の運用

  • システムテーブルを定期クエリで監視し、SLO違反や異常パターンを早期検知
  • 監査ログは外部SIEM（Splunk, Datadogなど）とも連携して保存
  • 本書でも「監査と品質管理」がUCの機能として紹介されており、実運用の中核になる部分

6.5 外部連携（Federation / Sharing）の活用

  • Federation：段階的移行やハイブリッド利用に有効（外部DBをそのまま参照）
  • Delta Sharing / Clean Rooms：外部パートナーとの共同分析をセキュアに実現
    👉 設計段階で「どこまでデータを外に見せるか」「共有範囲をどの境界にするか」を明確にすることが重要。

6.6 CI/CDと自動化

  • Terraform / Databricks Provider を活用し、カタログ・スキーマ・権限をIaC化
  • 検証環境 → 本番環境へはGitHub ActionsやAzure DevOps Pipelineで自動デプロイ
  • 「人手でカタログを作る」運用は避け、再現性あるIaC管理が推奨される

6.7 移行時のポイント（既存DWH → UC）

  • 段階的に「Federationで参照 → UC管理下へ移行」の流れが現実的
  • ストアドプロシージャや関数は互換性に注意（本書でも移行時の差異に触れられている）
  • Databricks AssistantやAI変換機能を活用すると、SQL移植の工数を削減できる

6.8 まとめ

  • カタログは責任境界ごとに切るのが設計の基本
  • スキーマ／テーブルは用途別、権限は最小限＋ABACで整理
  • 品質監視と監査ログ活用が実運用の肝
  • Federation/Sharingを計画的に使い分け、外部連携や移行をスムーズに
  • IaCによるCI/CD運用で再現性とセキュリティを高める

第7章　良い設計例 vs 悪い設計例（アンチパターン）対比表

Unity Catalog の「良い設計例 vs 悪い設計例（アンチパターン）」対比表を、設計と運用の主要観点ごとにまとめました。実装時のチェック観点（Why/リスク）も併記しています。

7.1 良い設計例 vs 悪い設計例（アンチパターン）

項目 良い設計 悪い設計（アンチパターン） なぜ良いか / リスク
カタログの境界 ドメイン/事業・規制・共有境界で切る
（例：sales, finance_pii, partner_x_cleanroom）		 個人/環境
（dev/stg/prod）だけで細切れに量産		 責任/監査の境界が明確。細切れは運用・監査・権限の重複地獄に。
スキーマの役割 用途で分割（raw, staging, mart, sandbox） テーブル乱立でスキーマは「その他」化 データライフサイクルが見える。混在は品質と可観測性が低下。
命名規則 <catalog>.<schema>.<table>で一貫。接頭辞/接尾辞で意味付け（mart_, dim_, fact_） 人によってバラバラ/略称乱立 発見性・学習コスト・自動化（CI/CD）に効く。命名はUI/検索性の基盤。
権限設計 カタログで一括付与→下位で例外最小化（PoLP） テーブルごと手当て・付け外し散発 継承を活かし事故を防ぐ。個別運用はスケールせずミスの温床。
細粒度制御 Row Filter/Column Maskを最小限・共通UDF化 条件をUDFに詰め込み肥大化/二重三重マスク 単純でテスト可能なポリシーが最適。複雑化は性能/保守性を劣化。
ABAC/タグ設計 先に共通タグ（region, sensitivity, owner）を定義し運用 後付けで都度タグ追加・表記揺れ 動的制御と探索性が向上。後追いはカタログのスパゲッティ化を招く。
ビュー層 ビジネスロジックはビューで抽象化（安定IF） テーブル直叩き＆アドホックSQL乱発 変更耐性が高まる。直叩きは下流破壊・影響範囲不明に。
リネージ活用 変更前にリネージで影響解析→リリース 変更/削除が勘と通知のみ MTTR短縮・監査対応に必須。勘運用は事故を増やす。
品質・SLO監視 システムテーブル/統計で更新遅延・NULL増加を監視 壊れてから気付く（手動点検） 早期検知・説明責任を担保。手運用はスケールしない。
Federationの使い方 段階移行/ハイブリッドで活用（権限はUC側に統合） 常時Federationで本番分析を回しっぱなし ETLレスは便利だが本番常用はSLA/コスト/最適化が不安定。
Delta Sharing/Clean Rooms 共有境界をカタログで設計。Clean Roomでクエリ制限 ファイル転送や恒久コピーで共有 最小権限/可撤回性/監査を確保。コピー共有はリーク&版ずれリスク。
Volumes（非構造化） Volumes＋外部ロケーションに集約。アクセスはUC経由 S3/ADLSの生URLを個々人が直参照 権限・監査が一元化。直参照は闇リンク化し統治不能。
モデル管理 Models in UCへ集約。Workspace Registryは段階廃止 ワークスペースごとに別Registry・手搬送 再現性/共有性/権限一元化。分散はバージョン地獄を招く。
CI/CD & IaC Terraform/Jobsでカタログ/権限/オブジェクトをコード化 手作業クリックと口伝手順 再現性/監査性/レビュー性を担保。手運用は人依存・ドリフト発生。
環境分離 可能ならWS/クレデンシャルで分離、カタログは最小 *-dev/-stg/-prodカタログが大量 権限/共有の重複を抑制。環境だけでカタログ増殖は管理困難に。
データ製品の責任 ドメインチームにオーナー明示（タグowner必須） 「みんなのテーブル」状態でオーナー不明 誰が品質/変更/問い合わせを担うか明確化。無責任体制を回避。
監査ログの扱い 外部SIEMに集約/保持期間ポリシー策定 既定保持のまま放置・突発抽出 追跡性/規制対応を実運用に組み込む。都度対応は漏れやすい。

7.2 導入時チェックリスト（スピード診断）

  • □ カタログ境界は「責任/規制/共有」で切れているか
  • □ スキーマは raw/staging/mart/sandbox 等で用途が分かれているか
  • □ PoLP：カタログでRead一括→例外は下位で最小化しているか
  • □ Row/Column/ABACはシンプルかつ共通UDF/共通タグで運用しているか
  • □ リネージとSLOはダッシュボード化されているか
  • □ Volumesで非構造化データをUC配下に統合しているか
  • □ Models in UCに統一できているか（移行計画は？）
  • □ Federationは段階移行/一時参照に留め、常用分析はレイクハウスへ取り込み済みか
  • □ Delta Sharing/Clean Roomsで共有し、ファイル配布をやめられているか
  • □ IaC/CI-CDで権限/オブジェクト/ジョブをコード管理しているか

Discussion