民主化を進めても、「このテーブルは何を意味するか」「このカラムの単位は」「いつ更新されるか」が分からないと使いこなせません。メタデータ基盤は、Bot/UIが裏で参照する辞書であり、人間が手動で引く社内 wiki でもあります。
メタデータの 4 階層
| 階層 | 情報 | 誰が見る |
|---|---|---|
| 1. テーブル | テーブル名 / 説明 / 所有者 / 更新頻度 / SLA | 全員 |
| 2. カラム | カラム名 / 型 / 意味 / NULL 許容 / 単位 / 例 | 全員(特に 書く人) |
| 3. 系譜 (Lineage) | 上流元 / 下流先 / 計算ロジック | アナリスト・エンジニア |
| 4. 利用ログ | 誰が / いつ / どんなクエリで使ったか | オーナー・データガバナンス |
ツールの代表的選択肢
dbt docs = dbt 内蔵機能( Core ユーザは無料、Cloud は月額)。 / = OSS、セルフホスト無料(マネージド SaaS は別料金)。Atlan / Alation / Collibra / Secoda = SaaS、OSS 版なし、有料のみ。dbt docs は dbt の世界の中だけ、それ以外は dbt + DWH + BI を横断する別レイヤです。
| ツール | 形態 | コスト | 強み | 弱み |
|---|---|---|---|---|
| dbt docs | dbt 内蔵 | Core: 無料 / Cloud: 月額 | dbt があれば自動生成、コードと整合、`schema.yml` の説明がそのまま web に | dbt model 内の世界だけ。Airflow 直書きや外部連携テーブルは漏れる |
| OSS (Apache 2.0) | セルフホスト無料 (運用工数あり) / Acryl SaaS は有料 | dbt + + + Airflow を横断、自動 lineage、利用統計、検索 | セルフホストの運用負荷、UI 学習コスト | |
| OSS (Apache 2.0) | セルフホスト無料 / Collate SaaS は有料 | OSS、UI が DataHub よりモダン、急成長中 | コミュニティ規模が DataHub よりは小 | |
| Atlan | SaaS のみ | 有料 ($$$) | UX 洗練、Slack 統合、UI が綺麗 | OSS なし、ロックイン懸念、価格高め |
| Alation | SaaS のみ | 有料 ($$$$) | ガバナンス機能厚い、エンタープライズ向け | OSS なし、価格高い |
| Collibra | SaaS のみ | 有料 ($$$$+) | 規制対応 (GDPR/SOX) に強い、大企業実績 | OSS なし、最も高価格帯 |
| Secoda | SaaS のみ | 有料 ($$) | 中小向けでシンプル | 機能限定、OSS なし |
この記事では「dbt 内」と「dbt 外を含む全社カタログ」をきちんと分けて使い分けます。前者は dbt docs、後者は / OpenMetadata / Atlan ── どれを選ぶかは規模と予算で決まります。
推奨スタートアップ:dbt docs から始める
既に dbt を使っているなら、まず dbt docs を真面目に書く。これだけで 6-7 割の効果が出ます。
version: 2
models: - name: orders description: "確定済みの注文(キャンセル・返金後の最終状態)" config: meta: owner: "team:commerce@hukuhuku.co.jp" sla_hours: 6 published: true # Bot に公開するか contains_pii: false update_frequency: "hourly" columns: - name: order_id description: "注文の一意識別子。UUID形式 (例: 'a1b2c3...')" tests: - unique - not_null - name: amount_jpy description: "注文金額(JPY、税込)。返金分は減算済み。負の値は禁止" tests: - not_null - name: customer_id description: "顧客ID(customers テーブルへの FK)。匿名顧客は 0" - name: created_at description: "注文時刻 (UTC)" meta: unit: "datetime"dbt docs を超える領域: の詳細
dbt docs の限界は「dbt を経由しないテーブル(Airflow 直書き、外部連携、CDC、生 SQL の DDL)が漏れる」こと。 は dbt の上位互換ではなく、dbt を含む全社レイヤを横断するメタデータプラットフォームです。
DataHub のライセンスと提供形態
| 形態 | 提供元 | コスト | 向く場面 |
|---|---|---|---|
| OSS セルフホスト | LinkedIn (元) → DataHub Project | 無料 (Apache 2.0) | エンジニアが運用工数を取れる組織 |
| Acryl Cloud (マネージド SaaS) | Acryl Data (商用化企業) | 有料 (要相談) | 運用工数を抑えたい / SLA が必要 |
DataHub 自体は無料の OSS です。Acryl Cloud という SaaS が別に存在し、それは 有料。「DataHub = 有料」と思われがちですが、 Compose や Helm で 自前で立てる分には完全無料で、機能制限もありません。
DataHub の核機能 4 つ
- 自動 Lineage: の `INFORMATION_SCHEMA.JOBS_*` / の ACCESS_HISTORY / manifest / OpenLineage から テーブル間の依存グラフを自動構築
- 利用統計: 「先週このテーブルを参照した user / クエリ数 / 平均レイテンシ」を可視化、使われていないテーブルを炙り出せる
- 所有者ピング & Subscription: メタデータが古い・壊れたとき所有者に Slack 通知。Subscribe しているテーブルの変更を購読
- 横断検索 (Elastic ベース): 全カラム名 + 説明 + タグ + 業務語彙 (Glossary Terms) を横断検索 ── EP.08 の発見 UX の土台
DataHub のセットアップ規模感
| タスク | 工数目安 |
|---|---|
| Docker Compose で起動 (PoC) | 1 日 |
| (本番) + 監視 | 1〜2 週 |
| BigQuery / Snowflake ingester 設定 | 1〜3 日 (DWH 1 つあたり) |
| dbt manifest ingester 設定 | 半日 |
| Looker / ingester | 1〜2 日 |
| Glossary 整備 + チームへの教育 | 継続 |
自前運用が重い場合は Acryl Cloud を選ぶ。SLA・自動アップグレード・サポート付き。日本語対応はないが UI は英語のみで実用的。
メンテを継続させる「責任の固定」
書いた人と運用する人がズレると腐る。dbt docs を最初に頑張って書いても、スキーマ変更時に description を更新しないと半年で陳腐化。所有者を モデル単位で固定し、 で description 必須にすると最低限保てる。
# .github/workflows/dbt-meta-check.ymlname: dbt metadata coverageon: [pull_request]
jobs: meta-coverage: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: pip install dbt-bigquery - run: dbt parse - name: Check column descriptions run: | python -c " import json m = json.load(open('target/manifest.json')) missing = [] for n, node in m['nodes'].items(): if node['resource_type'] != 'model': continue if not node.get('meta', {}).get('published'): continue for c, cfg in node['columns'].items(): if not cfg.get('description'): missing.append(f\"{node['name']}.{c}\") if missing: print('Missing descriptions:', missing) exit(1) "ツール選定の判断軸
| 状況 | 推奨 |
|---|---|
| dbt 主体、 200 人以下 | dbt docs だけでまず始める |
| dbt + Looker、200-1000 人 | dbt docs + DataHub を並走 |
| dbt 弱め、Airflow主体 | DataHub か OpenMetadata |
| スタートアップで運用工数を抑えたい | Secoda などの SaaS |
| 大企業でガバナンス重視 | Collibra / Alation |
ふくふくの推奨:3 段階で導入
- 1Phase 1(1-2 週間): dbt の schema.yml の description / meta を CI で必須化。これだけで利用者の理解度が劇的に上がる
- 2Phase 2(1-2 ヶ月): DataHub をセルフホストで立ち上げ、dbt + + を ingest。Lineage と検索が使えるようになる
- 3Phase 3(継続): 利用ログとの突合で 「使われてないテーブル」「説明が古いテーブル」を月次でレビュー、所有者に通知
次の話
EP.08 では、メタデータの上に立てる『発見 UX』。「こういうデータがあったのか」を非エンジニアにも気づかせるための、データカタログの UI/UX 設計。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。