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.

20191115-PGconf.Japan

584 views

Published on

PostgreSQLカンファレンス2019での発表資料です。

PostgreSQLだってビッグデータ処理したい!!
~GPUとNVMEを駆使して毎秒10億レコードを処理する技術~

Published in: Technology
  • Looking For A Job? Positions available now. FT or PT. $10-$30/hr. No exp required. ♣♣♣ http://t.cn/AieXS62G
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

20191115-PGconf.Japan

  1. 1. PostgreSQLだってビッグデータ処理したい!! ~GPUとNVMEを駆使して毎秒10億レコードを処理する技術~ HeteroDB,Inc Chief Architect & CEO KaiGai Kohei <kaigai@heterodb.com>
  2. 2.  設立: 2017年7月4日(火)  拠点: 品川区西大井1-1-2-206(西大井創業支援センター内)  事業内容: ✓ 高性能データ処理ソフトウェアの開発と販売 ✓ GPU&DB領域の技術コンサルティング 自己紹介  海外 浩平 (KaiGai Kohei)  Chief Architect & CEO of HeteroDB  PostgreSQL, Linux kernel 開発者 (2003~)  PG-Stromのメイン開発者(2012~)  興味範囲:Big-data, GPU, NVME, PMEM, Curling, … about myself about our company PG-Strom JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!2
  3. 3. PG-Stromとは? JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!3 【機能】  集計/解析ワークロードの透過的なGPU高速化  SQLからGPUプログラムを自動生成し並列実行  SSD-to-GPU Direct SQLによるPCIeバスレベルの最適化  列ストレージによるI/Oと並列計算の効率化 PG-Strom: GPUとNVMEの能力を最大限に引き出し、数十TB単位の データ処理を高速化するPostgreSQL向け拡張モジュール App GPU off-loading for IoT/Big-Data for ML/Analytics ➢ SSD-to-GPU Direct SQL ➢ Columnar Store (Arrow_Fdw) ➢ Asymmetric Partition-wise JOIN/GROUP BY ➢ BRIN-Index Support ➢ NVME-over-Fabric Support ➢ Procedural Language for GPU native code (PL/CUDA) ➢ NVIDIA RAPIDS data frame support (WIP) ➢ IPC on GPU device memory
  4. 4. PG-Strom as an Open Source Project JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!4 公式ドキュメント(英/日) http://heterodb.github.io/pg-strom/ ★がいっぱい ☺ GPL-v2.0で配布 2012年から継続して開発 ▌対応するPostgreSQLバージョン  PostgreSQL v11.x, v10.x ▌関連するPostgreSQL本体機能の強化  Writable FDW support (9.3)  Custom-Scan interface (9.5)  FDW and Custom-Scan JOIN pushdown (9.5) ▌PostgreSQLコミュニティイベントでの発表  PGconf.EU 2012 (Prague), 2015 (Vienna), 2018 (Lisbon)  PGconf.ASIA 2018 (Tokyo), 2019 (Bali, Indonesia)  PGconf.SV 2016 (San Francisco)  PGconf.China 2015 (Beijing)
  5. 5. 何を高速化するのか? JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!5
  6. 6. ログ収集デーモン: ターゲット:IoT/M2Mログの集計・解析処理 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!6 Manufacturing Logistics Mobile Home electronics なぜPostgreSQLか?  シングルノードで処理できるならそっちの方が運用が楽  エンジニアが慣れ親しんが技術で、運用ノウハウの蓄積が豊富 JBoF: Just Bunch of Flash NVME-over-Fabric (RDMA) DB管理者 BIツール(可視化) 機械学習アプリケーション (E.g, 異常検知など) 共通データ フレーム PG-Strom
  7. 7. どれ位のデータサイズを想定するか?(1/3) ※ 誰でも名前を知っている超有名企業の生産ラインの話です。 ➔ つまり100TB未満の領域をカバーできれば、大半のユーザには十分。 ある国内企業様の例: 半導体工場の製造ラインが生成したデータ100TBをPostgreSQLで管理 年間20TB 5年間保持 不良品検査 原因分析 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!7
  8. 8. どれ位のデータサイズを想定するか?(2/3) イマドキの2Uサーバなら、オールフラッシュで100TB普通に積める。 model Supermicro 2029U-TN24R4T Qty CPU Intel Xeon Gold 6226 (12C, 2.7GHz) 2 RAM 32GB RDIMM (DDR4-2933, ECC) 12 GPU NVIDIA Tesla P40 (3840C, 24GB) 2 HDD Seagate 1.0TB SATA (7.2krpm) 1 NVME Intel DC P4510 (8.0TB, U.2) 24 N/W built-in 10GBase-T 4 8.0TB x 24 = 192TB お値段 How much? 60,932USD by thinkmate.com (31st-Aug-2019) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!8
  9. 9. どれ位のデータサイズを想定するか?(3/3) とは言うものの、”余裕で捌ける”というにはちと大きい。 TB TB TB B JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!9
  10. 10. H/Wの能力を最大限に引き出すためのテクノロジー JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!10 • SSD-to-GPU Direct SQL 効率的な ストレージ • Apache Arrow対応 (列データストア) 効率的な データ構造 • PostgreSQL Partition • Asymmetric Partition-wise JOIN データの パーティション化
  11. 11. PG-Strom: SSD-to-GPU Direct SQL 効率的なストレージ JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!11
  12. 12. GPUとはどんなプロセッサなのか? JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!12 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA Tesla V100 スーパーコンピュータ (東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習 “計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか? シミュレーション
  13. 13. 一般的な x86_64 サーバの構成 GPUSSD CPU RAM HDD N/W JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!13
  14. 14. 大量データを処理する時のデータの流れ CPU RAM SSD GPU PCIe PostgreSQL データブロック 通常のデータフロー 本来は不要なレコードであっても、 一度CPU/RAMへロードしなければ 要・不要を判断できないため、 データサイズは大きくなりがち。 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!14 一度CPU/RAMへロードしなければ、 “ゴミデータ” であってもその要否を判断できない。
  15. 15. 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を処理し、 データ量を削減する データ量:小 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!15
  16. 16. 《要素技術》NVIDIA GPUDirect RDMA JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!16 物理アドレス空間 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
  17. 17. SSD-to-GPUダイレクトSQL(2/4)– システム構成とワークロード JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!17 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
  18. 18. SSD-to-GPUダイレクトSQL(3/4)– ベンチマーク結果  クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])  SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録  CPU+Filesystemベースの構成と比べて約3倍強の高速化 ➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!18 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)
  19. 19. SSD-to-GPUダイレクトSQL(4/4)– ソフトウェアスタック JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!19 Filesystem (ext4, xfs) nvme_strom kernel module NVMe SSD PostgreSQL pg_strom extension read(2) ioctl(2) Operating System Software Layer Database Software Layer blk-mq nvme pcie nvme rdmax Network HBA NVMe Request Network HBANVMe SSD NVME-over-Fabric Target RDMA over Converged Ethernet GPUDirect RDMA ファイルオフセット ➔ NVME-SSDのセクタ番号変換 ■ その他のソフトウェア コンポーネント ■ PG-Stromプロジェクトの 開発したソフトウェア ■ ハードウェア NVME-SSD上の特定セクタから、 GPUデバイスメモリへデータを 転送するよう仕込んだ NVME READコマンド External Storage Server Local Storage Layer
  20. 20. PG-Strom: Arrow_Fdw (列データストア) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!20 効率的なデータ構造
  21. 21. Apache Arrowとは(1/2) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!21 ▌特徴  列指向で分析用途向けに設計されたデータ形式  アプリケーションによらず、共通のデータ交換形式として利用可能  整数、実数、日付時刻、文字列など基本的なデータ型を定義 NVIDIA GPU PostgreSQL / PG-Strom
  22. 22. 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 tyoes? Map ------ 大半のデータ型はApache Arrow  PostgreSQLの間で変換可能 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!22
  23. 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 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!23 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に! Data Import Import!
  24. 24. 《背景》FDW (Foreign Data Wrapper) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!24  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
  25. 25. SSD-to-GPU Direct SQL on Arrow_Fdw(1/3) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!25 ▌なぜ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
  26. 26. 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) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!26 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
  27. 27. 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) のストライプ構成としては穏当な性能。 物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!27
  28. 28. 《補足》PostgreSQLデータベースからArrowファイルを生成する ✓ 基本的な使い方は、-cで指定したSQLの実行結果を、 -oで指定したファイルに書き出す。 $./pg2arrow -h Usage: pg2arrow [OPTION]... [DBNAME [USERNAME]] General options: -d, --dbname=DBNAME database name to connect to -c, --command=COMMAND SQL command to run -f, --file=FILENAME SQL command from file -o, --output=FILENAME result file in Apache Arrow format Arrow format options: -s, --segment-size=SIZE size of record batch for each (default is 256MB) Connection options: -h, --host=HOSTNAME database server host -p, --port=PORT database server port -U, --username=USERNAME database user name -w, --no-password never prompt for password -W, --password force password prompt Debug options: --dump=FILENAME dump information of arrow file --progress shows progress of the job. Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。 Apache Arrow Data Files Arrow_Fdw Pg2Arrow JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!29
  29. 29. PostgreSQLパーティショニングと PCIeバスレベル最適化 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!30 データのパーティション化
  30. 30. ログデータ向けPostgreSQLパーティション設定(1/2) ▌PostgreSQLテーブルとArrow外部テーブルを混在させたパーティション定義 ▌ログデータは追記のみで、常にタイムスタンプを持つ。 ➔ つまり、古いデータは月次/週次でArrow外部テーブルに移してよい。 logdata_201812 logdata_201901 logdata_201902 logdata_current logdata table (PARTITION BY timestamp) 2019-03-21 12:34:56 dev_id: 2345 signal: 12.4 タイムスタンプ 付きログデータ PostgreSQL tables 行データ構造 Read-writableだが低速 Arrow foreign table 列データ構造 Read-onlyだが高速 Unrelated child tables are skipped, if query contains WHERE-clause on the timestamp E.g) WHERE timestamp > ‘2019-01-23’ AND device_id = 456 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!31
  31. 31. ログデータ向けPostgreSQLパーティション設定(2/2) logdata_201812 logdata_201901 logdata_201902 logdata_current logdata table (PARTITION BY timestamp) 2019-03-21 12:34:56 dev_id: 2345 signal: 12.4 logdata_201812 logdata_201901 logdata_201902 logdata_201903 logdata_current logdata table (PARTITION BY timestamp) 一ヶ月後 2019年3月の データを抽出 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!32 ▌PostgreSQLテーブルとArrow外部テーブルを混在させたパーティション定義 ▌ログデータは追記のみで、常にタイムスタンプを持つ。 ➔ つまり、古いデータは月次/週次でArrow外部テーブルに移してよい。 タイムスタンプ 付きログデータ
  32. 32. PCIeバスレベルの最適化(1/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!33 効率的なP2P DMAには、ストレージに最も近いGPUを選ぶ事が必要 CPU CPU PCIe switch SSD GPU PCIe switch SSD GPU PCIe switch SSD GPU PCIe switch SSD GPU logdata 201812 logdata 201901 logdata 201902 logdata 201903 Near is Better Far is Worse
  33. 33. PCIeバスレベルの最適化(2/4)– GPU<->SSD Distance Matrix JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!34 $ 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を自動的に選択する
  34. 34. PCIeバスレベルの最適化(3/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!35 PCIe-switch経由のP2P DMAは、完全にCPUをバイパスする事ができる CPU CPU PCIe switch SSD GPU PCIe switch SSD GPU PCIe switch SSD GPU PCIe switch SSD GPU SCAN SCAN SCAN SCAN JOIN JOIN JOIN JOIN GROUP BY GROUP BY GROUP BY GROUP BY Pre-processed Data (very small) GATHER GATHER
  35. 35. PCIeバスレベルの最適化(4/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!36 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 slotGen3 x16 ▌HPC Server – optimization for GPUDirect RDMA ▌I/O Expansion Box NEC ExpEther 40G (4slots edition) Network Switch 4 slots of PCIe Gen3 x8 PCIe Swich 40Gb Ethernet CPU NIC Extra I/O Boxes
  36. 36. Combined GPU Kernel – データの移動を減らす工夫 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!37 処理ステップ間でGPU~CPUをデータがピンポンするのは絶対悪 GpuScan kernel GpuJoin kernel GpuPreAgg kernel GPU CPU Storage GPU Buffer GPU Buffer results DMA Buffer Agg (PostgreSQL) Combined GPU kernel for SCAN + JOIN + GROUP BY data size = Large data size = Small DMA Buffer SSD-to-GPU Direct SQL DMA Buffer No data transfer ping-pong
  37. 37. Asymmetric Partition-wise JOIN(1/5) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!38 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で処理する羽目に!
  38. 38. Asymmetric Partition-wise JOIN(2/5) 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) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!39
  39. 39. Asymmetric Partition-wise JOIN(3/5) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!40 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向けに、 開発者コミュニティへ提案中です。
  40. 40. Asymmetric Partition-wise JOIN(4/5) 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) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!41
  41. 41. Asymmetric Partition-wise JOIN(5/5) May be available at PostgreSQL v13 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!42
  42. 42. これらの技術を全て投入しての 大規模構成ベンチマーク JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!43
  43. 43. ~100TB程度の ログデータを シングルノードで 処理可能に 4ユニットの並列動作で、 100~120GB/sの 実効データ処理能力 列データ構造により ユニット毎25~30GB/sの 実効データ転送性能 大規模構成による検証(1/4) QPI SSD-to-GPU Direct SQL、列志向ストア、PCIeバス最適化の全てを投入 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の 物理データ転送性能 44 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!
  44. 44. 大規模構成による検証(2/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!45 HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台 による環境を構築 CPU2 CPU1 SerialCables dual PCI-ENC8G-08A (U.2 NVME JBOF; 8slots) x2 NVIDIA Tesla V100 x4 PCIe switch PCIe switch PCIe switch PCIe switch Gen3 x16 for each slot Gen3 x16 for each slot via SFF-8644 based PCIe x4 cables (3.2GB/s x 16 = max 51.2GB/s) Intel SSD DC P4510 (1.0TB) x16 SerialCables PCI-AD-x16HE x4 Supermicro SYS-4029GP-TRT SPECIAL THANKS
  45. 45. 大規模構成による検証(3/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!46 HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台 による環境を構築
  46. 46. 大規模構成による検証(4/4) 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 47 PCIe-SW PCIe-SW JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!! lineorder_p0 (879GB) lineorder_p1 (879GB) lineorder_p2 (879GB) lineorder_p3 (879GB) lineorder (---GB) Hash-Partition (N=4)
  47. 47. ベンチマーク結果(1/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!48 毎秒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
  48. 48. ベンチマーク結果(2/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!49 実効データ処理スループット 100GB/s を実現 9.39 9.53 9.56 8.62 8.50 9.87 6.44 8.60 8.95 8.91 7.76 7.77 8.66 37.42 37.48 37.66 37.77 37.83 37.75 36.43 37.38 37.14 37.14 36.55 36.57 36.60 191.29 194.99 195.57 120.37 124.01 128.21 85.73 91.20 92.82 92.40 74.93 75.54 76.77 0 20 40 60 80 100 120 140 160 180 200 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 実効データ処理スループット [GB/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
  49. 49. ベンチマーク結果(3/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!50 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)
  50. 50. 337.2 1,230 5347.9 0 1,000 2,000 3,000 4,000 5,000 6,000 PG-Strom 2.2 + Arrow_Fdw PG-Strom 2.2 PostgreSQL 11.5 全ワークロードの総実行時間 [sec] Total execution time of Star Schema Benchmark ベンチマーク結果(4/4) JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!51 長時間を要する集計・解析ワークロードで特に効果が顕著 (かなり長めの)お昼寝並みに 時間を要していたバッチ処理を オムツ替え程度の時間で実行。 (1時間半) (20分) (5分)
  51. 51. 余談:今年の性能目標は達成できた模様 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!52
  52. 52. JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!53 今後の方向性
  53. 53. ログ収集デーモン: 再掲:IoT/M2Mログの集計・解析処理 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!54 Manufacturing Logistics Mobile Home electronics なぜPG-Stromか?  容易にTBを越えるログデータに対しても対応可能な処理能力。  PostgreSQL周辺ソフトウェアやエンジニアの経験を活用できる。 JBoF: Just Bunch of Flash NVME-over-Fabric (RDMA) DB管理者 BIツール(可視化) 機械学習アプリケーション (E.g, 異常検知など) 共通データ フレーム PG-Strom
  54. 54. データ処理のライフサイクル全体を支えるプラットフォームに JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!55 device big-data summary machine- learning Insight ログデータの収集 Apache Arrow形式を 通じたデータ連携 毎秒10億件に達する 大量データ処理能力 GPUデータフレームを 通じた、機械学習アプ リとのデータ連携 大量データからの 異常検知など +
  55. 55. GPUの世界 今後)GPUメモリストアと、Python処理系からの直接参照 JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!56  既にセットアップ済みのGPUデバイスメモリ領域を 他のプログラムのアドレス空間にマップし、共有/参照するための機能 ✓ 解析対象のデータを選択、GPUへのロードまでをDBMSに任せる事ができる。 ➔ 都度、Pythonスクリプトで大量のCSVデータを読み出す必要がなくなる。 Storage SQLの世界 GPU device memory Foreign Table (gstore_fdw) INSERT UPDATE DELETE SELECT ✓ データ形式の変換 ✓ データ圧縮 ✓ トランザクション制御 cuDF 機械学習 アプリケーション 機械学習 フレームワーク cuDF Zero-copy 参照 WIP
  56. 56. 今後)アプリケーションの作り方はどのように変わるか? JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!57 従来のスクリプト PostgreSQLとのデータ連携に対応 PostgreSQLデータベースに接続 既にデータをロード済みの GPUデバイスメモリの識別子を取得 上記の識別子を用いて GPUデバイスメモリをオープン GPUカーネルを起動し、 統計解析・機械学習を実行 計算結果をGPUから書き戻す 結果を出力 CSVファイルをオープン GPUデバイスメモリをmalloc() 読み出したデータをGPUへ転送 CSVファイルを読み込み、同時に テキスト➔バイナリに変換 GPUカーネルを起動し、 統計解析・機械学習を実行 計算結果をGPUから書き戻す 結果を出力 CSVファイルを読み込むかわりに、PostgreSQLデータベースに接続する ➔ 既にセットアップ済みのGPUデバイスメモリ領域をマップ WIP
  57. 57. ぜひ一緒にやりましょう! JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!58 ✓ 問題解決に向けたアプローチの検討 ✓ 技術課題の洗い出し、実現可能性の検討 ✓ 必要な新機能の実装、実機・実データによる実証実験 ✓ 製品化/実システム適用に向けた諸々の技術支援 PG-Stromの能力を活かすソリューションを一緒に創る事のできる パートナー様、ユーザー様を探しています。
  58. 58. Resources JPUG Conference 2019 - PostgreSQLだってビッグデータ処理したい!!59 ▌リポジトリ  https://github.com/heterodb/pg-strom  https://heterodb.github.io/swdc/ ▌ドキュメント  http://heterodb.github.io/pg-strom/ ▌コンタクト  kaigai@heterodb.com  Tw: @kkaigai

×