20210731_OSC_Kyoto_PGStrom3.0

“爆速！”を実現する
PG-Strom v3.0の新機能
HeteroDB,Inc
Chief Architect & CEO
海外浩平 <kaigai@heterodb.com>

自己紹介／HeteroDB社について
OSC/Kyoto Online 2021 - “爆速！”を実現する PG-Strom v3.0の新機能
2
会社概要
 商号ヘテロDB株式会社
 創業 2017年7月4日
 拠点品川区北品川5-5-15
大崎ブライトコア4F
 事業内容高速データベース製品の販売
GPU＆DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
 海外浩平（KaiGai Kohei）
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
 IPA未踏ソフト事業において“天才プログラマー”認定 (2006)
 GPU Technology Conference Japan 2017でInception Awardを受賞

PG-Stromとは？
3
【機能】
 集計／検索ワークロードの透過的なGPU高速化
 GPU-Direct SQLによるI/Oの高速化。ほぼH/W理論値でデータを読み出し。
 Apache Arrow対応によるデータ交換、インポート時間をほぼゼロに。
 PostGIS関数のサポート（一部）。位置情報分析を高速化。
 GPUメモリにデータを常駐。OLTPワークロードとの共存。
PG-Strom: GPUとNVMEの能力を最大限に引き出し、
TB級のデータを高速処理するPostgreSQL向け拡張モジュール
App
GPU
off-loading
➢ GPU-code generator on the fly
➢ GPU-Direct SQL
➢ NVME-oF/NFSoRDMA support
➢ Columnar Store (Arrow_Fdw)
➢ Arrow min/max statistics
➢ GPU Memory Cache
➢ Asymmetric Partition-wise
JOIN/GROUP BY
➢ BRIN-Index Support
➢ PostGIS Support
➢ Pg2Arrow / MySQL2Arrow
NEW
NEW
UPDATE
UPDATE
時系列データ
リアルタイムデータ
GPUDirect
Storage

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

PG-Stromのターゲット： IoT/M2Mログデータ処理
Manufacturing Home electronics Logistics Mobile
DB Admin
BI Tools
(Visualization)
GPU-Direct SQL
PG-Strom v3.0
AI/ML Applications
(Anomaly detections, ...)
時系列の大量ログデータ
WHERE
JOIN
GROUP BY
PostGIS
JSONB
GPU
Cache
位置情報を含む
✓ GPUによる数千並列でのSQL実行
✓ GPU-Direct SQLで、NVMEデバイスの
理論限界速度で処理を実行
✓ GPU版PostGISによる
地理情報分析のサポート
✓ Apache Arrow形式を介した、
インポートなしでのデータ交換
✓ 使い慣れた PostgreSQL で
GPUを意識することなく
透過的にSQLを高速化
5

PG-Strom v3.0をリリースしました
6

本日のトピック
1. NVIDIA GPUDirect Storageへの対応
2. GPU-Direct SQLとNFS-over-RDMAの併用
3. Apache Arrow版BRIN-Index対応
PG-Strom v3.0新機能が、どう大量ログデータ処理を”爆速化”するか
7

① NVIDIA GPUDirect Storageへの対応
8

背景：SSD-to-GPUダイレクトSQL（1/2）
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
NVME-Strom
CPU/RAMを介することなく、
Peer-to-PeerのDMAを用いて
SSD上のデータブロックを直接
GPUに転送するLinux kernel module
WHERE句
JOIN
GROUP BY
GPUでSQLを処理し、
データ量を削減する
データ量：小
9

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

NVIDIA GPUDirect Storageとは？
 6/29にリリースされた CUDA Toolkit 11.4 の新機能
 NVMEデバイスから、GPUへの直接のデータ転送が可能
 データ転送のパフォーマンスは、ほぼほぼ NVME-Strom と同等
 NVME-oFデバイスや、NFS-over-RDMAにも対応
 OSの対応は、RHEL8.3～、Ubuntu 18.04/20.04
出典）https://developer.nvidia.com/gpudirect-storage
11

NVME-Strom と NVIDIA GPUDirect Storage を比較
NVME-Strom GPUDirect Storage
提供元 HeteroDB NVIDIA
公開日 5th-Sep-2016 29th-Jun-2021
対応OS RHEL7.x, RHEL8.x RHEL8.3～、Ubuntu 18.04/20.04
対応FS Ext4 Ext4, NFS, 商用の分散FS
PCI-E NVME-SSD 〇 (INBOX + Patch) 〇 (MOFED + Patch)
NVME-over-Fabric 実験的対応〇 (MOFED + Patch)
RAID Support md-raid (RAID0) md-raid (RAID0)
その他デバイス－ SDS(Software Defined Storage)、
ロジック搭載SSDなど
その他制約 I/Oサイズは PAGE_SIZE の倍数のみ O_DIRECT必須
PG-Stromでの対応 v2.0～ v3.0～
パフォーマンスほぼ同じ（デバイスの SeqRead 性能による）
RHEL7.x以外では NVIDIA GPUDirect Storage を推奨
※ MOFED = Mellanox Open Fabric Enterprise Driver
12

GPU-Direct SQLの性能測定
クエリ実行中の読み出し速度は、理論値に近い10.0GB/s
0
2,000
4,000
6,000
8,000
10,000
0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380
Total
Storage
Read
Throughput
[MB/sec]
Elapsed Time [sec]
Total Storage Read Throughput
during Query Execution [Q1_1]
Query Execution
with GPUDirect Storage
Query Execution with PostgreSQL Heap Storage
nvme1
nvme2
nvme3
nvme4
nvme1
nvme2
nvme3
nvme4
 測定に用いたIntel DC P4510のカタログスペックは SeqRead: 2750MB/s
➔ 4本で理論速度 11.0GB/s に対し、クエリ実行中の読み出し速度 10.0GB/s を達成。
（ファイルシステムだと高々3.8GB/s程度）
13

GPUDirect Storage対応とシステム構成
3rd-Party
Solutions
Local NVME-SSD
NVME-over-Fabric
(NVME-oF)
Software Defined
Storages (SDS)
HeteroDB
NVME-
Strom
PostgreSQL
heap
Apache
Arrow
WHERE-clause
GPU-Join
GPU Group-By
NFS-over-RDMA
従来は、GPUとNVME-SSDを
同一筐体に収めるのが、
H/W選定上の大きな制約
NVIDIA
GPUDirect Storage
高速ネットワーク (100Gb) 経由の
分散ストレージにも対応する
↓
H/W選定の自由と、
拡張性を両立できる。
価格的には少し…。
14

② GPU-Direct SQLとNFS-over-RDMAの併用
15

NFS-over-RDMAを試す（1/5）
RAM
NFSサーバ
DBサーバ（NFSクライアント）
RDMA対応NIC※
※ Mellanox社製 Connect X5シリーズなど
RDMA対応NIC※
RoCE (RDMA-over-Converged Ethernet)
NFSサーバ
DB/GPUサーバ
（NFSクライアント）
RDMA対応NIC※ RDMA対応NIC※
RoCE (RDMA-over-Converged Ethernet)
GPU上のデバイスメモリに、
NICを介してリモートから
直接のデータ転送
16

SYS-4029GP-TRT
SYS-1019GP-TT
100G-NIC
100G-NIC
GPU1
(A100)
CPU0
GPU0
(A100)
NVME
HCA
CPU0
PCIE-SW PCIE-SW
CPU1
開発用PC端末
192.168.80.106/24
192.168.80.108/24
オフィスLAN)
192.168.77.0/24
PCI-ENC8G-08A
(U.2 NVME-SSD x8)
Mellanox
connect-X5
Mellanox
connect-X5
NVME
HCA
NFSサーバ
DB/GPUサーバ
（NFSクライアント）
17

NFSサーバ側の設定
# modprobe svcrdma
# modinfo svcrdma
filename: /lib/modules/4.18.0-240.22.1.el8_3.x86_64/extra/mlnx-nfsrdma/svcrdma.ko
:
# echo rdma 20049 > /proc/fs/nfsd/portlist
# cat /proc/fs/nfsd/portlist
rdma 20049
rdma 20049
tcp 2049
tcp 2049
NFSクライアント側の設定
# modprobe rpcrdma
# modinfo rpcrdma
filename: /lib/modules/4.18.0-240.22.1.el8_3.x86_64/extra/mlnx-nfsrdma/rpcrdma.ko
:
# grep nvfs_ops /proc/kallsyms
ffffffffc319ddc8 b nvfs_ops [rpcrdma]
ffffffffc0c256c0 b nvfs_ops [nvme_rdma]
ffffffffc00dc718 b nvfs_ops [nvme]
# mount -o rdma,port=20049 192.168.80.106:/mnt/nfsroot /opt/nvme1
# dd if=/opt/nvme1/100GB of=/dev/null iflag=direct bs=32M
3106+1 records in
3106+1 records out
104230305696 bytes (104 GB, 97 GiB) copied, 11.8926 s, 8.8 GB/s
MOFEDドライバ版を使用
MOFEDドライバ版を使用
※但し、自分で再ビルドしないと
GPUDirect Storage対応機能が有効になっていない
nvidia-fsモジュールとの連携が有効になっている。
rdmaオプションをつけてNFSマウント
NFS-over-RDMAあり： 8.8GB/s
NFS-over-RDMAなし： 3.2GB/s
18

 SF=500 (DB: 453GB) の Star Schema Benchmark データに対してクエリを実行
 スループット = 453.6GB / (クエリ応答時間)
➔ ローカルのNVME-SSDには劣るものの、最大で 8.2GB/s 程度の処理レートを達成
（ただし、NFSサーバ側のH/Wが原因で律速している可能性はある。
Skylake-SPの場合、P2P-DMAが8.5GB/s程度で頭打ちになっていた。）
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
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
Query
Execution
Throughput
[MB/s]
SSBM Query Execution Throughput with GPUDirect SQL
(Local NVME vs NFS over RDMA)
PG-Strom v3.0 [PCI-E NVME] PG-Strom v3.0 [NFSoRDMA]
19

 Star Schema Benchmark実行中のI/O帯域を計測（iostat, nfsstat使用）
 Local NVME-SSD実行時に謎の速度変化があるが、概ねクエリの
実行スループットと同等のデータ読み出し速度
➔ 性能10%ダウン程度で、共有ファイルシステムが使えるなら十分アリでは？
0
2000
4000
6000
8000
10000
0 20 40 60 80 100
Storage
Read
Throughput
[MB/s]
Elapsed Time [sec]
Storage Read throughput under GPUDirect SQL
(Local NVME vs NFS-over-RDMA)
20

GPU-Direct SQL と NFS-over-RDMAで何が嬉しくなるか？
Manufacturing Home electronics Mobile & Vehicles
DB Admin
BI Tools
(Visualization)
GPU-Direct SQL
PG-Strom v3.0
AI/ML Applications
WHERE
JOIN
GROUP BY
PostGIS
JSONB
超高速ストレージ読み出し
GPU-Direct SQL + NFS-over-RDMA
ログの収集
NFS共有フォルダに Arrow ファイルを
放り込めば、即、分析に回せる
GPUによる検索/集計処理
WHERE句、JOIN、GROUP BYを
数千コアの並列実行で処理
プレゼンテーション層
リアルタイムデータに対する
処理結果をビジュアライズ
わざわざＤＢにインポート
したり、クラウドに
アップロードの必要がない。
21

③ Apache Arrow版 BRIN-Index対応
22

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

ログデータ処理に Apache Arrow を使うメリット
① 列データなので、クエリで参照された列だけをロードすればよい
➔ I/Oの量が減り、それに伴いクエリ応答時間が短くなる。
② ＤＢへデータをインポートする必要がない
➔ OS上でファイルコピーすれば、それで準備完了。
21.13 20.54 20.43 18.88 18.65 18.30 16.08 20.70 19.36 20.00 19.05 19.73 19.35
64.98 64.88 65.39 63.48 58.08 64.28 58.16 60.27 58.32 62.36 58.30 58.86 58.24
587.16
463.37 467.69
324.90
198.93
328.96
192.64
245.48 247.13
228.83
164.63 173.41 163.08
0.0
100.0
200.0
300.0
400.0
500.0
600.0
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
Number
of
rows
processed
per
second
[million
rows/sec]
Star Schema Benchmark
(SF=999 [875GB], 1xTesla A100 (PCI-E; 40GB), 4xDC P4510(1.0TB; U.2)
PostgreSQL v13.3 [Heap; row-data] PG-Strom v3.0 [Heap; row-data] PG-Strom v3.0 [Apache Arrow; column-data]
24

Apache Arrowが不得意なワークロード
Footer
Apache Arrow File
RecordBatch-2
RecordBatch-N
RecordBatch-1
Schema column-1 null-bitmap
column-1 values-array
column-3 null-bitmap
column-3 offset-array
column-3 extra buffer
固定長データ列（NULL可）
非NULL・固定長データ列
可変長データ列
非NULL・固定長データ列
① 更新・削除を伴うデータには向かない
② 特定の１行を抽出する事には不向き
➔ 基本、全件スキャンになるのだが、、、実は…。
RecordBatch-2が50万行とすると、
50万個の固定長データの配列と、
同じ長さのNULL-bitmap
INSERT-Onlyのデータを
バルクで書き込み続けるタイプの
ワークロードに向いたデータ構造
（IoT/M2Mログデータが典型）
25

関連機能：PostgreSQL BRINインデックス
26
▌BRIN ... Block Range Index
 一定範囲のブロック(8KB x 128個)で、対象列の最大値／最小値を記録するインデックス
 検索条件にマッチしない事が明らかなブロックを読み飛ばす事ができる。
➔ RAM/SSD～GPU間のデータ転送量／処理すべきレコード数を削減する事ができる。
時系列データ
データの発生した時刻順にレコードがINSERTされるため、
タイムスタンプが近いレコードは、物理的に近しい位置に
格納されるという特徴を持つ。
BRIN インデックス
条件句：
WHERE ymd BETWEEN ‘2016-01-01’
AND ‘2016-12-31’
False
True
True
True
False
min: ‘2015-01-01’
max: ‘2015-09-30’
min: ‘2015-10-01’
max: ‘2016-03-15’
min: ‘2016-03-15’
max: ‘2016-07-31’
min: ‘2016-08-01’
max: ‘2017-02-01’
min: ‘2017-02-01’
max: ‘2017-05-15’
必要最小限のデータだけをGPUに転送
タイムスタンプ
+αの条件句を並列に評価する。

Apache Arrowファイルに統計情報を埋め込む（1/2）
Apache Arrow File
Header “ARROW1¥0¥0”
Schema Definition
RecordBatch-1
RecordBatch-k
Footer
• Schema Definition (copy)
• RecordBatch[0] (offset, size)
:
• RecordBatch[k] (offset, size)
• Terminator “ARROW1”
RecordBatch-0
ArrowSchema
_num_fields = 3
ArrowField
name = “device_id”
type=Uint32
ArrowField
name = “attribute”
type=Float64
ArrowField
name = “ts”
type=TimeStamp
custom_metadata[]
ArrowKeyValue
key = “min_values”
value=“…”
ArrowKeyValue
key = “max_values”
value=“…”
 Apache Arrowデータ形式は、
Schema（表に相当）とField（列に相当）に
カスタムの Key-Value 値を埋め込む事を許容する。
➔ 標準のデータ形式に一切手を加えることなく、
Record-Batch毎の最小値/最大値を記録する事ができる。
27

Apache Arrowファイルに統計情報を埋め込む（2/2）
統計情報付き Apache Arrow ファイルの生成
$ pg2arrow -d postgres -o /dev/shm/flineorder_sort.arrow ¥
-t lineorder_sort --stat=lo_orderdate --progress
RecordBatch[0]: offset=1640 length=268437080 (meta=920, body=268436160) nitems=1303085
:
RecordBatch[9]: offset=2415935360 length=55668888 (meta=920, body=55667968) nitems=270231
$ ls -lh /dev/shm/flineorder_sort.arrow
-rw-r--r--. 1 kaigai users 2.4G 7月 19 10:45 /dev/shm/flineorder_sort.arrow
生成された統計情報の確認
$ python3
>>> import pyarrow as pa
>>> X = pa.RecordBatchFileReader('/dev/shm/flineorder_sort.arrow')
>>> X.schema
lo_orderkey: decimal(30, 8)
:
lo_suppkey: decimal(30, 8)
lo_orderdate: int32
-- field metadata --
min_values: '19920101,19920919,19930608,19940223,19941111,19950730,1996' + 31
max_values: '19920919,19930608,19940223,19941111,19950730,19960417,1997' + 31
lo_orderpriority: fixed_size_binary[15]
:
lo_shipmode: fixed_size_binary[10]
-- schema metadata --
sql_command: 'SELECT * FROM lineorder_sort'
RecordBatch ごと、最小値/最大値を埋め込み
28

統計情報を利用したクエリの最適化（1/3）
Arrowのスキーマ定義を利用したArrow_Fdw外部テーブルの定義
postgres=# IMPORT FOREIGN SCHEMA flineorder_sort
FROM SERVER arrow_fdw INTO public
OPTIONS (file '/dev/shm/flineorder_sort.arrow');
IMPORT FOREIGN SCHEMA
Arrowのmin/max statisticsを利用した問合せ例
postgres=# EXPLAIN ANALYZE
SELECT count(*) FROM flineorder_sort
WHERE lo_orderpriority = '2-HIGH'
AND lo_orderdate BETWEEN 19940101 AND 19940630;
QUERY PLAN
------------------------------------------------------------------------------------------
Aggregate (cost=33143.09..33143.10 rows=1 width=8) (actual time=115.591..115.593 rows=1loops=1)
-> Custom Scan (GpuPreAgg) on flineorder_sort (cost=33139.52..33142.07 rows=204 width=8)
(actual time=115.580..115.585 rows=1 loops=1)
Reduction: NoGroup
Outer Scan: flineorder_sort (cost=4000.00..33139.42 rows=300 width=0)
(actual time=10.682..21.555 rows=2606170 loops=1)
Outer Scan Filter: ((lo_orderdate >= 19940101) AND
(lo_orderdate <= 19940630) AND (lo_orderpriority = '2-HIGH'::bpchar))
Rows Removed by Outer Scan Filter: 2425885
referenced: lo_orderdate, lo_orderpriority
Stats-Hint: (lo_orderdate >= 19940101), (lo_orderdate <= 19940630) [loaded: 2, skipped: 8]
files0: /dev/shm/flineorder_sort.arrow (read: 217.52MB, size: 2357.11MB)
Planning Time: 0.210 ms
Execution Time: 153.508 ms
(11 rows)
29

列方向だけでなく、行方向での絞り込みと同義
Full Table Scan of Row-Data
(PostgreSQL Heap)
Full Table Scan of Column-Data
(Arrow_Fdw; no Stats-Hint)
Full Table Scan of Column-Data
with Min/Max Stats Hint
Only referenced
columns
ts BETWEEN ‘2021-04-01’
AND ‘2021-06-30’
30

 ログデータの“タイムスタンプ“に統計情報を付加するのがお勧め。
 Pg2Arrowだけでなく、他のツールが生成した Arrow ファイルに、
後付けで統計情報を埋め込むためのツールを準備中。
列／行双方の絞り込みで、上手くハマれば強烈に速くなる
254.905
99.587
10.052
1.191
0
50
100
150
200
250
300
Query
Response
Time
[sec]
(shorter
is
better)
Query response time of SSBM Q1_2 [mod]
PostgreSQL v13.3 PG-Strom v3.1dev [Row-Data]
PG-Strom v3.1dev [Apache Arrow; No Stats Hint] PG-Strom v3.1dev [Apache Arrow; with Stats Hint]
select sum(lo_extendedprice*lo_discount) as revenue
from flineorder_sort, date1
where lo_orderdate = d_datekey
and d_yearmonthnum = 199401
and lo_discount between 4 and 6
and lo_quantity between 26 and 35;
select sum(lo_extendedprice*lo_discount) as revenue
from flineorder_sort, date1
where lo_orderdate = d_datekey
and d_yearmonthnum = 199401
and lo_discount between 4 and 6
and lo_quantity between 26 and 35;
and lo_orderdate between 19940101 and 19940131;
GPU-Direct SQLの効果
Apache Arrowの効果
min/max statisticsの効果
31

まとめ
32

PG-Stromのターゲット： IoT/M2Mログデータ処理
Manufacturing Home electronics Logistics Mobile
DB Admin
BI Tools
(Visualization)
GPU-Direct SQL
PG-Strom v3.0
AI/ML Applications
WHERE
JOIN
GROUP BY
PostGIS
JSONB
GPU
Cache
位置情報を含む
 GPU-Direct SQL
ストレージの性能を最大限に引き出し、
さらに、NVME-oFやNFS-over-RDMAなど、
GPUとストレージを分離する事で更に
使いやすく。
 NFS-over-RDMAサポート
NVIDIA GPUDirect Storageの対応により、
多様なストレージデバイスを、
ログデータ分析のソースとして利用
できるように。
 Arrowの統計情報サポート
「タイムスタンプ」という
ログデータの特性を活かした
検索範囲の絞り込み。
33

おまけ
34

各種リソース
▌ソフトウェア
 GitHub: https://github.com/heterodb/pg-strom
 Document: http://heterodb.github.io/pg-strom/ja/
 Packages: https://github.com/heterodb/swdc
▌問合せ先
 e-mail: contact@heterodb.com （お仕事の相談など）
 twitter: @kkaigai （気軽な質問など）
35

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

20210731_OSC_Kyoto_PGStrom3.0

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20210731_OSC_Kyoto_PGStrom3.0

Similaire à 20210731_OSC_Kyoto_PGStrom3.0 (20)

Plus de Kohei KaiGai

Plus de Kohei KaiGai (16)

Dernier

Dernier (9)

20210731_OSC_Kyoto_PGStrom3.0