Download as PDF, PPTX
![SSD-to-GPUダイレクトSQL（3/3）– ベンチマーク結果
クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])
SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録
CPU+Filesystemベースの構成と比べて約3倍強の高速化
➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！15
2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313
8,252 8,266 8,266 8,154 8,158 8,186
7,933
8,094
8,240 8,225
7,975 7,969 8,107
0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3
QueryExecutionThroughput[MB/s]
Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3
PostgreSQL 11.5 PG-Strom 2.2 (Row data)](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-15-2048.jpg){kind=icon}
![SSD-to-GPU Direct SQL on Arrow_Fdw（2/3）– ベンチマーク結果①
クエリ実行スループット = (879GB; DB or 685GB; arrow) / (クエリ応答時間 [sec])
SSD-to-GPU Direct SQLとArrow_Fdwの併用により、16GB～58GB/sのクエリ実行
スループット（被参照列の数による）を達成。
サーバ構成は前述のものと同様；1Uラックマウント構成（1CPU, 1GPU, 3SSD）
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！23
2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313
8,252 8,266 8,266 8,154 8,158 8,186 7,933 8,094 8,240 8,225 7,975 7,969 8,107
56,228
57,780 58,409
28,832
30,597
32,963
18,255
20,924 21,460 21,632
16,172 16,262
17,835
0
10,000
20,000
30,000
40,000
50,000
60,000
Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3
QueryExecutionThroughput[MB/s]
Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3
PostgreSQL 11.5 PG-Strom 2.2 (Row data) PG-Strom 2.2 + Arrow_Fdw](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-23-2048.jpg){kind=icon}
![《補足》PostgreSQLデータベースから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 format options:
-s, --segment-size=SIZE size of record batch for each
(default is 256MB)
Connection options:
-h, --host=HOSTNAME database server host
-p, --port=PORT database server port
-U, --username=USERNAME database user name
-w, --no-password never prompt for password
-W, --password force password prompt
Debug options:
--dump=FILENAME dump information of arrow file
--progress shows progress of the job.
Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。
Apache Arrow
Data Files
Arrow_Fdw
Pg2Arrow
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！25](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-25-2048.jpg){kind=icon}
![《補足》PostgreSQLデータベースからArrowファイルを生成する
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！26
postgres=# SELECT * FROM hoge LIMIT 5;
id | a | b | c | d
----+---------+------------------+----------------------------------+----------------------------
1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732
2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892
3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115
4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831
5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714
(5 rows)
$ ./pg2arrow -h localhost -d postgres -c "SELECT * FROM hoge" -o /tmp/hoge.arrow --progress
RecordBatch 0: offset=400 length=60840 (meta=360, body=60480)
$ python3
>>> import pyarrow as pa
>>> f = pa.ipc.open_file('/tmp/hoge.arrow')
>>> f.schema
id: int32
a: float
b: double
c: string
d: timestamp[us]
>>> f.get_record_batch(0).to_pandas()](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-26-2048.jpg){kind=icon}
![《補足》PostgreSQLデータベースからArrowファイルを生成する
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！27
postgres=# SELECT * FROM hoge LIMIT 5;
id | a | b | c | d
----+---------+------------------+----------------------------------+----------------------------
1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732
2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892
3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115
4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831
5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714
(5 rows)
>>> f.get_record_batch(0).to_pandas()
id a b c d
0 1 912.185303 115.101984 c4ca4238a0b923820dcc509a6f75849b 2018-05-03 06:34:22.699732
1 2 443.358643 838.238200 c81e728d9d4c2f636f067f89cc14862c 2023-04-15 20:32:04.849892
2 3 724.744934 151.214334 eccbc87e4b5ce2fe28308fd9f2a7baf3 2020-09-09 08:36:16.945115
3 4 945.820862 679.363270 a87ff679a2f3e71d9181a67b7542122c 2024-09-01 02:23:25.905831
4 5 866.806213 936.137223 e4da3b7fbbce2345d7772b0674a318d5 2019-02-27 16:48:00.914714
.. ... ... ... ... ...
995 996 775.208069 650.437260 0b8aff0438617c055eb55f0ba5d226fa 2020-10-20 22:25:12.552472
996 997 307.992249 632.720383 ec5aa0b7846082a2415f0902f0da88f2 2023-05-21 01:51:49.750671
997 998 351.875305 228.426710 9ab0d88431732957a618d4a469a0d4c3 2023-10-10 01:00:49.554332
998 999 446.303772 506.119982 b706835de79a2b4e80506f582af3676a 2024-04-07 16:46:46.459525
999 1000 700.981323 704.731527 a9b7ba70783b617e9998dc4dd82eb3c5 2020-01-31 03:02:39.859514
[1000 rows x 5 columns]](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-27-2048.jpg){kind=icon}
![ベンチマーク結果（1/4）
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！32
実効データ処理スループット 100GB/s を実現
9.39 9.53 9.56 8.62 8.50 9.87
6.44 8.60 8.95 8.91 7.76 7.77 8.66
37.42 37.48 37.66 37.77 37.83 37.75 36.43 37.38 37.14 37.14 36.55 36.57 36.60
191.29
194.99 195.57
120.37
124.01
128.21
85.73
91.20 92.82 92.40
74.93 75.54 76.77
0
20
40
60
80
100
120
140
160
180
200
Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3
実効データ処理スループット
[GB/sec]
Results of Star Schema Benchmark
[SF=4,000 (3.5TB; 24B rows), 4xGPU, 16xNVME-SSD]
PostgreSQL 11.5 PG-Strom 2.2 PG-Strom 2.2 + Arrow_Fdw](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-32-2048.jpg){kind=icon}
![ベンチマーク結果（2/4）
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！33
毎秒10億レコードの処理性能をシングルノードで実現
64.0 65.0 65.2 58.8 58.0 67.3 43.9 58.7 61.0 60.8 52.9 53.0 59.1
255.2 255.6 256.9 257.6 258.0 257.5 248.5 254.9 253.3 253.3 249.3 249.4 249.6
1,681
1,714 1,719
1,058
1,090
1,127
753
801 816 812
658 664 675
0
200
400
600
800
1,000
1,200
1,400
1,600
1,800
Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3
単位時間あたり処理レコード数
[millionrows/sec]
Results of Star Schema Benchmark
[SF=4,000 (3.5TB; 24B rows), 4xGPU, 16xNVME-SSD]
PostgreSQL 11.5 PG-Strom 2.2 PG-Strom 2.2 + Arrow_Fdw
more than billion rows per second](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-33-2048.jpg){kind=icon}
![ベンチマーク結果（3/4）
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！34
SQL実行中は40GB/s前後（HW限界の95%）でデータを読み出し
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340
NVME-SSDReadThroughput[MB/s]
経過時間 [sec]
/dev/md0 (GPU0) /dev/md1 (GPU1) /dev/md2 (GPU2) /dev/md3 (GPU3)](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-34-2048.jpg){kind=icon}
![337.2
1,230
5347.9
0 1,000 2,000 3,000 4,000 5,000 6,000
PG-Strom 2.2
+ Arrow_Fdw
PG-Strom 2.2
PostgreSQL 11.5
全ワークロードの総実行時間 [sec]
Total execution time of Star Schema Benchmark
ベンチマーク結果（4/4）
Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！35
長時間を要する集計・解析ワークロードで特に効果が顕著
（かなり長めの）お昼寝並みに
時間を要していたバッチ処理を
オムツ替え程度の時間で実行。
（１時間半）
（２０分）
（５分）](https://image.slidesharecdn.com/20191210apachearrowmeetup-191211143856/75/20191211_Apache_Arrow_Meetup_Tokyo-35-2048.jpg){kind=icon}
Uploaded byKohei KaiGai
20191211_Apache_Arrow_Meetup_Tokyo
(2019-12-11) Apache Arrow Meetup Tokyo 2019 での発表資料です
![GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017]](https://cdn.slidesharecdn.com/ss_thumbnails/20170906dbtsgpussdacceleratespostgresqljp-170906073226-thumbnail.jpg?width=640&height=640&fit=bounds)
20191211_Apache_Arrow_Meetup_Tokyo
- 1. PostgreSQLだってビッグデータ処理したい！！ ～Apache Arrowが可能にする毎秒10億レコードのデータ処理～ HeteroDB,Inc Chief Architect& CEO KaiGai Kohei <kaigai@heterodb.com>
- 2. 設立： 2017年7月4日(火) 拠点： 品川区北品川5-13-15 事業内容： ✓ 高性能データ処理ソフトウェアの開発と販売 ✓ GPU&DB領域の技術コンサルティング ✓ オープンソースソフトウェアの開発と普及 自己紹介 海外 浩平 (KaiGai Kohei) Chief Architect & CEO of HeteroDB PostgreSQL, Linux kernel 開発者 (2003～) PG-Stromのメイン開発者（2012～） 興味範囲：Big-data, GPU, NVME, PMEM, Curling, … about myself about our company PG-Strom Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！2
- 3. PG-Stromとは？ Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！3 【機能】 集計／解析ワークロードの透過的なGPU高速化 SQLからGPUプログラムを自動生成し並列実行 SSD-to-GPU Direct SQLによるPCIeバスレベルの最適化 列ストレージによるI/Oと並列計算の効率化 PG-Strom: GPUとNVMEの能力を最大限に引き出し、数十TB単位の データ処理を高速化するPostgreSQL向け拡張モジュール App GPU off-loading for IoT/Big-Data for ML/Analytics ➢ SSD-to-GPU Direct SQL ➢ Columnar Store (Arrow_Fdw) ➢ Asymmetric Partition-wise JOIN/GROUP BY ➢ BRIN-Index Support ➢ NVME-over-Fabric Support ➢ Procedural Language for GPU native code (PL/CUDA) ➢ NVIDIA RAPIDS data frame support (WIP) ➢ IPC on GPU device memory
- 4. ログ収集デーモン： ターゲット：IoT/M2Mログの集計・解析処理 Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！4 Manufacturing Logistics Mobile Home electronics なぜPostgreSQLか？ シングルノードで処理できるならそっちの方が運用が楽 エンジニアが慣れ親しんが技術で、運用ノウハウの蓄積が豊富 JBoF: Just Bunch of Flash NVME-over-Fabric (RDMA) DB管理者 BIツール（可視化） 機械学習アプリケーション （E.g, 異常検知など） 共通データ フレーム PG-Strom
- 5. どれ位のデータサイズを想定するか？（1/3） ※ 誰でも名前を知っている超有名企業の生産ラインの話です。 ➔ つまり100TB未満の領域をカバーできれば、大半のユーザには十分。 ある国内企業様の例： 半導体工場の製造ラインが生成したデータ100TBをPostgreSQLで管理 年間20TB 5年間保持 不良品検査 原因分析 ApacheArrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！5
- 6. どれ位のデータサイズを想定するか？（2/3） イマドキの2Uサーバなら、オールフラッシュで100TB普通に積める。 model Supermicro 2029U-TN24R4TQty CPU Intel Xeon Gold 6226 (12C, 2.7GHz) 2 RAM 32GB RDIMM (DDR4-2933, ECC) 12 GPU NVIDIA Tesla P40 (3840C, 24GB) 2 HDD Seagate 1.0TB SATA (7.2krpm) 1 NVME Intel DC P4510 (8.0TB, U.2) 24 N/W built-in 10GBase-T 4 8.0TB x 24 = 192TB お値段 How much? 60,555USD by thinkmate.com (10th-Dec-2019) Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！6
- 7. どれ位のデータサイズを想定するか？（3/3） とは言うものの、”余裕で捌ける”というにはちと大きい。 TB TB TB B Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！7
- 8. GPUでI/Oを高速化する SSD-to-GPU Direct SQL ApacheArrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！8
- 9. GPUとはどんなプロセッサなのか？ Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！9 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA Tesla V100 スーパーコンピュータ （東京工業大学 TSUBAME3.0） ＣＧ（Computer Graphics） 機械学習 “計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか？ シミュレーション
- 10. 一般的な x86_64 サーバの構成 GPUSSD CPU RAM HDD N/W ApacheArrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！10
- 11. 大量データを処理する時のデータの流れ CPU RAM SSD GPU PCIe PostgreSQL データブロック 通常のデータフロー 本来は不要なレコードであっても、 一度CPU/RAMへロードしなければ 要・不要を判断できないため、 データサイズは大きくなりがち。 ApacheArrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！11 一度CPU/RAMへロードしなければ、 “ゴミデータ” であってもその要否を判断できない。
- 12. SSD-to-GPUダイレクトSQL（1/3） CPU RAM SSD GPU PCIe PostgreSQL データブロック NVIDIAGPUDirect RDMA CPU/RAMを介することなく、 Peer-to-PeerのDMAを用いて SSD上のデータブロックを直接 GPUに転送する機能。 WHERE句 JOIN GROUP BY GPUでSQLを処理し、 データ量を削減する データ量：小 Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！12
- 13. 《要素技術》NVIDIA GPUDirect RDMA ApacheArrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！13 物理アドレス空間 PCIe BAR1領域 GPU デバイス メモリ RAM NVMe-SSD Infiniband HBA PCIe デバイス GPUDirect RDMA GPUデバイスメモリを 物理アドレス空間に マップする機能 『GPUデバイスメモリの物理アドレス』が 存在すれば、PCIeデバイスとのDMAで、 Source/Destinationアドレスとして指定できる。 0xf0000000 0xe0000000 DMA要求 SRC: 1200th sector LEN: 40 sectors DST: 0xe0200000
- 14. SSD-to-GPUダイレクトSQL（2/3）– システム構成とワークロード Apache ArrowTokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！14 Supermicro SYS-1019GP-TT CPU Xeon Gold 6126T (2.6GHz, 12C) x1 RAM 192GB (32GB DDR4-2666 x 6) GPU NVIDIA Tesla V100 (5120C, 16GB) x1 SSD Intel SSD DC P4600 (HHHL; 2.0TB) x3 (striping configuration by md-raid0) HDD 2.0TB(SATA; 72krpm) x6 Network 10Gb Ethernet 2ports OS CentOS 7.7 (kernel-3.10.0-1062.1.2.el7) CUDA 10.1 + NVIDIA Driver 418.87.01 DB PostgreSQL v11.5 PG-Strom v2.2 ■ Query Example (Q2_3) SELECT sum(lo_revenue), d_year, p_brand1 FROM lineorder, date1, part, supplier WHERE lo_orderdate = d_datekey AND lo_partkey = p_partkey AND lo_suppkey = s_suppkey AND p_category = 'MFGR#12‘ AND s_region = 'AMERICA‘ GROUP BY d_year, p_brand1 ORDER BY d_year, p_brand1; customer 15M rows (2.0GB) date1 2.5K rows (400KB) part 1.8M rows (206MB) supplier 5.0M rows (659MB) lineorder 6.0B rows (876GB) シンプルな1Uサーバで、大量データの集計処理を実行 Star Schema Benchmark
- 15. SSD-to-GPUダイレクトSQL（3/3）– ベンチマーク結果 クエリ実行スループット= (879GB DB-size) / (クエリ応答時間 [sec]) SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録 CPU+Filesystemベースの構成と比べて約3倍強の高速化 ➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現 Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！15 2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313 8,252 8,266 8,266 8,154 8,158 8,186 7,933 8,094 8,240 8,225 7,975 7,969 8,107 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 QueryExecutionThroughput[MB/s] Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3 PostgreSQL 11.5 PG-Strom 2.2 (Row data)
- 16. 効率的な列データストア Arrow_Fdw（Apache Arrow対応） Apache ArrowTokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！16
- 17. 背景① データはどこで生成されるのか？ ETL OLTP OLAP 伝統的なOLTP&OLAPシステム－ データはDBシステムの内側で生成される Data Creation IoT/M2M時代 － データはDBシステムの外側で生成される Log processing BI Tools BI Tools Gateway Server Data Creation Data Creation Many Devices Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！17 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に！ Data Import Import!
- 18. 背景② PostgreSQLのデータ構造は結構無駄が多い Apache ArrowTokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！18 8kB HeapTuple Table Segment Block HeapTupleHeader nullmap 列A 列B 列D 列E Tuple SELECT B FROM this_table WHERE E like ‘%hoge%’; 要る？
- 19. Apache Arrowとは（1/2） Apache ArrowTokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！19 ▌特徴 列指向で分析用途向けに設計されたデータ形式 アプリケーションによらず、共通のデータ交換形式として利用可能 整数、実数、日付時刻、文字列など基本的なデータ型を定義 NVIDIA GPU PostgreSQL / PG-Strom
- 20. Apache Arrowとは（2/2）– データ型のマッピング ApacheArrowデータ型 PostgreSQLデータ型 補足説明 Int int2, int4, int8 FloatingPoint float2, float4, float8 float2 is an enhancement of PG-Strom Binary bytea Utf8 text Bool bool Decimal numeric Date date adjusted to unitsz = Day Time time adjusted to unitsz = MicroSecond Timestamp timestamp adjusted to unitsz = MicroSecond Interval interval List array types Only 1-dimensional array is supportable Struct composite types Union ------ FixedSizeBinary char(n) FixedSizeList array types? Map ------ 大半のデータ型はApache Arrow PostgreSQLの間で変換可能 Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！20
- 21. 《背景》FDW (Foreign DataWrapper) Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！21 FDWモジュールは、外部データ PostgreSQLの相互変換に責任を持つ。 Arrow_Fdwの場合、ファイルシステム上の Arrow 形式ファイルを Foreign Table という形で参照できるようにマップする（≠ インポートする）。 ➔ 改めてデータをDBシステムにインポートする必要がない。 外部テーブル（Foreign Table）－ PostgreSQL管理外のデータソースを、 あたかもテーブルであるかのように取り扱うための機能 PostgreSQL Table Foreign Table postgres_fdw Foreign Table file_fdw Foreign Table twitter_fdw Foreign Table Arrow_fdw External RDBMS CSV Files Twitter (Web API) Arrow Files
- 22. SSD-to-GPU Direct SQLon Arrow_Fdw（1/3） Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！22 ▌なぜApache Arrow形式が優れているのか？ 被参照列のみ読み出すため、I/O量が少なくて済む GPUメモリバスの特性から、プロセッサ実行効率が高い Read-onlyデータなので、実行時のMVCC検査を行う必要がない SSD-to-GPU Direct SQL機構を使って、被参照列だけを転送する。 PCIe Bus NVMe SSD GPU SSD-to-GPU P2P DMA WHERE-clause JOIN GROUP BY クエリの被参照列のみ、 ダイレクトデータ転送 Apache Arrow形式を解釈し、 データを取り出せるよう GPUコード側での対応。 小規模の処理結果だけを PostgreSQLデータ形式で返すResults metadata
- 23. SSD-to-GPU Direct SQLon Arrow_Fdw（2/3）– ベンチマーク結果① クエリ実行スループット = (879GB; DB or 685GB; arrow) / (クエリ応答時間 [sec]) SSD-to-GPU Direct SQLとArrow_Fdwの併用により、16GB～58GB/sのクエリ実行 スループット（被参照列の数による）を達成。 サーバ構成は前述のものと同様；1Uラックマウント構成（1CPU, 1GPU, 3SSD） Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！23 2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313 8,252 8,266 8,266 8,154 8,158 8,186 7,933 8,094 8,240 8,225 7,975 7,969 8,107 56,228 57,780 58,409 28,832 30,597 32,963 18,255 20,924 21,460 21,632 16,172 16,262 17,835 0 10,000 20,000 30,000 40,000 50,000 60,000 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 QueryExecutionThroughput[MB/s] Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3 PostgreSQL 11.5 PG-Strom 2.2 (Row data) PG-Strom 2.2 + Arrow_Fdw
- 24. SSD-to-GPU Direct SQLon Arrow_Fdw（3/3）– 結果の検証 Foreign table "public.flineorder" Column | Type | Size --------------------+---------------+-------------------------------- lo_orderkey | numeric | 89.42GB lo_linenumber | integer | 22.37GB lo_custkey | numeric | 89.42GB lo_partkey | integer | 22.37GB <-- ★Referenced by Q2_1 lo_suppkey | numeric | 89.42GB <-- ★Referenced by Q2_1 lo_orderdate | integer | 22.37GB <-- ★Referenced by Q2_1 lo_orderpriority | character(15) | 83.82GB lo_shippriority | character(1) | 5.7GB lo_quantity | integer | 22.37GB lo_extendedprice | integer | 22.37GB lo_ordertotalprice | integer | 22.37GB lo_discount | integer | 22.37GB lo_revenue | integer | 22.37GB <-- ★Referenced by Q2_1 lo_supplycost | integer | 22.37GB lo_tax | integer | 22.37GB lo_commit_date | character(8) | 44.71GB lo_shipmode | character(10) | 55.88GB FDW options: (file '/opt/nvme/lineorder_s401.arrow') ... file size = 310GB ▌Q2_1では、681GB中157GB (23.0%) だけをNVME-SSDから実際に読み出している。 ▌Q2_1の実行時間は24.3sなので、157GB / 24.3s = 6.46GB/s ➔ 3x Intel DC P4600 (2.0TB; HHHL) のストライプ構成としては穏当な性能。 物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化 Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！24
- 25. 《補足》PostgreSQLデータベースから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 format options: -s, --segment-size=SIZE size of record batch for each (default is 256MB) Connection options: -h, --host=HOSTNAME database server host -p, --port=PORT database server port -U, --username=USERNAME database user name -w, --no-password never prompt for password -W, --password force password prompt Debug options: --dump=FILENAME dump information of arrow file --progress shows progress of the job. Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。 Apache Arrow Data Files Arrow_Fdw Pg2Arrow Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！25
- 26. 《補足》PostgreSQLデータベースからArrowファイルを生成する Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！26 postgres=# SELECT * FROM hoge LIMIT 5; id | a | b | c | d ----+---------+------------------+----------------------------------+---------------------------- 1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732 2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892 3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115 4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831 5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714 (5 rows) $ ./pg2arrow -h localhost -d postgres -c "SELECT * FROM hoge" -o /tmp/hoge.arrow --progress RecordBatch 0: offset=400 length=60840 (meta=360, body=60480) $ python3 >>> import pyarrow as pa >>> f = pa.ipc.open_file('/tmp/hoge.arrow') >>> f.schema id: int32 a: float b: double c: string d: timestamp[us] >>> f.get_record_batch(0).to_pandas()
- 27. 《補足》PostgreSQLデータベースからArrowファイルを生成する Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！27 postgres=# SELECT * FROM hoge LIMIT 5; id | a | b | c | d ----+---------+------------------+----------------------------------+---------------------------- 1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732 2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892 3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115 4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831 5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714 (5 rows) >>> f.get_record_batch(0).to_pandas() id a b c d 0 1 912.185303 115.101984 c4ca4238a0b923820dcc509a6f75849b 2018-05-03 06:34:22.699732 1 2 443.358643 838.238200 c81e728d9d4c2f636f067f89cc14862c 2023-04-15 20:32:04.849892 2 3 724.744934 151.214334 eccbc87e4b5ce2fe28308fd9f2a7baf3 2020-09-09 08:36:16.945115 3 4 945.820862 679.363270 a87ff679a2f3e71d9181a67b7542122c 2024-09-01 02:23:25.905831 4 5 866.806213 936.137223 e4da3b7fbbce2345d7772b0674a318d5 2019-02-27 16:48:00.914714 .. ... ... ... ... ... 995 996 775.208069 650.437260 0b8aff0438617c055eb55f0ba5d226fa 2020-10-20 22:25:12.552472 996 997 307.992249 632.720383 ec5aa0b7846082a2415f0902f0da88f2 2023-05-21 01:51:49.750671 997 998 351.875305 228.426710 9ab0d88431732957a618d4a469a0d4c3 2023-10-10 01:00:49.554332 998 999 446.303772 506.119982 b706835de79a2b4e80506f582af3676a 2024-04-07 16:46:46.459525 999 1000 700.981323 704.731527 a9b7ba70783b617e9998dc4dd82eb3c5 2020-01-31 03:02:39.859514 [1000 rows x 5 columns]
- 28. シングルノード構成の限界に挑む マルチGPU + SSD-to-GPUDirect + Arrow_Fdw Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！28
- 29. ～100TB程度の ログデータを シングルノードで 処理可能に ４ユニットの並列動作で、 100～120GB/sの 実効データ処理能力 列データ構造により ユニット毎25～30GB/sの 実効データ転送性能 大規模構成による検証（1/3） QPI SSD-to-GPU Direct SQL、Arrow_Fdw、マルチGPU処理の全てを投入 CPU2CPU1RAMRAM PCIe-SW PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3HBA0 HBA1 HBA2 HBA3 GPU+4xSSDユニット あたり8.0～10GB/sの 物理データ転送性能 29 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！
- 30. 大規模構成による検証（2/3） Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！30 HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台 による環境を構築
- 31. 大規模構成による検証（3/3） UPI 879GBx4 = 3.5TBのテストデータを4つのパーティションに分散 CPU2CPU1RAMRAM PCIe-SW PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3HBA0 HBA1 HBA2 HBA3 31 PCIe-SW PCIe-SW Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！ lineorder_p0 (879GB) lineorder_p1 (879GB) lineorder_p2 (879GB) lineorder_p3 (879GB) lineorder (---GB) Hash-Partition (N=4)
- 32. ベンチマーク結果（1/4） Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！32 実効データ処理スループット 100GB/s を実現 9.39 9.53 9.56 8.62 8.50 9.87 6.44 8.60 8.95 8.91 7.76 7.77 8.66 37.42 37.48 37.66 37.77 37.83 37.75 36.43 37.38 37.14 37.14 36.55 36.57 36.60 191.29 194.99 195.57 120.37 124.01 128.21 85.73 91.20 92.82 92.40 74.93 75.54 76.77 0 20 40 60 80 100 120 140 160 180 200 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 実効データ処理スループット [GB/sec] Results of Star Schema Benchmark [SF=4,000 (3.5TB; 24B rows), 4xGPU, 16xNVME-SSD] PostgreSQL 11.5 PG-Strom 2.2 PG-Strom 2.2 + Arrow_Fdw
- 33. ベンチマーク結果（2/4） Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！33 毎秒10億レコードの処理性能をシングルノードで実現 64.0 65.0 65.2 58.8 58.0 67.3 43.9 58.7 61.0 60.8 52.9 53.0 59.1 255.2 255.6 256.9 257.6 258.0 257.5 248.5 254.9 253.3 253.3 249.3 249.4 249.6 1,681 1,714 1,719 1,058 1,090 1,127 753 801 816 812 658 664 675 0 200 400 600 800 1,000 1,200 1,400 1,600 1,800 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 単位時間あたり処理レコード数 [millionrows/sec] Results of Star Schema Benchmark [SF=4,000 (3.5TB; 24B rows), 4xGPU, 16xNVME-SSD] PostgreSQL 11.5 PG-Strom 2.2 PG-Strom 2.2 + Arrow_Fdw more than billion rows per second
- 34. ベンチマーク結果（3/4） Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！34 SQL実行中は40GB/s前後（HW限界の95%）でデータを読み出し 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 NVME-SSDReadThroughput[MB/s] 経過時間 [sec] /dev/md0 (GPU0) /dev/md1 (GPU1) /dev/md2 (GPU2) /dev/md3 (GPU3)
- 35. 337.2 1,230 5347.9 0 1,000 2,0003,000 4,000 5,000 6,000 PG-Strom 2.2 + Arrow_Fdw PG-Strom 2.2 PostgreSQL 11.5 全ワークロードの総実行時間 [sec] Total execution time of Star Schema Benchmark ベンチマーク結果（4/4） Apache Arrow Tokyo meetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！35 長時間を要する集計・解析ワークロードで特に効果が顕著 （かなり長めの）お昼寝並みに 時間を要していたバッチ処理を オムツ替え程度の時間で実行。 （１時間半） （２０分） （５分）
- 36. 余談：今年の性能目標は達成できた模様 Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！36
- 37. Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！37 今後の方向性
- 38. データ処理のライフサイクル全体を支えるプラットフォームに Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！38 device big-data summary machine- learning Insight ログデータの収集 Apache Arrow形式を 通じたデータ連携 毎秒10億件に達する 大量データ処理能力 GPUデータフレームを 通じた、機械学習アプ リとのデータ連携 大量データからの 異常検知など ＋
- 39. GPUの世界 PMEMの世界 Pythonの世界 今後）GPUメモリストアと、Python処理系からの直接参照 Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！39 既にセットアップ済みのGPUデバイスメモリ領域を 他のプログラムのアドレス空間にマップし、共有/参照するための機能 ✓ 解析対象のデータを選択、GPUへのロードまでをDBMSに任せる事ができる。 ➔ 都度、Pythonスクリプトで大量のCSVデータを読み出す必要がなくなる。 Storage SQLの世界 INSERT UPDATE DELETE SELECT 機械学習 アプリケーション 機械学習 フレームワーク Zero-copy 参照 WIP Foreign Table (gstore_fdw) ✓ データ形式の変換 ✓ トランザクション制御 Arrow Data Frame Arrow Data Frame 統計解析 ロジック
- 40. Resources Apache Arrow Tokyomeetup 2019 ～ PostgreSQLだってビッグデータ処理したい！！40 ▌リポジトリ https://github.com/heterodb/pg-strom https://heterodb.github.io/swdc/ ▌ドキュメント http://heterodb.github.io/pg-strom/ ▌コンタクト kaigai@heterodb.com Tw: @kkaigai