DuckDBデータリネージ：プロセス内分析のための列レベルのリネージ

DuckDBのデータ系統 これは、DuckDB SQL を介してデータがどのように移動するかを示す列レベルのマップです。どの Parquet ファイルとソース テーブルが各派生テーブルにデータを供給し、どの結合、キャスト、フィルタ、集計を経由するかを示します。 Gudu SQLFlow このツールは、専用のDuckDB方言パーサーを使用してDuckDBスクリプトを解析し、クエリを実行したりデータにアクセスしたりすることなく、インタラクティブな系統図を自動的に作成します。

DuckDBパイプラインに真の系譜が必要な理由

DuckDBは静かに本格的なデータインフラストラクチャへと成長しました。 dbt-duckdb プロジェクト、ローカル分析（後にデータウェアハウスへ移行）の基盤、アプリケーションやノートブックへの組み込み、そしてParquetデータレイクにおける計算エンジンとしての役割など、様々な場面で活用されています。これらのパイプラインで使用されるSQLは、データウェアハウスのSQLと同様の意思決定を行います。つまり、収益の計算、顧客のフィルタリング、ダッシュボードが読み取るテーブルの構築などです。

しかし、DuckDB プロジェクトは通常、データウェアハウスのような厳密なデータリネージ管理を受けません。これには構造的な理由があります。ほとんどのリネージツールはデータベースサーバーを前提としています。ランタイムログベースのリネージは中央エンジンからクエリログを収集し、カタログファーストのプラットフォームはサーバーのメタデータをクロールします。DuckDB はプロセス内にあります。多くの場合、サーバーも共有クエリ履歴もインストールするカタログエージェントもありません。変換ロジックは、 .sql ファイル、dbtモデル、およびスクリプトがリポジトリにチェックインされます。

そのため、静的SQL解析はDuckDBのデータリネージを構築する自然な方法であり、多くの場合唯一の方法となります。SQLFlowはSQLテキスト自体を解析するため、そのSQLがラップトップ、CIジョブ、またはアプリケーションプロセス内で実行される場合でも同様に機能します。

SQLFlowがDuckDBのデータリネージを構築する方法

SQLFlowは、 汎用SQLパーサー（GSP）は、2000年代半ばから開発され、方言ごとに約13,600のSQLテストフィクスチャで検証された商用SQLコンパイラのフロントエンドです。DuckDBは、 方言固有のパーサーを備えた39のデータベース — DuckDBの構文を後付けした汎用ANSI文法ではありません。パイプラインは次のとおりです。

1. 摂取する。 DuckDB SQL を貼り付けるか、スクリプト ファイルをアップロードするか、dbt マニフェストをインポートします。 dbt-duckdb プロジェクト。
2. 解析して解決する。 GSP は各ステートメントの完全な意味モデルを構築し、CTE、サブクエリ、ビュー、および 選択 * 拡大。
3. データフローを抽出します。 データフローアナライザーは、各出力列について、どのソース列がどの関数、型変換、結合、および集合演算子を経由してその列にデータを供給しているかを正確に記録します。
4. 視覚化してエクスポートします。 インタラクティブな図をドリルダウンして、任意の列を上流または下流にトレースし、グラフをJSON、CSV、またはPNG形式でエクスポートするか、REST API経由で取得できます。

例：read_parquet()とCTASによる系統追跡

DuckDBの代表的なパターンは テーブルをSELECTとして作成します ファイルを直接読み込む - ステージング負荷なし、Parquet ファイル は ソース。典型的なレポート作成手順：

CREATE TABLE reporting.daily_revenue AS SELECT CAST(o.order_ts AS DATE) AS order_date, c.region AS region, SUM(o.amount) AS revenue, COUNT(DISTINCT o.customer_id) AS buyers FROM read_parquet('lake/orders/*.parquet') AS o JOIN dim_customers AS c ON o.customer_id = c.customer_id WHERE o.status = 'completed' GROUP BY 1, 2;

SQLFlow の DuckDB パーサーは、 read_parquet() テーブルソースとして扱われるため、Parquetパスは未解決の関数呼び出しではなく、系統グラフ内の実際のノードとして表示されます。この1つのステートメントから、次の情報が抽出されます。

• 日次収益.収益 供給源は o.金額 パルケットの供給源から、 和（）.
• daily_revenue.order_date 供給源は o.order_tsを通じて キャスト に 日付.
• 日次収益地域 直接 dim_customers.region.
• o.ステータス, o.顧客ID、 と c.顧客ID これらは出力には直接反映されませんが、出力に影響を与えるため、SQLFlowはこれらを間接的な系統として記録します（詳細は後述）。

dbt プロジェクトやナイトリー スクリプトでこれらのステートメントを 50 個連鎖させると、グラフが複雑になります。SQLFlow はすべての中間テーブルを結合するため、ダッシュボードの番号を元の Parquet 列に正確に遡って追跡できます。

直接的な血統と間接的な血統

上記の例では、 o.ステータス 決して登場しない 日次収益しかし、 状態 データが入力されると、すべての収益数値が静かに変更されます。SQLFlow はこれを次のようにモデル化します。 間接的（影響）系統: 列は どこ, 参加する、 と グループ分け 句と内部集約は、直接データフローとは別に、個別に切り替え可能な独自の関係タイプを形成します。競合するツールのほとんどはこの区別をしていないため、影響分析で、サイレントデータバグの原因となる依存関係を見落としてしまうことになります。

DuckDBパイプラインの場合、これは二重に重要です。ファイルベースのソースには、警告となる外部キーや制約がないため、これらの依存関係が記録されるのはSQL自体だけになります。

dbt-duckdbプロジェクトの系譜

dbt-duckdb これは、DuckDB が本番環境で実行される最も一般的な方法の 1 つですが、dbt 独自の DAG はモデル レベルで停止します。 日次収益 に依存する stg_orders依存関係を持つ列ではなく、SQLFlow は dbt マニフェストをインポートして生成します。 列レベル コンパイルされたモデル全体にわたる系統を把握できるため、「どのマートが stg_orders.amount 変更する前に、実際に餌を与えているかどうかを確認してください。

同じ分析は移行時にも役立ちます。チームは頻繁に DuckDB でプロトタイプを作成し、その後モデルを クリックハウス, PostgreSQLまたはクラウドウェアハウス。SQLFlowはこれらすべてを方言固有の文法で解析するため、移動前に真の依存関係グラフをマッピングし、移動後に孤立したデータが残っていないことを、両側で1つのツールと1つのリネージモデルを使用して検証できます。

DuckDBの系統情報を取得するには、どのようなオプションがありますか？

アプローチ	得意なこと	DuckDBのギャップ
マニュアルドキュメント	意図とビジネスコンテキストの把握	書かれた翌日には陳腐化している。コラムの詳細がない。
オープンソースのパーサー（SQL Lineage, sqlglot)	Pythonワークフローで個々のクエリを解析する; 無料	解像度、星の拡張、クロスステートメントのステッチング、視覚化は自分で組み立てます。間接的な系譜はあなた次第です。
ランタイムログに基づく系統	サーバー上で実際に何が実行されたかを観察する	中央エンジンがログを出力することを前提としています。ラップトップ上またはアプリ内のプロセス内DuckDBには収集する対象がありません。
カタログ優先のプラットフォーム	ガバナンスワークフロー、所有権、スタック全体にわたる用語集	系統の深さは、方言ごとのSQL解析に依存します。埋め込まれたDuckDBスクリプトは、一流の情報源となることは稀です。
Gudu SQLFlow	SQLテキスト自体の静的な列レベル分析、方言対応、直接および間接的な系統情報	チーム規模での利用は商用プラン（個人クエリは無料プラン）

これらは相互に排他的ではありません。既にカタログを実行している場合、SQLFlow のエンタープライズ展開はリネージをエクスポートします。 DataHub、Microsoft Purview、およびOpenMetadataつまり、それはあなたが保管するカタログの背後にある解析エンジンとなるのです。

展開とプライバシー

SQLFlow は SQL コードの静的解析のみを実行し、テーブルや Parquet ファイルの行を読み取ることはありません。DuckDB スクリプトに独自のロジックをエンコードしているチームの場合、 SQLFlow オンプレミス SQLFlow Cloudは、ネットワーク内でDockerまたはKubernetesとして動作するため（エアギャップインストールもサポート）、SQLテキストさえもインフラストラクチャから外部に出ることはありません。無料プランは、プレミアムプランが月額$49.99から、オンプレミスプランは月額$500または選択したデータベースタイプごとに1回限りの$4,800で、2台のサーバーにインストール可能です。どちらもヘッドレスCLIとREST APIを介してスクリプト化できるため、自動化を重視し、CI環境で実行するDuckDBの文化に合致しています。

その一方で、同じエンジンは、増分スキャンと永続的なリネージリポジトリを使用して、100以上のデータベースと100万以上の列からなる大規模なデータベース群をバッチスキャンします。これにより、スタック内のDuckDB部分とデータウェアハウスを1つのリネージグラフにまとめることができます。

よくある質問

SQLFlowはread_parquet()とファイルソースを通してデータの流れを追跡できますか？

はい。DuckDB 方言パーサーは、 read_parquet() テーブルソースとして扱われるため、ファイルパスは系統グラフのソースノードとして表示され、Parquetから読み取られた列は他の列と同様に下流のテーブルにトレースされます。

系統情報を取得するには、DuckDBクエリを実行する必要がありますか？

いいえ。SQLFlowは静的解析ツールです。SQLテキストを解析するだけで、実行はしません。そのため、サーバー側のクエリログを収集する必要のない、プロセス内DuckDBに適しています。

SQLFlowはdbt-duckdbプロジェクトをサポートしていますか？

はい。dbtマニフェストをインポートすると、SQLFlowはモデル全体にわたる列レベルの系統図を生成します。これは、dbt独自のモデルレベルのDAGよりもきめ細かいものです。

DuckDBは、本格的な方言パーサーをサポートしているのか、それとも汎用的なANSI SQLをサポートしているのか？

本格的な方言パーサー。SQLFlowは、DuckDBを含む39種類のデータベースに対応した方言固有のパーサーを同梱しており、約13,600個の方言ごとのSQLテストフィクスチャで検証されたパーサーエンジンに基づいて構築されています。

DuckDBスクリプトからの系統情報をデータカタログに反映させることはできますか？

はい。エンタープライズ向け展開では、DataHub、Microsoft Purview、OpenMetadata用のエクスポートアダプタに加え、JSONおよびCSVエクスポート機能、カスタム統合用のREST APIが提供されます。

DuckDBの系統情報を取得するためにSQLFlowを利用する場合、費用はいくらですか？

SQLFlow Cloudには無料プランがあり、プレミアムプランは月額$49.99です。オンプレミスプランは月額$500、または選択したデータベースタイプごとに1回限りの$4,800です。詳細は以下をご覧ください。 価格設定 詳細は