BigQueryのデータリネージでデータマートの依存関係を可視化する

はじめに：このテーブル、どこ由来か分からない問題

BigQueryでデータ分析を続けていると、必ず一度はこの壁にぶつかります。

「ダッシュボードに出ているこの数字、どのテーブルを集計したものだっけ？」「このデータマート、元データはGA4のエクスポートだっけ、それとも別の集計テーブルだっけ？」

最初のうちはテーブルが数個しかないので頭の中で把握できます。ところが、生データ → 中間テーブル → データマート → ダッシュボード、という流れを作り込んでいくと、テーブルの数はあっという間に数十個に増えます。しかもスケジュールクエリで毎日自動更新していると、誰が何を参照しているのか、もはや本人ですら追えなくなってきます。

この「どのテーブルがどこ由来か分からない」状態は、地味ですが運用上かなり危険です。たとえば元テーブルのカラム名を変えたいとき、それを参照している下流のクエリがどれだけあるか分からないと、安心して変更できません。結果として「怖くて触れないテーブル」が増えていきます。

この記事では、テーブル同士の依存関係（どのテーブルがどのテーブルから作られているか）を可視化する2つの方法を紹介します。1つはGoogle Cloud標準の データリネージ 機能、もう1つは INFORMATION_SCHEMA.JOBS を使った手軽な代替手段です。

データリネージとは

データリネージ（data lineage）とは、データが「どこから来て、どう加工されて、どこへ行ったか」を辿れるようにする仕組みのことです。日本語では「データの系統」「来歴」などと訳されます。

イメージとしては、家系図のテーブル版です。あるデータマートを起点にして、

その上流（このマートは何から作られたか）
その下流（このマートは何に使われているか）

を線でつないで把握できる状態を指します。

リネージが整っていると、次のようなことがすぐ分かります。

あるテーブルを変更・削除したときの 影響範囲（下流に何があるか）
ダッシュボードの数字が合わないときの 原因の遡り（上流のどこで壊れたか）
似たような集計テーブルが乱立していないかの 棚卸し

要するに「触っていいテーブルか」「壊れたらどこを見るか」を判断するための地図です。

BigQuery / Dataplexのリネージ機能

Google Cloudには、このリネージを自動で収集・可視化してくれる機能があります。BigQueryのテーブルを対象にした データリネージ で、Dataplex（現在はDataplex Universal Catalog / Knowledge Catalogの一部）の機能として提供されています。

何ができるのか

大きく次の2段階のリネージに対応しています。

テーブルレベル（オブジェクトレベル）のリネージ — テーブルとテーブルのつながりを辿る。「マートAは生テーブルBとCから作られている」というレベルの把握。
カラムレベルのリネージ — 特定のカラムが、上流のどのカラムから来ているかを辿る。より細かい単位での追跡。

カラムレベルのリネージはBigQueryのデータを対象に提供されており、たとえば「集計結果のこの売上カラムは、元をたどると注文テーブルのこのカラムだ」といった粒度で確認できます。

どうやって有効化・確認するのか

リネージを使うには、まずプロジェクトで Data Lineage API を有効化します。有効化すると、対応するサービスがデータを処理・移動するたびに、リネージ情報が自動的に記録されていきます。

自動でリネージが収集される主なGoogle Cloudサービスは次のとおりです。

BigQuery
Dataflow
Cloud Composer
Dataproc
Cloud Data Fusion
Vertex AI

このうち中小ECの現場で関係してくるのは、まずBigQueryです。BigQueryで集計クエリを流していれば、その入力テーブルと出力テーブルの関係が自動で記録されていく、というイメージです。

確認は、Google Cloudコンソール上でテーブルを開き、リネージのビュー（系統を図で示すグラフ表示）から行います。テーブルを起点に上流・下流が線でつながって表示されるので、コードを読まなくても依存関係を目で追えます。

注意したい点

便利な機能ですが、いくつか前提があります。

記録には時間差がある — リネージ情報が反映されるまで、おおむね30分〜24時間程度かかる場合があります。クエリを流した直後にリアルタイムで見えるものではない、と考えておくのが安全です。
対応範囲は更新される — 対応サービスやカラムレベル対応の細かい条件は変わり得ます。実際に使う前に、必ず最新の公式ドキュメント（Dataplex / Knowledge Catalogのデータリネージのページ）で現時点の提供範囲を確認してください。
APIの有効化が前提 — 何もしなくても勝手に貯まるわけではなく、Data Lineage APIを有効にしてからのデータが対象です。過去に遡って全部見えるわけではありません。

「ちゃんとした地図がほしい」「カラム単位まで追いたい」というニーズには、この標準機能が第一候補になります。

INFORMATION_SCHEMA.JOBS で依存を把握する代替

「Dataplexの機能を有効化するほどではないけれど、ざっくり依存関係を知りたい」という場合は、BigQueryの クエリ履歴 から自力で依存を割り出す方法があります。

BigQueryには INFORMATION_SCHEMA.JOBS というビューがあり、過去に実行されたクエリジョブの情報が記録されています。この中の referenced_tables というカラムに、そのクエリが参照したテーブルの一覧が入っています。これを使えば「どのテーブルがどれだけ参照されているか」を集計できます。

まず、参照回数の多いテーブルを洗い出す基本のクエリです。

-- 過去30日間で、よく参照されているテーブルのランキング
SELECT
  t.project_id,
  t.dataset_id,
  t.table_id,
  COUNT(*) AS num_references
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS,
  UNNEST(referenced_tables) AS t
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
GROUP BY
  t.project_id, t.dataset_id, t.table_id
ORDER BY
  num_references DESC;

region-asia-northeast1 の部分は対象のリージョンに合わせて書き換えてください。referenced_tables は配列なので UNNEST で展開してから集計するのがポイントです。

次に、依存関係そのものを見るなら、「あるクエリが、どの出力先テーブルに、どの入力テーブルを使って書き込んだか」を取り出します。destination_table（書き込み先）と referenced_tables（参照元）を並べると、上流・下流の対応表が作れます。

-- 出力先テーブルごとに、参照している入力テーブルを一覧化する
SELECT
  destination_table.dataset_id AS dest_dataset,
  destination_table.table_id   AS dest_table,
  ref.dataset_id               AS source_dataset,
  ref.table_id                 AS source_table,
  COUNT(*)                     AS job_count
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS,
  UNNEST(referenced_tables) AS ref
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND destination_table.table_id IS NOT NULL
GROUP BY
  dest_dataset, dest_table, source_dataset, source_table
ORDER BY
  dest_dataset, dest_table;

この結果を見れば、「マートAは生テーブルBとCを参照して作られている」という関係が、出力先ごとに並びます。Dataplexのグラフ表示ほど見やすくはありませんが、SQLだけで済むので導入のハードルが低いのが利点です。

ただし、この方法にはいくつか限界があります。

INFORMATION_SCHEMA.JOBS には 保持期間 があり、古いジョブはさかのぼれません（標準では過去180日分）。
カラムレベルの依存までは分かりません。あくまでテーブル単位です。
手で実行された一時的なクエリも混ざるため、定常的な依存だけを見たい場合はフィルタの工夫が要ります。

「正式なリネージを入れる前に、まず現状を把握したい」「スケジュールクエリで作っているマートの依存を棚卸ししたい」といった場面で十分役立ちます。スケジュールクエリでデータマートを回している方は、まずこの代替クエリで現状を眺めてみるのがおすすめです。設定の流れは BigQueryのスケジュールクエリでデータマートを毎朝自動更新するも合わせてどうぞ。

活用：影響範囲の調査に効く

リネージが見えるようになると、日々の運用が一段ラクになります。とくに効くのが 影響範囲の調査 です。

たとえば次のような場面を考えてみます。

「生データのテーブルでカラム名を price から unit_price に変えたい。でも、これを参照している集計クエリやダッシュボードが壊れないか心配だ」

リネージがない状態だと、心当たりのあるクエリを片っ端から開いて price を検索する、という手作業になります。見落とせばダッシュボードが翌朝こっそり壊れます。

一方、リネージが整っていれば、

変更したい元テーブルを起点にする
下流（そのテーブルを参照している側）を辿る
出てきたマートやクエリだけを点検する

という流れで、調べる対象を必要な範囲に絞り込めます。「全部見る」から「関係するものだけ見る」に変わるので、確認の手間も見落としのリスクも大きく下がります。

逆方向、つまり「ダッシュボードの数字がおかしい」ときの原因調査でも同じです。下流（ダッシュボード）から上流（生データ）へ遡れば、どの段階で数字が壊れたかを順番に潰していけます。

このあたりは、データの正しさを保つテストの考え方ともつながります。依存が見えていれば、変更時にどのテーブルを検証すべきかが明確になるからです。テスト面の具体策は BigQueryのSQLをテストしてデータ品質を守るでまとめています。

まとめ

データマートが増えてくると、「どのテーブルがどこ由来か分からない」状態は必ず訪れます。そのときに頼りになるのが、データの来歴を辿るリネージです。

しっかり可視化したいなら — Google Cloud標準のデータリネージ（Dataplex / Knowledge Catalog）。Data Lineage APIを有効化すれば、BigQueryなどの処理が自動で記録され、コンソールのグラフでテーブル・カラム単位の依存を辿れます。提供範囲は更新されるため、導入前に最新の公式ドキュメントで確認してください。
まず現状把握したいなら — INFORMATION_SCHEMA.JOBS の referenced_tables を使った代替クエリ。SQLだけで、出力先テーブルごとの参照元を棚卸しできます。保持期間やテーブル単位までという制約はありますが、導入は手軽です。

どちらにせよ、依存関係が見えるようになると「触っていいテーブルか」「壊れたらどこを見るか」の判断が速くなります。テーブルが増えて怖くなってきたな、と感じたら、まずは代替クエリで自分のデータマートの地図を一度描いてみてください。