Spark SQLデータリネージ：Sparkパイプラインの列リネージ

Spark SQLデータリネージ これは、データが Spark SQL コード内をどのように移動するかを示す列レベルのマップです。どのソース列が、によって書き込まれるすべてのテーブルにデータを供給しているかを示します。 テーブルを作成します...AS SELECT また 挿入上書きそして、その過程で一時的なビュー、結合、関数、フィルターが実行されます。 Gudu SQLFlow 専用のSpark方言パーサーを使用してSpark SQLを静的に解析することで、そのマップを作成します。クラスターの計測、リスナーのアタッチ、ジョブの実行は不要です。SQLを貼り付けるだけで、系統図を取得できます。

ランタイムリスナーと静的解析：Sparkの履歴を取得する2つの方法

Sparkの世界における系譜管理には根本的に異なる2つのアプローチがあり、ほとんどのチームは最終的に両方を必要とします。

ランタイムの系譜 OpenLineageとそのSpark統合が採用しているアプローチは、Sparkセッションにリスナーをアタッチし、ジョブの実行ごとにリネージイベントを発行します。これは非常に優れた機能で、静的解析では把握できない実行レベルのメタデータとともに、実際に何が、いつ、どのデータセットに対して実行されたかを記録します。「昨晩のパイプラインは実際に何に影響を与えたのか？」という疑問に、ランタイムリネージが答えてくれます。

静的系統 SQLFlowのアプローチは、コンパイラが行うように、SQLテキスト自体を解析し、コードから系統情報を導き出します。これにより、ランタイムキャプチャでは構造的に処理できないすべてのことが網羅されます。

• まだ実行していないSQL。 プルリクエストに含まれる新しいパイプライン、別のチームから引き継いだスクリプト、四半期ごとにスケジュールされたジョブのバックログなど、これらは実行されるまで（場合によっては本番データに対して）ランタイムイベントを発行しません。
• コードレビュー。 レビュー担当者は、変更を承認する前に、変更の列レベルの依存関係グラフ全体を確認できるため、デプロイ後にその影響を発見する必要がなくなります。
• 移行監査。 ワークロードを Spark に移行する場合 (通常は Hive から)、依存関係グラフが必要になります。 全体 月末にのみ実行されるジョブを含むコードベース。静的解析では、すべてを一度に読み込むことができます。

	ランタイムリスナー (OpenLineage)	静的解析（SQLFlow）
血統が捉えられた	ジョブ実行ごとに、実行される	SQLテキストから、何かが実行される前に
必要	Sparkセッションでリスナーが設定されています。ジョブは実行される必要があります。	SQLファイルと、オプションのスキーマメタデータ
未実行のコードをカバーします	いいえ、ランニングもイベントもありません。	はい、PR、バックログ、めったに実行されないジョブ
実行メタデータ（タイミング、バージョン）	はい	いいえ — コードレベルのみ
典型的な使用例	稼働中のパイプラインの運用上の可観測性	影響分析、コードレビュー、移行監査、コンプライアンス文書作成

これらは互いに補完し合うものであり、競合するものではありません。ランタイムリネージは発生した事象を示し、静的リネージはコードの動作を示します。SQLFlow の DataHub、Microsoft Purview、および OpenMetadata 用のエクスポートアダプタを使用すると、静的に生成されたリネージをランタイムイベントと同じカタログに格納できるため、2 つのビューを並べて表示できます。

例：CTASへの一時ビューチェーン

Spark SQL で単純なリネージツールを無効化するパターンは、一時ビューチェーンです。ノートブックとジョブは、定期的にロジックをステージングします。 一時ビューの作成または置換 最終段階までのステップ テーブルを作成します...AS SELECT以下に、簡潔ながらも現実的な例を示します。

CREATE OR REPLACE TEMP VIEW clean_events AS SELECT CAST(event_time AS TIMESTAMP) AS event_ts, user_id, lower(event_name) AS event_name, amount FROM raw.events WHERE event_date >= date_sub(current_date(), 30); CREATE OR REPLACE TEMP VIEW user_daily AS SELECT user_id, to_date(event_ts) AS event_day, SUM(amount) AS daily_spend FROM clean_events WHERE event_name = 'purchase' GROUP BY user_id, to_date(event_ts); CREATE TABLE analytics.user_spend_30d USING PARQUET AS SELECT u.user_id, u.segment, d.event_day, d.daily_spend FROM user_daily d JOIN dim.users u ON u.user_id = d.user_id;

「どこで アナリティクス.user_spend_30d.daily_spend 「どこから来たのか？」という疑問に対する正直な答えは、2つのビューレイヤーを解決する必要がある。 毎日の支出 は SUM(clean_events.amount)、 と clean_events.amount は 生のイベント数SQLFlow はまさにその解決を実行し、完全なチェーンをレンダリングします。 生のイベント数 を通して クリーンイベント と ユーザーデイリー 最終テーブルに進出し、 和 集約は、それが起こるエッジに付随する。

また、ほとんどのツールが完全に無視している情報も捉えています。 間接的な系統列 イベント日付, イベント名、そして結合キー ユーザーID 決して登場しない 毎日の支出しかし、3つすべてがその価値を左右する。30日間フィルターを変更するか、 '購入' 述語と出力のすべての数値が変更されます。SQLFlow はこれらを個別の切り替え可能な関係タイプとしてモデル化するため、純粋なデータフローを表示することも、影響範囲全体を表示することもできます。スキーマ変更のレビューでは、影響範囲を表示するビューが実際に必要なビューです。

Spark SQL は SQLFlow を解決します

SQLFlowには、Spark SQL方言パーサーが同梱されています。これは、汎用的なANSI文法にSparkキーワードを追加したものではなく、39種類ある方言固有のパーサーの1つです。特にSpark SQLでは、以下の履歴を持つステートメントを処理します。

• テーブルを作成します...AS SELECT （CTAS） — Spark バッチ パイプラインの主力機能。すべての出力列は、完全な SELECT を通じてそのソースまで追跡されます。
• 挿入先 と 挿入上書き — SELECTリストと対象テーブルのスキーマ間の位置的な列マッピングを含みます。
• 一時ビューの作成または置換 ― 一時ビューは解決され、連鎖されるため、リネージはステージングレイヤーで停止するのではなく、ステージングレイヤーを通過します。
• CTE、サブクエリ、 選択 * 列参照は共通テーブル式とネストされたサブクエリによって解決され、スキーマメタデータが利用可能な場合はスター式が実際の列に展開されます。
• 関数、型変換、および集合演算子 — 各出力列の系統は、それが通過した変換を記録します。 毎日の支出 「金額から」だけではなく「 額 経由 和“.

Under the hood this is the General SQL Parser engine — a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. Lineage quality is a parsing problem before it is anything else, and that corpus is what keeps edge-case Spark syntax from silently producing wrong edges.

Spark SQLデータリネージがスタック内でどのように位置づけられるか

Sparkは単独で動作することはほとんどありません。そのテーブルは通常Hiveメタストアに格納され、Sparkワークロードの大部分はDatabricks上で実行されるようになっています。SQLFlowはこれらを、それぞれ独立して解析される第一級の方言として扱います。

• HiveジョブをSparkに移行しますか？レガシーHQLを分析します Hiveデータリネージパーサー そして、Sparkパーサーを使用して書き換えられたジョブを作成し、2つの依存関係グラフを比較して、変換時に何も失われていないことを確認します。
• Databricks上で実行中ですか？ Databricks データリネージ パーサー 本書は、オープンソースのSpark SQLとは乖離しており、単一の共通文法では適切に処理できないDatabricks SQL方言を対象としています。
• 混合環境？ SQLFlow はサポートされている 39 の方言すべてを 1 つの系統リポジトリに分析するため、Snowflake タスクによって生成されたテーブルを読み取る Spark ジョブは、1 つの連続したグラフとして表示されます。 SQLデータリネージツールの概要 全体像を把握するには。

入力方法は柔軟で、SQLの貼り付け、ファイルのアップロード、JDBC経由でのメタデータの取得、またはdbt-on-Sparkプロジェクト用のdbtマニフェストのインポートが可能です。出力は、インタラクティブなドリルダウン可能な図、JSON、CSV、PNG形式のエクスポート、および自動化のためのREST APIです。例えば、プルリクエストで変更されたSQLをCIステップとして分析するといったことが可能です。

展開と拡張

SQLFlow Cloudにはインタラクティブに使用できる無料プランがあり、プレミアムプランは月額$49.99です。SQLがネットワーク外に出られないチームは、 SQLFlow オンプレミス — DockerまたはKubernetesに対応、エアギャップ環境にも対応、選択したデータベースタイプごとに月額$500または1回限りの$4,800。いずれの場合も、SQLFlowはSQLコードの静的解析のみを実行し、テーブルの行を読み取ることはありません。エンタープライズ展開では、増分スキャンと永続的なリネージリポジトリを使用して、100以上のデータベースと100万以上の列からなる環境をバッチスキャンします。

よくある質問

系統情報を取得するには、稼働中のSparkクラスターが必要ですか？

いいえ。SQLFlowはSpark SQLテキストを静的に解析します。プルリクエスト、ベンダーからの納品物、移行バックログなど、これまで一度も実行されたことのないスクリプトを解析しても、本番コードから得られるのと同じ列レベルのデータ系列を取得できます。

これはOpenLineageのSpark統合とどう違うのですか？

OpenLineageは、Sparkセッション上のリスナーを介して実行時にリネージをキャプチャします。これは、実行中のジョブが実際に何をしたかを監視するのに最適です。SQLFlowはSQLコード自体からリネージを生成するため、実行されていないコードも対象とし、マージ前のレビューや移行監査をサポートし、クラスタへのアクセスも不要です。この2つは相互補完的な関係にあり、SQLFlowは実行時のリネージと並行して、DataHub、Purview、またはOpenMetadataにエクスポートできます。

SQLFlowは一時ビューを通してデータ系列を追跡できますか？

はい。 一時ビューの作成または置換 ステートメントはエンドツーエンドで解決されるため、最終的なCTASの列は、各ステップで関数と集計が適用された状態で、すべてのステージングビューをたどって物理的なソーステーブルまでトレースされます。

Databricks SQLは、ここでいうSpark SQLと同じものですか？

いいえ。SQLFlowは、それぞれ異なる方言パーサーを使用して解析します。Databricks SQLには独自の構文拡張があるため、独自の文法を持ちます。Databricks上で実行する場合はDatabricks方言を、オープンソースのSpark、EMR、または自己管理型クラスターの場合はSpark SQL方言を使用してください。

SQLFlowは私のデータを読み取りますか？

いいえ。SQLコードと、必要に応じてスキーマメタデータ（テーブルと列の定義）を分析します。行データには一切アクセスしません。オンプレミス版では、SQLテキストもネットワーク内に留まります。

Spark SQLの系統追跡とSQLFlowの費用はいくらですか？

SQLFlow Cloudは無料からスタート。プレミアムプランは月額$49.99。オンプレミス版は月額$500、または選択したデータベースタイプごとに1回限りの$4,800で、2台のサーバーにインストール可能。詳細は以下を参照。 価格設定 詳細は