Greenplumデータリネージ：MPPウェアハウスの列リネージ

Greenplumのデータ系統 これは、Greenplumウェアハウス内でデータがどのように流れるかを示す列レベルのマップです。外部テーブルやステージングスキーマから、INSERT-SELECT ELTチェーンやビューを経て、レポートが読み取る分散ファクトテーブルやディメンションテーブルへとデータが流れます。 Gudu SQLFlow Greenplum SQLを専用のGreenplum方言パーサー（同梱されている39種類の方言固有のパーサーのうちの1つ）で解析し、列ごとに追跡できるインタラクティブな図をレンダリングすることで、そのマップを自動的に構築します。

Greenplumのデータリネージに専用のパーサーが必要な理由

GreenplumはPostgreSQLファミリーのMPPデータベースであり、そのクエリ構文のほとんどはPostgresを知っている人なら誰でも馴染みのあるものです。しかし、Greenplumのシステムの中で最も系統的な重みを持つ部分は、まさに標準のPostgreSQLとは異なる部分なのです。

• 外部テーブル。 外部テーブルを作成する と gpfdist またはファイルロケーションは、Greenplum にデータが到着するための標準的な入り口です。 位置 と 形式 条項によって、各ロードパイプラインの最初のホップが失われます。
• 配布キー。 配給元 と ランダムに分布 これらの句は、ほぼすべてのテーブル定義に現れます。一般的なANSI文法はこれらを拒否するため、DDLも拒否され、結果としてこれらのテーブルには履歴が全く残りません。
• INSERT-SELECT ELT チェーン。 Greenplum のデータウェアハウスは通常、データベース内でデータを変換します。ステージング テーブルからコンフォームド テーブル、ファクト テーブルへ、各ステップで INSERT INTO ... SELECT 結合、キャスト、集約などを含む。リネージは、個々のステートメントごとに計算するのではなく、チェーンのすべてのホップにわたって統合する必要がある。

SQLFlow は、Greenplum サポートがエラーが抑制された PostgreSQL ではなく、別のダイアレクト パーサーであるため、3 つすべてを処理します。その内部のエンジンは 汎用SQLパーサー, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures.

実例：外部テーブルを分散ファクトテーブルにロードする

Greenplumのロードパイプラインのほとんどが従うパターンのコンパクト版を以下に示します。毎日の注文ファイルは、 gpfdist外部テーブルに格納され、分散されたファクトテーブルにマージされます。 注文ID:

CREATE EXTERNAL TABLE ext_stage.daily_orders ( order_id bigint, customer_id bigint, order_ts timestamp, amount numeric(12,2), channel text ) LOCATION ('gpfdist://etl-host:8081/daily_orders*.csv') FORMAT 'CSV' (HEADER); CREATE TABLE dw.fact_orders ( order_id bigint, customer_sk bigint, order_date date, net_amount numeric(12,2) ) DISTRIBUTED BY (order_id); INSERT INTO dw.fact_orders (order_id, customer_sk, order_date, net_amount) SELECT o.order_id, c.customer_sk, o.order_ts::date, o.amount - COALESCE(r.refund_amount, 0) FROM ext_stage.daily_orders o JOIN dw.dim_customer c ON c.customer_id = o.customer_id LEFT JOIN dw.stg_refunds r ON r.order_id = o.order_id WHERE o.channel <> 'test';

これを SQLFlow で実行すると、図は各列について dw.fact_ordersデータがどこから来たのか、そしてその過程で何が起こったのかを正確に把握すること。

対象列	ソース列	変身
fact_orders.order_id	ext_stage.daily_orders.order_id	直接コピー
fact_orders.customer_sk	dw.dim_customer.customer_sk	直接参加 顧客ID
fact_orders.order_date	ext_stage.daily_orders.order_ts	キャスト 日付
fact_orders.net_amount	daily_orders.amount, stg_refunds.refund_amount	引き算 合体する

テーブルレベルのビューでは何が隠されていたかに注目してください。 正味金額 2つの異なるテーブルからデータを受け取り、外部テーブルの チャネル 列はファクトテーブルに全く到達しないにもかかわらず、どの行が到達するかを制御します。SQLFlowは、この2番目のタイプの関係も捉えます。

ELTチェーンにおける直接的な系統と間接的な系統

上記の例では、 チャネル のみに現れる どこ 句と結合キーは、 の上 条件。どれも出力には反映されませんが、どれかを変更すると数値が変わります。 事実の注文SQLFlow はこれらを次のようにモデル化します。 間接的（影響）系統これは直接的なデータフローとは別の関係タイプであり、図の中でそれぞれを個別に切り替えることができます。ほとんどのデータリネージツールはこの区別をしていないため、影響分析でフィルタと結合の依存関係が見落とされてしまいます。

INSERT-SELECT チェーンの深さのため、これはほとんどの環境よりも Greenplum でより重要になります。典型的な環境では、外部テーブル、ステージングテーブル、適合レイヤー、ファクトレイヤー、レポートビューが互いに積み重ねられています。SQLFlow は、CTE、サブクエリ、ビュー、およびすべてのホップを通じて列参照を解決します。 選択 * 拡張により、レポート列からのトレースは、1つの連続したパスでソースファイルフィードまで遡ります。

Greenplumから移行しますか？まずは依存関係をマッピングしましょう。

Greenplumの多くの環境は現在、クラウドウェアハウスへの移行候補となっていますが、移行コスト超過の最大の原因は、未知の依存関係です。例えば、誰も文書化していないビュー、3人のユーザーがひっそりと閲覧しているステージングテーブル、新しいモデルで削除された下流レポートに必要な列などです。移行前に依存関係マップを作成することで、本番環境でこれらの問題を発見することを避けることができます。

SQLFlow を使用した系統優先の移行ワークフローは次のようになります。

1. 敷地内をスキャンする。 SQLFlowにGreenplumのDDL、ビュー定義、ロードスクリプトをフィードします。これらは、貼り付け、ファイルとしてアップロード、またはJDBC経由でライブで取得できます。エンタープライズ環境では、100以上のデータベースと100万以上の列からなる環境をバッチスキャンし、コードの変更に応じて増分再スキャンを実行します。
2. 実際に使用されているものを見つけましょう。 列レベルの系統管理により、実際の出力にデータを供給するテーブルと列が、何も読み取られないテーブルと列から分離されるため、20年分の蓄積データではなく、実際のデータウェアハウスを移行できます。
3. 動作の順序を考えて。 系統グラフは依存関係の順序を示します。どの主題領域が独立して動けるか、どの主題領域が上流のフィードの連鎖を引きずり込むかがわかります。
4. 対象物を確認します。 Snowflake、BigQuery、Redshift、Databricks、およびサポートされているその他の39種類のダイアレクトなど、移行先のダイアレクトを解析するエンジンは同じであるため、移行されたSQLを図式化して、移行前後の系統を比較することができます。

レガシー環境が混在するチームでは、他の MPP プラットフォームでも同じアプローチを採用しています。関連ページを参照してください。 Teradataデータリネージ と Verticaデータリネージ. GreenplumはPostgreSQLから派生しているため、プレーンなPostgresも実行している企業は、1つのツールで両方をカバーできます。 PostgreSQLのデータリネージ このページでは、その違いについて説明しています。

Greenplum SQLをSQLFlowに取り込む方法

• 貼り付けまたはアップロード: 個々のクエリ、スクリプト、またはバッチ .sql ブラウザ内のファイル。
• JDBCメタデータ: Greenplumに接続してテーブル定義を取得し、SQLを直接表示することで、リポジトリ内の内容ではなく、デプロイされた内容を反映するようにリネージが作成されます。
• グラビット摂取者: スケジュール設定され、繰り返し実行されるスキャンのための、メタデータの自動抽出。
• REST APIとCLI： CI またはオーケストレーションパイプラインからの分析を駆動する SQLFlow REST API またはヘッドレスCLIを使用し、結果をJSON、CSV、またはPNG形式でエクスポートします。

すべてはSQLテキストとスキーマメタデータの静的解析です。SQLFlowはテーブルの行を読み取ることはなく、オンプレミス版（DockerまたはKubernetes、エアギャップ対応）ではSQLテキストさえもネットワーク内に保持します。これはGreenplumが広く利用されている規制業界にとって特に重要です。データリネージは、DataHub、Microsoft Purview、またはOpenMetadataのいずれかを記録システムとして使用している場合は、これらのカタログにエクスポートすることもできます。

オープンソースの系統追跡ツールはどうでしょうか？

オープンソースのパーサー SQL Lineage と sqlglot これらは、個々の適切に処理されたクエリからテーブル間の関係を抽出するのに非常に役立ち、それが問題のすべてであれば、これで十分かもしれません。しかし、本番環境の Greenplum コードでは、次のような問題が生じます。 外部テーブルを作成する と 配給元 構文、ステートメント間の結合が必要なマルチホップ INSERT-SELECT チェーン、 選択 * スキーマメタデータを必要とする拡張機能と、フィルタや結合による間接的な系統解析。実際のロードスクリプトのいずれかを両方の方法で実行し、出力を比較してみてください。このテストは、どんな機能マトリックスよりも早く問題を解決します。

よくある質問

SQLFlowは、外部テーブルやDISTRIBUTED BYなどのGreenplum固有の構文をサポートしていますか？

はい。SQLFlowには専用のGreenplum方言パーサーが付属しているので、 外部テーブルを作成する, 配給元 句やその他の Greenplum DDL は、エラーを引き起こすことなく、適切に解析され、系統グラフに参加します。

GreenplumにPostgreSQLの方言をそのまま使っても大丈夫ですか？

通常のSELECT文はほとんどの場合正しく解析されますが、ロードパイプラインを定義する文（外部テーブルDDLや分散テーブル定義など）はGreenplum固有のものです。システム全体で正しく解析されるようにGreenplum方言を使用してください。SQLFlowは両方をサポートしているため、GreenplumとPostgresが混在する環境にも対応できます。

SQLFlowは、私のGreenplumテーブル内のデータにアクセスする必要がありますか？

いいえ。SQLFlowはSQLコードの静的解析を行い、必要に応じてJDBC経由でスキーマメタデータを読み取ります。テーブルの行を読み取ることは決してなく、オンプレミス版ではSQLテキストはすべてお客様のネットワーク内に保持されます。

SQLFlowはGreenplumからクラウドへの移行計画に役立ちますか？

はい。Greenplumの環境をスキャンして、真の列レベルの依存関係グラフを取得し、それを使用して移行の範囲と順序を決定し、次に移行されたSQLをターゲットプラットフォーム（Snowflake、BigQuery、Redshift、Databricks、および同じエンジンでサポートされている他の35の方言）上で図示して、孤立したSQLがないことを確認します。

Greenplumの系統を利用する場合、SQLFlowの費用はいくらですか？

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