20200828_OSCKyoto_Online

GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界
～PG-Stromで作るデータ処理基盤～
HeteroDB,Inc
Chief Architect & CEO
KaiGai Kohei <kaigai@heterodb.com>

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を受賞

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

PG-Stromとは？
【機能】
 集計／解析ワークロードの透過的な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

ログ収集デーモン：
ターゲット：IoT/M2Mログの集計・解析処理
Manufacturing Logistics Mobile Home electronics
なぜPostgreSQLか？
 DBMSとしての十分な基本機能（例：トランザクションなど）
 豊富な周辺ソフトウェアや拡張モジュールが存在する
 エンジニアが慣れ親しんだ技術で、運用ノウハウの蓄積が豊富
JBoF: Just Bunch of Flash
NVME-over-Fabric
(RDMA)
DB管理者
BIツール（可視化）
機械学習アプリケーション
（E.g, 異常検知など）
共通データ
フレーム PG-Strom

IoT/M2MデータのライフサイクルとPG-Stromの機能
時系列データ
（数TB～）
前処理済みデータ
リアルタイムデータ
ETL・
前処理
課題：
大容量データの保存・読出し
課題：
高頻度な更新と高速な解析処理の両立
Apache Arrow対応
（Arrow_Fdw）
SSD-to-GPU
Direct SQL
BRIN-Index
GPU Memory Store
（Gstore_Fdw）
RuntimeGPUCodeGeneration
PostGIS/JSONBdatasupport
PG-Strom機能群
データ量：大
データ量：小
AsymmetricPartition-wiseJOIN
PG-Strom
共通機能
PG-Strom
ストレージ機能

PG-Strom共通機能
～PostgreSQLのクエリ実行メカニズムとの融合～

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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価

SQLからGPUコードを自動生成（WHERE句の例）
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

実行計画を確認する
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)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
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)
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)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
どういう事か？

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%’
実行結果
GpuScan
GpuJoin
Agg
+
GpuPreAgg
SeqScan
HashJoin
Agg

GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Host
Buffer
GPU
CPU
Storage
単純にロジックを置き換えるだけでは、CPU<->GPU間で
データ転送のピンポンが発生してしまう。
Host
Buffer
Host
Buffer
実行結果
Host
Buffer
Agg
(PostgreSQL)

GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Host
Buffer
GPU
CPU
Storage
GPU上でデータ交換を行い、無用なDMAを発行しないようにする。
GPU
Buffer
GPU
Buffer 実行結果
Host
Buffer
Agg
(PostgreSQL)
SCAN + JOIN + GROUP BYを実行するGPUカーネル
data size
= large
data size
= small
通常、GPUから書き戻されるデータサイズは、
GPUへ転送するデータサイズよりもずっと小さい。

PG-Strom ストレージ機能①
SSD-to-GPU Direct SQL

一般的な x86_64 サーバの構成
GPUSSD
CPU
RAM
HDD
N/W

大量データを処理する時のデータの流れ
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
通常のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
一度CPU/RAMへロードしなければ、
“ゴミデータ” であってもその要否を判断できない。

SSD-to-GPUダイレクトSQL（1/4）
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
NVIDIA GPUDirect RDMA
CPU/RAMを介することなく、
Peer-to-PeerのDMAを用いて
SSD上のデータブロックを直接
GPUに転送する機能。
WHERE句
JOIN
GROUP BY
GPUでSQLを処理し、
データ量を削減する
データ量：小

SSD-to-GPUダイレクトSQL（2/4）－ソフトウェアスタック
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にも対応

SSD-to-GPUダイレクトSQL（3/4）– システム構成とワークロード
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

SSD-to-GPUダイレクトSQL（4/4）– ベンチマーク結果
 クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])
 SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録
 CPU+Filesystemベースの構成と比べて約3倍強の高速化
➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現
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)

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製品)
サードパーティなし

PG-Strom ストレージ機能②
Apache Arrow対応

背景① データはどこで生成されるのか？
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
DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に！
Data
Import
Import!

背景② PostgreSQLのデータ構造は結構無駄が多い
8kB
HeapTuple
Table Segment Block
HeapTupleHeader nullmap 列A 列B 列D 列E
Tuple
SELECT B FROM this_table WHERE E like ‘%hoge%’;
要る？

Apache Arrowとは（1/2）
▌特徴
 列指向で分析用途向けに設計されたデータ形式
 アプリケーションによらず、共通のデータ交換形式として利用可能
 整数、実数、日付時刻、文字列など基本的なデータ型を定義
NVIDIA GPU
PostgreSQL / PG-Strom

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の間で変換可能

FDW (Foreign Data Wrapper)
 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

SSD-to-GPU Direct SQL on Arrow_Fdw（1/3）
▌なぜ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

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）
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

《補足》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

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()

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]

マルチGPU+NVME-SSDでI/O性能の限界に挑む
～大規模構成によるベンチマーク～

～100TB程度の
ログデータを
シングルノードで
処理可能に
４ユニットの並列動作で、
100～120GB/sの
実効データ処理能力
列データ構造により
ユニット毎25～30GB/sの
実効データ転送性能
大規模構成による検証（1/3）
QPI
SSD-to-GPU Direct SQL、Arrow_Fdw、マルチGPU処理の全てを投入
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
GPU+4xSSDユニット
あたり8.0～10GB/sの
物理データ転送性能
35
PCIe-SW PCIe-SW
JBOF unit-0 JBOF unit-1
OSC.Kyoto Online ～GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界～

HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台による環境を構築

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)

ベンチマーク結果（1/2）
毎秒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

ベンチマーク結果（2/2）
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)

Asymmetric Partition-wise JOIN（1/4）
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で処理する羽目に！

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)
-> Hash (cost=1.50..1.50 rows=50 width=37)
(8 rows)

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向けに、
開発者コミュニティへ提案中です。

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 Cond: (p_1.a = t1.aid)
Hash Cond: (p_2.a = t1.aid)
(16 rows)

PG-Strom最新機能①
～PostGIS対応による地理情報分析～

PostGISって？（1/2）
▌概要
 点（Point）、線（LineString）、多角形（Polygon）等のジオメトリ要素、
およびそれらの間の演算を PostgreSQL で実行するための拡張モジュール
 演算の例 … 包含（Contains）、交差（Crosses）、接合（Touch）など
 GiSTインデックスに対応して高速な検索を実現
 2005年に PostGIS 1.0 がリリース。以降、15年にわたって継続的開発。
© GAIA RESOURCES
地理情報マスタセンサーデータ
位置情報（座標）を
含むデータを大量に生成
都道府県・市区町村などを単位とするデータの集計や絞り込み
【IoT/M2Mデータに対しての想定利用シーン】

PostGISって？（2/2）- Geometry型と空間関係演算の例
St_Distance(a,b)
ジオメトリ間の距離
St_Crosses(a,b)
ジオメトリの交差判定
St_Contains(a,b)
ジオメトリの包含判定

PostGISの高速化手法（1/2）- Bounding Box
▌Bounding Boxとは
 複雑な形状のポリゴンを包摂する最も小さな矩形領域
 (x1,y1) - (x2,y2) で表現できるのでデータ量が少ない
 PostgreSQL / PostGISが geometry 型を保存する時に自動的に生成される。
▌Bounding Boxの効果
 空間関係演算を行う前に、『明らかに接していない』ものを識別できる。
➔ 重なりを含むジオメトリのみ判定を行う事で、計算リソースを節約。
明らかに接していない
共通部分を持つ可能性
滋賀県
東京都
岐阜県

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)
ジオメトリ１がジオメトリ２を完全に包含
する場合に真を返す。
 bool st_crosses(geometry,geometry)
与えられたジオメトリが共通の内部の点を持ち、
かつそうでない点を持つ場合に真を返す。
GPUに実装された数千コアの
実行ユニットが、個々の行を
並列に評価する。

GiSTインデックスへの対応（1/2）
▌前提
 ポリゴン定義の数は、ポイント（GPSデータ等）に比べると数が少ない。
 GiST(R木)インデックスはBounding Boxだけを保持するので、ポリゴン定義データ
に比べると、通常は圧倒的にコンパクトなサイズとなる。
➔ GPUメモリに十分載せうるサイズである事が一般的
▌GPUでGiST(R木)インデックスを参照できれば
 数十万ポリゴン × 数億ポイントの突合といった規模のワークロードを、
一般的なWHERE句の評価と同程度の負荷で処理できる公算が高い。
 現在、技術課題を検討中
ポリゴン×ポイントの突合を圧倒的に高速化する（予定）
WIP
GiST(R木)インデックス
ポリゴン定義
点データを含む
テーブル
数千スレッドが
並列に
インデックスを
探索

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

PG-Strom最新機能②
～GPUメモリストアによるリアルタイム分析～

IoT/M2MデータのライフサイクルとPG-Stromの機能
時系列データ
（数TB～）
前処理済みデータ
リアルタイムデータ
ETL・
前処理
課題：
大容量データの保存・読出し
課題：
高頻度な更新と高速な解析処理の両立
Apache Arrow対応
（Arrow_Fdw）
SSD-to-GPU
Direct SQL
BRIN-Index
GPU Memory Store
（Gstore_Fdw）
RuntimeGPUCodeGeneration
PostGIS/JSONBdatasupport
PG-Strom機能群
データ量：大
データ量：小
AsymmetricPartition-wiseJOIN
PG-Strom
共通機能
PG-Strom
ストレージ機能
最新の位置情報だけなら、
（時系列で持たなければ）
意外とデータ量は小さい。

背景と課題
▌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

Gstore_Fdwアーキテクチャ
REDOログを利用してGPUメモリ側を非同期に更新する。
検索クエリの実行前に更新を適用すれば辻褄は合う！
Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL Backend
（OLTP系）
PostgreSQL Backend
（OLTP系）
PostgreSQL Backend
（OLTP系）
INSERT
UPDATE
DELETE
ログ追記
更新系処理では
一切GPUにタッチしない

Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
BG-Worker
（GPUバッファ管理）
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
数千スレッドで動作
ほぼ一瞬で適用できる
②GPUカーネルの起動

Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
Backend
（解析系SQL）
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
SQL処理の前に REDO ログを
適用すれば、辻褄はあう
（一貫性が保たれる）
GPU Kernel
to execute
SQL
②GPUカーネルの起動

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は必要ないが）

更新処理のパフォーマンス（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)

更新処理のパフォーマンス（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程度
 通常テーブルと外部テーブルの内部ロジックの違いに起因する差異は未検証

検索処理のパフォーマンス（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から、
指定領域内の数をカウント

検索処理のパフォーマンス（2/2）
(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万個の点を格納

検索＋更新処理のパフォーマンス
--- 裏で更新処理を実行
$ 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 万件適用している

実行環境の一例
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現在）で記載。

まとめ

まとめ
▌PG-StromはGPUを用いてSQLを高速化する拡張モジュールです。
が、GPUの並列処理性能を引き出すには、GPUにデータを供給する
ストレージ機能を適切に設定する必要があります。
▌データサイズが非常に大きい場合
 SSD-to-GPU Direct SQL機能
▌データが静的である／他の処理系からインポートする場合
 Apache Arrow対応（Arrow_Fdw機能）
▌データサイズが十分に小さい場合
 GPUメモリストア機能
▌地理情報データの分析を行う場合
 GPU版PostGIS機能
 GPU版GiSTインデックス（R木）機能

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月頃

20200828_OSCKyoto_Online

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20200828_OSCKyoto_Online

Similaire à 20200828_OSCKyoto_Online (20)

Plus de Kohei KaiGai

Plus de Kohei KaiGai (17)

Dernier

Dernier (9)

20200828_OSCKyoto_Online