ふくふくHukuhuku Inc.
EP.07Democracy 12分公開: 2026-05-10

メタデータ基盤を整える:dbt docs / DataHub / Atlan の選定と運用

「このテーブルって何?」に機械的に答える土台。カタログツールの選定軸、メタデータの粒度(テーブル・カラム・系譜・所有者)、メンテを継続させる運用設計を整理。

#メタデータ#{{dbt|*}}#DataHub#Atlan#カタログ
シェア

民主化を進めても、「このテーブルは何を意味するか」「このカラムの単位は」「いつ更新されるか」が分からないと使いこなせません。メタデータ基盤は、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 docsdbt 内蔵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 よりは小
AtlanSaaS のみ有料 ($$$)UX 洗練、Slack 統合、UI が綺麗OSS なし、ロックイン懸念、価格高め
AlationSaaS のみ有料 ($$$$)ガバナンス機能厚い、エンタープライズ向けOSS なし、価格高い
CollibraSaaS のみ有料 ($$$$+)規制対応 (GDPR/SOX) に強い、大企業実績OSS なし、最も高価格帯
SecodaSaaS のみ有料 ($$)中小向けでシンプル機能限定、OSS なし

この記事では「dbt 内」と「dbt 外を含む全社カタログ」をきちんと分けて使い分けます。前者は dbt docs、後者は / OpenMetadata / Atlan ── どれを選ぶかは規模と予算で決まります。

推奨スタートアップ:dbt docs から始める

既に dbt を使っているなら、まず dbt docs を真面目に書く。これだけで 6-7 割の効果が出ます。

dbt の schema.yml にメタデータを書く
YAML
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 / ingester1〜2 日
Glossary 整備 + チームへの教育継続

自前運用が重い場合Acryl Cloud を選ぶ。SLA・自動アップグレード・サポート付き。日本語対応はないが UI は英語のみで実用的。

メンテを継続させる「責任の固定」

メタデータが腐るパターン

書いた人と運用する人がズレると腐る。dbt docs を最初に頑張って書いても、スキーマ変更時に description を更新しないと半年で陳腐化。所有者を モデル単位で固定し、 で description 必須にすると最低限保てる。

CI でカラム description を必須化
YAML
# .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主体DataHubOpenMetadata
スタートアップで運用工数を抑えたいSecoda などの SaaS
大企業でガバナンス重視Collibra / Alation

ふくふくの推奨:3 段階で導入

  1. 1Phase 1(1-2 週間): dbt の schema.yml の description / meta を CI で必須化。これだけで利用者の理解度が劇的に上がる
  2. 2Phase 2(1-2 ヶ月): DataHub をセルフホストで立ち上げ、dbt + + を ingest。Lineage と検索が使えるようになる
  3. 3Phase 3(継続): 利用ログとの突合で 「使われてないテーブル」「説明が古いテーブル」を月次でレビュー、所有者に通知

次の話

EP.08 では、メタデータの上に立てる『発見 UX』。「こういうデータがあったのか」を非エンジニアにも気づかせるための、データカタログの UI/UX 設計。

シェア

この記事の感想を教えてください

あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。

シリーズの外も探す:

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp