Redshiftデータリネージ：クエリログからの自動列リネージ

Redshiftデータの系譜 これは、Amazon Redshift クラスター内でデータがどのように移動するかを示す列レベルのマップです。どのソース テーブルと列が各ターゲット テーブル、ビュー、レポートにデータを提供し、その過程でどのような変換が行われるかを示します。Redshift 自体はこのようなマップを保持しませんが、実行するすべての SQL ステートメントをログに記録し、Redshift ではすべての変換が SQL として表現されます。これらのログを解析すれば、完全なデータ リネージを自動的に再構築できます。まさにそれが、 Gudu SQLFlow 機能：Redshiftのクエリログをネイティブに取り込み、実行されたSQLを対話型の列レベルの系統図に変換します。

Redshiftに組み込みの系統表示機能がない理由

Redshift コンソールとシステム ビューは、クラスタを操作するために構築されており、データ フローを理解するために構築されているわけではありません。クエリ パフォーマンス、キューの動作、テーブル統計を調べることはできますが、Redshift では出力列を、それを生成したソース列にリンクするものは何もありません。Redshift が継承した PostgreSQL スタイルのカタログ依存関係追跡でさえ、Redshift 独自の機能の 1 つである遅延バインディング ビュー (作成されたビュー) では機能しません。 スキーマバインディングなし意図的に、基となるテーブルへの依存関係を記録しない。

Redshiftが保持するのは、生データ、つまりシステムテーブルなどです。 STL_QUERYTEXT と SYS_QUERY_HISTORY 実行されたステートメントのテキストを保存し、監査ログはすべてのクエリを長期保存のためにS3にアーカイブできます。SQL履歴はすべてそこにあります。欠けているのは、何千ものステートメントを読み取って「どこで fact_orders.net_revenue 「実際にはどこから来たのか？」その分析レイヤーはSQLリネージツールです。

クエリログからRedshiftのデータリネージを取得する方法

クエリログベースのリネージは、ソースリポジトリのみを分析する場合と比べて決定的な利点が1つあります。それは、実際に実行された内容をキャプチャできることです。スケジュールされたETL、アドホックなバックフィル、BIツールやオーケストレーターによって発行されたステートメント、SQLクライアントから実行された単発の修正など、バージョン管理されているかどうかに関わらず、すべてがクエリ履歴に記録されます。SQLFlowを使用したワークフローは次のとおりです。

1. 実行されたSQLを収集します。 Redshiftのシステムテーブル、またはRedshiftがS3に書き込む監査ログからステートメントテキストを取得します。Redshiftクエリログの取り込みは、SQLFlowのネイティブ入力として、貼り付けられたSQL、アップロードされたファイル、およびJDBC経由のライブメタデータと並んで利用できます。
2. Redshift専用のパーサーを使用して解析します。 SQLFlow は、専用の Redshift 方言パーサー (汎用 ANSI 文法ではなく、39 種類の方言固有のパーサーの 1 つ) を使用して各ステートメントを分析し、CTE、サブクエリ、ビュー、および 選択 * 拡大。
3. 融合して探求しよう。 すべてのステートメントからの系統は、対話的にドリルダウンできる 1 つのグラフに統合され、任意の列から上流または下流をトレースし、JSON、CSV、または PNG としてエクスポートしたり、クエリを実行したりできます。 SQLFlow REST API.

SQLFlowはSQLテキストの静的解析を行うため、テーブルの行を読み込むことはありません。必要なのはSQL文と、必要に応じてスキーマメタデータのみで、曖昧な参照を解決するために使用します。

具体的な例：ウィンドウ関数を使用したINSERT … SELECT

以下は、実際のRedshiftクエリログに記録されるステートメントの一例です。ウィンドウ関数を使用してレポートテーブルをロードする集計処理です。

INSERT INTO analytics.customer_monthly_rank (customer_id, order_month, monthly_revenue, revenue_rank) SELECT o.customer_id, DATE_TRUNC('month', o.order_date) AS order_month, SUM(o.amount) AS monthly_revenue, RANK() OVER ( PARTITION BY DATE_TRUNC('month', o.order_date) ORDER BY SUM(o.amount) DESC ) AS revenue_rank FROM sales.orders o WHERE o.status = 'complete' GROUP BY o.customer_id, DATE_TRUNC('month', o.order_date);

SQLFlowは、この単一のステートメントから、2つの異なるカテゴリの列レベルの系統情報を抽出します。

対象列	直接の情報源	間接的（影響）源
顧客ID	注文の顧客ID	注文状況 （どこ）
注文月	注文日 経由 日付切り捨て	注文状況
月間収益	注文数 経由 和	注文状況, 注文の顧客ID, 注文日 （グループ化）
収益順位	注文数 経由 和 それから RANK() オーバー	注文日 （パーティション分割） 注文状況

2番目のカテゴリーに注目してください。 注文状況 出力には決して現れないが、その格納方法を変更すると、ターゲット テーブルのすべての数値が変わる。SQLFlow はこれをモデル化する。 間接的な系統 — WHERE、GROUP BY、JOIN条件、およびウィンドウパーティションを介して作用する列 — を、切り替え可能な別の関係タイプとして扱います。ほとんどのデータリネージツールはこの区別をしていませんが、これはまさに「どのレポートがこの列を読み取るか」と「どのレポートがこの列の影響を受けるか」の違いです。

Redshift固有の構成要素は依然として単なるSQLである

後期拘束力のある見解

遅延バインディングビューは、ビューを基となるテーブルから切り離すための標準的な Redshift パターンであり、設計上、カタログベースの依存関係クエリからは見えません。ただし、SQL パーサーにとって、遅延バインディングビューは単なるビュー定義です。SQLFlow はビューの SELECT を解析し、他のビューと同様に出力列をソースに接続するため、リネージはそのまま流れます。 スキーマバインディングなし.

DISTKEY、SORTKEY、およびDISTSTYLE

分散キーとソートキーはパフォーマンスを左右し、データフローは左右しません。 DISTKEY(customer_id) SORTKEY(order_date) 他のテーブルと同じ系統を持ちます。SQLFlow は Redshift DDL を解析し、テーブルとその列を記録し、物理チューニング句はグラフに影響を与えることなく渡されます。テーブルがどの状態であっても、系統は正しく維持されます。 ディススタイルすべて, 平、 また 鍵.

RedshiftはPostgreSQLではありません

RedshiftはPostgreSQLから派生していますが、構文と動作は大きく異なっています。そのため、SQLFlowは既存のパーサーを再利用するのではなく、専用のRedshiftパーサーを同梱しています。 PostgreSQLの系譜 parser — each of the 39 supported dialects gets its own grammar, validated against a corpus of roughly 13,600 per-dialect SQL test fixtures built up over two decades of commercial parser development.

Redshift SQLをSQLFlowに取り込む方法

入力	それがあなたにもたらすもの
Redshiftクエリログ	実行されたすべての声明の系譜 ― 完全な真実の全体像
JDBC経由のライブメタデータ	クラスターから直接取得したDDLおよびビュー定義
アップロードされたSQLファイル	ETLスクリプトとリポジトリをバッチとして分析
貼り付けられたSQL	ブラウザ上で単一のステートメントの即時履歴を表示
dbtマニフェスト	Redshiftで構築されるdbtモデル全体にわたる列レベルの系統

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

他のアプローチと比べてどうでしょうか？

オープンソースのパーサーなど SQL Lineage と sqlglot 個々の整形式ステートメントから系統を抽出するには十分であり、少数のクリーンなクエリには十分かもしれません。 ギャップは、本番環境の Redshift ログで発生します。数千のステートメント、Redshift 固有の構文、ビューがビューの上にレイヤー化されています。 選択 * スキーマメタデータを拡張し、フィルタやウィンドウパーティションを介して間接的にリネージを行う必要があるプラットフォーム。カタログファーストのプラットフォームは、多くのシステムにわたるメタデータの整理と管理に優れていますが、高度なSQL分析を行うには、通常、専用のリネージエンジンが必要となります。そのため、SQLFlowはDataHub、Purview、OpenMetadataと競合するのではなく、これらのプラットフォーム向けのエクスポートアダプタを提供しています。

Redshiftを他のデータウェアハウスと並行して実行する場合、同じエンジンが同じアプローチでそれらをカバーします。 Snowflakeのデータ系統 クエリ履歴から取得します。これは、Redshift のログベースの取り込みとよく似ています。また、規制環境の場合、 SQLFlow オンプレミス ネットワーク内のDockerまたはKubernetes上で実行されるため、SQLテキストがインフラストラクチャから外部に送信されることはありません。

よくある質問

SQLFlowは私のRedshiftクラスター内のデータを読み取りますか？

いいえ。SQLFlowはSQLコードの静的解析を行い、必要に応じてスキーマメタデータ（テーブルと列の定義）を読み取ります。テーブルの行を読み取ることはありません。オンプレミス版では、SQLテキストもネットワーク内に留まります。

RedshiftのSQLはどこから来るのですか？

実行されたステートメントがどこに保存されていても、Redshiftのクエリ履歴システムテーブル、S3にアーカイブされた監査ログ、ETLスクリプトリポジトリ、またはJDBC経由でリアルタイムに取得されるDDLとビュー定義など、どこからでもログを取得できます。Redshiftのクエリログ取り込みはネイティブのSQLFlow入力であるため、リネージはクラスタ上で実際に実行された内容を反映します。

後からバインディングを行うビューは、系統にとって問題となるのでしょうか？

これらはカタログベースの依存関係追跡を無効にします。なぜなら、Redshiftは設計上、これらの依存関係を記録しないからです。ただし、パーサーベースの系統追跡には問題ありません。SQLFlowはビューのSQL定義を直接解析し、他のビューと同様に列をソースに接続します。

SQLFlowでは、フィルターを通してのみ結果に影響を与える列が表示されますか？

はい。SQLFlowは、直接的なデータ系列（実際に出力列にデータが流れ込む場合）と間接的なデータ系列（WHERE、JOIN、GROUP BY、およびウィンドウパーティション句を介して作用する列）を区別し、図上でそれぞれを個別に切り替えることができます。

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

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