Unity Catalog Lineageで実現するデータ系譜と影響分析｜テーブル・カラム単位の追跡

データパイプラインが複雑化すると、「あるテーブルを変更したら下流のどこに影響するか」「ゴールドテーブルの数値は どのソースカラムから導出されたか」という問いに即座に答えられる仕組みが不可欠になります。 Unity Catalog Lineageは、Databricks上で実行されるSparkジョブのテーブル間・カラム間の依存関係を 自動的に記録し、UIとAPIの両面で可視化・照会できる機能です。

この記事では、Lineageの仕組み、UIでの視覚化方法、Information Schemaビュー、REST APIでのプログラム取得、 カラムレベルリネージの詳細、影響分析の実務手順、そしてDatabricks認定試験での出題ポイントを整理します。

データ系譜（Lineage）とは

データ系譜とは、データがどこから来て、どのように変換され、どこに格納されたかの追跡記録です。 Unity Catalog Lineageは、Sparkジョブが読み取ったテーブル（上流）と書き込んだテーブル（下流）の関係を 自動的にキャプチャします。ETLコードに特別なアノテーションを加える必要はありません。

• テーブルレベル: テーブルAを読み取ってテーブルBに書き込んだ、という依存関係
• カラムレベル: テーブルAのprice列とquantity列がテーブルBのrevenue列の算出に使われた、という変換経路
• ノートブック/ジョブ: どのノートブック・ジョブがその変換を実行したか

このように3層の情報が自動的に蓄積されることで、データガバナンスと障害調査の両方が効率化されます。

Data Explorer UIでのリネージ可視化

最も直感的な確認方法は、Data Explorer（Catalog Explorer）のUIです。 テーブルの詳細ページで「Lineage」タブを開くと、上流テーブル（読み取り元）と下流テーブル（書き込み先）が 有向グラフとして表示されます。

• ノードをクリックすると、そのテーブルの詳細に遷移できる
• カラムレベルのリネージを展開すると、カラム同士の関係がハイライトされる
• ノートブック/ジョブのリンクから、変換を実行したコードに直接ジャンプできる

UIは非技術者との共有にも適しており、「このレポートの数値はどこから来ているか」を ビジネスユーザーに説明する際にも活用できます。

Information SchemaのLINEAGEビュー

プログラム的にLineage情報を取得したい場合、Information Schemaの専用ビューが便利です。 Unity CatalogのInformation Schemaはsystem.information_schemaに格納されています。

-- テーブルレベルのリネージ: どのテーブルがどのテーブルに依存しているか
SELECT
  source_table_full_name,
  target_table_full_name,
  event_type,         -- READ / WRITE
  created_by,         -- 実行ユーザー
  event_time
FROM system.access.table_lineage
WHERE target_table_full_name = 'prod.gold.daily_revenue'
ORDER BY event_time DESC
LIMIT 50;

-- カラムレベルのリネージ: 特定カラムの算出元を逆引き
SELECT
  source_table_full_name,
  source_column_name,
  target_table_full_name,
  target_column_name,
  event_time
FROM system.access.column_lineage
WHERE target_table_full_name = 'prod.gold.daily_revenue'
  AND target_column_name = 'total_amount'
ORDER BY event_time DESC;

system.access.table_lineageはテーブル単位の依存を、system.access.column_lineageはカラム単位の依存を提供します。 これらのビューへのアクセスにはメタストア管理者またはアカウント管理者の権限が必要です。

REST APIでのリネージ取得

CI/CDパイプラインや外部ガバナンスツールとの統合にはREST APIが最適です。 Unity Catalog APIの/lineage-trackingエンドポイントを使います。

# テーブルの上流リネージを取得
GET /api/2.1/unity-catalog/lineage-tracking/table-lineage
  ?table_name=prod.gold.daily_revenue
  &direction=UPSTREAM

# レスポンス例（簡略化）
{
  "upstreams": [
    {
      "tableInfo": {
        "name": "prod.silver.orders",
        "catalog_name": "prod",
        "schema_name": "silver"
      },
      "notebookInfos": [
        {
          "notebook_id": "12345",
          "workspace_id": "67890"
        }
      ]
    }
  ]
}

# カラムレベルの上流リネージを取得
GET /api/2.1/unity-catalog/lineage-tracking/column-lineage
  ?table_name=prod.gold.daily_revenue
  &column_name=total_amount

REST APIではdirectionパラメータでUPSTREAM（上流）とDOWNSTREAM（下流）を 切り替えられます。影響分析にはDOWNSTREAM、根本原因調査にはUPSTREAMを使います。

カラムレベルリネージの詳細

カラムレベルリネージは、テーブルレベルより粒度の細かい追跡です。 Sparkが実行する論理プラン（Catalyst Optimizer経由）を解析して、 入力カラムから出力カラムへの変換経路を導出します。

UDFの内部ロジックはSparkの論理プランでは解析できないため、カラムリネージは 「UDFの入力カラム → UDFの出力カラム」のレベルで記録されます。UDF内部でどのカラムが 実際に使われたかは区別できない点に注意してください。

影響分析の実務手順

影響分析とは、「あるテーブルやカラムを変更した場合、下流のどのテーブル・ダッシュボード・ジョブに影響するか」 を事前に洗い出す作業です。Lineageを使った手順は以下の通りです。

1. 変更対象のテーブル/カラムを特定する
2. Data Explorer UIまたはREST APIで下流（DOWNSTREAM）リネージを取得する
3. 影響を受けるテーブル、ビュー、ダッシュボードの一覧を作成する
4. 各下流オブジェクトのオーナーに変更を通知する
5. 変更後にリネージが正しく更新されていることを確認する

-- 影響分析: silver.ordersを変更した場合の下流テーブルを洗い出し
SELECT DISTINCT
  target_table_full_name,
  target_column_name
FROM system.access.column_lineage
WHERE source_table_full_name = 'prod.silver.orders'
  AND source_column_name = 'amount'
ORDER BY target_table_full_name;

-- 結果例:
-- prod.gold.daily_revenue     | total_amount
-- prod.gold.customer_summary  | lifetime_value
-- prod.gold.monthly_report    | gross_sales

この結果から、silver.orders.amountカラムの型変更やリネーム時に 3つのGoldテーブルの再検証が必要だと分かります。

Lineageの制約と注意点

• Databricks外部からの書き込み（Airflow→S3直接など）はLineageに記録されない
• Lineage情報の保持期間は1年間（それ以前のデータは自動削除される）
• JDBC/ODBC経由のクエリはテーブルレベルのみ（カラムレベルリネージは非対応）
• DLTパイプラインのリネージはDLT UIに別途表示される（2026年時点ではInformation Schemaと統合途上）
• ストリーミングジョブのリネージはマイクロバッチ単位で記録される

試験で問われるポイント

• Lineageの追跡粒度: テーブルレベルとカラムレベルの両方が可能
• Lineage情報の取得方法: UI / Information Schema / REST API の3つ
• 影響分析の方向: UPSTREAM（根本原因）とDOWNSTREAM（影響範囲）
• Lineageの自動記録: ETLコードへの追加設定は不要
• 制約: Databricks外部の処理はLineageに含まれない
• system.access.table_lineageとsystem.access.column_lineageのビュー名

問題で確認

よくある質問