データリネージとは？定義、例、そしてその仕組み

What is data lineage? データ系統 これは、データが元のソースから最終的な宛先までたどる経路を文書化したもので、その過程で通過するすべてのテーブル、ビュー、ジョブ、変換を含みます。これは、すべてのデータチームが抱く2つの疑問に答えるものです。 「この価値観はどこから来たのか？」 （由来） 「下流工程では、何がそれに左右されるのか？」 （影響分析）SQLベースのシステムでは、通常、データの移動や整形を行うSQLコードを解析することで、データリネージが自動的に抽出されます。

このページは、実務担当者向けの定義です。データリネージが実際に記録する内容、テーブルレベルとカラムレベルの粒度の違い、直接的な関係と間接的な関係、データリネージを構築する3つの方法、そして誰が本当にそれを必要とするのかについて説明します。ほとんどのデータウェアハウスでは変換ロジックがSQLで実行されるため、例ではSQLを使用しています。

系譜が答える2つの質問：起源と影響分析

データリネージは、双方向に読み取れる1つのグラフです。 上流 そして、データ来歴が明らかになります。レポート内の数値から出発して、すべてのビュー、結合、計算を遡って、その数値が導き出された元のソース列までたどり着きます。これは、監査人、規制当局、そして誤った数値のデバッグを行うすべての人にとって重要な方向性です。

読んでみて 下流 そして、影響分析が行われます。名前変更、型変更、または削除したい列から始めて、影響を受けるすべてのテーブル、ビュー、プロシージャ、およびレポートを列挙します。これは、スキーマ変更や移行を行う前にエンジニアが重視する方向性であり、代替案としては、何千ものスクリプトをgrepして運任せにするしかありません。

これらの用語は時として曖昧に使われる。厳密には、 由来 逆方向トレースは、 影響分析 は順方向のトレースであり、 データ系統 これは、両方のトラバーサルを可能にする基盤となる依存関係グラフです。

具体的な例

通常の倉庫明細書について考えてみましょう。

INSERT INTO monthly_revenue (month, total) SELECT DATE_TRUNC('month', o.order_date) AS month, SUM(o.amount) AS total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.region = 'EMEA' GROUP BY DATE_TRUNC('month', o.order_date);

この一つの記述から抽出された系譜には、すでに2つの異なる種類の関係性が存在する。

• 直系の血統 — データは実際に出力に流れ込みます。 注文日 フィード 月次収益.月 を通して 日付切り捨て、 と 注文数 フィード 月間収益合計 を通して 和.
• 間接的な系統 — 出力には含まれないものの、出力に影響を与える列： 顧客地域 行をフィルタリングし、 注文の顧客ID 参加しました 顧客ID どの行が一致するかを決定します。 地域 は埋まっており、すべての数字は 月間収益 変化があっても、 地域 結果にはどこにも表示されません。

実際のパイプラインは、ビュー、ストアドプロシージャ、dbt モデルを通して階層化された、このようなステートメントが何千個も連なったものです。リネージツールが存在するのは、人間がそのようなグラフを頭の中で記憶しておくことができないからです。マルチホップやストアドプロシージャのリネージなど、より詳細な事例については、こちらをご覧ください。 データ系統の例 攻略ガイド。

テーブルレベルと列レベルの系統

系統情報には2つの粒度があり、その違いによって実際に何ができるかが決まります。

	テーブルレベルの系統	列レベルの系統
記録される内容	月間収益 から構築されています 注文 と 顧客	月間収益合計 = SUM(orders.amount)フィルター済み 顧客地域参加日 customer_id = id
影響分析	近似値: 変更された列が一切影響を与えないテーブルを含む、テーブルのすべての利用者にフラグを立てます。	正確: 列が実際に供給する消費者のみにフラグを立てます
監査回答	「本報告書では、これらの表を使用しています」	「この数値は、まさにこれらのソースフィールドから、これらの変換を経て算出されたものです。」
典型的な情報源	ジョブオーケストレーターのメタデータ、クエリログ	SQL自体を解析する

テーブルレベルの系統情報は収集コストが安く、パイプラインの最初のマップとして役立ちますが、実際の質問のほとんどは列に関するものです。どのレポートが メールこの規制された数値にどのソース フィールドが供給しているかは、削除したい列を読み取る下流のすべてです。そのためには、各出力列を結合、サブクエリ、CTE、ビュー、および 選択 * 拡張: パーサー作業、ログスクレイピングではありません。メカニズムについては、ガイドで詳しく説明しています。 列レベルのデータリネージ.

データリネージの構築方法：3つのアプローチ

市販されている家系図作成ツールはすべて、3つの手法のいずれかを組み合わせて使用している。

アプローチ	仕組み	得意なこと	弱い
静的SQL分析	SQLコード（ビュー、プロシージャ、ETLスクリプト、dbtモデル）を解析し、構文と意味から依存関係グラフを導出します。	列レベルの精度。最近実行されていないものも含め、すべてのコードパスを網羅。データへのアクセスは不要。	各SQL方言を真に理解するパーサーが必要です。非SQL変換（Python、Spark DataFrame）は対象外です。
ランタイム/クエリログベース	実際に実行された内容を観察する ― ウェアハウスクエリ履歴、オーケストレーターイベント（OpenLineage/Marquezモデル）	SQL以外のジョブを含む、多様なジョブにおける実際の実行状況を把握し、「いつ何が実行されたか」の真値を特定する。	観測期間中に実行されたパスのみが表示されます。粒度は多くの場合テーブルレベルです。ログには依然としてSQLが含まれており、列の詳細を取得するには解析する必要があります。
マニュアルドキュメント	アナリストはマッピングをスプレッドシートまたはカタログに手書きで記録する	パーサーでは推測できないビジネスコンテキストと定義	書かれた翌日には陳腐化する。実際の規模では誤りが発生しやすい。

これらは互いに補完し合うものであり、競合するものではありません。実行履歴は実行された内容を示し、手動によるキュレーションはビジネス上の意味を付加し、静的SQL分析は列レベルのロジックマップを提供します。データウェアハウスの変換ロジックのほとんどはSQLであるため、静的分析が最も重要な役割を果たし、その品質はパーサーの品質に直結します。 Gudu SQLFlow takes this approach with 39 dialect-specific parsers (Snowflake, BigQuery, Oracle, SQL Server, Teradata, and 34 more), built on a SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. That depth is what lets it handle the SQL that breaks simpler parsers: Oracle PL/SQL and T-SQL stored procedures, dynamic SQL assembled at runtime, temp tables, and view stacks.

データリネージは何のために使用されるのですか？

実務における系統情報の採用のほぼすべては、以下の4つのユースケースによって説明できます。

• 法令遵守。 BCBS 239では、銀行がリスク数値がソースデータからどのように集計されるかを説明することが求められています。GDPRのデータマッピング義務では、個人データがどのシステムや派生テーブルに流れ込むかを把握する必要があります。列レベルの来歴情報は、これら両方の要件を満たす成果物です。「これらの変換を通じて、これらの正確なソースフィールド」が求められます。
• データガバナンス。 カタログや用語集は、手動で履歴を管理すると古くなってしまいます。自動的に抽出された履歴は、コードの変更に合わせて依存関係マップを最新の状態に保ち、カタログプラットフォームに直接データを供給できます。たとえば、SQLFlowには、DataHub、Microsoft Purview、OpenMetadata用のエクスポートアダプタが付属しています。
• デバッグと根本原因分析。 ダッシュボードに誤った数値が表示された場合、Lineageは「このテーブルに言及しているすべてのスクリプトを検索する」という作業を「この列から逆方向にたどる」という作業に変換します。数日ではなく、数時間で済みます。
• 移住と近代化。 OracleやTeradataからSnowflake、BigQuery、またはDatabricksに移行する前に、依存関係グラフを確認することで、どのデータをどの順序で一緒に移行する必要があるか、また、どのオブジェクトがもはや読み取られず、移行せずに削除できるかがわかります。

役立つ経験則として、もしあなたのチームが、スキーマの変更によって何が壊れるか誰も確信が持てなかったために変更を遅らせたことがあるなら、あなたは既にデータリネージを必要としているのです。ただ、それを手動で、ゆっくりと、そしてエラーを伴いながら計算しているだけです。

よくある質問

データリネージとは、簡単に言うとどういうものですか？

これは、データの出所と行き先を示す地図です。どのデータソースが各テーブルやレポートにデータを提供し、その間にどのような変換が行われるかを示します。データの依存関係グラフと考えてください。これは、過去（出所）と未来（影響分析）の両方をたどることができます。

データリネージとデータプロベナンスの違いは何ですか？

プロベナンスは、ある出力からその起源までを遡って辿る経路です。リネージは依存関係グラフ全体を指し、一方向のプロベナンスと、もう一方向の影響分析をサポートします。日常的な用法ではこれらの用語は重複して使われますが、グラフとトラバーサルの違いが重要な点です。

間接的なデータ系統とは何ですか？

間接的な系統は、結果には現れないが結果に影響を与える列、つまり、 どこ フィルター、 参加する 条件、そして グループ分け 句。これらはすべての出力値を変更するため、これらを無視した影響分析は不完全です。SQLFlow は間接的な系統を、切り替え可能な別の関係タイプとしてモデル化しますが、ほとんどの系統ツールはこの区別をしません。

GDPRまたはBCBS 239への準拠には、データリネージが必要ですか？

どちらのフレームワークも「データリネージ」を必須技術として明記しているわけではありませんが、どちらもデータリネージが提供する機能を必要としています。BCBS 239では、銀行に対し、リスクデータがどのようにソースから集約されているかを示すよう求めており、GDPRのデータマッピングでは、個人データの流れを把握することが求められています。列レベルのデータリネージは、こうした証拠を大規模に生成するための標準的な方法です。

データリネージを自動的に作成するにはどうすればよいですか？

SQLを静的解析リネージツールに渡しましょう。SQLFlowを使えば、SQLの貼り付け、ファイルのアップロード、JDBC経由でのデータベース接続、dbtマニフェストのインポート、Snowflakeクエリ履歴やRedshiftクエリログの取り込みなどが可能です。コードを解析し、対話型の列レベル図、JSON/CSVエクスポート、REST APIを生成します。エンタープライズ環境では、100以上のデータベースと100万以上の列からなる環境をバッチスキャンできます。

系譜を作成するには、私の実際のデータへのアクセスが必要ですか？

静的解析ではそうはいきません。SQLの解析にはコードと、必要に応じてスキーマメタデータ（テーブルと列の定義）が必要ですが、テーブルの行は必要ありません。SQLFlowのオンプレミス版では、SQLテキスト自体がネットワーク内に保持されるため、銀行などの規制環境にも適しています。