データリネージ - L0 カリキュラム

ストーリー

田

田中VPoE

データ品質に問題が見つかった時、最初に聞かれるのは「このデータはどこから来たのか？」だ

あなた

上流のどのテーブルが原因なのかを追跡する必要がありますね

あ

田

田中VPoE

それがデータリネージ — データの系譜だ。上流から下流へのデータの流れを可視化し、影響範囲の分析、障害の原因特定、コンプライアンス対応を可能にする

あなた

dbtにもリネージ機能がありますよね

あ

田

田中VPoE

dbtのDAG（Directed Acyclic Graph）はリネージの一形態だ。しかしdbtだけでは不十分で、dbt外のデータフロー（Airflow、Kafka、Fivetran等）も含めた全体リネージが必要になる。OpenLineageという標準仕様が登場し、ツール横断的なリネージ管理が可能になりつつある

データリネージとは

3つのリネージ

種類	説明	例
テーブルリネージ	テーブル間の依存関係	orders → fact_orders → revenue_mart
カラムリネージ	カラム間の変換関係	orders.amount → fact_orders.net_amount
ジョブリネージ	パイプライン/ジョブの実行関係	Airflow DAG → dbt run → BI refresh

テーブルリネージの例:

  PostgreSQL.orders ──→ brz_orders ──→ slv_orders ──→ fact_orders ──→ revenue_daily
  PostgreSQL.customers ──→ brz_customers ──→ slv_customers ──→ dim_customer ──┘
  Stripe.invoices ──→ brz_invoices ──→ slv_payments ──→ fact_payments ──→ revenue_daily

  影響分析:
  Q: 「PostgreSQL.ordersのスキーマが変わったら、何に影響する？」
  A: brz_orders → slv_orders → fact_orders → revenue_daily が影響を受ける

カラムリネージの重要性

カラムリネージの例:

PostgreSQL.orders.amount
  → brz_orders.amount (そのまま)
  → slv_orders.total_amount (CAST + リネーム)
  → fact_orders.net_amount (割引適用: total_amount - discount)
  → revenue_daily.net_revenue (SUM(net_amount))
  → Looker.daily_revenue (表示)

PIIトラッキング:
  PostgreSQL.customers.email (PII)
    → brz_customers.email (PII)
    → slv_customers.email_hash (SHA256でハッシュ化 → PIIではない)
    → dim_customer.email_hash (PIIではない → BIに表示OK)

リネージツール

主要ツール比較

ツール	タイプ	リネージ方式	特徴
dbt	ビルトイン	SQLの解析	dbtモデル内のリネージのみ
OpenLineage	標準仕様	イベントベース	ツール横断、OSS標準
DataHub	カタログ + リネージ	メタデータ収集	LinkedIn発、包括的
Apache Atlas	ガバナンス	メタデータ収集	Hadoopエコシステム
Marquez	リネージ特化	OpenLineage互換	軽量、API中心
Atlan	商用	自動収集	エンタープライズ向け

OpenLineage

OpenLineage の仕組み:

各ツールがOpenLineageイベントを発行:

  Airflow ──→ ┌──────────────────┐
  dbt    ──→  │ OpenLineage API  │ ──→ Marquez / DataHub
  Spark  ──→  │ (標準仕様)        │     (リネージストア)
  Flink  ──→  └──────────────────┘

OpenLineage イベント例:
{
  "eventType": "COMPLETE",
  "job": {
    "namespace": "dbt",
    "name": "gold.revenue_daily"
  },
  "inputs": [
    {"namespace": "bigquery", "name": "silver.slv_orders"},
    {"namespace": "bigquery", "name": "silver.slv_customers"}
  ],
  "outputs": [
    {"namespace": "bigquery", "name": "gold.revenue_daily"}
  ],
  "run": {
    "runId": "run_abc123"
  }
}

リネージの活用シーン

実践的なユースケース

ユースケース	説明	リネージの使い方
影響分析	ソーステーブルの変更による影響範囲特定	下流のすべてのテーブルとダッシュボードを特定
根本原因分析	データ品質問題の原因追跡	問題のあるテーブルから上流をたどる
コンプライアンス	PIIデータの流れの追跡	PIIカラムが最終的にどこに到達するかを確認
変更管理	スキーマ変更のリスク評価	変更の影響を受けるダッシュボードの数を把握
データ廃止	不要テーブルの安全な削除	下流に消費者がいないことを確認

影響分析の実践

シナリオ: PostgreSQL.orders テーブルにカラム追加

影響分析フロー:
1. リネージでPostgreSQL.ordersの下流を検索
2. 影響を受けるテーブル一覧:
   ├── brz_orders (CDC取り込み → 自動で新カラム追加)
   ├── slv_orders (dbtモデル → SELECT * なら自動、明示指定なら修正不要)
   ├── fact_orders (dbtモデル → 使わないカラムは影響なし)
   └── revenue_daily (fact_ordersに依存 → 影響なし)
3. 結論: カラム追加は後方互換 → 影響なし

「リネージは保険のようなものだ。普段は意識しないが、問題が起きた時に『あってよかった』と痛感する。特にPIIの流れを把握していないとGDPR/個人情報保護法違反のリスクがある」 — 田中VPoE

まとめ

ポイント	内容
リネージの種類	テーブルリネージ、カラムリネージ、ジョブリネージ
OpenLineage	ツール横断的なリネージの標準仕様
活用シーン	影響分析、根本原因分析、コンプライアンス、変更管理
PIIトラッキング	カラムリネージでPIIの流れを追跡し、コンプライアンスを確保

チェックリスト

3種類のリネージの違いを説明できる
OpenLineageの仕組みと主要ツールを理解した
リネージを使った影響分析の方法を理解した
PIIトラッキングの重要性を説明できる

次のステップへ

次は「データカタログ」を学びます。組織内のデータを発見可能にし、メタデータを一元管理する仕組みを身につけましょう。

推定読了時間: 30分