ストーリー
田
田中VPoE
オーナーシップ体制が決まったら、次は「メタデータ」だ。データカタログの中核をなすものだ
あなた
メタデータは「データについてのデータ」ですよね。テーブル名やカラムの型とか
あ
田
田中VPoE
技術的メタデータはその通りだ。しかしメタデータには3種類ある。技術的メタデータ、ビジネスメタデータ、そして運用メタデータだ。これら3つが揃って初めて「データを発見して、理解して、信頼して使える」状態になる
あなた
3つのメタデータを管理するのは大変そうですね
あ
田
田中VPoE
だからこそ「戦略」が必要だ。全部を手動で管理しようとすると破綻する。自動収集を最大限活用しつつ、人間が付加する価値に集中するのがポイントだ
メタデータの3つの種類
種類と役割
| 種類 | 内容 | 具体例 | 主な利用者 |
|---|
| 技術的メタデータ | データの物理的な構造情報 | テーブル名、カラム名、データ型、制約、パーティション | データエンジニア |
| ビジネスメタデータ | データのビジネス上の意味と文脈 | ビジネス定義、計算ロジック、利用目的、オーナー | アナリスト、ビジネスユーザー |
| 運用メタデータ | データの運用状態に関する情報 | 更新頻度、最終更新日時、品質スコア、利用頻度 | データスチュワード |
3つのメタデータの関係
メタデータの3層構造:
ビジネスメタデータ(なぜ・何のために)
│ 「月間アクティブユーザー数」
│ 定義: 30日以内にログインした一意のユーザー数
│ オーナー: プロダクト部長
│
技術的メタデータ(何が・どこに)
│ テーブル: analytics.monthly_active_users
│ カラム: user_id (bigint), last_login (timestamp)
│ パーティション: month
│
運用メタデータ(いつ・どのように)
更新頻度: 日次 03:00 JST
最終更新: 2026-03-04 03:15:22
品質スコア: 99.2%
月間クエリ数: 1,240回
データカタログの構築
データカタログの機能要件
| 機能 | 説明 | 優先度 |
|---|
| 検索・発見 | キーワード、タグ、ドメインでデータを検索 | 最重要 |
| データプロファイリング | カラムの統計情報、分布、サンプルデータの表示 | 高 |
| リネージ | データの流れ(ソース→変換→消費先)の可視化 | 高 |
| 品質情報 | 品質スコア、最終チェック日時の表示 | 高 |
| アクセス管理 | データへのアクセス権限の確認・申請 | 高 |
| コラボレーション | コメント、レビュー、ブックマーク | 中 |
| 変更通知 | スキーマ変更やオーナー変更の通知 | 中 |
| API | プログラマティックなメタデータの取得・更新 | 中 |
データカタログツールの比較
| ツール | 種別 | 強み | 弱み |
|---|
| DataHub | OSS(LinkedIn) | リネージが強力、拡張性が高い | 導入・運用の技術力が必要 |
| Amundsen | OSS(Lyft) | 検索体験が優れている | 機能が限定的 |
| Apache Atlas | OSS(Hortonworks) | Hadoopエコシステムとの統合 | UIがやや古い |
| Collibra | 商用 | ガバナンス機能が充実 | 高コスト |
| Alation | 商用 | AI活用のメタデータ管理 | 高コスト |
| AWS Glue Data Catalog | クラウド | AWS統合が容易 | AWS外のソースは手間 |
| Google Data Catalog | クラウド | GCP統合が容易 | GCP外のソースは手間 |
メタデータ収集の自動化
自動収集と手動入力の使い分け
| メタデータ項目 | 収集方法 | 理由 |
|---|
| テーブル名、カラム名、データ型 | 自動 | スキーマから機械的に取得可能 |
| レコード数、NULL率、分布 | 自動 | プロファイリングで自動算出 |
| 最終更新日時、更新頻度 | 自動 | パイプラインログから取得 |
| 利用頻度、クエリ数 | 自動 | クエリログから自動集計 |
| リネージ(上流・下流) | 自動+手動 | パイプラインから自動取得、手動で補完 |
| ビジネス定義 | 手動 | 人間にしか書けない |
| オーナー、スチュワード | 手動 | 組織的な判断が必要 |
| 品質SLA | 手動 | ビジネス要件に基づく判断 |
自動収集のアーキテクチャ
メタデータ自動収集パイプライン:
[データソース] [メタデータ収集] [データカタログ]
PostgreSQL ──→ スキーマクロール ──→
BigQuery ──→ API取得 ──→ DataHub /
S3 ──→ ファイル分析 ──→ Amundsen ──→ 検索・閲覧
Airflow ──→ DAG解析 ──→ etc. ──→ リネージ表示
dbt ──→ manifest解析 ──→ ──→ 品質ダッシュボード
Looker ──→ API取得 ──→
[メタデータ収集の頻度]
├── スキーマ: 日次(変更検知時は即時)
├── プロファイリング: 週次
├── リネージ: dbt/Airflowの実行ごと
└── 利用統計: 日次
メタデータ管理のベストプラクティス
オーナーシップとの連携
| プラクティス | 説明 |
|---|
| スチュワードの品質責任 | 各ドメインのスチュワードがメタデータの品質を責任持って維持 |
| ビジネス定義のレビュー | 新規データの登録時にオーナーがビジネス定義をレビュー |
| 変更管理 | スキーマ変更時にカタログも同時に更新される仕組み |
| 利用者フィードバック | データ利用者が不備や改善点をコメントで指摘できる |
メタデータの品質管理
| 品質指標 | 測定方法 | 目標値 |
|---|
| カバレッジ | ビジネス定義がある項目数 / 全項目数 | 80%以上 |
| 鮮度 | 最終更新から30日以内の項目の割合 | 90%以上 |
| オーナー率 | オーナーが割り当てられている項目の割合 | 100% |
| 利用率 | 月1回以上検索・閲覧されたデータ資産の割合 | 60%以上 |
「メタデータは”データの取扱説明書”だ。取扱説明書がなければ、せっかくのデータも使えない。しかし取扱説明書を書くのに全エネルギーを使ってしまっては本末転倒だ。自動化できるものは自動化し、人間は”ビジネスの文脈”という自動化できない部分に集中する」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| 3種類のメタデータ | 技術的、ビジネス、運用メタデータを統合管理 |
| データカタログ | 検索・発見、プロファイリング、リネージが主要機能 |
| 自動化戦略 | 技術的・運用メタデータは自動、ビジネスメタデータは手動 |
| 品質管理 | カバレッジ、鮮度、オーナー率、利用率で測定 |
チェックリスト
次のステップへ
次は「プライバシーとコンプライアンス」を学びます。個人情報保護法やGDPRへの対応を含む、データコンプライアンスの設計方法を身につけましょう。
推定読了時間: 30分