データ基盤

Unity Catalogとは？階層・権限・リネージの仕組みを解説

2026/10/10 シリーズ「Databricks 入門」 第3回 / 全4回

🤖 AIが執筆しています

GRANT USE CATALOG ON CATALOG sales TO `sales_analysts`;
GRANT USE SCHEMA, SELECT ON SCHEMA sales.gold TO `sales_analysts`;

Unity Catalog とは：Databricks に組み込まれたガバナンスの層

Databricks の文書は、Unity Catalog を、Databricks に組み込まれた、データと AI のための統合されたガバナンスの層と説明している³。2023 年 11 月 8 日より後に作られたワークスペースでは、Unity Catalog が自動で有効になる³。

ガバナンスの柱の文書は、データの安全を統制するための二つの要点として、だれがどのデータにアクセスできるかを理解することと、だれが最近どのデータにアクセスしたかを理解することを挙げる⁴。Unity Catalog の機能も、前者を受け持つ権限の仕組みと、後者を受け持つ監査とリネージの記録に分けて見ると整理しやすい。

階層：メタストアの下のカタログ、スキーマ、テーブル

Unity Catalog では、統制するものはすべて、セキュリティ保護可能なオブジェクト、つまり利用者やグループに権限を付けられるオブジェクトとして扱われる³。最上位はメタストアで、メタストアは一つのクラウドのリージョンに一つ置かれる⁵。メタストアの下では、たとえばテーブルを、カタログ名、スキーマ名、テーブル名の 3 段の名前（catalog.schema.table）で呼ぶ。

カタログはデータの資産の最上位の層で、組織の単位や、開発・本番といった開発の段階ごとに分けて使う。スキーマはカタログの中を、さらに細かい分類に分ける⁵。スキーマの中には、テーブルとビュー（クエリを保存した仮想の表）のほか、表の形をしないファイルの集まりを統制するボリューム、関数、機械学習のモデルが入る。クラウドのストレージに接続するためのオブジェクトは、カタログの下ではなく、メタストアの直下に置かれる³。ストレージ資格情報はストレージにアクセスするための認証の情報で、外部ロケーションはストレージのパスと、そこに入るためのストレージ資格情報の組である⁵。

ベストプラクティスの文書は、メタストアはリージョンを分けるためのもので、データを分ける単位としては想定しておらず、データを分ける主な単位はカタログだと書く⁶。ガバナンスの文書は、カタログを業務の領域（営業、マーケティング、財務など）ごとに分けることを推奨の型として挙げている²。

マネージドテーブルと外部テーブル

Unity Catalog のテーブルとボリュームには、マネージドと外部の 2 種類がある⁷。マネージドでは、Unity Catalog が、アクセスの制御・監査・リネージといった統制に加えて、ファイルの整理や削除の時期といった保存のライフサイクルも受け持つ。外部では、Unity Catalog は統制だけを受け持ち、ファイルは利用者が管理する保存先に置かれる。外部テーブルを削除しても、Unity Catalog からテーブルの情報が消えるだけで、データのファイルは残る。

マネージドテーブルは、Databricks の既定で、推奨のテーブルの種類である⁸。マネージドテーブルを誤って削除しても、既定では削除から 7 日間は UNDROP という命令で元に戻せ、その期間が過ぎるとデータのファイルが消される。この期間は、0 時間（戻せなくする）か 7〜30 日に変えられる（公開プレビューの機能）。Databricks は、外部テーブルもいずれはマネージドテーブルへ移すよう勧めている⁶。

マネージドテーブルの保存先を利用者が自分のクラウドに設定した場合は、ファイルはそのクラウドのアカウントの中に置かれ、そのライフサイクルを Unity Catalog が受け持つ⁹。ただし、デフォルトストレージ（サーバーレスのワークスペースが使える既定の保存先）は、利用者のクラウドのアカウントではなく、利用者の Databricks のアカウントの側にある¹⁰。また、Databricks の文書は、マネージドテーブルも外部のエンジンからオープンな API で読み書きできるので、マネージドテーブルはベンダーロックインを生まないと書く⁷。これは Databricks 自身の主張である。

権限の仕組み：明示的な付与と、下への継承

Unity Catalog では、利用者やグループが何かをするには、その権限を明示的に付与されている必要がある¹¹。

テーブルを読むには、テーブルへの SELECT、親のスキーマへの USE SCHEMA、親のカタログへの USE CATALOG の三つがすべて要る¹¹。USE の権限を付けられるのは、カタログやスキーマの所有者か、MANAGE の権限を持つ利用者だけなので、テーブルの所有者が、承認された範囲の外にいる人へ勝手にテーブルを共有することを防げる。

親のオブジェクトに付けた権限は、その下にある今の子と将来の子のすべてに自動で効く¹¹。ただし、メタストアに付けた権限は子に継承されず、カタログを作るといったメタストアの単位の操作だけを決める。所有権も下へは継承されない。MANAGE の権限を持つ利用者は、所有者でなくても、そのオブジェクトの権限の管理、所有権の移転、削除ができる。権限を誤って広げないよう、すべての権限をまとめて与える ALL PRIVILEGES には MANAGE が含まれない。BROWSE の権限は、データそのものは読ませずに、オブジェクトの存在とメタデータだけを見せる。

権限を付けられるのは、Databricks のアカウントの単位で定義した利用者、グループ、サービスプリンシパル（自動の処理のための ID）だけである⁶。ワークスペースの中だけで作った古い形のグループには、Unity Catalog のデータへの権限を付けられない¹²。そのうえでベストプラクティスの文書は、権限は個人ではなくグループに付け、多くのオブジェクトの所有者もグループにすることを勧めている⁶。本番のテーブルへ直接書き込む権限は、人ではなく、サービスプリンシパルに限るよう書いている。

また、既定では、同じメタストアにつながるすべてのワークスペースから、すべてのカタログが見える。ただし、新しいワークスペースと一緒に自動で作られるワークスペースのカタログは、既定でそのワークスペースだけに結びついている¹³。カタログを特定のワークスペースに結びつけると、結びつけていないワークスペースからは、カタログへの権限を持つ利用者でもアクセスできなくなる¹³。

行と列の単位の制御：行フィルター、列マスク、ABAC

テーブル単位の権限だけでは、同じテーブルの中で、人によって見せる行や列を変えられない。そのために、Unity Catalog には行フィルターと列マスクがある¹⁴。行フィルターは、クエリのたびに各行を評価する SQL の関数で、利用者が見られる行を絞る。列マスクは、特定の列で利用者に見せる値を変える。たとえば、人事のテーブルの給与の列を、人事部以外の利用者には隠せる。

多くのテーブルに同じ規則をそろえて適用するには、属性ベースのアクセス制御（ABAC）を使う¹⁴。ABAC では、オブジェクトに管理タグ（governed tags）を付け、そのタグを条件にしたポリシーをカタログやスキーマに付ける¹⁵。カタログに付けたポリシーは、その中のすべてのテーブルに効き、個々のテーブルの所有者はそれを外せない¹⁶。テーブルに付けた行フィルターや列マスクも、ABAC の行フィルターや列マスクのポリシーも、それだけではデータへのアクセスを与えず、オブジェクトへの権限の上に制限を加える¹⁶。これとは別に、ABAC には、条件に合うオブジェクトに権限を与える GRANT のポリシーもある¹⁵。ABAC は 2026 年 4 月に一般提供になり、このとき、ビューを通してクエリを実行したときの絞り込みを、ビューの所有者ではなくクエリを実行した利用者の ID で評価するよう、動作が変わった¹⁷。拒否のポリシーやメタストアの単位のポリシー、ビューへの適用は、まだベータの段階である¹⁵。

リネージと監査：何が記録され、何が記録されないか

Unity Catalog は、Databricks で実行されたクエリについて、リネージを列の単位まで自動で記録し、同じメタストアにつながるすべてのワークスペースの分をまとめる¹⁸。記録されるのは、Spark の DataFrame（Spark で表の形のデータを扱う型）を使う処理や、ノートブックや SQL エディタのような Databricks SQL の経路で実行したクエリである。テーブルへの BROWSE か SELECT の権限が無い利用者は、そのテーブルのリネージを見られない。

一方で、同じ文書は、記録されない場合を挙げている¹⁸。2024 年 9 月 1 日より前のリネージは見られない。カタログ、スキーマ、テーブル、ビュー、列の名前を変えると、リネージは引き継がれない。Spark の RDD という古い形のデータ処理は記録されない。読み書きの相手をパスで指定すると、列の単位のリネージは記録されない。利用者が書いた関数（UDF）のリネージは、テーブルの単位でしか記録されない。リネージをクエリで調べられるシステムテーブル（Databricks が運用の記録を表として置くもの）が保持するのは直近 1 年分で、記録されるのはすべての読み書きのうちの一部である¹⁹。

だれがいつ何をしたかは、監査ログに記録される。監査ログを SQL のクエリで調べられるシステムテーブル system.access.audit は、2026 年 10 月の時点でまだ公開プレビューの段階である²⁰。

権限が届かない経路

Unity Catalog の権限は、Unity Catalog を通るアクセスにしか効かない。クラウドのストレージへの接続の文書は、マネージドテーブルの保存先のバケットへの直接のアクセスを利用者やサービスプリンシパルに与えないよう勧め、そこにアクセスしてよいのは Unity Catalog が使う ID だけだと書く⁹。バケットに直接アクセスできる利用者は Unity Catalog のアクセス制御を回避でき、その直接のアクセスは監査やリネージにも記録されないからである。外部テーブルについても、外部のシステムからデータのファイルを直接読むときには、Unity Catalog の権限は適用されない²¹。また、Hive メタストアへの古い形のアクセスを止めても、クラスター（処理を動かす計算資源の組）に付けたクラウドの資格情報は使えるので、これも Unity Catalog の外の経路として残る²²。

外部のエンジンに Unity Catalog を通して読ませる経路もある。Unity Catalog は、Delta Lake のクライアント向けの Unity REST API と、Apache Iceberg のクライアント向けの Iceberg REST カタログという、外部のプログラムから呼べる二つの窓口を提供している²³。クレデンシャルベンディングでは、Unity Catalog が外部のエンジンに有効期限の短い資格情報を渡し、その資格情報は連携を設定した Databricks の利用者の権限を引き継ぐ²⁴。この外部からのアクセスは既定で無効で、ALL PRIVILEGES にも外部利用の権限は含まれない²⁵。資格情報を渡してファイルを直接読ませる方式では、行フィルターや列マスクの付いたテーブルは読めない²⁴。2026 年 10 月には、こうしたテーブルを、Databricks のサーバーレスの計算資源が絞り込んでから外部のエンジンに返す方式が一般提供になった²⁶。ただし、対象は特定の方式で作ったマネージドテーブルに限られ、使えるのは読み取りだけである²⁷。

権限とリネージは、メタストアの境界も越えない⁶。別のリージョンのメタストアにデータを共有すれば、共有先で権限を付け直す必要がある。

以前の仕組みと、オープンソース版

Unity Catalog の前は、ワークスペースごとの Hive メタストアと、そのテーブルのアクセス制御が使われていた。この方式では、クラスターでテーブルのアクセス制御を有効にしない限り、すべての利用者が Hive メタストアのすべてのデータにアクセスできた²⁸。Databricks は、Unity Catalog の利点を、アカウントの中の複数のワークスペースにまたがるデータのアクセスを一か所で管理し監査できることだと説明する²⁸。ワークスペースごとの Hive メタストアは Databricks の文書でレガシーの機能とされ、Unity Catalog への移行が勧められている。Hive メタストアのテーブルでは、組み込みの監査、リネージ、アクセス制御をはじめとする Unity Catalog の統制の機能を、すべては使えない²⁹。

Unity Catalog には、オープンソース版もある。Databricks は 2024 年 6 月に Unity Catalog をオープンソースにし、Linux Foundation の傘下の LF AI & Data に移した³⁰。同じ発表は、製品版の機能を段階を追ってオープンソース版に移すと書いている。オープンソース版はまだ LF AI & Data のサンドボックスの段階のプロジェクトで（財団の中での段階で、ソフトウェアの完成度を示すものではない）³¹、その開発計画では、行フィルター、列マスク、リネージは、時期の決まっていない項目として載っているだけである³²。そのため、本稿で説明した機能の多くは、Databricks の製品版の Unity Catalog の機能である。

外から見た Unity Catalog

Unity Catalog の設計を説明した 2025 年の SIGMOD の論文があるが、38 人の著者はすべて Databricks の所属である。その要旨によれば、設計の妥当性の根拠も、自社の数千の顧客の導入での経験である³³。Unity Catalog を独立に評価した論文は、調べた範囲では見当たらなかった。

外部からは批判もある。データのバージョン管理の製品を売る lakeFS の Katz は、2026 年の記事で、Unity Catalog をよいソフトウェアだと認めたうえで、相互運用は一方向で、ほかのエンジンは Databricks が管理するテーブルを読めるが、Databricks はほかが管理するテーブルを十分には扱わないと批判した³⁴。同じ記事は、比べる相手として Snowflake と AWS Glue を挙げ、Snowflake は外部のカタログが管理する Iceberg のテーブルも読み書きできると書いている³⁴。外部のデータベースを Unity Catalog から使うフォーリンカタログは、Databricks の文書でも読み取り専用とされている³⁵。ただし、ワークスペースに付いていた内部の Hive メタストアを連携させた場合は、読み書きができる³⁶。なお、マネージドテーブルはロックインを生まないという Databricks の主張は、外のエンジンから Databricks のテーブルへの向きについてのもので、lakeFS の批判は、Databricks から外が管理するテーブルへの向きについてのものである。両者は同じ点を争っておらず、どちらも利害のある立場からの主張である。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。