Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

725 views

Published on

PGconf.ASIA 2018発表資料
ビッグデータ処理のためのGPUとNVME-SSD活用
~クエリ処理速度10GB/sへの挑戦~

Published in: Technology
  • Be the first to comment

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

  1. 1. ビッグデータ処理のためのGPUとNVME-SSD活用 ~クエリ処理速度10GB/sへの挑戦~ HeteroDB,Inc Chief Architect & CEO 海外 浩平 <kaigai@heterodb.com>
  2. 2. テーマ:どのようにしてこのベンチマーク結果を実現したのか ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20182 ベンチマーク条件  シングルノード環境でのPostgreSQL v11beta3とPG-Strom v2.1develによる結果。  1.05TBのデータベースに対して13種類のStar Schema Benchmark クエリを実行。 ➔全件スキャンを含む集計系クエリを80秒弱で実行 ≒ 13.5GB/s 0 2,000 4,000 6,000 8,000 10,000 12,000 14,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 for PostgreSQL 11beta3 + PG-Strom v2.1devel PG-Strom v2.1devel max 13.5GB/sのクエリ処理速度をシングルノードで実現
  3. 3. HeteroDB社について ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20183 会社概要  商号 ヘテロDB株式会社  創業 2017年7月4日  拠点 品川区西大井1-1-2-201  事業内容 高速データベース製品の販売 GPU&DB領域の技術コンサルティング ヘテロジニアスコンピューティング技術を データベース領域に適用し、 誰もが使いやすく、安価で高速なデータ解析基盤を提供する。 代表者プロフィール  海外 浩平(KaiGai Kohei)  OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの 開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ プストリームへの貢献。  2007年 IPA未踏ソフト事業において“天才プログラマー”認定  2017年 GPU Technology ConferenceのTop-5 Posters Finalistに
  4. 4. RDBに求められる諸機能 ✓ 可用性/クラスタリング ✓ バックアップ/運用管理 ✓ トランザクション ✓ BI・可視化 ➔ PostgreSQLのものをAs-Isで利用 中核技術 – PG-Strom PG-Strom: GPUの持つ数百~数千コアと広帯域メモリを利用して、 SQLワークロードを高速化するPostgreSQL向け拡張モジュール GPU 大量データの集計・解析 機械学習・統計解析 PG-Strom ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20184 大量のデータを高速に ストレージから読み出す
  5. 5. GPUとはどんなプロセッサなのか? ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20185 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA Tesla V100 スーパーコンピュータ (東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習 “計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか? シミュレーション
  6. 6. ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20186 PostgreSQLはどうGPUを活用するのか? ~PG-Stromのアーキテクチャ~
  7. 7. PostgreSQL  PG-Strom間の相互作用 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20187 SQL Parser Query Optimizer Query Executor Storage Manager Database Files GPU Path constructor GPU Code generator GPU JIT compiler (NVRTC) GpuScan GpuJoin GpuPreAgg PL/CUDA nvme-strom Gstore_fdw CustomScanインターフェース (PgSQL v9.5~) PG-Strom
  8. 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列 複数の処理アルゴリズムを競わせ、“コスト値”で評価 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20188
  9. 9. 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リソースの解放 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20189
  10. 10. SQLからGPUコードを自動生成(WHERE句の例) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201810 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 コンパイラ Parallel Execution
  11. 11. 実行計画を確認する ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201811 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) どういう事か?
  12. 12. 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%’ 実行結果 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201812 GpuScan GpuJoin Agg + GpuPreAgg SeqScan HashJoin Agg
  13. 13. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/3) GpuScan kernel GpuJoin kernel GpuPreAgg kernel DMA Buffer GPU CPU Storage 単純にロジックを置き換えるだけでは、CPU<->GPU間で データ転送のピンポンが発生してしまう。 DMA Buffer DMA Buffer 実行結果 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201813 DMA Buffer Agg (PostgreSQL)
  14. 14. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/3) GpuScan kernel GpuJoin kernel GpuPreAgg kernel DMA Buffer GPU CPU Storage GPU上でデータ交換を行い、無用なDMAを発行しないようにする。 GPU Buffer GPU Buffer 実行結果 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201814 DMA Buffer Agg (PostgreSQL) SCAN + JOIN + GROUP BYを実行するGPUカーネル data size = large data size = small 通常、GPUから書き戻されるデータサイズは、 GPUへ転送するデータサイズよりもずっと小さい。
  15. 15. 実行計画を確認する(再掲) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201815 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) Combined GPU kernel で処理する部分
  16. 16. ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201816 GPUの役割を再定義する ~どのようにI/Oを高速化するのか~
  17. 17. 一般的な x86_64 サーバの構成 GPUSSD CPU RAM HDD N/W ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201817
  18. 18. 大量データを処理する時のデータの流れ CPU RAM SSD GPU PCIe PostgreSQL データブロック 通常のデータフロー 本来は不要なレコードであっても、 一度CPU/RAMへロードしなければ 要・不要を判断できないため、 データサイズは大きくなりがち。 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201818 一度CPU/RAMへロードしなければ、 “ゴミデータ” であってもその要否を判断できない。
  19. 19. 中核機能:SSD-to-GPUダイレクトSQL CPU RAM SSD GPU PCIe PostgreSQL データブロック NVIDIA GPUDirect RDMA CPU/RAMを介することなく、 Peer-to-PeerのDMAを用いて SSD上のデータブロックを直接 GPUに転送する機能。 WHERE句 JOIN GROUP BY GPUでSQLを処理し、 データ量を削減する データ量:小 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201819 v2.0
  20. 20. 要素技術 GPUDirect RDMA (1/2) ▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能  元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術  Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能 Copyright (c) NVIDIA corporation, 2015 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201820
  21. 21. 要素技術 GPUDirect RDMA (2/2) 物理アドレス空間 PCIe BAR1領域 GPU デバイス メモリ RAM NVMe-SSD Infiniband HBA PCIe デバイス GPUDirect RDMA GPUデバイスメモリを 物理アドレス空間に マップする機能 『GPUデバイスメモリの物理アドレス』が 存在すれば、PCIeデバイスとのDMAで、 Source/Destinationアドレスとして指定できる。 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201821 0xf0000000 0xe0000000 DMA要求 SRC: 1200th sector LEN: 40 sectors DST: 0xe0200000
  22. 22. ベンチマーク結果(シングルノード) NVME and GPU accelerates PostgreSQL beyond the limitation -PGconf.EU 2018-22 2172.3 2159.6 2158.9 2086.0 2127.2 2104.3 1920.3 2023.4 2101.1 2126.9 1900.0 1960.3 2072.1 6149.4 6279.3 6282.5 5985.6 6055.3 6152.5 5479.3 6051.2 6061.5 6074.2 5813.7 5871.8 5800.1 0 1000 2000 3000 4000 5000 6000 7000 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 QueryProcessingThroughput[MB/sec] Star Schema Benchmark on NVMe-SSD + md-raid0 PgSQL9.6(SSDx3) PGStrom2.0(SSDx3) H/W Spec (3xSSD) SSD-to-GPU Direct SQLでハードウェアの限界に近いSQL処理速度を実現  DBサイズ 353GB (sf: 401) の Star Schema Benchmark を用いてクエリ処理時間を計測  CPU: Intel Xeon E5-2650v4, RAM: 128GB, GPU: NVIDIA Tesla P40, SSD: Intel 750 (400GB; SeqRead 2.2GB/s)x3  NVME-SSDの理論限界は 2.2GB/s x 3 = 6.6GB/s。SQL処理スループットもそれに近い 6.2GB/s まで出ている。
  23. 23. SSD-to-GPU Direct SQL - ソフトウェアスタック ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201823 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-SSDのセクタ番号変換 NVMEoF Target (JBOF) NVMe Request ■ その他のソフトウェア コンポーネント ■ PG-Stromプロジェクトの 開発したソフトウェア ■ ハードウェア NVME over Fabric nvme_strom v2.0 で NVME-over-Fabric (RDMA) に対応
  24. 24. uninitialized File BLK-100: unknown BLK-101: unknown BLK-102: unknown BLK-103: unknown BLK-104: unknown BLK-105: unknown BLK-106: unknown BLK-107: unknown BLK-108: unknown BLK-109: unknown (参考)PostgreSQL / Linux kernelディスクバッファとの一貫性 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201824 BLK-100: uncached BLK-101: cached by PG BLK-102: uncached BLK-103: uncached BLK-104: cached by OS BLK-105: cached by PG BLK-106: uncached BLK-107: uncached BLK-108: cached by OS BLK-109: uncached BLCKSZ (=8KB) Transfer Size Per Request BLCKSZ * NChunks BLK-108: cached by OS BLK-104: cached by OS BLK-105: cached by PG BLK-101: cached by PG BLK-100: uncached BLK-102: uncached BLK-103: uncached BLK-106: uncached BLK-107: uncached BLK-109: uncached unused SSD-to-GPU P2P DMA Userspace DMA Buffer (RAM) Device Memory (GPU) CUDA API (userspace) cuMemcpyHtoDAsync ① PG-Strom がPostgreSQLの shared buffer をチェックする ✓ 対象ブロックが既にPostgreSQLによって shared buffer にロードされていた場合 ✓ 対象ブロックがall-visibleでない可能性がある場合(visibility-mapによる検査) ② NVME-StromがOSの page cache をチェックする ✓ 対象ブロックが既にLinux kernelによって page cache 上にロードされていた場合 ✓ 但し、fast-SSD modeであり当該 page cache が dirty である場合を除く ③ その他のブロックに対しSSD-to-GPU P2P DMAを実行 BLK-108: cached by OS BLK-104: cached by OS BLK-105: cached by PG BLK-101: cached by PG
  25. 25. 適用例:ログ集積・解析システム ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201825 GPU+NVME-SSD搭載 データベースサーバ SQLによる検索 セキュリティ事故 被害状況把握 影響範囲特定 責任者への報告 • 高速なトライ&エラー • 使い慣れたインターフェース • 行データのままで高速な検索 従来システム40分の クエリを30秒で実行 Aug 12 18:01:01 saba systemd: Started Session 21060 of user root.
  26. 26. Run faster, beyond the limitation
  27. 27. アプローチ① – より高速なNVME-SSDを使ってみる(1/2) Intel DC P4600 (2.0TB, HHHL) SeqRead: 3200MB/s, SeqWrite: 1575MB/s RandRead: 610k IOPS, RandWrite: 196k IOPS Interface: PCIe 3.0 (x4) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201827
  28. 28. アプローチ① – より高速なNVME-SSDを使ってみる(2/2) Broadwell-EP世代のCPUでは、P2P DMAのルーティング性能7.1GB/sで頭打ち ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201828
  29. 29. アプローチ② – より新しいCPUを使ってみる(1/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201829 Supermicro 1019GP-TT CPU: Xeon Gold 6126T (2.6GHz, 12C) RAM: 192GB (32GB DDR4-2666 x6) GPU: NVIDIA Tesla P40 (3840C, 24GB) x1 SSD: Intel SSD DC P4600 (2.0TB, HHHL) x3 HDD: 2.0TB (SATA, 72krpm) x6 N/W: 10Gb ethernet x2ports
  30. 30. アプローチ② – より新しいCPUを使ってみる(2/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201830 Skylake-SP世代のCPUで、P2P DMAのルーティング性能8.5GB/sまで改善 GPU SSD-1 SSD-2 SSD-3 md-raid0 Xeon Gold 6126T routing by CPU
  31. 31. ハードウェア構成に関する考慮事項(1/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201831 ① 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の配下に接続されている必要がある。 CPUよりはPCIeスイッチ経由の方が望ましい。 https://docs.nvidia.com/cuda/gpudirect-rdma/index.html#supported-systems
  32. 32. ハードウェア構成に関する考慮事項(2/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201832 PCIe-switchがI/Oをバイパスする事でCPUの負荷を軽減できる。 CPU CPU PLX SSD GPU PLX SSD GPU PLX SSD GPU PLX SSD GPU SCAN SCAN SCAN SCAN JOIN JOIN JOIN JOIN GROUP BY GROUP BY GROUP BY GROUP BY 非常に少ないボリュームのデータ GATHER GATHER
  33. 33. PCIeスイッチ付ハードウェア(1/2)- HPC向けサーバ ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201833 Supermicro SYS-4029TRT2 x96 lane PCIe switch x96 lane PCIe switch CPU2 CPU1 QPI Gen3 x16 Gen3 x16 for each slot Gen3 x16 for each slot Gen3 x16 マルチノードMPI向けに最適化されたハードウェアが売られている
  34. 34. PCIeスイッチ付ハードウェア(2/2)- I/O拡張ボックス ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201834 NEC ExpEther 40G (4slots) 4 slots of PCIe Gen3 x8 PCIe Swich 40Gb Ethernet ネットワーク スイッチ CPU NIC 追加のI/O boxes 必要性能・容量に応じてハードウェアを柔軟に増設できる
  35. 35. ハードウェア構成に関する考慮事項(3/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201835 Most of the SQL workloads are executed inside of the I/O box CPU CPU PLX SSD GPU PLX SSD GPU PLX SSD GPU PLX SSD GPU SCAN SCAN SCAN SCAN JOIN JOIN JOIN JOIN GROUP BY GROUP BY GROUP BY GROUP BY GATHER GATHER I/O BoxI/O BoxI/O BoxI/O Box
  36. 36. ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201836 I/O拡張ボックスによる ストレージパスの最適化
  37. 37. I/O拡張ボックスによるシステム構成 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201837 PCIe I/O Expansion Box Host System (x86_64 server) NVMe SSD PostgreSQL Tables PostgreSQL Data Blocks Internal PCIe Switch SSD-to-GPU P2P DMA (Large data size) GPU WHERE-clause JOIN GROUP BY PCIe over Ethernet Pre-processed small data Boxあたり 数GB/sの SQL実行性能 Boxあたり 数GB/sの SQL実行性能 Boxあたり 数GB/sの SQL実行性能 NIC / HBA シングルノードのPostgreSQLなので、 DB運用・アプリ開発が容易 性能・容量の段階的増強 PostgreSQL上ではパーティション化された子テーブルとして管理 v2.1
  38. 38. ハードウェアを意識したパーティション構成 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201838 lineorder lineorder_p0 lineorder_p1 lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 PostgreSQL v11新機能:Hash Partitioningによるデータ分散 key INSERT ハッシュ化 hash = f(key) hash % 3 = 2 hash % 3 = 0 元データ 1053GB 部分データ 351GB 部分データ 351GB 部分データ 351GB v2.1
  39. 39. Partition-wise GpuJoin/GpuPreAgg(1/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201839 lineorder lineorder_p0 lineorder_p1 lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 PostgreSQL v11新機能:各パーティション子テーブルのスキャンを並列実行 Scan Scan Scan Gather Join Agg クエリ結果 Scan レコード数が多いと 結合処理が大変 v2.1
  40. 40. Partition-wise GpuJoin/GpuPreAgg(2/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201840 lineorder lineorder_p0 lineorder_p1 lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 JOIN / GROUP BYまで終わってから、処理結果を統合したい Join Gather Agg クエリ結果 Scan Scan PreAgg Join Scan PreAgg Join Scan PreAgg v2.1
  41. 41. Partition-wise GpuJoin/GpuPreAgg(3/3) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201841 ssbm =# EXPLAIN SELECT sum(lo_extendedprice*lo_discount) as revenue FROM lineorder,date1 WHERE lo_orderdate = d_datekey AND d_year = 1993 AND lo_discount between 1 and 3 AND lo_quantity < 25; QUERY PLAN ------------------------------------------------------------------------------ Aggregate -> Gather Workers Planned: 9 -> Parallel Append -> Parallel Custom Scan (GpuPreAgg) Reduction: NoGroup Combined GpuJoin: enabled GPU Preference: GPU2 (Tesla P40) -> Parallel Custom Scan (GpuJoin) on lineorder_p2 Outer Scan: lineorder_p2 Outer Scan Filter: ((lo_discount >= '1'::numeric) AND (lo_discount <= '3'::numeric) AND (lo_quantity < '25'::numeric)) Depth 1: GpuHashJoin (nrows 102760469...45490403) HashKeys: lineorder_p2.lo_orderdate JoinQuals: (lineorder_p2.lo_orderdate = date1.d_datekey) KDS-Hash (size: 66.03KB) GPU Preference: GPU2 (Tesla P40) NVMe-Strom: enabled -> Seq Scan on date1 Filter: (d_year = 1993) -> Parallel Custom Scan (GpuPreAgg) Reduction: NoGroup Combined GpuJoin: enabled GPU Preference: GPU1 (Tesla P40) : I/O拡張ボックス2で実行できる部分 v2.1
  42. 42. SSD~GPU間の距離(1/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201842 lineorder lineorder_p0 lineorder_p1 lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 あるSSD上のテーブルをスキャンする時は、同一筐体内のGPUを使うべき Good Not Good v2.1
  43. 43. SSD~GPU間の距離(2/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201843 $ pg_ctl restart : LOG: - PCIe[0000:80] LOG: - PCIe(0000:80:02.0) LOG: - PCIe(0000:83:00.0) LOG: - PCIe(0000:84:00.0) LOG: - PCIe(0000:85:00.0) nvme0 (INTEL SSDPEDKE020T7) LOG: - PCIe(0000:84:01.0) LOG: - PCIe(0000:86:00.0) GPU0 (Tesla P40) LOG: - PCIe(0000:84:02.0) LOG: - PCIe(0000:87:00.0) nvme1 (INTEL SSDPEDKE020T7) LOG: - PCIe(0000:80:03.0) LOG: - PCIe(0000:c0:00.0) LOG: - PCIe(0000:c1:00.0) LOG: - PCIe(0000:c2:00.0) nvme2 (INTEL SSDPEDKE020T7) LOG: - PCIe(0000:c1:01.0) LOG: - PCIe(0000:c3:00.0) GPU1 (Tesla P40) LOG: - PCIe(0000:c1:02.0) LOG: - PCIe(0000:c4:00.0) nvme3 (INTEL SSDPEDKE020T7) LOG: - PCIe(0000:80:03.2) LOG: - PCIe(0000:e0:00.0) LOG: - PCIe(0000:e1:00.0) LOG: - PCIe(0000:e2:00.0) nvme4 (INTEL SSDPEDKE020T7) LOG: - PCIe(0000:e1:01.0) LOG: - PCIe(0000:e3:00.0) GPU2 (Tesla P40) LOG: - PCIe(0000:e1:02.0) LOG: - PCIe(0000:e4:00.0) nvme5 (INTEL SSDPEDKE020T7) LOG: GPU<->SSD Distance Matrix LOG: GPU0 GPU1 GPU2 LOG: nvme0 ( 3) 7 7 LOG: nvme5 7 7 ( 3) LOG: nvme4 7 7 ( 3) LOG: nvme2 7 ( 3) 7 LOG: nvme1 ( 3) 7 7 LOG: nvme3 7 ( 3) 7 PCIeデバイス間の距離に基づいて、 最適なGPUを自動的に選択する v2.1
  44. 44. ベンチマーク(1/3)– システム構成 HeteroDB Products Brief (1H-2019 edition)44 NEC Express5800/R120g-2m CPU: Intel Xeon E5-2603 v4 (6C, 1.7GHz) RAM: 64GB OS: Red Hat Enterprise Linux 7 (kernel: 3.10.0-862.9.1.el7.x86_64) CUDA-9.2.148 + driver 396.44 DB: PostgreSQL 11beta3 + PG-Strom v2.1devel lineorder_a (351GB) lineorder_b (351GB) lineorder_c (351GB) NEC ExpEther (40Gb; 4slots版) I/F: PCIe 3.0 x8 (x16幅) x4スロット + internal PCIe switch N/W: 40Gb-ethernet NVIDIA Tesla P40 # of cores: 3840 (1.3GHz) Device RAM: 24GB (347GB/s, GDDR5) CC: 6.1 (Pascal, GP104) I/F: PCIe 3.0 x16 Intel DC P4600 (2.0TB; HHHL) SeqRead: 3200MB/s SeqWrite: 1575MB/s RandRead: 610k IOPS RandWrite: 196k IOPS I/F: PCIe 3.0 x4 v2.1 SPECIAL THANKS FOR
  45. 45. ベンチマーク(2/3) – 測定結果 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201845  I/O拡張ボックス毎に351GB、計1055GBのデータベースを構築し、13種類のSSBMクエリを実行  SQL実行を伴わない SSD→Host への Raw-I/O データ転送は 9GB/s 弱が限界。 つまり、Raw-I/Oのストレージ読出しよりも、SQLを高速に実行てきている。 2,388 2,477 2,493 2,502 2,739 2,831 1,865 2,268 2,442 2,418 1,789 1,848 2,202 13,401 13,534 13,536 13,330 12,696 12,965 12,533 11,498 12,312 12,419 12,414 12,622 12,594 0 2,000 4,000 6,000 8,000 10,000 12,000 14,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 for PgSQL v11beta3 / PG-Strom v2.1devel on NEC ExpEther x3 PostgreSQL v11beta3 PG-Strom v2.1devel Raw-I/O限界値 I/O拡張ボックス3台構成で、max 13.5GB/s のクエリ処理速度を実現! v2.1
  46. 46. ベンチマーク(3/3) – 測定結果 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201846 0 2000 4000 6000 8000 10000 12000 14000 16000 nvme0n1 nvme1n1 nvme2n1 nvme3n1 nvme4n1 nvme5n1 各I/O拡張ボックスに均等にI/O負荷が分散しており、更なるスケールが期待できる  SQL実行中のRaw-I/O性能は、I/O拡張ボックスあたり5000~5100MB/s、NVME-SSDあたり 2600MB/s 程度。  I/O拡張ボックス間で負荷が偏っていないため、機材を増設した時の性能スケールが期待できる。 ➔ 8枚搭載時の予想性能は 4.5GB/s x8 = 36GB/s前後で、DWH専用機に匹敵する性能をPostgreSQLで実現可能。 v2.1
  47. 47. ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201847 13.5GB/s 3x I/O拡張ボックス 30GB/s(予想) 8x I/O拡張ボックス シングルノードのPostgreSQLで、DWH専用機や小規模クラスタ並み処理性能
  48. 48. 想定利用シーン – M2Mログデータ処理・解析 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201848 増え続けるログデータの管理、集計から解析・機械学習まで対応したデータ管理基盤 Manufacturing Logistics Mobile Home electronics GPU + NVME-SSD なぜPG-Stromを適用するのか?  処理ユニットの拡張により、シングルノードで~数十TBのデータにも対応。  蓄積した生ログデータのまま、H/W限界に近い速度で集計する事が可能。  使い慣れたPostgreSQLのSQL構文、周辺アプリケーションを適用可能。
  49. 49. ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201849 今後の方向性
  50. 50. 今後の方向性 CPU RAM SSD GPU PCIe PostgreSQL データブロック WHERE句 JOIN GROUP BY データ量:小 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201850 Apache Arrow ファイル その① より大容量のストレージ・ データサイズに対応する。 その② SSD~GPU間の データ転送効率を高める。 その③ GPU上でのクエリ処理効率を高くする
  51. 51. NVME-over-Fabric (RDMA) 対応 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 2018 ready ホストシステム SSD SSD SSD HBA CPU 100Gb ネットワーク JBOF ✓ サーバ筐体に搭載可能な限界を越えてNVME-SSDを搭載可能 ✓ データサイズの増加に合わせてストレージ容量を拡張可能 GPU/DB-node Storage-node SSD-to-GPU Direct SQL over 100Gb Ethernet with RDMA protocol SSD SSD SSD SSD SSD SSD SSD SSD SSD HBA JBOF SSD SSD SSD SSD SSD SSD HBA 51 PCIe Switch 8.0TB x 32 = 256TB
  52. 52. 列形式データファイルの直接マッピング (1/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201852 ▌大量のログデータをDBへ取り込む際の課題  PostgreSQL内部データ形式への変換と、トランザクション制御の負荷が高く時間を要する  そもそもログデータに行単位の可視性チェック(MVCC)は不要 ➔特定の外部データ形式(Apache Arrowなど)をGPUが理解し、処理できるようにする事で、 センサ/ログデータの高速な解析と、SQLによる柔軟なデータ操作の両立が可能。 外部テーブル(Foreign Table)- PostgreSQL管理外のデータソースを、 あたかもテーブルであるかのように取り扱うための機能 Table 外部テーブル postgres_fdw 外部テーブル file_fdw 外部テーブル Gstore_fdw 外部テーブル Arrow_fdw 外部RDBMSサーバ CSVファイル GPUデバイスメモリ Arrowファイル WIP
  53. 53. 列形式データファイルの直接マッピング (2/2) ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201853 PostgreSQLデータブロック(行形式)に加えて、GPU側のSQL実装を Arrow形式に対応させる事で、不要なI/Oとデータ形式変換を避ける Foreign Scan GpuJoin GpuPreAgg Agg Arrowファイル ストレージI/O SSD→CPU CPU → GPU GPU → GPU GPU → CPU データ形式変換 (CPU) 負荷の大半は この部分に集中 GpuJoin on Arrow Files GpuPreAgg Agg Arrowファイル ストレージI/O SSD→GPU GPU → GPU GPU → CPU Point-1 列指向形式なので、 転送すべきデータ量が 少なくて済む Point-2 列指向形式なので、 GPUのメモリアクセス 性能を引き出しやすい 従来の動作 Arrow 形式への対応強化 WIP
  54. 54. 《補足》なぜGPUには列指向のデータが向いているか? ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201854 ▌行データ形式 – 不連続なデータアクセス (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コア
  55. 55. 《将来像》GPU/SSDの潜在能力を引き出し、サーバ集約を実現 ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201855 従来、数十台のサーバで分散処理を行っていたワークロードを、 NVME-SSDとGPUという最新ハードウェアの力で2~3Uサイズに圧縮 従来型サーバの処理能力を 1台あたり600MB/sとすると、 4GPU構成での期待性能値30GB/sは、 従来型サーバ50台分の処理能力に 相当する。
  56. 56. まとめ ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201856  PG-Strom GPUを用いてSQLを高速化するPostgreSQL向け拡張モジュール。H/Wのポテンシャルを 最大限に引き出す事で、TB級以上の大量データを集計・解析するためのソフトウェア  ユニーク技術:SSD-to-GPUダイレクトSQL NVME-SSD上のデータブロックをP2P DMAによりGPUへ直接転送。ホストシステムへ データをロードする前にSQL処理をGPUで実行し、データ量を減らす。 その結果、I/OボトルネックのSQL処理性能を改善する。  I/O拡張ボックスを利用したマルチGPU/SSD構成 PCIeバスを制御するCPUの負荷集中を避けるため、PCIeスイッチ内蔵のI/O拡張ボックスを 用いて、ストレージに近い場所でP2P DMAのPCIeパケットを交換する。 CPUの負荷軽減だけでなく、DB容量・処理性能の要請に応じた段階的増強が可能。 3台構成で処理性能 13.5GB/s までは実証。それ以上はハードウェア次第。  適用領域 M2M/IoTといった、大量のログ情報を集積・処理するデータベースシステム。 シングルノードのPostgreSQLという運用のシンプルさと、 使い慣れたSQLやアプリケーションといったスキルセットの継続性が特長。  今後の方向性 より大規模なストレージ … NVME-over-Fabric対応 より効率的なデータ読出し … 列形式(Apache Arrow)ファイル対応
  57. 57. まとめ ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 201857 ▌Gitリポジトリ https://github.com/heterodb/pg-strom ▌ドキュメント http://heterodb.github.io/pg-strom/ja/ ▌コンタクト ML: pgstrom@heterodb.com e-mail: kaigai@heterodb.com twitter: @kkaigai Questions?

×