列レベルのデータリネージ：その概要と、テーブルレベルでは不十分な理由

列レベルのデータリネージ クエリ、ビュー、またはレポートのすべての出力列を、その出力列を生成する正確なソース列にマッピングし、その過程で適用されたすべての変換（関数、キャスト、結合、集計、フィルタ）もマッピングします。テーブルレベルのリネージが「テーブル」と言っている場合 注文 フィードテーブル 収益報告「列レベルの系統は「収益レポート合計 は SUM(orders.amount)フィルター済み 注文状況 そしてグループ化された 顧客地域「それは、影響分析、デバッグ、監査の回答が概算ではなく正確になる粒度です。」

このページでは、用語を定義し、CTE、結合、集計を含む実際のクエリで出力列の1つを順に説明し、この情報を抽出するにはパターンマッチングではなく意味論的SQL解析が必要な理由を説明します。リネージという概念が初めての方は、まず データリネージとは何か、そしてなぜそれが重要なのか列ごとの詳細情報については、こちらに戻ってきてください。

列レベルのデータリネージレコードは

ステートメントが書き込む、または返す各列について、列レベルの系統グラフには次の3つの情報が格納されます。

• ソース列: 出力に値が流れ込む物理列は、CTE、サブクエリ、ビュー、一時テーブルなどの任意の数の中間層を介して解決されます。
• 変化： パスに適用される操作、例： 和（）, キャスト（）, 場合 式、文字列関数、および集合演算子など 連合.
• 関係の種類: ソース列の値が実際に出力に反映されるか（直接的な系譜）、それともフィルター、結合、グループ化などによって結果が形作られるだけか（間接的な系譜）を区別します。ほとんどのツールはこの区別を無視しているため、この区別については後述します。

テーブルレベルの系統図だけでは不十分な理由

テーブルレベルのデータリネージは作成コストが低く、最初の方向把握には非常に役立ちます。どのテーブルとビューがどのテーブルとビューにデータを供給しているかを示すマップを作成できるからです。問題は、データチームが実際に回答を必要とする質問は列に関する質問であり、テーブルレベルの粒度では過大評価せざるを得ないということです。

質問	テーブルレベルの回答	列レベルの回答
名前を変更すると何が壊れますか 顧客メール?	読み取るすべてのオブジェクト 顧客 — しばしば数十件の誤検出が発生する	参照する見解、手順、および報告のみ メール 具体的には
ダッシュボードに表示されているこの間違った数字はどこから来ているのですか？	「これら4つのテーブルの上流のどこかに」	ダッシュボードフィールドから物理ソース列への正確な式チェーン
どの出力にPIIが含まれていますか？ ssn?	ソーステーブルの下流にあるすべてのテーブルは、 ssn 伝播する	正確な列のセット ssn 実際に価値が到達する
このステージング列を削除できますか？	不明 — テーブルが参照されているため、	はい、下流の列が直接的または間接的に読み取らない場合は

誤検出によるコストは、決して机上の空論ではありません。スキーマ変更によってテーブルレベルで40個のダウンストリームダッシュボードがフラグ付けされたとしても、実際に変更された列を使用するダッシュボードが3個だけであれば、残りの37個は不必要に再テストされるか、さらに悪いことに、チームがデータリネージツールを無視するようになる原因となります。データリネージの信頼性は精度によって決まり、その精度は列レベルでこそ発揮されるのです。

具体的な例：CTE、結合、集計を介した1つの列

ここに、小さくても現実的なクエリがあります。目標: 総収益 由来する。

WITH recent_orders AS ( SELECT o.order_id, o.customer_id, o.amount, o.status FROM orders o WHERE o.order_date >= DATE '2026-01-01' ) SELECT c.region, SUM(r.amount) AS total_revenue FROM recent_orders r JOIN customers c ON c.customer_id = r.customer_id WHERE r.status = 'COMPLETED' GROUP BY c.region;

解決する 総収益 3回跳ぶ：

1. 総収益 は次のように定義される。 SUM(r.amount)そのため、その値は列から取得されます 額 関係のエイリアス r集計関数を通して渡されます。
2. r これはテーブルではありません。これはCTEです。 最近の注文、 だれの 額 列はパススルーです 注文数物理ソースが判明する前に、エイリアス、CTE、および列射影のすべてを解決する必要があります。
3. したがって、完全な直系家系は単一の物理的な柱となる。 注文数 → 最近の注文数 → 和（） → 総収益.

しかし、結果には直接現れないものの、結果を左右する5つの列が存在する。 注文日 CTE 内の行をフィルタリングします。 注文状況 外側で再び濾過する どこ, 注文の顧客ID と 顧客.顧客ID どの行が結合するかを決定し、 顧客地域 行を集計バケットにグループ化する方法を決定します。これらのセマンティクスを変更して、 総収益 変更は、それらの値が出力に反映されなくても発生します。テキスト検索では、「このクエリは 注文 と 顧客「列レベルの系統は、どの列が値を保持し、どの 5 つの列がその値を制御しているかを示します。」

直接的な系統と間接的な系統：fdd/fddiの区別

これらの2種類の関係には、それぞれ別の名前がふさわしい。Gudu SQLFlowの系統モデルでは、 直接データフロー （ラベル付き） fdd) は、ソース列の値が、関数、キャスト、または集計によって変換される可能性があり、ターゲット列に流れ込むことを意味します。 間接データフロー （ラベル付き） fddi) は、ソース列が値を提供せずにターゲットに影響を与えることを意味します。 どこ 述語、 参加する 条件、 グループ分け 鍵、および同様の節。

SQLFlow では、これらをダイアグラム上で個別に切り替え可能なリレーションシップ タイプとしてモデル化します。間接的なリネージをオフにすると、純粋な値の由来が表示されます。これは、どのソース フィールドが規制対象レポートに反映されるかを証明する際に監査担当者が必要とするビューです。オンにすると、影響範囲全体が表示されます。これは、フィルタ カラムを削除すると、下流のすべての集計がサイレントに変更されるため、エンジニアがカラムを操作する前に必要とするビューです。競合するほとんどのリネージ ツールは、この区別を全く行いません。直接フローのみを報告して実際の影響を見逃すか、すべてをまとめて表示し、回避するためにカラム レベルに移動した誤検出を再び導入します。

なぜ正規表現ではなく意味解析が必要なのか

テーブル名や列名をSQLテキストでパターンマッチングしてデータ系列を抽出したくなる気持ちは理解できます。しかし、このアプローチは、実際のSQLでよく見られる構造にまさに引っかかってしまいます。

• 星の膨張。 選択 * 列名は一切指定されていません。どの列が通過するかは、分析時の基となるリレーションのスキーマ、および結合の場合は、結合されたすべてのリレーションの結合されたスキーマに依存します。解決 * メタデータとスコープルールが必要です。テキストパターンでは列リストを生成できません。
• 解像度を表示します。 クエリが読み取られるとき v_sales.net_amount真の系譜はビューの定義を通して辿られ、ビューは通常、他のビューの上に積み重ねられます。アナライザーは各定義を再帰的に展開し、列マッピングを結合する必要があります。これは文字列ではなく、解決済みの意味モデルに対する操作です。
• 範囲と曖昧さ。 資格のないコラム 状態 3つのテーブルを結合する場合、SQLのスコープ規則とテーブルのスキーマによって決定される、正確に1つのリレーションのみに属します。誤った推測をすると、リネージグラフが静かに破損します。
• 表現。 COALESCE(ax, by), 場合 ブランチとウィンドウ関数はそれぞれ、異なる一連の寄与列を定義します。これらを捉えることができるのは、真の式ツリーだけです。
• 方言。 オラクルの 接続方法T-SQLの 出力 条項、BigQueryの を除外する 星印リストによると、各方言には、汎用ANSI文法では正しく解析できない構文が存在します。SQLFlowは、最小公倍数的な単一の文法ではなく、39種類の方言固有のパーサーを同梱しています。

In short, accurate column-level lineage is a compiler problem. SQLFlow is built on the General SQL Parser, a full SQL compiler front-end (lexer, parser, semantic resolver, data-flow analyzer) developed commercially since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. The same engine resolves the hardest cases: stored procedure bodies in Oracle PL/SQL and SQL Server T-SQL, lineage through procedure parameters and temp tables, and dynamic SQL assembled inside procedures.

列レベルの系統を実際に取得する

Gudu SQLFlow は自動化された SQLデータリネージツール このページに記載されている列レベルのグラフを、貼り付けたクエリ、アップロードしたファイル、JDBC経由のライブデータベースメタデータ、dbtマニフェストファイル、Snowflakeクエリ履歴、Redshiftクエリログなど、あらゆるSQLデータから生成します。出力は、列ごとにドリルダウンできるインタラクティブな図、JSONまたはCSV形式の構造化されたデータ系列データ、PNGエクスポート、およびREST APIです。

エンタープライズ規模では、100以上のデータベースと100万以上の列からなる環境をバッチスキャンし、永続的なリネージリポジトリに対して増分スキャンを実行し、DataHub、Microsoft Purview、およびOpenMetadataにエクスポートするため、列レベルのリネージを既存のカタログ内に保持できます。分析は静的であるため、SQLFlowはSQLコードとスキーマメタデータのみを読み取り、テーブルの行を読み取ることはありません。また、オンプレミス版ではSQLテキストはすべてネットワーク内に保持されます。

上記のようなトレースをサブクエリ、ビュー、ストアドプロシージャ、dbt モデルにわたってさらに詳しく知りたい場合は、当社のライブラリを参照してください。 作業済みデータリネージの例.

よくある質問

テーブルレベルのデータリネージとカラムレベルのデータリネージの違いは何ですか？

テーブルレベルの系統記録では、どのテーブルとビューがどのテーブルとビューにデータを提供しているかが記録され、オブジェクトペアごとに1つのエッジが作成されます。列レベルの系統記録では、出力列ごとに、その列にデータを提供している正確なソース列と適用された変換が記録されます。列レベルの粒度によって、影響分析における誤検出が排除され、監査結果の精度が向上します。

間接的（影響）系譜とは何ですか？

間接的なデータフローは、ソース列を、その値自体には寄与しないものの、影響を与える出力にリンクします。これには、WHERE句、JOIN条件、GROUP BYキー、および集計述語内の列が含まれます。SQLFlowでは、これを独立した関係タイプ（fddi）としてモデル化し、図の中で直接データフロー（fdd）とは別に切り替えることができます。

正規表現やgrepを使って、列レベルのデータ系列を抽出できますか？

確実にはできません。スター展開、ビュー解決、修飾されていない列名、CASEやCOALESCEなどの式はすべて、SQLとスキーマメタデータの実際の解析から構築されたセマンティックモデルを必要とします。パターンマッチングではテーブル名は特定できますが、どの列がどこに流れるかを解決することはできません。

ビューやSELECT * を通じて、列レベルの系統情報は機能しますか？

はい、ツールがそれらを解決すれば可能です。SQLFlowは、スキーマメタデータに対してSELECT *を展開し、ビュー、CTE、サブクエリを通じて列参照を再帰的に解決するため、最終的な出力列から物理的なソース列まで、データの流れを追跡できます。

ストアドプロシージャと動的SQLの両方で動作しますか？

はい。SQLFlowには、Oracle PL/SQLとSQL Server T-SQL専用のプロシージャパーサーがあり、プロシージャパラメータと一時テーブルを介した履歴を追跡し、プロシージャ内で組み立てられた動的SQLを解決し、プロシージャ間の呼び出しのコールグラフを表示します。

自分のSQLの列レベルのデータ系列を取得するにはどうすればよいですか？

SQLFlow Cloudの無料プランにクエリを貼り付けると、列レベルの図がブラウザに表示されます。データベース全体の場合は、JDBC経由で接続するか、dbtマニフェストをインポートしてください。規制環境の場合は、SQLFlow On-Premiseが自社ネットワーク内のDockerまたはKubernetesで動作します。