SQLを用いた大量データ分析～GPUによる高速化アプローチ～

SQLを用いた大量データ分析 ～GPUによる高速化アプローチ～ HeteroDB,Inc Chief Architect & CEO 海外 浩平 <kaigai@heterodb.com>

自己紹介 ▌自己紹介  名前：  所属：  経歴： 海外 浩平（KaiGai Kohei） ヘテロＤＢ株式会社 筑波大学 第三学群 情報学類卒 筑波大学大学院 経営・政策科学研究科修了 日本電気株式会社（2003～2017）勤務 ✓ PostgreSQLやLinuxなど、OSSの開発に従事  受賞： ヘテロＤＢ社を設立（2017）、現在に至る。 IPA未踏ソフトウェア創造事業において、 天才プログラマ／スーパークリエーター認定（2006） GTC Japan 2017にて、Inception Awardを受賞（2017） ▌ヘテロDB社について  所在地：  設立：  従業員数：  資本金：  業務内容： 2 東京都品川区北品川 2017年7月4日 2名 999万円 高速データベース製品（PG-Strom）の開発と販売 GPUやPostgreSQL、その他オープンソース領域の技術コンサルティング 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

本日のトピック ① GPUとはどんなプロセッサなのか ② GPUを用いてSQLを高速化する ③ TBを越えるデータを高速に分析する ④ 静的なデータを超高速に分析する ⑤ 数十GBのデータを超々高速に分析する ⑥ まとめ 3 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

① GPUとはどんなプロセッサなのか？ 4 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPUとはどんなプロセッサなのか？（1/2） 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA A100 スーパーコンピュータ （東京工業大学 TSUBAME3.0） シミュレーション ＣＧ（Computer Graphics） 機械学習 数千コアの並列処理ユニット、TB/sのスループットに達する広帯域メモリを ワンチップに実装した半導体デバイス。 “同じ計算を大量のデータに並列実行” を最も得意とする 5 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPUとはどんなプロセッサなのか？（2/2） 10,000コア前後の処理能力とTB/sを越えるメモリ帯域を ワンチップに実装した並列演算プロセッサ CPU 小回りが利くが輸送力は小さな 乗用車のようなプロセッサ 6 GPU 乗り降りは少し手間だが、大量輸送が 可能な高速鉄道のようなプロセッサ モデル Intel Xeon Platinum 8490H NVIDIA H100 [PCI-E] 世代 Saphire Rapids Hopper コア数 60 cores (functional) 7296 cores (simple) メモリ容量・性能 最大4.0TB [DDR5; 600GB/s] 80GB [HBM2e; 2000GB/s] L1キャッシュ 48KB / core 256KB / SM[64 cuda cores] L2キャッシュ 2MB / core 50MB / GPU L3キャッシュ 112.5MB / CPU ------ TDP 350W 350W 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

キャッシュとメモリから見える設計思想の違い CPUの特徴 GPUの特徴 ✓ 動作クロックが高い ✓ キャッシュを多く搭載 ✓ 分岐予測など高度な制御機能 ✓ コア数が非常に多い ✓ キャッシュは控え目 ✓ メモリ帯域が非常に太い core cache DRAM core cache DRAM ✓ 動作クロックが高くキャッシュが豊富な設計は、メモリアクセスの局所性を期待 できるデスクトップアプリケーションなど、多くのソフトウェアに適する。 ✓ GPUの設計は、大量のデータをプロセッサコアに流し込む事に特化した設計。 ➔ 行列計算や、それから派生する機械学習用途でヒット。 7 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPUにおける『並列計算』 step.1 item[0] item[1] item[2] item[3] item[4] GPUを用いた item[5] Σi=0...N-1item[i] item[6] item[7] 配列総和の計算 item[8] item[9] item[10] item[11] SELECT count(X), sum(Y), avg(Z) FROM my_table; item[12] item[13] item[14] item[15] ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● step.2 ◆ step.4 step.3 ▲ ■ ◆ ◆ ▲ ◆ ◆ ▲ ◆ ◆ ▲ ■ log2N ステップで items[]の総和を計算 ◆ 集約関数の計算で用いる仕組み HW支援によるコア間の同期機構 8 ★ 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

② GPUを用いてSQLを高速化する ～PG-Stromのご紹介～ 9 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

SQL処理のイメージとGPUの適用 行列計算の場合 ベクトル v 𝑣×𝐴 v0 v1 v2 v3 × × × × 行列A ak,0 ak,1 ak,2 ak,3 vn-4 vn-3 vn-2 vn-1 異なるデータに 同じ演算を多数実行 × × × × ak,n-4 ak,n-3 ak,n-2 ak,n-1 テーブルスキャンの方向 テーブルスキャンの場合 WHERE x_val % 2 = 1 x_val = 123 x_val = 234 x_val = 345 x_val = 456 x_val = 567 〇 × 〇 × 〇 ● ● ● ● ● GPUコア ✓ DBテーブルをある種のベクトルと見なせば、 一度の処理サイクルで数千～万行の処理が可能に 10 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

拡張モジュールによるSQL処理への介入 ▌SQL処理の一部（SCAN、JOIN、Group-By）をGPUで処理させる。 ▌PostgreSQLに「GPUでの実行」を選択させる。 SQLクエリ SQLパーサ PG-Strom SQLオプティマイザ GPU実行計画作成 SQLエグゼキュータ GPUでのSQL処理 問合せ結果 11 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

SQL実行計画の違い（1/2）
Scan -> Join -> Group-Byの順に問い合わせを実行
ssbm=# explain select
from
where
and
and
and

sum(lo_extendedprice*lo_discount) as revenue
lineorder,date1
lo_orderdate = d_datekey
d_year = 1993
lo_discount between 1 and 3
lo_quantity < 25;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------Finalize Aggregate (cost=124610396.32..124610396.33 rows=1 width=32)
-> Gather (cost=124610395.15..124610396.26 rows=11 width=32)
Workers Planned: 11
-> Partial Aggregate (cost=124609395.15..124609395.16 rows=1 width=32)
-> Hash Join (cost=83.51..124558623.10 rows=10154410 width=10)
Hash Cond: (lineorder.lo_orderdate = date1.d_datekey)
-> Parallel Seq Scan on lineorder (cost=0.00..124371569.79 rows=71108687 width=14)
Filter: ((lo_discount >= '1'::numeric) AND
(lo_discount <= '3'::numeric) AND
(lo_quantity < '25'::numeric))
-> Hash (cost=78.95..78.95 rows=365 width=4)
-> Seq Scan on date1 (cost=0.00..78.95 rows=365 width=4)
Filter: (d_year = 1993)
(11 rows)

12

探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

SQL実行計画の違い（2/2）
GPUで一気にScan -> Join -> Group-By(前処理) を実行する計画
ssbm=# explain select
from
where
and
and
and

sum(lo_extendedprice*lo_discount) as revenue
lineorder,date1
lo_orderdate = d_datekey
d_year = 1993
lo_discount between 1 and 3
lo_quantity < 25;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------Aggregate (cost=12514769.09..12514769.10 rows=1 width=32)
-> Gather (cost=12514768.87..12514769.08 rows=2 width=8)
Workers Planned: 2
-> Parallel Custom Scan (GpuPreAgg) on lineorder (cost=12513768.87..12513768.88 rows=1 width=8)
GPU Projection: pgstrom.psum(((lo_extendedprice * lo_discount))::double precision)
GPU Scan Quals: ((lo_discount >= '1'::numeric) AND
(lo_discount <= '3'::numeric) AND
(lo_quantity < '25'::numeric)) [rows: 6000030000 -> 325914800]
GPU Join Quals [1]: (lo_orderdate = d_datekey) ... [nrows: 325914800 -> 46541040]
GPU Outer Hash [1]: lineorder.lo_orderdate
GPU Inner Hash [1]: date1.d_datekey
GPU-Direct SQL: enabled (GPU-0)
-> Seq Scan on date1 (cost=0.00..78.95 rows=365 width=4)
Filter: (d_year = 1993)
(12 rows)

13

探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

③ TBを越えるデータを高速に分析する ～GPU-Direct SQL機構～ 14 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPU-Direct SQL機構（1/3） プロセッサに大量のデータを流し込む事が生命線 GPUの特徴 ✓ コア数が非常に多い ✓ キャッシュは控え目 ✓ メモリ帯域が非常に太い GPU core メモリバス (HBM2e) 2000GB/s core 数十GB DRAM PCI-E 4.0 (x16 lane) cache 26.0GB/s 数TB～ Storage DRAM 15 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPU-Direct SQL機構（2/3） Storage Block Read PCI-E Bus 大量の ”ゴミデータ” も含む Buffer Copy SCAN Buffer Copy JOIN GROUP BY 16 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPU-Direct SQL機構（3/3） P2P-DMAを利用し、NVME-SSDとGPUを直結してデータ転送 Storage Block Read by NVIDIA GPUDirect Storage SCAN P2P-DMA JOIN GROUP BY PCI-E Bus P2P-DMA : Peer-to-Peer Direct Memory Access 17 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

ベンチマーク 測定環境 Supermicro AS-2014CS-TR CPU: AMD EPYC 7402P (24C, 2.8GHz) x1 RAM: 16GB DDR4-3200 ECC x8 GPU: NVIDIA A100 [PCI-E; 40GB] x1 SSD: Intel D7-P5510 [3.84TB] x4 DB: PostgreSQL 15.3 + PG-Strom v5.0dev SSBM (900GB; 60億行) select from where and and and 18 sum(lo_extendedprice*lo_discount) as revenue lineorder,date1 lo_orderdate = d_datekey d_year = 1993 lo_discount between 1 and 3 lo_quantity < 25; 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

④ 静的なデータを超高速に分析する ～Apache Arrow形式～ 19 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

Apache Arrowデータ形式（1/2） ▌列指向の構造化データ形式  被参照列のみ読み出す（= I/O量の削減）が可能  データが隣接しているため、SIMD命令やGPUでの処理性能を引き出しやすい ▌多くのビッグデータ系OSSで対応が進んでいる  SparkやDrill、Python(PyArrow)など。PG-Strom (Arrow_Fdw) もその一つ。 ▌留意点  更新はほぼ不可能。追記のみ（Insert-Only）と考えた方がよい PG-Strom (Arrow_Fdw) 20 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

Apache Arrowデータ形式（2/2） 物理的な（ファイル上の）レイアウト Apache Arrow File Header “ARROW1¥0¥0” Schema Definition RecordBatch: A列 NULL-Bitmap 長さの同じ配列を 列ごとに寄せ集め たもの。 A列 Values-array B列 NULL-Bitmap Record Batch-k RecordBatch-1 RecordBatch-k B列 Values-index 被参照列のみの ロードが容易 B列 Values-body C列 NULL-Bitmap C列 Values-array D列 NULL-Bitmap A列 B列 C列 D列 D列 Values-array RecordBatch-N Footer Schema Definition Custom Metadata Terminator “ARROW1” 21 Schema Definition: 列名やデータ型、属性が 列の数だけ列挙されている。 テーブル定義に相当する。 SELECT SUM(D) FROM f_arrow_tbl WHERE B LIKE ‘%abc%’; 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

外部テーブルの利用（1/2） Foreign Tableを用いてArrowファイルをテーブルのように扱う ssbm=# IMPORT FOREIGN SCHEMA f_lineorder FROM SERVER arrow_fdw INTO public OPTIONS (file '/opt/pgdata15/f_lineorder_s1000.arrow'); IMPORT FOREIGN SCHEMA ssbm=# ¥d f_lineorder Foreign table "public.f_lineorder" Column | Type | Collation | Nullable | Default | FDW options --------------------+---------------+-----------+----------+---------+------------lo_orderkey | bigint | | | | lo_linenumber | integer | | | | lo_custkey | integer | | | | lo_partkey | integer | | | | lo_suppkey | integer | | | | lo_orderdate | integer | | | | lo_orderpriority | character(15) | | | | lo_shippriority | character(1) | | | | lo_quantity | integer | | | | lo_extendedprice | integer | | | | lo_ordertotalprice | integer | | | | lo_discount | integer | | | | lo_revenue | integer | | | | lo_supplycost | integer | | | | lo_tax | integer | | | | lo_commit_date | character(8) | | | | lo_shipmode | character(10) | | | | Server: arrow_fdw FDW options: (file '/opt/pgdata15/f_lineorder_s1000.arrow') 22 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

外部テーブルの利用（2/2）
あたかもPostgreSQLテーブルであるかのように問合せが可能
ssbm=# explain analyze select
from
where
and
and
and

sum(lo_extendedprice*lo_discount) as revenue
f_lineorder,date1
lo_orderdate = d_datekey
d_year = 1993
lo_discount between 1 and 3
lo_quantity < 25;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------Aggregate (cost=14535261.08..14535261.09 rows=1 width=8) (actual time=8930.580..8930.582 rows=1 loops=1)
-> Custom Scan (GpuPreAgg) on f_lineorder (cost=14535261.06..14535261.07 rows=1 width=8)
¥
(actual time=8930.570..8930.573 rows=1 loops=1)
GPU Projection: pgstrom.psum(((lo_extendedprice * lo_discount))::bigint)
GPU Scan Quals: ((lo_discount >= 1) AND (lo_discount <= 3) AND (lo_quantity < 25))
¥
[plan: 5999990000 -> 9999983, exec: 0 -> 812331034]
GPU Join Quals [1]: (lo_orderdate = d_datekey) ... [plan: 9999983 -> 1428010,
¥
exec: 812331034 -> 119144472]
GPU Outer Hash [1]: f_lineorder.lo_orderdate
GPU Inner Hash [1]: date1.d_datekey
referenced: lo_orderdate, lo_quantity, lo_extendedprice, lo_discount
file0: /opt/pgdata15/f_lineorder_s1000.arrow (read: 89.41GB, size: 502.92GB)
-> Seq Scan on date1 (cost=0.00..78.95 rows=365 width=4) (actual time=0.058..0.281 rows=365 loops=1)
Filter: (d_year = 1993)
Rows Removed by Filter: 2191
Planning Time: 1.775 ms
Execution Time: 8932.515 ms
(14 rows)

23

探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

SSBMによる比較 800 705.16 702.32 Query Execution Throughput [M Rows/sec] 700 665.01 600 500 select from where and and and 400 300 200 sum(lo_extendedprice*lo_discount) as revenue f_lineorder,date1 lo_orderdate = d_datekey d_year = 1993 lo_discount between 1 and 3 lo_quantity < 25; 157.80 157.04 157.86 100 26.60 26.38 25.37 0 Q1_1 PostgreSQL 15.3 Q1_2 PG-Strom v5.0 [Heap] Q1_3 PG-Strom v5.0 [Arrow] ✓ 先ほどのケースと比較しても、さらに４倍強の高速化 • GPU側実装の改善により、もう５～６割は性能向上の余地あり。 ✓ 静的なデータであれば、非常に効果が大きいオプション 24 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

《補足》PostgreSQLデータベースからArrowファイルを生成する Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。 ✓ 基本的な使い方は、-cで指定したSQLの実行結果を、 -oで指定したファイルに書き出す。 $./pg2arrow -h Usage: pg2arrow [OPTION]... [DBNAME [USERNAME]] General options: -d, --dbname=DBNAME database name to connect to -c, --command=COMMAND SQL command to run -f, --file=FILENAME SQL command from file -o, --output=FILENAME result file in Apache Arrow format Arrow_Fdw Pg2Arrow Apache Arrow Data Files 25 Arrow format options: -s, --segment-size=SIZE size of record batch for each (default is 256MB) Connection options: -h, --host=HOSTNAME -p, --port=PORT -U, --username=USERNAME -w, --no-password -W, --password database server host database server port database user name never prompt for password force password prompt Debug options: --dump=FILENAME --progress dump information of arrow file shows progress of the job. 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

⑤ 数十GBのデータを超々高速に分析する ～GPU-Cache機構～ 26 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPU-Cache機構（1/2） ストレージからの読出しが必要でないデータサイズなら？ データ量がこのサイズなら、 そもそもストレージから 読み出す必要、無くないで すか？ GPU core メモリバス (HBM2e) 2000GB/s 数十GB DRAM GPU-Cache テーブルの内容をGPUにキャッシュして おき、ストレージからの読出しなしに、 GPU上でSQLを実行する機能。 差分ログを通じてキャッシュは更新され、 常に最新の情報に対して問い合わせを行 う事ができる。 27 PCI-E 4.0 (x16 lane) 26.0GB/s 数TB～ Storage 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

GPU-Cache機構（2/2） 最初はテーブル全体のコピーをGPUメモリに転送する 初期ロード ※DB起動時に自動ロードも可 GPU-Cache PostgreSQL テーブル 28 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～ GPUデバイスメモリ

GPU-Cache機構（2/2） テーブルの更新は行トリガを通じてREDOログバッファに記録 行トリガー 更新 REDOログバッファ 削除 更新ログ 更新ログ 削除ログ 更新 GPU-Cache PostgreSQL テーブル 29 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～ GPUデバイスメモリ

GPU-Cache機構（2/2） GPUでのクエリ実行前に、それまでの更新をGPU-Cacheに反映する REDOログバッファ 更新ログ 更新ログ 更新ログ 更新ログ 削除ログ 削除ログ GPU-Cache PostgreSQL テーブル 30 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～ GPUデバイスメモリ

ベンチマーク例 ✓ 2kBの特徴ベクトル同士を比較し、その類似度が一定の閾値を越えたものを 出力するクエリの応答時間を計測。 ✓ データ量は1000万行（約20GB） ✓ CPU処理の47倍、さらに同じGPUを使った場合と比較しても、I/O処理を省略 できる分、猛烈な高速化を実現できている。 ✓ 数十GB程度のデータ量に適合するオプション 47.2 times faster 31 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

⑥ まとめ 32 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

まとめ（1/2） データ量とその特性によって異なるデータ分析戦略 ▌データ量が非常に大きい（～TBスケール）  データはしばしば更新される ✓ PostgreSQLテーブルに対する GPU-Direct SQLの利用 ✓ 毎秒 20GB/s 程度のデータ処理能力を実現できる。  データは静的である ✓ Apache Arrow形式ファイルからの GPU-Direct SQL の利用 ✓ 被参照列のみ読み出す事で I/O 量を削減する。 ▌データ量がそこそこ大きい（～数十GBスケール） ✓ 検索条件が複雑・計算量が多く、データ量がGPU-RAMに載る程度の大きさで あれば、GPU-Cache の利用が選択肢。更新のあるDBにも適する。 ▌データ量は大きくない ✓ ノーマルの PostgreSQL で十分 ✓ マルチコアCPU + NVME-SSDで十分な処理能力 33 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

まとめ（2/2） PG-Stromのこれから ▌PG-Strom v5.0のリリース ▌クラウド環境での利用  MDXでの評価検証、デプロイするためのVMイメージ  他のパブリッククラウドでの利用 ▌GPU実装の改善  メモリ帯域を有効活用するための内部データ構造の変更 ▌その他のSQL機能のサポート  パーティション対応、Hyper-Log-Log、カスタムモジュールの追加 ▌リソース  GitHub： https://github.com/heterodb/pg-strom  ドキュメント： http://heterodb.github.io/pg-strom/ja/  問合せ先： contact@heterodb.com / Tw: kkaigai 34 探索的ビッグデータ解析と再現可能研究～SQLを用いた大量データ分析～

• https://github.com/heterodb/pg-strom
• http://heterodb.github.io/pg-strom/ja/

オモシロ技術を、カタチにする。