20180217 FPGA Extreme Computing #10

SSD/GPUがPostgreSQLを加速する。
～ハードウェア限界性能への挑戦～
HeteroDB,Inc
チーフアーキテクト兼代表取締役社長
海外浩平 <kaigai@heterodb.com>

HeteroDB社について
FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)2
▌会社概要
 商号ヘテロDB株式会社
 創業 2017年7月4日
 社員数 2名（海外浩平、柏木岳彦）
 事業内容データ解析アプライアンス製品販売
データベース技術コンサルティングサービス
 拠点品川区西大井1-1-2-206 (西大井創業支援センター内)
▌代表者プロフィール
 海外浩平 (KaiGai Kohei)
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。セキュリティ強化や外部データ連携等の
貢献があり、PostgreSQLのMajor Contributorとして知られている。
 2007年 IPA未踏ソフト事業において “天才プログラマー” 認定
 2012年～ GPUによるPostgreSQL高速化モジュールの開発を開始
 2017年 NECを退職し、柏木と共に HeteroDB 社を創業

【期間限定】自己紹介
カーリングやってます。

最近の話題：まさかの日経デビュー

我々のミッション
+
GPUを用いたSQL処理の高速化製品の提供
GPU
PG-Strom

データ解析基盤としての用途
 バッチ／レポーティング
 ビジネスインテリジェンス
 異常検知／ログ解析
 統計解析／機械学習
etc...
RDBMSとしての本質的な機能
 SQLパース／クエリ最適化
 トランザクション
 バックアップ／可用性
 レプリケーション
 スケールアウト
 周辺ツールとの接続
etc...
PG-Stromとは？ (1/2)
一部処理のオフロード
PG-Strom: GPUの持つ数千並列コアと広帯域メモリを活用して
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
自前で何もかも揃えるのではなく、
PostgreSQL本体機能・周辺機能を
必要に応じてチョイスする。

PostgreSQLの共通インフラ
PG-Stromとは？ (2/2)
SQL Parser
Query
Optimizer
Query
Executor
Storage
PG-Strom
CustomScan
Interface
Database Applications
Storage
Manager
Transaction
Manager
Parallel
Workers
【I/O中心ワークロードの高速化】
 SSD-to-GPUダイレクトSQL実行
 インメモリ列指向キャッシュ
 JOIN+GROUP BY Combined kernel
【基本機能】
• SQL to GPUプログラムジェネレータ
• GPUコード実行時コンパイラ
• GPUカーネルの非同期並列実行
【計算中心ワークロードの高速化】
 PL/CUDA ユーザ定義関数
 gstore_fdw – onGPUデータストア
 In-DB 機械学習ライブラリ
v2.0
v2.0

PostgreSQL/PG-Stromは
どのようにクエリを実行するか

PostgreSQLの内部構造
SQL Parser
Query Optimizer
Query Executor
Storage
Manager
Transaction
Manager
IPC
(Lock, Latch,
shmem)
SQLクエリ
パース木
クエリ実行計画
クエリ
実行結果  SQL構文を分解し、取り扱いやすい
内部データ形式（パース木）に変換
 文法エラーの検出
 統計情報を元にコスト値を算出
 最も合理的と予想される実行計画を
作成する。
 クエリ実行計画に基づいて、
ScanやJoin、Sortなどを実行する。
 PostgreSQL内部のインフラを使用

PostgreSQLはどのように実行計画を作るか (1/2)
Scan
t0 Scan
t1
Scan
t2
Join
t0,t1
Join
(t0,t1),t2
GROUP
BY cat
ORDER
BY score
LIMIT
100

PostgreSQLはどのように実行計画を作るか (2/2)
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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価

CustomScanによる介入
同じ結果を返しさえすれば、手段は問わない。
CustomScan (GpuJoin)
(*BeginCustomScan)(...)
(*ExecCustomScan)(...)
(*EndCustomScan)(...)
:
SeqScan
on t0
SeqScan
on t1
GroupAgg
key: cat
ExecInitGpuJoin(...)
 GPUコンテキストの初期化
 自動生成したGPUプログラムの
実行時コンパイル開始
ExecGpuJoin(...)
 配下のt0,t1からデータを読み出し、
DMAバッファにセット
 GPUへ非同期タスクをキック
 実行が完了した非同期タスクを
取り出し、結果をGroupAggへ渡す。
ExecEndGpuJoin(...)
 非同期タスクの終了待ち（あれば）
 GPUリソースの解放

PG-Strom基本機能(1/2) – SQLからGPUコードを自動生成
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
Compiler
(nvrtc)
Just-in-time
Compile
Parallel
Execution
v1.0

PG-Strom基本機能(2/2) – 非同期・並列実行
非同期DMA転送
GPUメモリ
GPU搭載の数千コアによる
並列実行
処理済みのブロックは開放
GPUへのデータ転送と、GPUでのSQL処理をパイプライン化する事で
PCIeバスのデータ転送速度の “遅さ” を隠ぺい。
 同時に、GPU RAMサイズ以上のデータを効率的に処理する事が可能に。
約64MBのブロック毎に転送
平均10万～30万行を含む
GPU上のバッファに余裕がある限り、
先行ブロックの処理完了を待たず、
次々にデータを送り込む。
v1.0

実際にユーザ様の課題をヒアリングしてみると・・・。
I/O
(ストレージ)
計算
(CPU)
『大量データの処理で困ってるんです・・・』
 実際にはCPU以上にI/O問題である事もしばしば

果たして I/O のボトルネックを PG-Strom で解消できるのか？

SSD-to-GPUダイレクトSQL実行
～GPUの役割を再定義する～

SSD-to-GPUダイレクトSQL実行とは
PCIe Bus
NVMe SSD GPU
SSD-to-GPU P2P DMA
(NVMe-Stromドライバ)
WHERE句
JOIN
GROUP BY
Large PostgreSQL
Tables
PostgreSQL
データブロック
SSD-to-GPUダイレクトSQL
SSDから転送したレコードを、
GPUの数千コアを用いて
SQLワークロードを実行。
CPUがロード/処理すべきデータ
量を削減し、I/Oを高速化。
従来のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
SELECT cat, count(*), avg(X)
FROM t0 JOIN t1 ON t0.id = t1.id
WHERE YMD >= 20120701
GROUP BY cat;
SQL最適化ステージ
SQL実行ステージ
SQL-to-GPU
プログラム
ジェネレータ
GPUコード
実行時
コンパイル
SQLからGPUプログラムを
自動的に生成し、実行時
コンパイルを行う
ストレージからデータをロードする“前に” GPUでデータ量を減らす。
GPUコード生成
SQLから自動的にGPU
コードを生成するため、
利用者からは透過的に
GPUを使用するように
見える。
GPUでのSQL実行
PostgreSQLのデータ
ブロックを、直接
SSDからGPUへ転送。
SQLワークロードを
GPU上で並列実行する
事で、不要なデータを
ふるい落とす。
CPUでのSQL実行
GPUで前処理済みの
データを処理するため、
本来のデータ量よりも
遥かに小さな負荷を
処理するだけで済む。
v2.0

要素技術① GPUDirect RDMA (1/2)
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
 元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
 Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015

要素技術① GPUDirect RDMA (2/2)
物理アドレス空間
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

要素技術② NVMe-SSD
Intel SSD
750 Series
Intel SSD
DC P4600
Samsung
PM1725
HGST
Ultrastar SN260
Seagate
Nytro 5910
Interface PCIe 3.0 x4 PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16
Capacity 400GB, 800GB,
1.2TB
2.0TB, 4.0TB 3.2TB, 6.4TB 1.6TB, 3.2TB,
6.4TB
7.7TB
Form Factor HHHL HHHL HHHL HHHL FHHL
Max SeqRead 2.5GB/s 3.2GB/s 6.0GB/s 6.1GB/s 8.0GB/s
Max SeqWrite 1.2GB/s 1.9GB/s 2.0GB/s 2.2GB/s 4.7GB/s
Rand Read 460K IOPS 617K IOPS 1000K IOPS 1200K IOPS 975K IOPS
Rand Write 290K IOPS 225K IOPS 120K IOPS 200K IOPS 130K IOPS
Warranty 5years 5years 5years 5years 5 years
MTBF 1.2M hours 1.0M hours 2.0M hours 2.0M hours 2.0M hours
Target consumer enterprise / data-center
高速SSDの本命として、NVMe規格に対応した製品が各社からリリース

ベンチマーク (1/3) – SSBMベンチマーク環境
■ クエリ例
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
1200万件
(1.6GB)
date1
2500件
(400KB)
part
180万件
(206MB)
supplier
400万件
(528MB)
lineorder
24億件
(351GB)
典型的な Star Schema に JOIN, GROUP BY を含む集計クエリを実行
v2.0
読出し: 2.2GB/s
Intel SSD 750
3840コア搭載
NVIDIA Tesla P40
測定環境
Chassis Supermicro 5018GR-T
CPU Xeon E5-2650v4 (2.2GHz, 12C) x1
RAM 128GB (16GB DDR4-2133 x 8)
GPU NVIDIA Tesla P40 (3840C, 24GB) x1
SSD Intel SSD 750 (HHHL; 400GB) x3
OS
Red Hat Enterprise Linux 7.4
CUDA 9.0 + Latest driver
DB PostgreSQL v9.6 + PG-Strom 2.0devel

ベンチマーク (2/3) – SSBMによるスループット計測
▌典型的なバッチ・レポーティング処理を模した Star Schema Benchmark にて計測
 PostgreSQLの処理速度は 2.1GB/s 程度で頭打ち（SSDを3枚束ねた場合）
 SSD-to-GPUダイレクトSQL実行を用いるPG-Stromの場合、ハードウェア限界に近い
6.2GB/s 近くまで処理性能を引き出せている。
 従来はDWH専用機や小規模クラスタを用いていた水準の能力を１台のマシンで。
SSD x2枚構成の
理論限界値 [4.4GB/s]
SSD x3枚構成の
理論限界値 [6.6GB/s]
v2.0

〈参考〉GTC2017でSSD-to-GPU機能の発表がTop-5に選出
世界中から集まったGPU関連R&Dの
ポスター発表全138件のうち、
最も評価の高い5件の一つとして選出。
（来場者投票では惜しくも次点…）
GPU Technology Conference 2017
8th~ 11th May, San Jose

〈補足〉ハードウェア構成に関する考慮事項
▌課題
① CPUのP2P DMAルーティング性能
② マルチGPU環境への適用
① PCIeスイッチを介して
SSDとGPUが接続の場合
OK
② CPUがPCIeバスを管理し、
SSDにGPU直接接続の場合
Workable
③ SSDとGPUが互いに異なる
CPUに接続の場合
Not Supported
CPU CPU
PLX
SSD GPU
PCIeスイッチ
CPU CPU
SSD GPU
CPU CPU
SSD GPU
QPI
SSDとGPUのペアは、同一CPUまたはPLXの配下に接続されている必要がある

BroadwellとSkylakeでP2P DMA性能に差はあるか。
NVMe-SSD
Intel DC P4600 (2.0TB) x3
(md-raid0構成)
NVIDIA
Tesla V100
(5120C, 16GB)
CPU
Intel Xeon Gold 6126T
(12C, 2.6GHz)
測定用に新しいサーバを買っちゃった！

ベンチマーク (3/3) – Skylake + Volta GPUによる計測
▌Raw-I/O性能で8.5GB/s、SQL応答時間ベースで7.5GB/sのスループット
 Broadwellの7.2GB/sという限界値は突破してくれた
▌疑問）標準PostgreSQLの性能値がやたら落ちているのでは？
0
1000
2000
3000
4000
5000
6000
7000
8000
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 (on SkyLake + Volta)
PgSQL v10 PG-Strom v2.0

余談）Spectre/Meltdown対策パッチの影響？？
0
200
400
600
800
1000
1200
1400
1600
1800
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 / with PostgreSQL 10
kernel-3.10.0-693.el7.x86_64 (対策前) kernel-3.10.0-693.11.6.el7.x86_64 (対策済)
▌全般的に10-15%程度のデグレードがあるが、
2.2GB/s  1.4GB/sを説明できるほど顕著な差ではない。
▌現時点ではまだ納得のいく答えが得られていない。Any Ideas?

マルチGPU環境への対応に向けて (1/2)
▌～PostgreSQL v10までの課題
 ある一時点においては、常に特定の１テーブルだけがスキャンの対象
 SSD-to-GPUダイレクトSQL実行を使うには、SSDに近傍のGPUを選択しなければならない。
 複数GPU搭載でも、スキャン中のテーブルを保存するSSDに近傍のGPUだけがアクティブ
となり、リソース有効活用の面で課題があった。
PostgreSQL v10までは、パーティション子テーブルの並列スキャンに非対応
t1
t2
t3
t4
Append
～PostgreSQL v10
t1
t2
t3
t4
Append
PostgreSQL v11以降
※個々の子テーブルの
スキャンが並列化
される事はあるパーティション配下の子テーブル
全てを並列にスキャン

マルチGPU環境への対応に向けて (2/2)
 ワーカーの並列化に伴い、GPU1/GPU2を同時に利用する事が可能に
 マルチGPU環境においても、計算機資源を有効に活用できることに。
Append
ワーカーの起動時に対象SSDの近傍GPUを選択し、複数GPUを同時利用可能に
t1 t2 t4t3
GPU1 GPU2
BgWorker BgWorker BgWorker BgWorker
CPU並列処理用の
ワーカープロセス
テーブル t1 を保存する
SSDと同一のCPUに接続
されているGPU1を選択
PCIe接続トポロジーに
基づく自動チューニング

ハードウェア限界を越える
～インテリジェントストレージ構想～

更なる性能向上を目指すには
▌方針① SSDから読み出すデータ量を減らす
▌方針② CPUにP2P DMAを仲介させない
NVMe
SSD GPU
CPU
PCIeバス
P2P DMA Packet
ルーティング性能の
限界
NVMe-SSD読出し
速度での律速
実はGPUには
処理能力に
余裕がある

OLTPの世界 OLAPの世界
インテリジェント・ストレージ構想(1/3) – SSD上の行⇒列変換
SSD上でRow-to-Column変換を行い、Rowで書いてColumnで読む
R/C
変換
ロジック
列データ
解析系データ
読出し
（列形式）
業務データ
書込み
（行データ）
データ形式変換
FPGA等による
H/W実装
SQLクエリ処理
GPU本来の計算能力を
引き出す列データ形式
集計済み、
JOIN済み
データ
列抽出において
必要なデータだけ
取出し

インテリジェント・ストレージ構想(2/3) – SSD上の行⇒列変換
カスタムロジックを搭載可能な NVMe-SSD 製品が
容易に入手可能になりつつある。
Nallatech社
250Sシリーズ
NGD Systems社
Catalina 2 NVMe PCIe SSD
SSD上のロジックは単純で汎用性の高いデータ形式変換に特化
集積度の高いGPUでは、処理内容が都度変化するSQLを“超”並列実行
PostgreSQLデータブロック
カスタムロジック
PageHeader ItemPointers
Record-01Record-02
Record-03Record-04Record-05
Record-06Record-07
Record-08Record-09
列A
列D
列F

《補足》なぜGPUには列指向のデータが向いているか
▌行データ形式 – 不連続なデータアクセス (random memory access)
 メモリトランザクションの回数が増え、データバスの使用率が低下
▌列データ形式 – 隣接領域に対するデータアクセス (coalesced memory access)
 最小限のメモリトランザクション回数、データバスの使用率を最大化
32bit
Memory transaction width: 256bit
32bit 32bit32bit 32bit 32bit
32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit
Memory transaction width: 256bit
256bit幅のメモリトランザクション
中、
32bit x 8 = 256bitが有効なデータ
（バス使用率 100.0%）
256bit幅のメモリトランザクション中、
32bit x 1 = 32bitのみ有効なデータ
（バス使用率 12.5%）
GPUコア
GPUコア
GPUの能力をフルに引き出すには、適切なデータ形式の選択が必要

SCAN + JOIN + GROUP BY 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
v2.0
PostgreSQLは集計クエリを何ステップかに分解して実行する。
データ受け渡し
データ受け渡し

集約演算まで一気にGPU側で行ってしまう事で、
ロードすべきデータ量を極端に削減する事ができる。
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Agg
(PostgreSQL)
GPU
CPU
Storage
実行
結果
GpuScan + GpuJoin + GpuPreAgg Combined Kernel
data size
= large
data size
= small
v2.0
Data
Blocks

10GBのデータをスキャンして、
最終的にCPU側へ書き戻されたのは 1.2kB のみ。
v2.0

〈参考〉PCIe拡張I/Oボックス製品
世の中には PCIe バスを引き延ばして外部I/O拡張Boxに接続する製品がある。
• 直接GPUを装着するのに比べて
省スペース。
• （製品によっては）I/O拡張Boxの
内部でP2P DMAを完結できる。

トランザクション制御
（シングルノード）
インテリジェント・ストレージ構想(3/3) – エッジ側SQL実行
外部PCIe拡張ユニットを用いてSSD/GPUペアを拡張し、
ハードウェア限界を超えたスループットを実現する。
アップリンク・データフロー
PCIe拡張Box内部でのSQL前処理により、
相対的にI/Oサイズは小さくなる。
もはやホストシステム自身の
バス幅は律速要因ではなくなる。エッジ・データフロー
最大限のスループットで
SSDからGPUへデータを
読み出し、SQL前処理で
データ量を削減するadopter
adopter
adopter
トランザクション制御の世界大量データ処理の世界
必要に応じて
ユニットの
増設も可能
PostgreSQLから見ると、単に大量のGPUとSSDを
搭載しただけのシングルノード構成。
複雑な分散トランザクションを使用する必要が
ないため、運用をシンプル化できる。
PCIe拡張ユニット内で完結するP2P DMAのトラフィックがアップリンク側に
漏れなければ、スペック及びGPUの処理能力からみて、一台あたり10GB/sの
処理性能は十分に実現可能。
データサイズの増加に伴い、PCIe拡張ユニットを増設する事で対応できる。
PCIe
Switch
PCIe
Switch
PCIe
Switch

まとめ
▌PG-Stromとは？
 GPUを使ってSQL集計・解析ワークロードを高速化する拡張モジュール
 GPUプログラムの自動生成、非同期・並列実行
▌GPUでI/Oが早くなるワケないじゃん！？
 P2P DMAを使ってSSD上のデータブロックを直接GPUに転送
データをロードすれば、SQL処理の実行は元々やっている事
SCAN/JOIN/GROUP BYを前処理する事で、データ量を大幅に削減
 I/OネックのStar Schema Benchmarkで、処理スループット 7.5GB/s を達成
少し前のDWH専用機に匹敵する性能を1Uラックサーバで実現
▌ハードウェアの限界を越える
 ロジック付きSSD上で、行形式⇒列形式へ変換しデータ量を削減。
 PCIe 拡張I/O Boxを使用して、本体に負荷をかけず ”ノード内分散処理”
いずれのケースでも、ユーザ／アプリ視点からは単純な
シングルノードのPostgreSQLに見える。分散トランザクション等不要。

20180217 FPGA Extreme Computing #10

20180217 FPGA Extreme Computing #10

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20180217 FPGA Extreme Computing #10

Similaire à 20180217 FPGA Extreme Computing #10 (20)

Plus de Kohei KaiGai

Plus de Kohei KaiGai (15)

20180217 FPGA Extreme Computing #10