More Related Content Similar to 20200828_OSCKyoto_Online (20) More from Kohei KaiGai (17) 20200828_OSCKyoto_Online2. HeteroDB社について
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~2
会社概要
商号 ヘテロDB株式会社
創業 2017年7月4日
拠点 品川区北品川5-13-15
事業内容 高速データベース製品の販売
GPU&DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
海外 浩平(KaiGai Kohei)
OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
IPA未踏ソフト事業において“天才プログラマー”認定 (2006)
GPU Technology Conference Japan 2017でInception Awardを受賞
4. PG-Stromとは?
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~4
【機能】
集計/解析ワークロードの透過的なGPU高速化
SSD-to-GPU Direct SQLによるPCIeバスレベルの最適化
Apache Arrow対応によるデータ交換、インポート時間をほぼゼロに
GPUメモリにデータを常駐。OLTPワークロードとの共存
一部PostGIS関数のサポート。位置情報分析を高速化
PG-Strom: GPUとNVME/PMEMの能力を最大限に引き出し、
テラバイト級のデータを高速処理するPostgreSQL向け拡張モジュール
App
GPU
off-loading
for IoT/Big-Data
for ML/Analytics
➢ SSD-to-GPU Direct SQL
➢ Columnar Store (Arrow_Fdw)
➢ GPU Memory Store (Gstore_Fdw)
➢ Asymmetric Partition-wise
JOIN/GROUP BY
➢ BRIN-Index Support
➢ NVME-over-Fabric Support
➢ Inter-process Data Frame
for Python scripts
➢ Procedural Language for
GPU native code (w/ cuPy)
➢ PostGIS Support
NEW
NEW
8. PostgreSQLはどのように実行計画を作るか
Scan
t0 Scan
t1
Join
t0,t1
統計情報)
nrows: 120万行
width: 80
インデックス:なし
候補パス
HashJoin
cost=4000
候補パス
MergeJoin
cost=12000
候補パス
NestLoop
cost=99999
候補パス
Parallel
Hash Join
cost=3000
候補パス
GpuJoin
cost=2500
WINNER!
PostgreSQLビルトインの実行パス拡張モジュールによる提案
(PostgreSQL v9.5以降)
(PostgreSQL v9.6以降)
GpuJoin
t0,t1
統計情報)
nrows: 4000行
width: 120
インデックス:id列
複数の処理アルゴリズムを競わせ、“コスト値”で評価
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~8
9. SQLからGPUコードを自動生成(WHERE句の例)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~9
QUERY: SELECT cat, count(*), avg(x) FROM t0
WHERE x between y and y + 20.0 GROUP BY cat;
:
STATIC_FUNCTION(bool)
gpupreagg_qual_eval(kern_context *kcxt,
kern_data_store *kds,
size_t kds_index)
{
pg_float8_t KPARAM_1 = pg_float8_param(kcxt,1);
pg_float8_t KVAR_3 = pg_float8_vref(kds,kcxt,2,kds_index);
pg_float8_t KVAR_4 = pg_float8_vref(kds,kcxt,3,kds_index);
return EVAL((pgfn_float8ge(kcxt, KVAR_3, KVAR_4) &&
pgfn_float8le(kcxt, KVAR_3,
pgfn_float8pl(kcxt, KVAR_4, KPARAM_1))));
} :
例) 条件句中の数値演算式を
CUDA命令列にオンデマンドで変換
Reference to input data
SQL expression in CUDA source code
Run-time
コンパイラ
(nvrtc)
Parallel
Execution
10. 実行計画を確認する
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~10
postgres=# EXPLAIN ANALYZE
SELECT cat,count(*),sum(ax) FROM tbl NATURAL JOIN t1 WHERE cid % 100 < 50 GROUP BY cat;
QUERY PLAN
---------------------------------------------------------------------------------------------------
GroupAggregate (cost=203498.81..203501.80 rows=26 width=20)
(actual time=1511.622..1511.632 rows=26 loops=1)
Group Key: tbl.cat
-> Sort (cost=203498.81..203499.26 rows=182 width=20)
(actual time=1511.612..1511.613 rows=26 loops=1)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
(actual time=1511.554..1511.562 rows=26 loops=1)
Reduction: Local
Combined GpuJoin: enabled
-> Custom Scan (GpuJoin) on tbl (cost=13455.86..220069.26 rows=1797115 width=12)
(never executed)
Outer Scan: tbl (cost=12729.55..264113.41 rows=6665208 width=8)
(actual time=50.726..1101.414 rows=19995540 loops=1)
Outer Scan Filter: ((cid % 100) < 50)
Rows Removed by Outer Scan Filter: 10047462
Depth 1: GpuHashJoin (plan nrows: 6665208...1797115,
actual nrows: 9948078...2473997)
HashKeys: tbl.aid
JoinQuals: (tbl.aid = t1.aid)
KDS-Hash (size plan: 11.54MB, exec: 7125.12KB)
-> Seq Scan on t1 (cost=0.00..2031.00 rows=100000 width=12)
(actual time=0.016..15.407 rows=100000 loops=1)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
どういう事か?
11. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (1/3)
Aggregation
GROUP BY
JOIN
SCAN
SELECT cat, count(*), avg(x)
FROM t0 JOIN t1 ON t0.id = t1.id
WHERE y like ‘%abc%’
GROUP BY cat;
count(*), avg(x)
GROUP BY cat
t0 JOIN t1
ON t0.id = t1.id
WHERE y like ‘%abc%’
実行結果
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~11
GpuScan
GpuJoin
Agg
+
GpuPreAgg
SeqScan
HashJoin
Agg
12. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/3)
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Host
Buffer
GPU
CPU
Storage
単純にロジックを置き換えるだけでは、CPU<->GPU間で
データ転送のピンポンが発生してしまう。
Host
Buffer
Host
Buffer
実行結果
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~12
Host
Buffer
Agg
(PostgreSQL)
13. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/3)
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Host
Buffer
GPU
CPU
Storage
GPU上でデータ交換を行い、無用なDMAを発行しないようにする。
GPU
Buffer
GPU
Buffer 実行結果
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~13
Host
Buffer
Agg
(PostgreSQL)
SCAN + JOIN + GROUP BYを実行するGPUカーネル
data size
= large
data size
= small
通常、GPUから書き戻されるデータサイズは、
GPUへ転送するデータサイズよりもずっと小さい。
18. SSD-to-GPUダイレクトSQL(2/4)- ソフトウェアスタック
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~18
Filesystem
(ext4, xfs)
nvme_strom
kernel module
NVMe SSD
NVIDIA Tesla GPU
PostgreSQL
pg_strom
extension
read(2) ioctl(2)
Hardware
Layer
Operating
System
Software
Layer
Database
Software
Layer
blk-mq
nvme pcie nvme rdma
Network HBA
ファイルオフセットと
NVMEセクタ番号を変換
NVMEoF Target
(JBOF)
NVMe
Request
■ Other software component
■ Our developed software
■ Hardware
NVME over Fabric
on RoCE network
ローカルSSDだけでなく、
NVME-oFデバイスからの
RDMAにも対応
19. SSD-to-GPUダイレクトSQL(3/4)– システム構成とワークロード
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~19
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
20. SSD-to-GPUダイレクトSQL(4/4)– ベンチマーク結果
クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])
SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録
CPU+Filesystemベースの構成と比べて約3倍強の高速化
➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~20
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)
21. SSD-to-GPU Direct SQLの今後
NVIDIAが2020Q4にリリース予定のGPUDirect Storageドライバに対応
➔ 機能的には同等で、SDSや圧縮SSDソリューション等も利用可能に
NVIDIA GPUDirect Storage HeteroDB NVME-Strom
対応OS RHEL8, Ubuntu 18.04 RHEL7, RHEL8
ローカルSSD 〇 (MOFED + patch) 〇 (INBOX + patch)
NVME-oF対応 〇 (MOFED + patch) 〇 (INBOX + patch)
ファイル
システム対応
NFS, Ext4
一部商用分散FS
Ext4
RAID対応 md-raid (RAID0) md-raid (RAID0)
ワークロード Read, Write Read
その他制約 O_DIRECT必須 I/Oサイズは
PAGE_SIZEの倍数のみ
周辺システム Excelero (SDS製品)
ScaleFlux (圧縮SSD製品)
サードパーティなし
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~21
23. 背景① データはどこで生成されるのか?
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
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~23
DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に!
Data
Import
Import!
25. Apache Arrowとは(1/2)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~25
▌特徴
列指向で分析用途向けに設計されたデータ形式
アプリケーションによらず、共通のデータ交換形式として利用可能
整数、実数、日付時刻、文字列など基本的なデータ型を定義
NVIDIA GPU
PostgreSQL / PG-Strom
26. Apache Arrowとは(2/2)– データ型のマッピング
Apache Arrowデータ型 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の間で変換可能
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~26
27. FDW (Foreign Data Wrapper)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~27
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
28. SSD-to-GPU Direct SQL on Arrow_Fdw(1/3)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~28
▌なぜ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
29. 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)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~29
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
30. SSD-to-GPU Direct SQL on 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) のストライプ構成としては穏当な性能。
物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~30
31. 《補足》PostgreSQLデータベースからArrowファイルを生成する
✓ 基本的な使い方は、-cで指定したSQLの実行結果を、
-oで指定したファイルに書き出す。
$ pg2arrow --help
Usage:
pg2arrow [OPTION] [database] [username]
General options:
-d, --dbname=DBNAME Database name to connect to
-c, --command=COMMAND SQL command to run
-t, --table=TABLENAME Table name to be dumped
(-c and -t are exclusive, either of them must be given)
-o, --output=FILENAME result file in Apache Arrow format
--append=FILENAME result Apache Arrow file to be appended
(--output and --append are exclusive. If neither of them
are given, it creates a temporary file.)
Arrow format options:
-s, --segment-size=SIZE size of record batch for each
Connection options:
-h, --host=HOSTNAME database server host
-p, --port=PORT database server port
-u, --user=USERNAME database user name
-w, --no-password never prompt for password
-W, --password force password prompt
Other options:
--dump=FILENAME dump information of arrow file
--progress shows progress of the job
--set=NAME:VALUE config option to set before SQL execution
--help shows this message
Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。
Apache Arrow
Data Files
Arrow_Fdw
Pg2Arrow
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~31
32. 《補足》PostgreSQLデータベースからArrowファイルを生成する
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~32
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()
33. 《補足》PostgreSQLデータベースからArrowファイルを生成する
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~33
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]
37. 大規模構成による検証(3/3)
UPI
879GBx4 = 3.5TBのテストデータを4つのパーティションに分散
CPU2CPU1RAM RAM
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
37
PCIe-SW PCIe-SW
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~
lineorder_p0
(879GB)
lineorder_p1
(879GB)
lineorder_p2
(879GB)
lineorder_p3
(879GB)
lineorder
(---GB)
Hash-Partition (N=4)
38. ベンチマーク結果(1/2)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~38
毎秒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
40. Asymmetric Partition-wise JOIN(1/4)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~40
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
課題:パーティション子テーブルのスキャン結果を先に ”CPUで” 結合
Scan
Scan
Scan
Append
Join
Agg
Query
Results
Scan
大量のレコードを
CPUで処理する羽目に!
41. Asymmetric Partition-wise JOIN(2/4)
postgres=# explain select * from ptable p, t1 where p.a = t1.aid;
QUERY PLAN
----------------------------------------------------------------------------------
Hash Join (cost=2.12..24658.62 rows=49950 width=49)
Hash Cond: (p.a = t1.aid)
-> Append (cost=0.00..20407.00 rows=1000000 width=12)
-> Seq Scan on ptable_p0 p (cost=0.00..5134.63 rows=333263 width=12)
-> Seq Scan on ptable_p1 p_1 (cost=0.00..5137.97 rows=333497 width=12)
-> Seq Scan on ptable_p2 p_2 (cost=0.00..5134.40 rows=333240 width=12)
-> Hash (cost=1.50..1.50 rows=50 width=37)
-> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37)
(8 rows)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~41
42. Asymmetric Partition-wise JOIN(3/4)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~42
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
非パーティション側テーブルとのJOINを各子テーブルへ分配し、
先にJOIN/GROUP BYを実行することでCPUが処理すべき行数を減らす。
Join
Append
Agg
Query
Results
Scan
Scan
PreAgg
Join
Scan
PreAgg
Join
Scan
PreAgg
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
各子テーブル毎に
JOIN/GROUP BY済み。
処理すべき行数は僅か。
※ 本機能はPostgreSQL v13向けに、
開発者コミュニティへ提案中です。
43. Asymmetric Partition-wise JOIN(4/4)
postgres=# set enable_partitionwise_join = on;
SET
postgres=# explain select * from ptable p, t1 where p.a = t1.aid;
QUERY PLAN
----------------------------------------------------------------------------------
Append (cost=2.12..19912.62 rows=49950 width=49)
-> Hash Join (cost=2.12..6552.96 rows=16647 width=49)
Hash Cond: (p.a = t1.aid)
-> Seq Scan on ptable_p0 p (cost=0.00..5134.63 rows=333263 width=12)
-> Hash (cost=1.50..1.50 rows=50 width=37)
-> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37)
-> Hash Join (cost=2.12..6557.29 rows=16658 width=49)
Hash Cond: (p_1.a = t1.aid)
-> Seq Scan on ptable_p1 p_1 (cost=0.00..5137.97 rows=333497 width=12)
-> Hash (cost=1.50..1.50 rows=50 width=37)
-> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37)
-> Hash Join (cost=2.12..6552.62 rows=16645 width=49)
Hash Cond: (p_2.a = t1.aid)
-> Seq Scan on ptable_p2 p_2 (cost=0.00..5134.40 rows=333240 width=12)
-> Hash (cost=1.50..1.50 rows=50 width=37)
-> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37)
(16 rows)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~43
47. PostGISの高速化手法(1/2)- Bounding Box
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~47
▌Bounding Boxとは
複雑な形状のポリゴンを包摂する最も小さな矩形領域
(x1,y1) - (x2,y2) で表現できるのでデータ量が少ない
PostgreSQL / PostGISが geometry 型を保存する時に自動的に生成される。
▌Bounding Boxの効果
空間関係演算を行う前に、『明らかに接していない』ものを識別できる。
➔ 重なりを含むジオメトリのみ判定を行う事で、計算リソースを節約。
明らかに接していない
共通部分を持つ可能性
滋賀県
東京都
岐阜県
48. PostGISの高速化手法(2/2)- GiSTインデックス
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~48
▌GiSTインデックスとは
GiST(Generalized Search Tree)は、ツリー構造を持つインデックスを一般化
したフレームワーク。
PostGISのGeometry型は、GiST上にR木を実装したもの
▌GiSTのR木でできること
包含(@演算子)や重なり(&&演算子)判定で、インデックスを用いた絞込み
特に多数のポリゴン×ポイントの重なり判定で計算量が増大しやすい
➔ 事前の絞り込みで計算量を抑え込む
# 国土地理院の市町村形状データをインポート
$ shp2pgsql N03-20_200101.shp | psql gistest
gistest=# ¥d+
List of relations
Schema | Name | Type | Owner | Size |
--------+-------------+----------+--------+------------+
public | geo_japan | table | kaigai | 243 MB |
gistest=# ¥di+
List of relations
Schema | Name | Type | Owner | Table | Size |
--------+--------------------+-------+--------+-----------+---------+
public | geo_japan_pkey | index | kaigai | geo_japan | 2616 kB |
public | geo_japan_geom_idx | index | kaigai | geo_japan | 14 MB |
49. PG-StromにおけるPostGIS対応(Jul-2020現在)
▌ジオメトリ生成
geometry st_makepoint(float8,float8,...)
2点から Point ジオメトリを生成する
▌空間関係演算
float8 st_distance(geometry,geometry)
2つのジオメトリ間の距離を導出する
bool st_dwithin(geometry,geometry,float8)
ジオメトリが、指定したジオメトリから
指定した距離内にある場合に真を返す。
bool st_contains(geometry,geometry)
ジオメトリ1がジオメトリ2を完全に包含
する場合に真を返す。
bool st_crosses(geometry,geometry)
与えられたジオメトリが共通の内部の点を持ち、
かつそうでない点を持つ場合に真を返す。
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~49
GPUに実装された数千コアの
実行ユニットが、個々の行を
並列に評価する。
50. GiSTインデックスへの対応(1/2)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~50
▌前提
ポリゴン定義の数は、ポイント(GPSデータ等)に比べると数が少ない。
GiST(R木)インデックスはBounding Boxだけを保持するので、ポリゴン定義データ
に比べると、通常は圧倒的にコンパクトなサイズとなる。
➔ GPUメモリに十分載せうるサイズである事が一般的
▌GPUでGiST(R木)インデックスを参照できれば
数十万ポリゴン × 数億ポイントの突合といった規模のワークロードを、
一般的なWHERE句の評価と同程度の負荷で処理できる公算が高い。
現在、技術課題を検討中
ポリゴン×ポイントの突合を圧倒的に高速化する(予定)
WIP
GiST(R木)インデックス
ポリゴン定義
点データを含む
テーブル
数千スレッドが
並列に
インデックスを
探索
51. GiSTインデックスへの対応(2/2)
gistest=# EXPLAIN SELECT gid,count(*) FROM geo_japan j, geopoint p
WHERE n03_001 = '茨城県' and st_dwithin(j.geom, st_makepoint(p.x, p.y), 0.02)
GROUP BY gid;
QUERY PLAN
----------------------------------------------------------------------------------------------------
HashAggregate (cost=572080.29..572082.55 rows=226 width=12)
Group Key: j.gid
-> Custom Scan (GpuPreAgg) (cost=572075.77..572078.60 rows=226 width=12)
Reduction: Local
Combined GpuJoin: enabled
-> Custom Scan (GpuJoin) on geopoint p (cost=71788.46..593630.11 rows=2260026 width=4)
Outer Scan: geopoint p (cost=0.00..163696.15 rows=10000115 width=16)
Depth 1: GpuHashJoin+GiST Index (heap-size: 115.95KB, nrows 10000115...2260026)
IndexFilter: (j.geom && st_expand(st_makepoint(p.x, p.y), '0.02'::double precision)) ¥
on geo_japan_geom_idx (index-size: 13.50MB)
JoinQuals: st_dwithin(j.geom, st_makepoint(p.x, p.y), '0.02'::double precision)
-> Seq Scan on geo_japan j (cost=0.00..8929.24 rows=226 width=2042)
Filter: ((n03_001)::text = '茨城県'::text)
(12 rows)
IndexFilter(depth=1)に注目
st_makepoint(p.x, p.y)の結果をst_expand()で上下左右に 0.02 ずつ
拡張した長方形領域と、j.geomのBoundary Boxに重複があるかをチェック。
➔ この関係性を用いてGiSTインデックス(R木)降下していく。
もし少しでも重なり合う可能性があれば、実際に st_dwithin()を実行して
JoinQualsが成立するかをチェックする。
WIP
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~51
54. 背景と課題
▌GPUとホストメモリは“遠い”
通常、GPUはPCI-Eバスを介してホストシステムと接続する。
PCI-E Gen 3.0 x16レーンだと、片方向 16GB/s 「しかない」
行って帰ってのレイテンシは数十マイクロ秒単位。
DRAMの転送速度は140GB/sでレイテンシは100ns程度。
もしL1/L2に載っていれば数ns単位でアクセス可能
出展:https://gist.github.com/eshelman/343a1c46cb3fba142c1afdcdeec17646
▌高い更新頻度
もし100万デバイスが10秒に一度、
現在位置を更新するなら?
➔ 単純 UPDATE を毎秒10万回実行。
➔ 1.0sec / 10万 = 10us
▌リアルタイム性に対する要請
利用者が検索、解析したいのは、
「その時点での最新の状態」
➔ 後でまとめてバッチ、では通用しない。
GPU
Device
RAM
RAMCPU
900GB/s
140GB/s
16GB/s
PCI-E
Gen3.0
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~54
58. Gstore_Fdw外部テーブルの定義
CREATE FOREIGN TABLE ft (
id int,
x float,
y float,
z text
) server gstore_fdw
options (gpu_device_id '1',
base_file '/opt/pgdata-dev/ft.base',
redo_log_file '/opt/pmem-dev/ft.redo’,
max_num_rows '4000000',
primary_key 'id');
(補足)
base_fileはNVMEストレージ上に配置するのが望ましい。
✓ mmap(2)してバイト単位のランダムアクセスが多発するため、
PMEMの微妙なアクセスの遅さが性能差として見えてしまう。
redo_log_fileはPMEM上に配置するのが望ましい。
✓ トランザクションのコミット時にREDOログを永続化する必要があるため。
追記書き出しのみだが、細かい単位でCPUキャッシュをフラッシュする。
(逆にブロックデバイスのようなfsyncは必要ないが)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~58
59. 更新処理のパフォーマンス(1/2)
--- 200万行を投入
INSERT INTO ft (SELECT x, 100*random(),
100*random(),
md5(x::text)
FROM generate_series(1,2000000) x);
--- 以下のクエリを pgbench で投入
--- (クライアント数:20を想定)
UPDATE ft SET x = 100*random(),
y = 100*random()
WHERE id = (SELECT 20*(100000.0*random())::int + :client_id);
--- 実行計画
EXPLAIN ....;
QUERY PLAN
-------------------------------------------------------------------
Update on ft (cost=0.02..100.03 rows=10000 width=58)
InitPlan 1 (returns $0)
-> Result (cost=0.00..0.02 rows=1 width=4)
-> Foreign Scan on ft (cost=0.00..100.01 rows=10000 width=58)
Filter: (id = $0)
Index Cond: id = $0
(6 rows)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~59
60. 更新処理のパフォーマンス(2/2)
$ pgbench -p 6543 postgres -n -f test.sql -c 20 -j 10 -T 10
transaction type: test.sql
scaling factor: 1
query mode: simple
number of clients: 20
number of threads: 10
duration: 10 s
number of transactions actually processed: 1236401
latency average = 0.162 ms
tps = 123631.393482 (including connections establishing)
tps = 123674.819689 (excluding connections establishing)
(補足)
まだ排他ロックで実装している箇所があり、クライアント数が20を越えた辺りで
サチり始める。
➔ Row-Idの払い出しや、REDOログの書き込み位置などロックレス化できるハズ。
PostgreSQLの通常テーブル(on NVME-SSD):
20クライアント 65k TPS、80クライアント160k TPS程度
通常テーブルと外部テーブルの内部ロジックの違いに起因する差異は未検証
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~60
61. 検索処理のパフォーマンス(1/2)
--- GpuScan (GPU版PostGIS) + Gstore_Fdw
=# SELECT count(*) FROM ft
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90,¥
10 90,10 10))’, st_makepoint(x,y));
count
-------
94440
(1 row)
Time: 75.466 ms
--- 通常版PostGIS + PostgreSQLテーブル
=# SET pg_strom.enabled = off;
SET
=# SELECT count(*) FROM tt
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90,¥
10 90,10 10))', st_makepoint(x,y));
count
-------
94440
(1 row)
Time: 332.300 ms
200万個のPointから、
指定領域内の数をカウント
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~61
62. 検索処理のパフォーマンス(2/2)
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~62
(100,100)
(0,0)
(90,90)
(90,10)
(90,12)(12,12)
(12,88) (90,88)
(10,90)
(10,10)
この領域内に含まれる
点(Point)を抽出した
テーブル ft および tt には
(0,0)~(100,100)の範囲内に
ランダムに 200万個の点を格納
63. 検索+更新処理のパフォーマンス
--- 裏で更新処理を実行
$ pgbench -p 6543 postgres -n -f test.sql -c 15 -T 60
:
duration: 60 s
number of transactions actually processed: 9188638
latency average = 0.098 ms
tps = 153143.595549 (including connections establishing)
tps = 153148.363454 (excluding connections establishing)
--- ヘビーな更新処理中に GPU での集計クエリを実行
=# SELECT count(*) FROM ft
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90, ¥
10 90,10 10))', st_makepoint(x,y));
2020-07-26 17:26:12.283 JST [261916] LOG: gstore_fdw: Log applied (nitems=635787,
length=54396576, pos 750323824 => 787623328)
count
-------
94629
(1 row)
Time: 136.456 ms
ヘビーな更新処理中であっても、若干の処理速度低下で応答
集計処理の開始時点で、GPU側ストアを
最新の状態にリフレッシュするため、
未適用のREDOログを 63.5 万件適用している
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~63
64. 実行環境の一例
GPUメモリストアが前提なら、NVMEは不要でH/W要件が緩い。
➔ メジャークラウドのGPUインスタンスでも実行可能に
WIP
モデル名 p3.2xlarge p3.8xlarge p3.16xlarge NC6s v NC12s v3 NC24s v3
vCPU 8 core 32 core 64 core 6 core 12 core 24 core
RAM 61GB 244GB 488GB 112 GB 224 GB 448 GB
GPU 1 x Tesla V100
(16GB; 5120C)
4 x Tesla V100
(16GB; 5120C)
8 x Tesla V100
(16GB; 5120C)
1 x Tesla V100
(16GB; 5120C)
2 x Tesla V100
(16GB; 5120C)
4 x Tesla V100
(16GB; 5120C)
オンデマンド
料金 4.324USD/h 16.906USD/h 32.682USD/h ¥299.22/h ¥782.91/h ¥711.74/h
※ オンデマンド料金は、各社東京リージョンの本体のみ単価(2020/7/26現在)で記載。
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~64
67. PG-Strom v3.0のリリースに向けて
▌新機能の予定
NVIDIA GPUDirect Storageへの対応
✓ Ubuntu 18.04でのSSD-to-GPU Direct SQLや、
サードパーティによるSDSへの対応も含意
GPU版 PostGIS の提供
GPUメモリストアの提供
CUDA 11/Ampere世代GPUへの対応
PostgreSQL v13への対応
AWS/Azureクラウドでの対応
▌リリース時期
2020年12月頃
OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~67