データリネージとカタログ

なぜ「どこから来たか」が分析基盤の急所なのか

分析基盤は、生ログやアプリDBの抽出から始まり、何十段ものETL/ELTを経てダッシュボードやMLの特徴量にたどり着きます。テーブルは数百から数千、それらを生むジョブも同数。ここで日常的に起きる二つの問いが、基盤運用の急所です。

• 影響分析（下流方向）: 「この生テーブルの列名を変える／このジョブを止めると、どのダッシュボードとどのMLが壊れるか」。
• 根本原因追跡（上流方向）: 「経営会議の売上KPIが先週から変だ。この数字はどのテーブル群の、どの変換を経て作られたのか」。

素朴には「SQLを全部grepする」で当たりを付けられますが、変換が多段でエンジンも複数（バッチSQL、Spark、ストリーム処理、BIツール内の計算列）になると破綻します。必要なのは、データ資産どうしの生成・依存関係を機械可読なグラフとして持つことです。これがデータリネージ（data lineage） で、それを検索・信頼判断できる形に束ねる発見層がデータカタログ（data catalog） です。DB内部のクエリ最適化（/database/）が「1つのクエリの中の依存」を扱うのに対し、ここで扱うのは基盤全体をまたぐデータ資産間の依存であり、粒度も寿命も桁が違います。

採取の二系統：静的解析と実行時採取

リネージの辺をどうやって集めるか。ここが精度と網羅性を左右する要で、大きく二つの流派があります。

静的解析（デザインタイム） は、SQLやジョブ定義といったコードを実行せずにパースし、依存を推定します。INSERT INTO gold.sales SELECT ... FROM silver.orders JOIN silver.customers ... を構文解析すれば、silver.orders と silver.customers から gold.sales への辺、さらに SELECT の各式をたどればどの入力列がどの出力列を作るかというカラムレベルの辺まで導けます。実行を伴わないので全パイプラインを事前に俯瞰でき、CIでの影響分析（マージ前に壊れる下流を検出）に向きます。弱点は、SELECT *・動的生成SQL・UDFの中身・外部関数など、静的には解決できない参照を取りこぼす点です。

実行時採取（ランタイム） は、クエリエンジンやオーケストレータが実際に読み書きしたオブジェクトをイベントとして記録します。エンジンの実行計画やクエリログには「このジョブが実際に読んだテーブルと書いたテーブル」が残るため、動的SQLでも実測として辺が取れます。オープンな系ではOpenLineageのような規約でジョブ開始・完了イベントに入出力データセットを載せて収集します。弱点は、実行されない経路は現れないこと（当日走らなかったジョブの辺は欠ける）と、収集の仕込みが要ることです。

両者は排他ではなく、併用が定石です。静的解析で網羅的な設計上の依存を押さえ、実行時採取で実測と動的経路を補う。カラムレベルまで採るかは費用対効果の判断で、テーブルレベルなら安価に全体を覆え、カラムレベルは影響分析の精度を上げる代わりにパース・保持コストが増えます。

カタログ：発見可能性という別の問題

リネージが「関係」を扱うのに対し、カタログが解くのは発見可能性（discoverability） です。数千テーブルの基盤で「顧客の解約率を出したい。どのテーブルを使えばいいか」に答えられなければ、正しいデータがあっても価値になりません。カタログは各データ資産に付随するメタデータを一元化した索引です。集めるメタデータは層で分けて捉えると整理できます。

技術メタデータ : スキーマ（列名・型）, パーティション, 物理配置, サイズ
運用メタデータ : 最終更新時刻(鮮度), 行数推移, ジョブ成否, クエリ頻度
ビジネスメタデータ: 論理名・説明, 用語集(glossary)への紐付け, タグ, 機密区分
社会的メタデータ : 所有者(owner), よく使う人, Q&A, 人気度(利用統計)

これらを全文検索とファセット絞り込みに載せることで、「churn を含み、鮮度が24時間以内で、認証済みの（信頼できる）テーブル」を引けるようになります。ここで効くのが社会的メタデータで、利用統計（誰がどれだけ叩いているか）は信頼のシグナルになります。多数のダッシュボードが依存し、著名なアナリストが使っているテーブルは、名前が似た放置テーブルより信頼できる——という判断を、人手のドキュメントに頼らず自動収集した事実で支えるのがモダンなカタログの発想です。

ガバナンスと影響分析：同じグラフを二方向に使う

リネージとカタログを束ねると、ガバナンスと影響分析が同じ基盤の上で回り始めます。両者は同じDAGを逆向きにたどる操作にすぎません。

影響分析（下流方向） は、変更の波及を事前に見積もります。ある列を消す前にリネージを下流へ展開すれば、依存する中間テーブル・ダッシュボード・MLジョブが列挙でき、壊れる範囲を実行前に把握できます。カラムレベルのリネージがあれば「その列だけを参照している資産」に絞れるため、過剰な巻き込みを避けられます。これはCIに組み込む価値が高く、スキーマ変更のPRに対して「この変更は下流の12資産に影響し、うち3つは認証済みダッシュボード」と自動注記できます。

根本原因・監査（上流方向） は、下流の異常や規制対応で由来をたどります。KPIの異常時に上流へ展開すれば、途中のどのジョブが失敗・変質したかを絞り込めます。規制面では、ある個人情報（PII）列がどこまで伝播したかをリネージで全経路たどることが、削除要求（忘れられる権利）や漏洩時の影響範囲特定に直結します。

ガバナンスの肝は、分類（classification）をリネージで伝播させることです。生テーブルの列を「PII・機密」とタグ付けしたら、そこから生成される下流の列も同じ機密度を継ぐべきです。これを人手で維持するのは不可能なので、カラムリネージに沿ってタグを自動伝播させ、下流に現れた機密データにも一貫したアクセス制御・マスキングを効かせます。こうして「誰が・どのデータを・どこまで使えるか」というポリシーを、資産ごとの個別設定ではなく由来に基づいて一元的に運用できます。

まとめ

• データリネージは、テーブル/カラム/ジョブをノード、生成関係を有向辺とするDAG。上流→下流で影響分析、下流→上流で根本原因追跡という、同じグラフの二方向利用になる。
• 採取には静的解析（コードをパース、事前に俯瞰できるが動的参照に弱い）と実行時採取（実測、正確だが走った経路のみ）があり、併用が定石。カラムレベルまで採るかは費用対効果で決める。
• データカタログは技術・運用・ビジネス・社会的メタデータを一元化した索引で、解く問題は発見可能性。利用統計などの社会的メタデータは信頼のシグナルとして効く。
• メタデータは人手台帳ではなく各システムから自動で継続収集するのが原理的な解。カタログの価値は自動収集ソースの広さでほぼ決まる。
• リネージ×カタログでガバナンスと影響分析が同一基盤に載る。機密タグをカラムリネージに沿って伝播させ、由来に基づくアクセス制御を実現する。
• リネージは推定と欠測を含む。切れた辺は「依存なし」ではなく「未観測」。カバレッジ自体を管理指標にし、影響分析の結果は保守的に運用する。