テーマ切替
Professional 学習教材 ⑧ データガバナンス（配点 7%）
本教材は Databricks 認定データエンジニア Professional（上位資格） 試験のドメイン⑧「データガバナンス」を、Unity Catalog を軸に、Associate より運用・設計寄りの観点（カタログ設計・データリネージ・監査・タグ・所有権/権限の運用）で深く学ぶための自習教材です。以下の公式ドキュメント（日本語）を実読し、重要用語・概念を漏らさず、この md 単体で学習が完結するようまとめています。
参照した公式ページ:
- https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/ （Unity Catalog とは）
- https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/data-lineage （データ系列）
- https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse-architecture/data-governance/ （データと AI ガバナンスの原則）
- https://learn.microsoft.com/ja-jp/azure/databricks/catalogs/ （カタログとは）
- https://learn.microsoft.com/ja-jp/azure/databricks/admin/system-tables/ （システムテーブル リファレンス）
補足として以下も参照:
- .../data-governance/unity-catalog/access-control/privileges-reference （特権リファレンス）
- .../database-objects/tags （タグの適用）
- .../admin/system-tables/audit-logs （監査ログ システムテーブル）
- .../data-governance/unity-catalog/best-practices （Unity Catalog ベストプラクティス）
1. このドメインの概要
Professional 試験のデータガバナンス領域は、Unity Catalog（ユニティカタログ） を中心に、データと AI 資産の「統合ガバナンス（unified governance）」をどう設計・運用するかを問います。Associate では「3階層ネームスペースと GRANT の基本」が中心ですが、Professional では以下の運用・設計寄りの深い理解が求められます。
- カタログ設計: 環境（dev/staging/prod）やビジネスドメイン、組織単位でカタログ・スキーマをどう分割し、データ分離（data isolation）と権限継承をどう設計するか。
- データリネージ（系列）: 列レベルまで自動追跡される仕組み、確認方法（Catalog Explorer / システムテーブル）、影響分析・根本原因調査への活用、そして制限事項。
- 監査（audit）とシステムテーブル:
system.access.auditなどのシステムテーブルで「誰がいつ何にアクセスしたか」を記録・分析し、コンプライアンスに対応する運用。 - タグ付け・データ検出・所有権/権限: タグによる分類とデータ発見、
BROWSEによるセルフサービス、所有権とMANAGE、最小特権の原則の運用。
Unity Catalog は Azure Databricks に組み込まれたデータと AI の統合ガバナンスレイヤーであり、ワークスペースに対して有効化すると、テーブルへのクエリやモデル呼び出し時のアクセス制御、系列の追跡、監査ログの記録が自動的に動作します（2023年11月9日以降に作成されたワークスペースでは自動的に有効）。操作は Catalog Explorer、SQL、Databricks CLI、REST API で行います。
2. 重要用語集
| 用語（日本語） | English | 説明 |
|---|---|---|
| Unity Catalog（ユニティカタログ） | Unity Catalog | Azure Databricks に組み込まれたデータと AI の統合ガバナンスレイヤー。アクセス制御・系列・監査・検出を一元的に提供。OSS 実装も存在。 |
| メタストア | Metastore | Unity Catalog の最上位コンテナ。アカウント内でリージョンごとに1つ。カタログや外部ロケーション、資格情報、共有などを保持。データ分離の既定単位ではない（分離は通常カタログから）。 |
| カタログ | Catalog | 3階層ネームスペースの第1層。データ組織の主要単位であり、データ分離とアクセスの論理カテゴリを表す。スキーマを含む。 |
| スキーマ（データベース） | Schema (Database) | 第2層。テーブル・ビュー・ボリューム・関数・モデルを含む組織レイヤー。 |
| テーブル | Table | 第3層のデータオブジェクト。マネージド／外部の2種。常に Delta または Iceberg（マネージド）。 |
| ビュー | View | クエリ結果を仮想テーブルとして参照するオブジェクト。 |
| 具体化されたビュー | Materialized View | 事前計算・保存されるビュー。REFRESH で更新。 |
| ボリューム | Volume | 表形式でない（非構造化含む）ファイルを管理するオブジェクト。マネージド／外部。FUSE マウント /Volumes/<catalog>/<schema>/<volume>/ を提供。 |
| 関数 | Function | UDF などの登録関数。EXECUTE で呼び出し。 |
| モデル | Model (Registered Model) | MLflow 登録済みモデル。関数の一種として扱われる。バージョンを持つ。 |
| セキュリティ保護可能なオブジェクト | Securable Object | プリンシパルに権限を付与できるオブジェクトの総称。 |
| プリンシパル | Principal | 権限を付与される主体。ユーザー／サービスプリンシパル／グループ。 |
| 3階層ネームスペース | Three-level namespace | catalog.schema.object の3レベル参照。Hive の2階層 schema.table との違い。 |
| マネージドテーブル/ボリューム | Managed table / volume | ガバナンスとファイルストレージのライフサイクルの両方を Unity Catalog が管理。推奨形式。 |
| 外部テーブル/ボリューム | External table / volume | アクセスは Unity Catalog が管理するが、データライフサイクルとファイルレイアウトはクラウド側で管理。 |
| マネージドストレージ | Managed storage | マネージド資産の既定格納場所。メタストア／カタログ／スキーマの各レベルで設定可。最下位の設定が優先。 |
| 外部ロケーション | External Location | ストレージ資格情報とクラウドパスを組み合わせ、ストレージアクセスを制御・監査するオブジェクト。 |
| ストレージ資格情報 | Storage Credential | クラウドストレージへの認証を表すオブジェクト。 |
| データリネージ（系列） | Data Lineage | データの取得元・変換・行き先を列レベルまで自動追跡する機能。メタストア配下の全ワークスペースで集約。 |
| 列レベル系列 | Column-level lineage | 列単位でアップストリーム／ダウンストリームの派生関係を追跡。 |
| 外部リネージ | External lineage | Salesforce / MySQL / Tableau / Power BI 等を外部メタデータとして登録し、系列グラフを Databricks 外へ拡張。 |
| 影響分析 | Impact analysis | 変更・削除前に、依存するテーブル/ジョブ/ダッシュボードを特定すること。 |
| 根本原因調査 | Root cause analysis | 予期しない結果からアップストリームをトレースし原因を特定すること。 |
| 監査ログ | Audit log | すべてのデータアクセスとシステムアクティビティの記録。system.access.audit テーブル。 |
| システムテーブル | System tables | system カタログ配下の、アカウント運用データの Databricks ホスト型分析ストア。監査・課金・計算・系列などを保持。 |
| タグ | Tag | セキュリティ保護可能オブジェクトを整理・分類するキー（+任意の値）。検索・検出・ABAC に利用。 |
| 管理タグ | Governed tag | 許可キー/値と割り当て可能なユーザーを制御するアカウントレベルのタグ。ASSIGN 特権が必要。 |
| システムタグ | System tag | Databricks 事前定義の管理タグ。キー/値は変更不可。 |
| 所有権 | Ownership | オブジェクトに対する全権限と、権限付与・所有権譲渡・削除の権利。作成者が初期所有者。 |
| MANAGE 特権 | MANAGE privilege | 所有者でなくても権限管理・所有権譲渡・削除を可能にする特権。所有権に近いが差異あり。 |
| 権限継承 | Privilege inheritance | 上位オブジェクトの権限が子に自動継承される仕組み（特権モデル v1.0）。 |
| 使用権限 | Usage privilege | USE CATALOG / USE SCHEMA。オブジェクト操作の前提となるが、それ自体はデータアクセスを許可しない。 |
| BROWSE 特権 | BROWSE privilege | USE CATALOG/USE SCHEMA なしにメタデータ検出・表示・アクセス要求を可能にする特権。 |
| 属性ベースアクセス制御 | ABAC | タグ等の属性に基づくアクセス制御ポリシー。タグは上位から暗黙継承（列レベルは除く）。 |
| ワークスペースカタログバインド | Workspace-catalog binding | カタログアクセスをワークスペース境界に制限する機能。 |
| 既定のカタログ | Default catalog | カタログ名を省略した時に使われるカタログ。ワークスペースごとに構成。 |
| メダリオンアーキテクチャ | Medallion architecture | Bronze/Silver/Gold のレイヤ設計。カタログ/スキーマ設計に対応させる。 |
| データ検出 | Data discovery | Catalog Explorer・検索・BROWSE により利用可能なデータ資産を見つけること。 |
| 責任分担 | Responsibility separation | クラウド管理者・メタストア管理者・カタログ/スキーマ所有者への権限委任の設計。 |
| OpenSharing | Open Sharing (Delta Sharing) | オープンプロトコルによるリージョン/クラウド/組織間の安全なデータ共有。 |
| Lakehouse Federation | Lakehouse Federation | 外部データシステムをミラーする外部カタログで読み取り専用クエリを行う機能。 |
3. 詳細解説
3-1. データガバナンスの原則（統合ガバナンス、well-architected 観点）
Well-Architected（適切に設計されたレイクハウス）の「データと AI ガバナンス」の柱では、資産とアクセスを**一元的（centrally）**に管理する方法を扱います。3つのアーキテクチャ原則があります。
データと AI 管理を統合する（Unify data and AI management）
- 信頼できるデータ資産を収集・統合・整理・永続化し、価値を最大化するための基盤。
- 統合カタログ（unified catalog） が、すべてのデータ／分析成果物とそのメタデータを一元的・一貫して格納。
- エンドユーザーが利用可能なデータセットを**検出（discover）でき、全資産の系列（lineage）**を追跡して可視性を提供する。
データと AI セキュリティを統合する（Unify data and AI security）
- 2つの教義: 「誰がどのデータにアクセスできるか」と「誰が最近どのデータにアクセスしたか」を理解すること。これは規制業界のコンプライアンス要件にほぼ不可欠。
- 統合セキュリティにより、全資産でアクセス許可モデルを一元的・一貫して管理。
- データアクセスは一元的に監査され、アラート・監視でアカウンタビリティ（説明責任）を促進する。
データ品質基準を確立する（Establish data quality standards）
- データ品質のディメンション: 完全性・精度・有効性・一貫性など。
- 最終データセットの品質を能動的に管理し、ビジネスユーザーにとって信頼できる情報とする。
Unity Catalog はこれらを実現する組み込みツールを提供します（アクセス制御、検出＝Catalog Explorer、系列、監査、データ分類、データ品質監視、データ共有、AI ガバナンス）。
試験の観点: 「統合ガバナンス」は "1つのカタログですべての資産を一元管理し、アクセス制御・系列・監査を一貫適用する" という思想。分散した Hive メタストアではなく、Unity Catalog に集約することが答えになりやすい。
3-2. Unity Catalog のオブジェクト階層とカタログ設計（環境/ドメイン分割の考え方）
オブジェクトモデル
Unity Catalog が管理する全資産はセキュリティ保護可能なオブジェクトとしてモデル化されます。階層は上から:
メタストア (Metastore) ── リージョンごとに1つ
├─ カタログ (Catalog) ← 3階層の第1層
│ └─ スキーマ (Schema) ← 第2層
│ ├─ テーブル (Table) ← 第3層（catalog.schema.table）
│ ├─ ビュー / 具体化ビュー
│ ├─ ボリューム (Volume)
│ ├─ 関数 (Function) / モデル (Model)
│ └─ サービス (Service: モデルサービング / MCP)
└─ メタストア直下のオブジェクト:
ストレージ資格情報 / 外部ロケーション / 接続 (Connection) / 共有 (Share) など- データと AI 資産（テーブル、ビュー、ボリューム、関数、モデル、サービス）は 3レベルネームスペース
catalog.schema.objectに従う。 - テーブルとボリュームは マネージド（ガバナンス＋ファイルストレージのライフサイクル両方を UC が管理）か 外部（ガバナンスのみ UC が管理）。
- ストレージ資格情報・外部ロケーション・接続・共有はメタストアのすぐ下に配置。
カタログ設計の考え方
カタログは**データ分離の主要単位（primary unit of data isolation）**であり、データアクセスの論理カテゴリを表します。設計は組織単位やソフトウェア開発ライフサイクル（SDLC）スコープを反映することが多い。
- 例: 運用データ用カタログ vs 開発データ用カタログ、非顧客データ用 vs 機密顧客データ用。
- カタログは通常、環境スコープ・チーム・部署、またはその組み合わせに対応させる。これにより権限階層でアクセスを効率的に管理できる。
- メダリオンアーキテクチャとの対応例: 環境（dev/staging/prod）をカタログに、Bronze/Silver/Gold をスキーマに割り当てる、あるいはドメインをカタログに割り当てるなど、要件に応じて設計。
データ分離とストレージ
- 各カタログは通常、独自のマネージドストレージの場所を持ち、カタログレベルで物理データを分離できる。
- メタストアレベルにストレージを置き、独自ストレージを持たないカタログの既定格納先とすることも可能。
- より細かい分離のためスキーマレベルでストレージ追加も可能。データは階層内の最も低い（most specific）利用可能な場所に格納される。
- ベストプラクティス: カタログレベルのストレージを優先。初期の UC ではメタストアレベルストレージが必要だったが、現在は不要。メタストアレベルを作る場合は専用コンテナを使う。UC 外からアクセスできるコンテナや DBFS ルートのコンテナは使わない。
メタストア設計
- 1リージョン＝1メタストア。同リージョンの全ワークスペースがそれを共有 ＝ カタログは本質的にリージョンごとに分離される。
- メタストアはリージョン分離を提供するが、データ分離の既定単位ではない（分離は通常カタログから開始）。
- リージョン/クラウドをまたぐ共有は OpenSharing (Delta Sharing) を使う。頻繁アクセスのテーブルを複数メタストアに外部テーブル登録するのは避ける（整合性問題・エグレス料金）。
カタログの種類
- 標準カタログ（Standard catalog）: データオブジェクト整理の主要ユニット。通常のカタログ。
- 外部カタログ（Foreign catalog）: Lakehouse Federation 専用。外部データシステムのDBをミラーし、読み取り専用クエリを可能にする。
- 新規ワークスペース作成時に自動プロビジョニングされるもの:
hive_metastoreカタログ: レガシ Hive メタストア管理データのリポジトリ。Hive メタストアは非推奨で、UC への移行が推奨。- ワークスペースカタログ（Workspace catalog）: 通常ワークスペース名を共有。ワークスペース内の全ユーザーが既定でアクセス可。自動有効化時は既定カタログとして指定され、既定でそのワークスペースにバインドされる。
__databricks_internalカタログ: Lakeflow パイプラインや AI/BI ダッシュボード等の内部状態格納用の予約カタログ。照会・変更・削除してはならない。監査ログやシステムテーブルに現れることがある（想定内）。systemカタログ: システムテーブルを含む（後述）。
既定のカタログ・ワークスペースバインド
- 既定のカタログ: カタログ名を省略した操作で使われる。ワークスペース管理者が変更可能。
- ワークスペースカタログバインド: カタログアクセスをワークスペース境界に制限。例:
prod_catalogをprod_workspaceにのみバインド。バインドを指定しない限り、カタログは同一メタストアにアタッチされた全ワークスペースと共有される。
アイデンティティ設計（プリンシパル）
- 特権はアカウントレベルで定義したプリンシパル（ユーザー／グループ／サービスプリンシパル）に割り当てる。SCIM で IdP からアカウントへプロビジョニング推奨。
- ワークスペースレベルの SCIM は避け、アカウントレベルで一元管理。グループは IdP で定義・管理し、ユーザー個人ではなくグループに権限・所有権を割り当てる。
- サービスプリンシパルでジョブを実行（自動化のため。ユーザーで運用書き込みを実行すると誤上書きリスク）。
3-3. データリネージ（系列）の自動追跡と活用・制限
仕組み
Unity Catalog は Azure Databricks で実行されるクエリの系列を列レベル（column level）まで自動的にキャプチャし、メタストアにアタッチされた全ワークスペースにわたって集約します。ノードはテーブル/ビュー、ML モデルバージョン、外部アセット、ファイルパスを表せます。
系列の活用ユースケース:
- 影響分析: テーブル/列の変更・削除前に依存するテーブル・ジョブ・ダッシュボードを特定。
- 根本原因調査: ダウンストリームの異常からアップストリームをトレースし分岐点を発見。
- 機密データフローの追跡: コンプライアンス監査で規制対象データの発生元・変換・利用を確認。
- チーム間依存関係の把握: どのチームがアップストリームを所有し、どのチームがテーブルを使うか。
外部リネージ（External lineage）: Salesforce / MySQL 等のアップストリームや Tableau / Power BI 等のダウンストリームを UC の**外部メタデータ（external metadata）**オブジェクトとして登録すると、UC テーブルと同一グラフで表示できる。
要件
系列キャプチャの要件:
- テーブルは Unity Catalog メタストアに登録されていること。
- 外部アセットは UC の外部メタデータオブジェクトとして追加し、他のセキュリティ保護可能オブジェクトとの関係を構成する。
- クエリは Spark DataFrame（DataFrame を返す Spark SQL 関数など） または Databricks SQL インターフェイス（ノートブック / SQL クエリエディター） を使う。
系列表示の要件（権限）:
- テーブル/ビューの親カタログに対して最低
BROWSE権限が必要。親カタログはワークスペースからアクセス可能である必要（ワークスペースカタログバインド参照）。 - ノートブック・ジョブ・ダッシュボードは、ワークスペースのアクセス制御で定義された各オブジェクトへの権限が必要。
- Unity Catalog 対応パイプラインは
CAN VIEW権限が必要。
コンピューティング要件:
- Delta テーブル間のストリーミングの系列追跡: Databricks Runtime 11.3 LTS 以降。
- Lakeflow パイプラインの列系列追跡: Databricks Runtime 13.3 LTS 以降。
ネットワーク要件: VNet インジェクション環境では、コントロールプレーン内の Event Hubs エンドポイントへの送信接続を許可するファイアウォール規則が必要な場合がある。
確認方法
- Catalog Explorer: テーブルの [系列] タブ → [系列グラフの表示]。既定で1レベル表示、プラスアイコンで展開。列をクリックすると列レベル系列（例:
revenue列の派生元アップストリーム列）を表示。ジョブ系列は [ジョブ]→[ダウンストリーム]、ダッシュボード系列は [ダッシュボード]。 - Genie Code（自然言語）:
/getTableLineages（上流・下流依存関係）、/getTableInsights（ユーザーアクティビティ等の分析）。 - システムテーブル:
system.access.table_lineage（テーブル/パスの読み書きイベントごとに1レコード）とsystem.access.column_lineage（列の読み書きイベントごと、ソースなしイベントは除く）でプログラム的にクエリ可能。
権限モデル
系列グラフは Unity Catalog と同じアクセス許可モデルを共有します。ユーザーはオブジェクトに対して最低 BROWSE または SELECT を持たなければ系列を調べられません。系列は全ワークスペースで集約されるため、適切な権限があれば別ワークスペースでキャプチャされた系列も見えます（ただし他ワークスペースのノートブック/ダッシュボード等の詳細はマスクされる）。
例: userA に USE SCHEMA と特定テーブルの SELECT のみ付与した場合、そのテーブルは見えるが、アクセス権のないダウンストリームテーブルは masked ノードとして表示され、展開できない。カタログに BROWSE を付与すれば、そのスキーマ内の任意テーブルの系列グラフを表示できる。
保持期間
- Catalog Explorer に表示される系列データは無期限保持。ただし2024年9月1日以降にキャプチャされた系列のみ利用可能。
- 系列システムテーブル（
table_lineage/column_lineage）は、ローリング1年間のデータウィンドウを保持。
制限事項（重要・システムテーブルにも適用）
- 2024年9月1日より前の系列データは利用不可。
- ジョブ API の
runs submitやspark submitタスクのジョブは系列ビューで使えない（テーブル/列レベル系列はキャプチャされるが、ジョブ実行へのリンクは不可）。 - 名前を変更したカタログ・スキーマ・テーブル・ビュー・列の系列は保持されない。
- Spark SQL データセットのチェックポイント使用時は系列をキャプチャしない。
- Lakeflow パイプラインの PRIVATE テーブル使用時はカバレッジが不完全。
- **RDD（回復性のある分散データセット）**は系列にキャプチャされない。
- グローバル一時ビューは系列に記録されない。
- トランザクションは読み書きのたびに系列を生成し、ロールバックされても系列イベントは保持される。
system.information_schema配下のテーブルは系列に記録されない。- 列レベル系列の制限:
- ソース/ターゲットがパスとして参照される場合（例:
select * from delta."s3://.../path"）は列系列不可。両方がテーブル名で参照される場合（例:select * from catalog.schema.table）のみサポート。 - **UDF（ユーザー定義関数）**はソース列とターゲット列のマッピングを隠す場合がある。
- ソース/ターゲットがパスとして参照される場合（例:
3-4. 監査ログ・システムテーブルによるガバナンス運用
システムテーブルとは
システムテーブルは system カタログにある、アカウント運用データの Databricks ホスト型分析ストアです。コスト監視・セキュリティイベント監査・計算/ジョブパフォーマンス追跡・データ/AI ワークロード監視に使い、アカウント全体の履歴監視が可能。データはメタストアと同じリージョンの Databricks ホスト型ストレージに格納され、OpenSharing で安全に共有されます。
system カタログには access、billing、compute、lineage（非推奨・空）、query、storage、marketplace、serving、lakeflow、mlflow、tags、ai_gateway、data_classification、sharing などのスキーマがあります。
注:
system.information_schemaは他のシステムテーブルと動作が異なる（各カタログ内の情報スキーマ）。system.operational_dataとsystem.lineageスキーマは非推奨で空テーブルを含む。
主要なシステムテーブル一覧
| テーブル | テーブルパス | 説明 | 無料保持 | データ範囲 |
|---|---|---|---|---|
| 監査ログ（Public Preview） | system.access.audit | リージョン内ワークスペースの全監査イベント | 365日 | ワークスペースレベルはリージョン、アカウントレベルはグローバル |
| テーブル系列 | system.access.table_lineage | テーブル/パスの読み書きイベントごとに1レコード | 365日 | リージョン |
| 列の系列 | system.access.column_lineage | 列の読み書きイベントごと（ソースなしは除く） | 365日 | リージョン |
| ワークスペース（Public Preview） | system.access.workspaces_latest | 全ワークスペースメタデータの緩やかに変化するディメンション | 不定 | グローバル |
| 課金対象使用状況 | system.billing.usage | 課金対象の全使用状況 | 365日 | グローバル |
| 料金 | system.billing.list_prices | SKU 価格の履歴ログ | 不定 | グローバル |
| クラスター | system.compute.clusters(計算) | 計算構成の全履歴（SCD） | 365日 | リージョン |
| ノードタイムライン | system.compute.node_timeline | 使用率メトリック | 90日 | リージョン |
| SQL ウェアハウスイベント | system.compute.warehouse_events | 開始/停止/スケール等 | 365日 | リージョン |
| クエリ履歴（Public Preview） | system.query.history | SQL ウェアハウス/サーバーレスの全クエリ | 365日 | リージョン |
| ジョブ / タスク / 実行タイムライン | system.lakeflow.jobs ほか | ジョブ・タスクの追跡 | 365日 | リージョン |
| データ分類結果（Public Preview） | system.data_classification.results | 機密データクラスの列レベル検出 | 13か月 | リージョン |
| 管理タグ（Beta） | system.tags.governed_tags | 全管理タグ定義のバージョン管理レコード | 365日 | グローバル |
| 予測最適化（Public Preview） | system.storage.predictive_optimization_operations_history | 予測最適化の操作履歴 | 180日 | リージョン |
| モデルサービング使用状況（Public Preview） | system.serving.endpoint_usage | エンドポイント要求ごとのトークン数 | 90日 | リージョン |
課金使用量・価格テーブルは無料。Public Preview テーブルはプレビュー中は無料だが、将来課金の可能性あり。上記以外に Private Preview のテーブルがアカウントに現れる場合があり、既定で空（利用は Databricks アカウントチームに問い合わせ）。
監査ログ システムテーブル system.access.audit
「誰がいつ何にアクセス・操作したか」を記録する、ガバナンスの中核テーブル（Public Preview）。主なスキーマ列:
| 列名 | 型 | 説明 |
|---|---|---|
account_id | string | アカウント ID |
workspace_id | string | ワークスペース ID（アカウントレベルイベントは 0） |
version | string | 監査ログスキーマのバージョン |
event_time | timestamp | イベントのタイムスタンプ（UTC、+00:00）。クエリは event_date より event_time でフィルタするとパフォーマンス向上 |
event_date | date | アクション実行日 |
source_ip_address | string | 要求元 IP |
user_agent | string | 要求元エージェント |
session_id | string | セッション ID |
user_identity | struct | 要求を開始したユーザー ID（email 等） |
service_name | string | 要求を開始したサービス名（例: unityCatalog） |
action_name | string | イベントカテゴリ（例: getTable） |
request_id | string | 要求 ID |
request_params | map | 全要求パラメータのキー値マップ（要求種別により異なる） |
response | struct | 応答戻り値（statusCode、errorMessage、result） |
audit_level | string | WORKSPACE_LEVEL / ACCOUNT_LEVEL |
event_id | string | イベント ID |
identity_metadata | struct | run_by / run_as 等（専用計算のグループアクティビティ監査用） |
考慮点: ほとんどの監査ログはワークスペースのリージョンでのみ利用可能。アカウントレベルは workspace_id = 0。
有効化とアクセス権限
- システムテーブルは Unity Catalog により管理される。アカウントで有効化するには少なくとも1つの Unity Catalog 対応ワークスペースが必要。全ワークスペースのデータを含むが、アクセスできるのは UC 対応ワークスペースのみ。
- メタストアは特権モデル バージョン 1.0（＝特権継承サポート）である必要がある。
- アクセス権限: アカウント管理者ロールかつメタストア管理者ロールを持つユーザーは既定でアクセス可。他ユーザーには、管理者が
systemカタログのUSE CATALOG、対象スキーマのUSE SCHEMA、対象スキーマのSELECTを付与する。 - システムテーブルは読み取り専用で変更不可。
運用上の注意（既知の問題）
- 新しい列がいつでも追加され得る（固定スキーマ依存のクエリは壊れる可能性）。既存列は変更・削除されない。別テーブルへ書き込む場合はスキーマ進化を有効化。
- リアルタイム監視は非対応。データは1日を通して更新される。
- 十分に選択的でないクエリは
System Table query returned too much data...エラーを返す（より選択的な述語を追加）。 - セキュリティ: システムテーブル情報は機密であり、プラットフォーム外へ移動しないよう強く推奨。エクスポートした情報のセキュリティ維持と誤用防止の責任がある。
- ストリーミング利用時は
skipChangeCommits = trueを設定（削除でストリームが中断しないように）。VACUUMは既定7日保持。
3-5. タグ付け・データ検出・所有権/権限の運用
タグ（Tags）
タグは、セキュリティ保護可能オブジェクトの整理・分類に使うキー（+任意の値）です。ワークスペース検索でテーブル・ビューの検索/検出を簡略化できます。
警告: タグデータはプレーンテキストで格納され、グローバルにレプリケートされる場合がある。個人情報・機密情報をタグ名/値/記述子に使わないこと。
タグ付け可能なオブジェクト: カタログ、スキーマ、テーブル、テーブル列、ボリューム、ビュー、関数、登録済みモデル、モデルバージョン、外部メタデータ（Public Preview）。ダッシュボード、Genie エージェント、Databricks アプリ、ノートブックにも別途付与可能。
必要な権限: オブジェクトの所有者であるか、対象オブジェクトの
APPLY TAG＋ 親スキーマのUSE SCHEMA＋ 親カタログのUSE CATALOG。管理タグの場合はさらに管理タグへのASSIGN特権。制約:
- タグキーは大文字小文字を区別（
Salesとsalesは別）。 - 1オブジェクト（テーブル/列）あたり最大 50 タグ。1テーブルの全列合計で最大 1,000 列タグ。
- キー/値の最大長は各 256 文字。
- キーに使えない文字:
. , - = / :。先頭/末尾のスペース不可。 - タグ検索は正確な単語一致が必要。
- 1つの
ALTER TABLEで複数列に同時割り当て不可（列ごとに個別実行）。
- タグキーは大文字小文字を区別（
管理タグ（Governed tags）: アカウントレベルで一貫性と制御の規則が適用されるタグ。許可キー/値を定義し、割り当て可能なユーザー/グループを制御。適切な権限を持つユーザー/グループのみ割り当て・変更可。UI ではロックアイコンで表示。既存タグと同じキーの管理タグを作ると、既存割り当てが自動的に管理される。管理タグ削除後はタグはオブジェクトに残るが管理されなくなる。
システムタグ（System tags）: Databricks 事前定義の特別な管理タグ。キー/値は変更・削除不可。割り当て許可ユーザーは制御可能。レンチアイコンで表示。データ分類・所有権・ライフサイクル追跡等の標準化に利用。
ABAC での暗黙的タグ継承: ABAC ポリシー評価時のみ、上位レベルのタグは配下の全オブジェクトに自動適用される（カタログのタグ → 全スキーマ/テーブル）。ただし列レベルには継承されない。ABAC 以外では一般にタグ継承は起こらない。
Information Schema:
INFORMATION_SCHEMA.CATALOG_TAGS/SCHEMA_TAGS/TABLE_TAGS/COLUMN_TAGS/VOLUME_TAGSからタグ情報を取得可能。
データ検出（Data discovery）
- Catalog Explorer が UC 登録データ/AI 資産の検出・管理 UI。
BROWSE特権により、USE CATALOG/USE SCHEMAなしでオブジェクトの存在確認・名前/説明/タグ表示・アクセス要求ができる。Databricks は カタログレベルでAll account usersグループにBROWSEを付与して組織全体でデータを検出可能にすることを推奨。- アクセス要求の送信先（メール/Slack/Teams/PagerDuty/webhook 等）を構成すると、ユーザーがオブジェクトを検出した後にセルフサービスでアクセスを要求できる。既定のメール送信先を有効化しておくと、要求はカタログ所有者/オブジェクト所有者に送られる。
所有権と権限の運用
- 所有権（Ownership）: 作成者が初期所有者。所有者はオブジェクトの全権限（テーブルなら
SELECT/MODIFY等）＋権限付与＋所有権譲渡の権利を持つ。運用オブジェクトの所有権は個人ではなく必ずグループに割り当てる。 - MANAGE 特権: 所有者でなくても権限管理・所有権譲渡・削除が可能。所有権に近いが、MANAGE を持つだけでは全特権が自動付与されない（各特権は個別付与が必要だが、MANAGE 保有者はそれらを明示的に付与できる）。コンテナに MANAGE を付与すると全子オブジェクトにも MANAGE が及ぶ。
ALL PRIVILEGESにはMANAGEは含まれない。 - 最小特権の原則（Principle of least privilege）: 通常はユーザーが必要とする階層内の特定オブジェクト/レベルにのみ権限を付与。
CREATE TABLE/CREATE VOLUME等はスキーマレベルで付与を推奨。 USE CATALOG/USE SCHEMAの役割: これらはデータへのアクセスそのものは許可しない前提条件。例えばテーブルにSELECTを持っていても、親カタログにUSE CATALOGがなければアクセスできない。これによりカタログ/スキーマ所有者が、下位オブジェクト所有者の付与に関わらずアクセス境界を制御できる。- 責任分担の設計例: クラウド管理者がいくつかの外部ロケーションを設定 → メタストア/UC 管理者に管理を委任 → カタログ/スキーマ所有者が外部テーブル/ボリューム登録で細かいアクセスを制御。
CREATE EXTERNAL LOCATIONは信頼できる管理者/データエンジニアのみに付与。エンドユーザーに一般的なREAD FILES/WRITE FILESは付与しない（表形式でないデータのパスアクセスはボリュームを使う）。 - 管理者ロール: アカウント管理者・ワークスペース管理者・メタストア管理者。メタストア管理者は省略可能（必要時のみ割り当て）。強力なロール/特権（
ALL PRIVILEGES、MANAGE）は控えめに、可能な限りグループに割り当てる。
4. 構文・コード例
3階層ネームスペースでの参照
sql
-- catalog.schema.table でテーブルを参照
SELECT * FROM prod_catalog.sales.orders;
-- 既定カタログ/スキーマを設定して短縮参照
USE CATALOG prod_catalog;
USE SCHEMA sales;
SELECT * FROM orders; -- prod_catalog.sales.orders と同義
-- ボリューム内ファイルのパス参照
LIST '/Volumes/prod_catalog/sales/landing/';カタログ・スキーマの作成と所有権
sql
CREATE CATALOG IF NOT EXISTS prod_catalog
MANAGED LOCATION 'abfss://prod@storageacct.dfs.core.windows.net/catalog';
CREATE SCHEMA prod_catalog.sales;
-- 運用オブジェクトの所有権はグループへ譲渡
ALTER CATALOG prod_catalog OWNER TO `data-platform-admins`;
ALTER SCHEMA prod_catalog.sales OWNER TO `sales-eng-team`;GRANT / REVOKE（権限付与）
sql
-- 使用権限（前提条件）: データアクセスそのものは許可しない
GRANT USE CATALOG ON CATALOG prod_catalog TO `sales-eng-team`;
GRANT USE SCHEMA ON SCHEMA prod_catalog.sales TO `sales-eng-team`;
-- テーブル読み取り。SELECT だけでは足りず、上位の USE CATALOG/USE SCHEMA が必要
GRANT SELECT ON TABLE prod_catalog.sales.orders TO `analysts`;
-- スキーマに付与 → 継承で配下の現在・将来の全テーブルに SELECT
GRANT SELECT ON SCHEMA prod_catalog.sales TO `analysts`;
-- 作成権限はスキーマレベルで付与（最小特権）
GRANT CREATE TABLE, CREATE VOLUME ON SCHEMA prod_catalog.sales TO `sales-eng-team`;
-- データ検出のための BROWSE を全ユーザーに（カタログレベル）
GRANT BROWSE ON CATALOG prod_catalog TO `account users`;
-- 書き込み（挿入/更新/削除）
GRANT MODIFY ON TABLE prod_catalog.sales.orders TO `etl-service-principal`;
-- 権限管理を委任（所有者でなくても管理可能）
GRANT MANAGE ON SCHEMA prod_catalog.sales TO `sales-governance`;
-- 付与状況の確認 / 取り消し
SHOW GRANTS `analysts` ON TABLE prod_catalog.sales.orders;
REVOKE SELECT ON TABLE prod_catalog.sales.orders FROM `analysts`;タグの付与・解除
sql
-- DBR 16.1 以降: SET TAG / UNSET TAG
SET TAG ON CATALOG catalog `cost_center` = `hr`;
UNSET TAG ON CATALOG catalog cost_center;
-- DBR 13.3 以降: ALTER ... SET TAGS / UNSET TAGS
ALTER TABLE prod_catalog.sales.orders SET TAGS ('domain' = 'sales', 'pii' = 'false');
-- 列に管理タグを付与（列は1コマンド1列）
ALTER TABLE abac.customers.profiles
ALTER COLUMN SSN
SET TAGS ('pii' = 'ssn');
-- 管理タグ付き列は、先にタグを外してから列を削除（データリーク防止）
UNSET TAG ON COLUMN abac.customers.profiles.SSN pii;
ALTER TABLE abac.customers.profiles DROP COLUMN SSN;
-- タグ情報の取得
SELECT * FROM prod_catalog.information_schema.table_tags;
SELECT * FROM prod_catalog.information_schema.column_tags;データリネージ（系列）の確認
sql
-- テーブル系列: 対象テーブルの上流/下流を確認
SELECT source_table_full_name, target_table_full_name,
entity_type, event_time
FROM system.access.table_lineage
WHERE target_table_full_name = 'prod_catalog.sales.orders'
AND event_time >= current_date() - INTERVAL 30 DAYS
ORDER BY event_time DESC;
-- 列レベル系列: 特定列の派生元（アップストリーム列）
SELECT source_table_full_name, source_column_name,
target_table_full_name, target_column_name
FROM system.access.column_lineage
WHERE target_table_full_name = 'prod_catalog.sales.orders'
AND target_column_name = 'revenue';系列表示には対象カタログへの最低 BROWSE（または対象への SELECT）が必要。
監査ログ system.access.audit へのクエリ
sql
-- 直近7日で誰がどのテーブルにアクセスしたか（Unity Catalog イベント）
SELECT event_time, user_identity.email AS user, action_name,
request_params['full_name_arg'] AS object_name,
response.statusCode
FROM system.access.audit
WHERE service_name = 'unityCatalog'
AND action_name IN ('getTable', 'generateTemporaryTableCredential')
AND event_time >= current_timestamp() - INTERVAL 7 DAYS -- event_time でフィルタ（性能）
ORDER BY event_time DESC;
-- 失敗した（権限拒否など）操作を抽出
SELECT event_time, user_identity.email, action_name, response.errorMessage
FROM system.access.audit
WHERE response.statusCode <> 200
AND event_date >= current_date() - INTERVAL 1 DAYS;
-- 特定ユーザーのアクティビティ集計
SELECT action_name, count(*) AS cnt
FROM system.access.audit
WHERE user_identity.email = 'user@company.com'
AND event_time >= current_timestamp() - INTERVAL 30 DAYS
GROUP BY action_name ORDER BY cnt DESC;システムテーブルアクセス権の付与
sql
GRANT USE CATALOG ON CATALOG system TO `auditors`;
GRANT USE SCHEMA ON SCHEMA system.access TO `auditors`;
GRANT SELECT ON SCHEMA system.access TO `auditors`; -- audit / lineage 等5. 試験で問われるポイント
- 3階層ネームスペース
catalog.schema.object。Hive の2階層との違い。既定カタログを省略時に使う挙動。 USE CATALOG/USE SCHEMAは前提条件でありデータアクセスは許可しない。SELECTがあってもこれらがなければアクセス不可 → カタログ/スキーマ所有者のアクセス境界。- 権限継承: スキーマ/カタログレベルの付与が配下の現在・将来のオブジェクトに継承される（特権モデル v1.0）。最小特権では作成系はスキーマレベルで付与。
BROWSE:USE CATALOG/USE SCHEMAなしでメタデータ検出・アクセス要求。All account usersにカタログレベルで付与するのがデータ検出のベストプラクティス。- 所有権 vs
MANAGE: MANAGE は権限管理・譲渡・削除を可能にするが、全特権を自動付与しない。ALL PRIVILEGESにはMANAGE・EXTERNAL USE LOCATION・EXTERNAL USE SCHEMAは含まれない。 - データリネージは列レベルまで自動キャプチャ、メタストア配下の全ワークスペースで集約。表示には最低
BROWSE。系列は同じ権限モデルを共有し、権限のない下流はmaskedノード。 - 系列の制限: 名前変更で系列は保持されない／パス参照時は列系列不可（テーブル名参照のみ可）／UDF はマッピングを隠す／RDD・グローバル一時ビュー・チェックポイントは不可／2024/9/1 以前は不可／システムテーブルはローリング1年。
- 監査は
system.access.audit。event_timeでフィルタ（event_dateより高性能）。アカウントレベルイベントはworkspace_id = 0。誰がいつ何にアクセスしたかを回答。 - システムテーブルのアクセス: アカウント管理者＋メタストア管理者は既定で可。他ユーザーには
systemのUSE CATALOG＋USE SCHEMA＋SELECT。読み取り専用。UC 対応ワークスペースからのみアクセス可。 - カタログ設計: カタログ＝データ分離の主要単位。環境/ドメイン/組織単位で分割。所有権はグループに。メタストアはリージョン単位で分離を提供するが分離の既定単位ではない。
- マネージド vs 外部: マネージドが推奨（自動最適化・メタデータキャッシュ等）。外部は既存データ/DR/外部リーダー・ライター要件時。外部テーブルへの外部アクセスは UC の制御・監査・系列をバイパスするため制限。
- タグの制約: 1オブジェクト最大50タグ、キー/値256文字、キーに
. , - = / :不可、大文字小文字区別。タグはプレーンテキストで機密情報を入れない。管理タグ（ASSIGN）とシステムタグの違い。ABAC のときだけ上位からタグが暗黙継承（列レベルは除く）。 - OpenSharing: リージョン/クラウド/組織をまたぐ共有。系列とアクセス制御はメタストア境界を越えない点に注意。
- 統合ガバナンスの3原則: データ/AI 管理の統合・セキュリティの統合（アクセス制御＋監査）・データ品質基準。
6. 理解度チェックリスト
- [ ] 3階層ネームスペース
catalog.schema.objectを説明し、メタストア→カタログ→スキーマ→テーブル/ビュー/ボリューム/関数/モデルの階層を図示できる - [ ]
USE CATALOG/USE SCHEMAが「データアクセスの前提条件」であり、それ自体はアクセスを許可しないことを説明できる - [ ]
SELECTを持つユーザーがUSE CATALOGを欠くとテーブルにアクセスできない理由（アクセス境界）を説明できる - [ ] 権限継承の仕組みと、
CREATE TABLE等をスキーマレベルで付与する最小特権の理由を説明できる - [ ]
BROWSE特権の用途と、All account usersに付与するデータ検出ベストプラクティスを説明できる - [ ] 所有権と
MANAGE特権の違い、ALL PRIVILEGESに含まれない特権（MANAGE/EXTERNAL USE ...）を挙げられる - [ ] 運用オブジェクトの所有権を個人でなくグループに割り当てる理由を説明できる
- [ ] データリネージが列レベルまで自動キャプチャされ、メタストア配下の全ワークスペースで集約されることを説明できる
- [ ] 系列表示に必要な最低権限（
BROWSE）と、権限のない下流がmaskedノードになる挙動を説明できる - [ ] 系列の主な制限（名前変更・パス参照・UDF・RDD・グローバル一時ビュー・2024/9/1・保持1年）を列挙できる
- [ ] Catalog Explorer・システムテーブル・Genie Code の3つの系列確認方法を挙げられる
- [ ]
system.access.auditの主要列と、event_timeでフィルタする理由を説明できる - [ ] 監査ログで「誰がいつ何にアクセスしたか」を抽出する SQL を書ける
- [ ] システムテーブルの有効化条件とアクセス権付与（
systemの USE CATALOG/USE SCHEMA/SELECT）を説明できる - [ ] カタログを環境/ドメイン/組織単位で分割する設計と、カタログ＝データ分離の主要単位である理由を説明できる
- [ ] メタストアがリージョン単位で1つであること、分離の既定単位はカタログであることを説明できる
- [ ] マネージドテーブル/ボリュームが推奨される理由と、外部を使うべきケースを区別できる
- [ ] タグの制約（数・文字数・使用不可文字・大文字小文字区別）と機密情報を入れない注意を説明できる
- [ ] 管理タグ（ASSIGN）・システムタグ・ABAC の暗黙的タグ継承（列レベル除外）を説明できる
- [ ]
GRANT/REVOKE/SHOW GRANTS、ALTER ... OWNER TO、SET TAGS/UNSET TAGSを正しく書ける - [ ] 統合ガバナンスの3原則（管理の統合・セキュリティの統合・データ品質）を説明できる
- [ ] OpenSharing の用途と、系列/アクセス制御がメタストア境界を越えない制限を説明できる