Analytics Accelerator quickstart guide#
このクイックスタートガイドでは、次のことを行います。
スタンドアロンのコミュニティPostgresインスタンスにPGAA拡張機能をインストールします。
オブジェクトストレージにサンプルベンチマークデータセットを指す保存場所を作成します。
複雑な分析クエリを実行し、Seafowlエンジンが動作していることを確認します。
クエリプランの分析を実行します。
前提条件#
Postgresインスタンスを実行している環境。サポートされているプラットフォームの完全なリストについては、 Analytics Accelerator compatibility を参照してください。
EDBアクセストークン。
Postgresインスタンスへのパッケージのダウンロードとインストール#
EDBリポジトリからパッケージをダウンロードします。
export EDB_SUBSCRIPTION_TOKEN=<your-token>
curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.deb.sh" | sudo -E bash
sudo apt-get install -y postgresql-<version>-pgaa
<version> はPostgresバージョンです。
export EDB_SUBSCRIPTION_TOKEN=<your-token>
curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.rpm.sh" | sudo -E bash
sudo dnf install -y postgresql-<version>-pgaa
<version> はPostgresバージョンです。
postgresql.conf ファイルを編集してpgaa
をshared_preload_libraries に追加し、
Postgresバックグラウンドワーカーを介したSeafowlクエリエンジンの自動管理と起動を有効にします。
shared_preload_libraries = pgaa
pgaa.autostart_seafowl = on
変更を保存した後、Postgresサービスを再起動します。再起動したら、Postgresインスタンスにログインし、PGAA拡張機能を作成します。
CREATE EXTENSION IF NOT EXISTS pgaa CASCADE;
CASCADE を使用すると、必要な依存関係 PGFS なども作成されます。
\dx
を使用して、拡張機能がインストールされていることを確認し、バージョンを確認します。
保存場所の構成#
TPC-Hベンチマークデータを含むパブリックS3バケットを指す保存場所を作成します。
SELECT pgfs.create_storage_location(
quickstart-sample-data,
s3://beacon-analytics-demo-data-us-east-1-prod,
{"skip_signature": "true", "region": "us-east-1"}
);
保存場所が作成されたことを確認します。
SELECT pgfs.list_storage_locations();
分析テーブルの作成#
次の分析テーブルを作成します。これらのテーブルは、サンプル Benchmark datasets のDelta Lakeファイルに直接マッピングします。
CREATE TABLE supplier () USING PGAA WITH (pgaa.storage_location = quickstart-sample-data, pgaa.path = tpch_sf_1/supplier, pgaa.format = delta);
CREATE TABLE lineitem () USING PGAA WITH (pgaa.storage_location = quickstart-sample-data, pgaa.path = tpch_sf_1/lineitem, pgaa.format = delta);
CREATE TABLE orders () USING PGAA WITH (pgaa.storage_location = quickstart-sample-data, pgaa.path = tpch_sf_1/orders, pgaa.format = delta);
CREATE TABLE nation () USING PGAA WITH (pgaa.storage_location = quickstart-sample-data, pgaa.path = tpch_sf_1/nation, pgaa.format = delta);
分析クエリーの実行#
このクエリは、マルチサプライヤーの注文の遅延の原因となったサウジアラビアのサプライヤーを特定します。これは、大規模な結合と複数のサブクエリーを含む大量の分析タスクです。
SELECT
s_name,
COUNT(*) AS numwait
FROM
supplier,
lineitem l1,
orders,
nation
WHERE
s_suppkey = l1.l_suppkey
AND o_orderkey = l1.l_orderkey
AND o_orderstatus = F
AND l1.l_receiptdate > l1.l_commitdate
AND EXISTS (
SELECT
- FROM
lineitem l2
WHERE
l2.l_orderkey = l1.l_orderkey
AND l2.l_suppkey <> l1.l_suppkey
)
AND NOT EXISTS (
SELECT
- FROM
lineitem l3
WHERE
l3.l_orderkey = l1.l_orderkey
AND l3.l_suppkey <> l1.l_suppkey
AND l3.l_receiptdate > l3.l_commitdate
)
AND s_nationkey = n_nationkey
AND n_name = SAUDI ARABIA
GROUP BY
s_name
ORDER BY
numwait DESC,
s_name
LIMIT 100;
クエリプランの分析#
PGAAがこのクエリーをどのように高速化するかを確認するには、上記のステートメントにEXPLAIN
を先頭に追加し、出力を検査します。
QUERY PLAN
- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SeafowlDirectScan: Logical Plan
Limit: skip=0, fetch=100
Sort: numwait DESC NULLS FIRST, supplier.s_name ASC NULLS LAST
Projection: supplier.s_name, count(Int64(1)) AS count(*) AS numwait
Aggregate: groupBy=[[supplier.s_name]], aggr=[[count(Int64(1))]]
Filter: supplier.s_suppkey = l1.l_suppkey AND orders.o_orderkey = l1.l_orderkey AND orders.o_orderstatus = Utf8("F") AND l1.l_receiptdate > l1.l_commitdate AND EXISTS (<subquery>) AND NOT EXISTS (<subquery>) AND supplier.s_nationkey = nation.n_nationkey AND nation.n_name = Utf8("SAUDI ARABIA")
Subquery:
Projection: l2.l_orderkey, l2.l_partkey, l2.l_suppkey, l2.l_linenumber, l2.l_quantity, l2.l_extendedprice, l2.l_discount, l2.l_tax, l2.l_returnflag, l2.l_linestatus, l2.l_shipdate, l2.l_commitdate, l2.l_receiptdate, l2.l_shipinstruct, l2.l_shipmode, l2.l_comment
Filter: l2.l_orderkey = outer_ref(l1.l_orderkey) AND l2.l_suppkey != outer_ref(l1.l_suppkey)
SubqueryAlias: l2
TableScan: lineitem
Subquery:
Projection: l3.l_orderkey, l3.l_partkey, l3.l_suppkey, l3.l_linenumber, l3.l_quantity, l3.l_extendedprice, l3.l_discount, l3.l_tax, l3.l_returnflag, l3.l_linestatus, l3.l_shipdate, l3.l_commitdate, l3.l_receiptdate, l3.l_shipinstruct, l3.l_shipmode, l3.l_comment
Filter: l3.l_orderkey = outer_ref(l1.l_orderkey) AND l3.l_suppkey != outer_ref(l1.l_suppkey) AND l3.l_receiptdate > l3.l_commitdate
SubqueryAlias: l3
TableScan: lineitem
Cross Join:
Cross Join:
Cross Join:
TableScan: supplier
SubqueryAlias: l1
TableScan: lineitem
TableScan: orders
TableScan: nation
(24 rows)
プランの先頭にSeafowlDirectScan
の存在は、PGAAがクエリ実行の完全な制御を取得し、標準のPostgresエグゼキュータをバイパスしてデータレイクに対して直接クエリを実行していることを示します。
何十億行もPostgresに引き込んで処理するのではなく、結合、フィルタ、集計を含む論理プラン全体が最適化された分析エンジンにプッシュダウンされます。
サブクエリープッシュダウン
lineitemテーブルのEXISTSおよびNOT EXISTSサブクエリーに注意してください。これらはPostgresによって一つ一つ実行されていません。代わりに、それらはParquetファイルに対して並列処理されるグローバル論理プランの一部です。ベクトル化されたジョイン
Cross Joinノードと上位のFilterノードは、エンジンがストレージレイヤーでハッシュジョインまたはネストされたループジョインを実行していることを示します。述語プッシュダウン
n_name = Utf8("SAUDI ARABIA")やo_orderstatus = Utf8("F")のようなフィルタは、初期スキャン中に適用されます。これは、関連するデータのみがレイクから読み取られ、I/Oが大幅に削減されることを意味します。最終的な集計とソート
AggregateおよびSortは、パイプラインの最後で、最後の100行がPostgresクライアントに返される前に発生します。
結論#
PGAAを正常にインストールし、クラウドベースのオブジェクトストレージに到達するように構成し、複雑なSQLロジックサブクエリや結合を含むがネイティブにオフロードされていることを確認しました。
Seafowl DirectScanを活用することで、Postgresインスタンスがペタバイト規模のデータレイクへのゲートウェイとして機能し、トランザクションコンピューティングとは無関係にスケールする分析パフォーマンスを提供できるようになりました。