BigQueryデータリネージ：Google BigQuery SQLの列レベルのリネージ

BigQueryのデータリネージ これは、BigQuery プロジェクト内でデータがどのように移動するかを示すマップです。どのソース テーブルと列が各派生テーブル、ビュー、スケジュール済みクエリにデータを提供し、どの式が途中でデータを変換するかを示します。Google の Dataplex は、テーブル レベルで BigQuery ジョブのリネージを自動的にキャプチャします。 列 どの関数や結合を通して、SQL自体を解析する必要があるかを判断する必要があります。 Gudu SQLFlow ネストされた を解決する専用の BigQuery 方言パーサーでまさにそれを実現します。 構造 分野、 UNNEST星の膨張、そして列単位の粒度まで掘り下げたビューチェーン。

BigQueryの系統追跡が見た目より難しい理由

BigQueryのSQLは、一般的なANSI SQLではありません。特に、以下の3つの機能は、汎用的な文法に依存するデータ系統追跡ツールにとって大きな障害となります。

• 入れ子構造と繰り返し構造を持つ列。 単一の BigQuery 列は 構造 他のフィールドを含む、または 配列 構造体の。真の系統は内部まで遡る必要があります。 注文顧客メール は、 注文顧客の国両者とも物理的には同じ列に存在しているにもかかわらず。
• UNNEST. 繰り返しフィールドをフラット化すると、1 つの行が複数になり、クエリの途中で派生関係が導入されます。モデル化しないパーサー UNNEST フラット化されたエイリアスと、それが由来する配列フィールドとの間の関連性が失われます。
• 星の膨張。 選択 * 複数のビューを経由するということは、出力列がクエリテキストのどこにも記述されていないことを意味します。そのため、それらを解決するには、目の前の単一のステートメントだけでなく、テーブルとビューの定義が必要になります。

SQLFlowにはBigQuery専用のパーサーが付属しています（ 39の言語固有の構文解析器 製品には、3つすべてを処理する単一の汎用文法はありません。CTE、サブクエリ、ビュー、スター展開を通じてすべての列参照を解決し、ネストされた 構造 フィールドを第一級の系統ノードとして扱う。

Dataplexはテーブルレベルのジョブ履歴を提供します。では、その次は？

Dataplex (Google Cloud のデータガバナンス レイヤー) は、その機能において非常に優れています。実行中の BigQuery ジョブを監視し、各ジョブが読み書きしたテーブルを記録します。スケジュールされたクエリがデータを格納することを知りたい場合は、 dw.日次収益 から 生の注文Dataplexが既に教えてくれています。

実行時ジョブの監視では、これらのテーブル間の変換ロジック、つまりどのソース列がどの出力列に、どの式、フィルタ、結合を介して供給されるかといった情報は把握できません。この情報はSQLテキストにのみ存在するため、抽出するにはSQL解析が必要です。この2つのアプローチは、それぞれ異なる疑問に答えるものです。

質問	Dataplexジョブの履歴	SQLFlow解析済みリネージ
このジョブはどのテーブルに影響しますか？	はい、ジョブ実行ごとに自動的に行われます。	はい、SQLから
どの列がフィードするか 日次収益合計?	いいえ — テーブルの粒度	はい、出力列ごと
各出力列を計算する式は何ですか？	いいえ	はい：関数、キャスト、集約
どの列がフィルタリングまたは結合（間接的な系統）のみに使用されますか？	いいえ	はい、別個の切り替え可能なレイヤーとして
まだ実行されていないSQLのリネージ（コードレビュー、移行）	いいえ、実行された仕事が必要です	はい、SQLテキストの静的解析です。

チームは通常、両方を使用します。常時稼働のジョブインベントリにはDataplexを使用し、列精度で「この列を変更すると何が壊れるのか」や「この数値は正確にはどこから来ているのか」といった疑問に答える必要がある場合はSQL解析を使用します。

実例：CREATE TABLE AS SELECT with UNNEST

BigQueryの典型的なパターンは次のとおりです。注文テーブルから繰り返し出現するフラットな収益テーブルを作成します。 行項目 構造体。

CREATE TABLE dw.order_line_revenue AS SELECT o.order_id, o.customer.email AS customer_email, li.product_id, li.qty * li.unit_price AS line_revenue FROM raw.orders AS o, UNNEST(o.line_items) AS li WHERE o.status = 'COMPLETE';

これをSQLFlowに渡すと、生成される列レベルの系統図は次のようになります。

• 注文明細の収益。顧客メールアドレス ネストされたフィールドから取得されます raw.orders.customer.email — 構造体全体ではなく、構造体メンバーのみ お客様 カラム。
• order_line_revenue.line_revenue から来る raw.orders.line_items.qty と raw.orders.line_items.unit_priceを通じて UNNEST エイリアス li そして乗算が行われます。どちらのソースフィールドも繰り返し構造の中に存在し、SQLFlow はフラット化の過程を追跡します。
• 生の注文ステータス 次のように表示されます 間接的な系統: 出力には現れませんが、 どこ フィルターとは、結果の各行を整形することを意味します。SQLFlow は、直接的なデータフローと間接的な影響 (WHERE、JOIN、GROUP BY 列) を、図で個別に切り替えることができる別々の関係タイプとしてモデル化します。これは、ほとんどのデータリネージツールでは区別されていない点です。

間接的な系譜は、一見したよりも重要です。誰かが列挙値を変更すると、 状態純粋に直系の血統ツールによると ライン収益 影響を受けない。いや、そうではない。下流のすべての収益数値が変化する。間接的な影響経路を考慮しない影響分析は、盲点のある影響分析である。

スケジュールされたクエリとビューチェーンのトレース

ほとんどのBigQuery環境では、興味深いデータの流れは単一のステートメントではなく、連鎖です。つまり、生のテーブル、ビューのレイヤー、レポートテーブルを生成するスケジュール済みクエリ、そしてさらにその上にビューが重ねられる、といった流れです。個々のリンクは簡単に読み取れますが、ソース列からダッシュボードフィールドまでのエンドツーエンドのパスはそうではありません。

SQLFlow はセット全体をまとめて分析します。ビュー DDL とスケジュールされたクエリ SQL (貼り付け、ファイルアップロード、JDBC 経由のライブメタデータ、dbt マニフェスト、または Grabit メタデータ抽出) を与えると、ビューの参照が解決され、チェーンが構築されます。 選択 * 各レイヤーで実際のスキーマに基づいて展開され、生成された図では、任意の出力列をクリックして、すべての中間ビューを遡って、生テーブルのソース列までたどることができます。エクスポートはJSON、CSV、PNG形式、またはREST APIを介したプログラムによる実行が可能で、エンタープライズ展開ではデータリネージをDataHub、Microsoft Purview、またはOpenMetadataにプッシュします。

強制されていない制約からのER図

BigQuery は主キーと外部キーのみをサポートしています。 施行されていません 制約：オプティマイザとドキュメント作成のためにDDLで宣言されますが、書き込み時にはチェックされません。強制されないため、多くのチームはこれらを役に立たないメタデータだと考えがちです。しかし、そうではありません。これらはまさにER図に必要な関係宣言なのです。

SQLFlowのER推論はBigQueryを理解します 施行されていません PK/FK イディオム: DDL をこれに通すと、次のような制約からエンティティ関係図が描画されます。 プライマリキー (order_id) の追加は強制されません そしてマッチング 外部キー...参照...適用されません 宣言。その結果、既にお持ちの DDL から直接生成された、倉庫の ER モデルが得られます。このモデルは、おそらく他の場所には関係ドキュメントが存在しないスキーマに対応しています。

どのチームがBigQueryデータリネージを何に利用しているか

• スキーマ変更前の影響分析： 列が実際にフィードするすべてのスケジュール済みクエリ、ビュー、レポートを検索します。 UNNEST そして、構造体へのアクセスは、名前を変更したり型を変更したりする前に行います。
• 誤った数値のデバッグ： ダッシュボードの指標からビューチェーンを遡って、その指標を生成した正確なソースフィールドと式を特定します。
• 移行計画： BigQuery へのデータ移行や BigQuery からのデータ移行を行う際、依存関係グラフによって、データの移行順序や安全に残せるデータがわかります。SQLFlow は、同じ列レベルのグラフを構築します。 スノーフレーク と Amazon Redshiftそのため、1つのツールで倉庫間のデータ移行を両側でマッピングできます。
• コンプライアンスと監査： どのソースフィールドが、監査人が要求する列粒度で規制対象の出力に流れ込むかを証明する。これは、手動で維持するのではなく、SQLから生成される。

プライバシー、導入、価格設定

SQLFlow は、SQL コードとスキーマ メタデータのみの静的解析を実行します。BigQuery テーブルの行を読み取ることはなく、データアクセス権限を持つサービス アカウントも必要ありません。SQL テキストと DDL だけで十分です。SQLFlow Cloud には無料ティアがあります (プレミアムは $49.99/月)。規制環境の場合、 SQLFlow オンプレミス 必要に応じてエアギャップされた独自のネットワーク内でDockerまたはKubernetes上で実行され、選択したデータベースタイプごとに月額$500または1回限りの$4,800です。詳細は以下をご覧ください。 価格ページエンタープライズ展開では、増分スキャンと永続的なデータリネージリポジトリを使用して、100以上のデータベースと100万以上の列からなる環境をバッチスキャンします。

よくある質問

Dataplexは既にBigQueryの系統情報を提供してくれるのではないですか？

はい、テーブルレベルでは可能です。Dataplexは、各BigQueryジョブがどのテーブルを読み書きするかを自動的に記録するため、ジョブのインベントリをしっかりと把握できます。ただし、SQL内の変換ロジック（どの列がどの式を介してどの列に渡されるかなど）は抽出されません。そのためには、SQLを解析するツールが必要であり、SQLFlowはまさにそれを提供します。

SQLFlowはSTRUCT型およびARRAY型の列を通して系統を追跡できますか？

はい。BigQueryパーサーはネストされた構造体フィールドを個々の系統ノードとしてモデル化するため、 顧客メール と 顧客の国 別々の系統を持ち、 UNNEST 繰り返し出現する列の平坦化。

SQLFlowはBigQueryビューにおけるSELECT *をどのように処理しますか？

スター式は実際のテーブルとビューの定義に対して展開されるため、すべての暗黙の列に明示的な系統が割り当てられます。これは、マルチレイヤービューチェーンを通じて機能し、その背後にある列は 選択 * 上流の複数のビューで定義されている可能性があります。

スケジュールされたクエリとビューをまとめて、系統情報をマッピングできますか？

はい。スケジュールされたクエリのSQLとビューのDDLを1つのジョブとして分析し、SQLFlowがエンドツーエンドのチェーンを結合するため、レポート列をマテリアライズクエリとすべての中間ビューを通して、元のソース列まで遡って追跡できます。

SQLFlowは私のBigQueryデータにアクセスする必要がありますか？

いいえ。これは静的解析です。SQLテキストとオプションのスキーマメタデータのみを扱います。テーブルの行データは一切読み取られません。オンプレミス環境では、SQLテキストもネットワーク内に留まります。

SQLFlowの料金はいくらですか？

SQLFlow Cloudは無料でご利用いただけます。プレミアムアカウントは月額$49.99です。SQLFlow On-Premiseは月額$500、または選択したデータベースタイプごとに1回限りの$4,800で、2台のサーバーにインストール可能です。