Unity Catalogのメタデータを取得する
Databricks の Unity Catalogのメタデータを取得してDelta化するノートブックを作りました。
Unity Catalogのメタデータを抽出するノートブックを作ってみました。せっかく作ったので紹介できればと思います。
1. Unity Catalog メタデータ抽出ツール概要
1.1 基本機能
Unity Catalogから以下の情報を自動的に抽出・整理します：
テーブル基本情報
- テーブル名、スキーマ名、カタログ名
- テーブル種別（MANAGED / EXTERNAL / VIEW）
- 所有者、作成日時、最終更新日時
- データ形式（Delta、Parquet等）
詳細設定情報
- パーティション戦略とパーティションカラム
- クラスタリング設定有無（主にLiquid Clustering）
- Auto Optimization設定（書き込み最適化、自動コンパクション）
- Change Data Feed (CDF) 設定
- VACUUM・Time Travel保持期間設定
パフォーマンス・品質情報
- ファイル数、データサイズ
- 統計情報設定（対象列数）
- Z-ORDER実行履歴（オプション）
- テーブル機能（tableFeatures）
カラム詳細情報
- カラム名、データ型、NULL許可
- 数値精度、スケール
- 主キー・外部キー制約 ※DatabricksのPK、FKは情報提供目的の設定なので注意してください
- パーティション・クラスタリング対象フラグ
- コメント情報
1.2 出力形式
Delta Lake テーブルとして出力
- リアルタイム性：最新の情報を常に参照可能
- 履歴管理：過去の状態との比較や変化の追跡
- 分析可能性：SQLやBIツールでの集計・分析
- 統合性：他のデータとの結合や横断分析
その他の活用方法
以下のような拡張した使い方も想定しています(実装はしていないです。。)
- CSV出力でExcel連携
- APIアクセスでWikiやドキュメント自動生成
- BIダッシュボードでの可視化
- データカタログツールとの連携
2. 抽出・確認できる情報
2.1 テーブル関連の情報
テーブル一覧の出力ニーズを想定しています。
テーブル情報（TABLE_DDL_INFO）
| カラム名 | 説明 | データ型 |
|---|---|---|
| catalog_name | カタログ名 | STRING |
| schema_name | スキーマ名 | STRING |
| table_name | テーブル名 | STRING |
| table_type | テーブル種別 | STRING |
| storage_format | ストレージ形式 | STRING |
| partition_strategy | パーティション戦略 | STRING |
| partition_columns | パーティションカラム | ARRAY<STRING> |
| clustering_strategy | クラスタリング戦略 | STRING |
| clustering_columns | クラスタリングカラム | ARRAY<STRING> |
| auto_optimize_write | 書き込み最適化 | BOOLEAN |
| auto_optimize_compact | 自動コンパクション | BOOLEAN |
| cdf_enabled | Change Data Feed | BOOLEAN |
| vacuum_retention_hours | VACUUM保持時間 | INTEGER |
| stats_column_limit | 統計列数制限 | INTEGER |
| time_travel_retention_days | Time Travel保持日数 | INTEGER |
| num_files | ファイル数 | LONG |
| size_in_bytes | サイズ（バイト） | LONG |
| table_features | テーブル機能 | ARRAY<STRING> |
以下はDatabricksのサンプルで提供されているSamplesカタログ配下のスキーマにあるテーブル情報を取得してみました。(長いので画面ショット3枚)
2.2 カラム関連の情報
カラム一覧の出力ニーズを想定しています
カラム情報（COLUMN_DDL_INFO）
| カラム名 | 説明 | データ型 |
|---|---|---|
| catalog_name | カタログ名 | STRING |
| schema_name | スキーマ名 | STRING |
| table_name | テーブル名 | STRING |
| column_name | カラム名 | STRING |
| ordinal_position | カラム順序 | INTEGER |
| data_type | データ型 | STRING |
| is_nullable | NULL許可 | BOOLEAN |
| is_partition_column | パーティションカラム | BOOLEAN |
| is_clustering_column | クラスタリングカラム | BOOLEAN |
| is_primary_key | 主キー | BOOLEAN |
| foreign_key_reference | 外部キー参照 | STRING |
以下はサンプルに格納されているtpchのカラム情報です
3. これが何の役に立ちそうなのか
3.1 手作業によるメタデータ管理の限界とリスク
データ基盤は複雑になりやすいです。手作業による棚卸は、以下のような問題が発生しがちです：
- 情報の陳腐化：手動更新のため、最新状態との乖離が生じる
- 作業負荷の集中：特定の「知っている人」への問い合わせが集中
- ミスの発生：手作業による転記ミスや漏れのリスク
- 非効率な情報収集：複数のシステムを横断した情報収集の手間
これらはデータマネジメントの観点からも重要な問題です。適切なメタデータ管理ができていない組織では、データ品質の低下や必要なデータがデータ基盤に集まらないなど、使われないデータ基盤になるリスクがます。
3.2 SIの現場でよくある要求と属人的管理の課題
プロジェクト参画時の情報収集
「新しくプロジェクトにアサインされたのですが、データ基盤の全体像を把握したいです。どんなテーブルがあるのか、一覧をもらえませんか？」
顧客への報告資料作成
「来週のステコミで現在のデータ資産の状況を報告する必要があります。テーブル数やデータサイズの一覧が欲しいです。」
運用引き継ぎ時の文書作成
「システムの運用を別チームに引き継ぐことになりました。パーティション設定や最適化設定などの技術仕様をまとめる必要があります。」
知っている人」への依存
多くの現場では、特定の詳しいメンバーに質問が集中する状況が発生しています：
- 構築担当者への負荷集中：「〇〇さんに聞けば分かる」状態の常態化
- 回答待ち時間の発生：問い合わせから回答までの時間ロス
- 属人化によるリスク：キーマンの異動や退職時の知識喪失
3.3 ドキュメント不備
実際のプロジェクト現場では、以下のような状況がよく見られます：
- 設計書と実態の乖離：構築後の設定変更が文書に反映されていない
- 部分的な情報しかない：一部のテーブルのみ文書化されている状況
- 複数の情報源：ExcelやWiki、チャットなどに散在する情報
これらの課題は、新規メンバーの立ち上がり時間が長くなったり、運用品質の低下につながります。
4. 今後の展望
ビジネスメタデータを入力、管理できるようにしたいと思っています。
入力はAppsで作れるかもしれません。
ワークフローまでできるとデータマネジメントっぽいですが、なかなか大変そう。
参考資料
ツールのソースコード
紹介したツール(ノートブック)は以下のリポジトリで公開しています。
Discussion