TrinoとPrestoのデータリネージ：フェデレーションSQLにおける列リネージ

Trinoのデータ系統 Trino (および Presto) SQL を介してデータがどのように流れるかを示す列レベルのマップです。どのカタログのどのソース列が各出力列に供給され、どの結合、関数、フィルタを介して供給されるかを示します。 Trino はフェデレーションクエリエンジンであるため、単一のステートメントで次のものを読み取ることができます。 ハイブ, postgresql、 と 氷山 カタログを一度に処理するため、正確な系統はすべての列を完全修飾名に解決する必要があります カタログ.スキーマ.テーブル.列 テーブル名だけでなく、識別子も必要です。 Gudu SQLFlow TrinoとPrestoの両方に対応した専用の方言パーサーを使用することで、これを実現しています。

連邦制がトリノのデータ系統をより困難にする理由

従来のデータウェアハウスでは、データ系列は 1 つのデータベース内に存在します。クエリ内のすべてのテーブルは同じシステムに属し、 売上注文 曖昧さはありません。 Trino はその前提を覆します。その目的はデータを結合することです 横切って システム（S3 上の Hive テーブル、PostgreSQL 運用データベース、Iceberg の lakehouse テーブルなど）はすべて同じ場所に表示される可能性があります。 選択.

これは、ほとんどの系統追跡ツールがうまく処理できない3つの問題を引き起こします。

• カタログ間で名前が重複している。 hive.sales.orders と postgresql.sales.orders これらは異なるシステムに存在する、それぞれ異なる物理テーブルです。カタログ修飾子を削除する系統では、これらが1つのノードに統合されてしまい、それに基づいて構築されたあらゆる下流の影響分析が誤りとなります。
• 部分的な資格取得。 実際のクエリでは、3 部構成の名前をあらゆる場所で明示的に記述することはめったにありません。セッションのデフォルトのカタログとスキーマ、エイリアス、および 使用 ステートメント。リゾルバは、そのコンテキストからすべての列参照の完全な識別情報を再構築する必要があります。
• システム間の境界を一つの記述で示す。 1 アイスバーグに挿入... HiveとPostgreSQLから選択するデータ移動 3つのシステム間で 1つのステートメントで表現できます。テーブルレベルの系統情報は、影響を受けたシステムを示しますが、列レベルの系統情報だけが、どのPostgreSQL列がどのIceberg列に反映されたかを示します。

SQLFlow のセマンティック リゾルバーは完全な カタログ.スキーマ.テーブル.列 系統グラフの各ノードにパスを設定することで、カタログ間の列が明確に区別され、エンドツーエンドで追跡可能になります。

具体的な例：Icebergターゲット、HiveおよびPostgreSQLソース

以下は、典型的なフェデレーション書き込みの例です。運用中のPostgreSQLデータベースとHiveの注文履歴を結合し、Icebergカタログに顧客価値テーブルを作成します。

INSERT INTO iceberg.analytics.customer_value SELECT c.customer_id, lower(c.email) AS email, sum(o.order_total) AS lifetime_value, count(*) AS order_count FROM postgresql.crm.customers AS c JOIN hive.sales.orders AS o ON c.customer_id = o.customer_id WHERE o.order_status = 'COMPLETED' GROUP BY c.customer_id, lower(c.email);

これをSQLFlowでTrino方言を選択して実行すると、出力列ごとに次の図が表示されます。

対象列（iceberg.analytics.customer_value）	ソース列	関係
顧客ID	postgresql.crm.customers.customer_id	直接、パススルー
メール	postgresql.crm.customers.email	直接、 より低い（）
生涯価値	hive.sales.orders.order_total	直接、 和（）
注文数	hive.sales.orders 行	直接、 カウント（*）
すべての列	hive.sales.orders.order_status	間接的（WHEREフィルター）
すべての列	o.顧客ID / c.顧客ID	間接的（JOIN条件、GROUP BY）

最後の2行に注目してください。 注文ステータス 出力には表示されませんが、その入力方法を変更すると、すべての数値が変わります。 顧客価値SQLFlow はこれを次のようにモデル化します。 間接的（影響）系統これは、直接データフローとは別に、切り替え可能なリレーションシップタイプです。ほとんどのデータリネージツールはこの区別をしていませんが、これは共有Hiveテーブルのフィルタ列を操作する前に必要な情報です。

TrinoとPrestoは異なる方言ですが、SQLFlowは両方を解析します。

TrinoはPresto（PrestoSQLとして）から分岐し、2020年に改名されました。それ以来、2つの方言は分岐しています。SQLFlowは TrinoとPrestoそれぞれに方言固有のパーサーを別々に用意するサポートされている39のダイアレクトのうち、互換性フラグ付きの汎用ANSI文法は1つもありません。PrestoDBを新しいTrinoクラスタと並行して運用している場合は、ソースごとに適切なダイアレクトを選択することで、両方とも正しく解析されます。

パーサーは、2000 年代半ばから開発され、方言ごとに約 13,600 のテスト フィクスチャで検証されている商用 SQL コンパイラ フロントエンドである General SQL Parser (GSP) から来ています。GSP は、各ステートメントの完全な意味モデルを構築し、CTE、サブクエリ、ビュー、および 10 行目、および 11 行目、および 12 行目、および 13 行目、および 13 行目、および 14 行目、および 15 行目、および 16 行目、および 17 行目、および 18 行目、および 19 選択 * 拡張――そしてそのデータフローアナライザーは、ソースとターゲットの関係を抽出する。スター拡張は、他のほとんどどの場所よりもトリノにおいて重要である。 選択 * フェデレーション結合では複数のシステムから列が取得され、それを正しく展開するには各カタログのスキーマメタデータが必要となりますが、SQLFlowはそれをSQLとともに取り込むことができます。

SQLFlowを使用してTrinoの系統を生成する方法

1. SQLを収集する。 個々のクエリを貼り付けたり、ETL スクリプトのファイルをアップロードして定義を表示したり、JDBC 経由でメタデータを取得したりできます。全環境をカバーするには、Grabit/SQLFlow インジェスター このユーティリティはメタデータをバッチ処理で抽出します。
2. 方言を選んでください。 ソースごとに、TrinoまたはPrestoを使用します。同じパイプラインにHive DDLまたはSpark SQLジョブも含まれている場合は、それぞれを独自のダイアレクトで分析します。SQLFlowはこれらすべてをサポートしており、エンタープライズ環境では結果を永続的なリネージリポジトリに保存します。
3. 探索してエクスポートする。 インタラクティブな図で任意の列を上流または下流にトレースし、間接的な系統をオンまたはオフに切り替え、JSON、CSV、またはPNGとしてエクスポートするか、REST APIを介してグラフをクエリできます。v8.2.3以降では、平易な英語で質問することもできます（「どのIcebergテーブルが postgresql.crm.customers.emailAIの回答に含まれるすべての表と列は、表示される前に分析されたグラフに対して検証されます。

エンタープライズ規模では、SQLFlowは100以上のデータベースと100万以上の列からなる環境をバッチスキャンし、増分スキャンを実行し、永続的なデータリネージリポジトリを保持し、DataHub、Microsoft Purview、およびOpenMetadataにエクスポートします。これにより、Trinoのデータリネージは、チームが既に利用しているカタログに取り込まれます。

静的SQL分析とランタイムイベントリネージの比較

Trinoの履歴を取得するもう1つの一般的な方法は、ランタイムキャプチャです。エンジンのクエリイベントをフックし、実行されたステートメントごとに履歴を出力します（OpenLineageエコシステムはこの方法で動作します）。ランタイムキャプチャは、実際のセッションコンテキストで実際に実行された内容を記録するのに非常に優れています。ただし、カバレッジと深度に欠点があります。キャプチャウィンドウ中に実行されたクエリしか認識できず、すべてのクラスタに計測器を設置する必要があります。

SQLFlowのアプローチである静的解析は、SQLコード自体を解析します。これには、まだ実行されていないスケジュール済みジョブ、ビュー定義、レビュー中のリポジトリコードが含まれます。また、クラスタにエージェントは必要なく、テーブル行データを読み取ることもありません。規制環境では、 オンプレミス版 （Docker/Kubernetesは）SQLテキストさえもネットワーク内に保持します。多くのチームは両方を使用しています。運用監視にはランタイムイベントを、デプロイ前の包括的な影響分析には静的解析を使用します。

スタックの残りの部分における系統

Trino は、ほとんどの場合、全体像を捉えていません。クエリ対象の Hive テーブルは通常、Hive または Spark ジョブによってロードされ、結果は多くの場合、下流のマートに供給されます。SQLFlow は、同じエンジンを使用してこれらのレイヤーを分析します。詳細については、専用ガイドを参照してください。 Hiveデータ系統 と ClickHouseのデータリネージまたは完全な SQLデータリネージツールの概要 全39の方言を網羅しています。各レイヤーが永続的な系統リポジトリに分析されるため、Hiveテーブルを書き込んだSparkジョブから、フェデレーションされたTrinoクエリを経て、Icebergターゲットに至るまでの列を追跡できます。

よくある質問

SQLFlowはTrinoとPrestoの両方をサポートしていますか？

はい。TrinoとPrestoは、SQLFlowの39種類のダイアレクト固有パーサーのうちの2つです。ご使用のエンジンに合ったダイアレクトを選択してください。両方を実行する場合は、それぞれのソースをそれぞれのダイアレクトで解析してください。

SQLFlowはTrinoカタログ全体にわたる系譜を追跡できますか？

はい。SQLFlowはすべての列を完全修飾されたcatalog.schema.table.columnというIDに解決するため、hive、postgresql、icebergのカタログを結合するクエリは、カタログ間でデータを移動するINSERT文を含め、各システムの列を区別したままのリネージを生成します。

SQLFlowは私のTrinoクラスターやデータへのアクセスを必要としますか？

いいえ。SQLFlowはSQLコードの静的解析を実行し、必要に応じてスキーマメタデータを使用して名前を解決し、SELECT *を展開します。テーブルの行を読み取ることはなく、クラスタ上にエージェントも必要ありません。オンプレミス版では、SQLテキストは完全にネットワーク内に保持されます。

SQLFlowでは、WHERE句とJOIN句の列について何が表示されますか？

これらは間接的（影響）な系譜として表示されます。これは、出力には反映されないものの、結果に影響を与える列のための、別の関係タイプです。図の中で間接的な系譜の表示/非表示を切り替えることができます。これは、ほとんどの系譜ツールでは区別されていない点です。

Trinoの系統情報をデータカタログにエクスポートできますか？

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

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

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