SlideShare a Scribd company logo
1 of 41
Download to read offline
PostgreSQLだってビッグデータ処理したい!!
~Apache Arrowが可能にする毎秒10億レコードのデータ処理~
HeteroDB,Inc
Chief Architect & CEO
KaiGai Kohei <kaigai@heterodb.com>
 設立: 2017年7月4日(火)
 拠点: 品川区北品川5-13-15
 事業内容:
✓ 高性能データ処理ソフトウェアの開発と販売
✓ 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
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!2
PG-Stromとは?
Apache Arrow Tokyo meetup 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
ログ収集デーモン:
ターゲット:IoT/M2Mログの集計・解析処理
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!4
Manufacturing Logistics Mobile Home electronics
なぜPostgreSQLか?
 シングルノードで処理できるならそっちの方が運用が楽
 エンジニアが慣れ親しんが技術で、運用ノウハウの蓄積が豊富
JBoF: Just Bunch of Flash
NVME-over-Fabric
(RDMA)
DB管理者
BIツール(可視化)
機械学習アプリケーション
(E.g, 異常検知など)
共通データ
フレーム PG-Strom
どれ位のデータサイズを想定するか?(1/3)
※ 誰でも名前を知っている超有名企業の生産ラインの話です。
➔ つまり100TB未満の領域をカバーできれば、大半のユーザには十分。
ある国内企業様の例:
半導体工場の製造ラインが生成したデータ100TBをPostgreSQLで管理
年間20TB
5年間保持
不良品検査
原因分析
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!5
どれ位のデータサイズを想定するか?(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,555USD
by thinkmate.com
(10th-Dec-2019)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!6
どれ位のデータサイズを想定するか?(3/3)
とは言うものの、”余裕で捌ける”というにはちと大きい。
TB
TB
TB
B
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!7
GPUでI/Oを高速化する
SSD-to-GPU Direct SQL
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!8
GPUとはどんなプロセッサなのか?
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!9
主にHPC分野で実績があり、機械学習用途で爆発的に普及
NVIDIA Tesla V100
スーパーコンピュータ
(東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習
“計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか?
シミュレーション
一般的な x86_64 サーバの構成
GPUSSD
CPU
RAM
HDD
N/W
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!10
大量データを処理する時のデータの流れ
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
通常のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!11
一度CPU/RAMへロードしなければ、
“ゴミデータ” であってもその要否を判断できない。
SSD-to-GPUダイレクトSQL(1/3)
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
NVIDIA GPUDirect RDMA
CPU/RAMを介することなく、
Peer-to-PeerのDMAを用いて
SSD上のデータブロックを直接
GPUに転送する機能。
WHERE句
JOIN
GROUP BY
GPUでSQLを処理し、
データ量を削減する
データ量:小
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!12
《要素技術》NVIDIA GPUDirect RDMA
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!13
物理アドレス空間
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
SSD-to-GPUダイレクトSQL(2/3)– システム構成とワークロード
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!14
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(3/3)– ベンチマーク結果
 クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])
 SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録
 CPU+Filesystemベースの構成と比べて約3倍強の高速化
➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!15
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)
効率的な列データストア
Arrow_Fdw(Apache Arrow対応)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!16
背景① データはどこで生成されるのか?
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
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!17
DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に!
Data
Import
Import!
背景② PostgreSQLのデータ構造は結構無駄が多い
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!18
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)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!19
▌特徴
 列指向で分析用途向けに設計されたデータ形式
 アプリケーションによらず、共通のデータ交換形式として利用可能
 整数、実数、日付時刻、文字列など基本的なデータ型を定義
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の間で変換可能
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!20
《背景》FDW (Foreign Data Wrapper)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!21
 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 Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!22
▌なぜ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)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!23
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
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) のストライプ構成としては穏当な性能。
物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!24
《補足》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
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!25
《補足》PostgreSQLデータベースからArrowファイルを生成する
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!26
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()
《補足》PostgreSQLデータベースからArrowファイルを生成する
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!27
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 + SSD-to-GPU Direct + Arrow_Fdw
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!28
~100TB程度の
ログデータを
シングルノードで
処理可能に
4ユニットの並列動作で、
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の
物理データ転送性能
29
PCIe-SW PCIe-SW
JBOF unit-0 JBOF unit-1
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!
大規模構成による検証(2/3)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!30
HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台 による環境を構築
大規模構成による検証(3/3)
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
31
PCIe-SW PCIe-SW
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!
lineorder_p0
(879GB)
lineorder_p1
(879GB)
lineorder_p2
(879GB)
lineorder_p3
(879GB)
lineorder
(---GB)
Hash-Partition (N=4)
ベンチマーク結果(1/4)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!32
実効データ処理スループット 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
ベンチマーク結果(2/4)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!33
毎秒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
ベンチマーク結果(3/4)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!34
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)
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)
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!35
長時間を要する集計・解析ワークロードで特に効果が顕著
(かなり長めの)お昼寝並みに
時間を要していたバッチ処理を
オムツ替え程度の時間で実行。
(1時間半)
(20分)
(5分)
余談:今年の性能目標は達成できた模様
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!36
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!37
今後の方向性
データ処理のライフサイクル全体を支えるプラットフォームに
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!38
device
big-data
summary
machine-
learning
Insight
ログデータの収集
Apache Arrow形式を
通じたデータ連携
毎秒10億件に達する
大量データ処理能力
GPUデータフレームを
通じた、機械学習アプ
リとのデータ連携
大量データからの
異常検知など
+
GPUの世界
PMEMの世界
Pythonの世界
今後)GPUメモリストアと、Python処理系からの直接参照
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!39
 既にセットアップ済みのGPUデバイスメモリ領域を
他のプログラムのアドレス空間にマップし、共有/参照するための機能
✓ 解析対象のデータを選択、GPUへのロードまでをDBMSに任せる事ができる。
➔ 都度、Pythonスクリプトで大量のCSVデータを読み出す必要がなくなる。
Storage
SQLの世界
INSERT
UPDATE
DELETE
SELECT
機械学習
アプリケーション
機械学習
フレームワーク
Zero-copy
参照
WIP
Foreign
Table
(gstore_fdw)
✓ データ形式の変換
✓ トランザクション制御
Arrow
Data Frame
Arrow
Data Frame
統計解析
ロジック
Resources
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!40
▌リポジトリ
 https://github.com/heterodb/pg-strom
 https://heterodb.github.io/swdc/
▌ドキュメント
 http://heterodb.github.io/pg-strom/
▌コンタクト
 kaigai@heterodb.com
 Tw: @kkaigai
20191211_Apache_Arrow_Meetup_Tokyo

More Related Content

What's hot

20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGISKohei KaiGai
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdwKohei KaiGai
 
20210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.020210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.0Kohei KaiGai
 
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームKouhei Sutou
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望Kohei KaiGai
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]Kohei KaiGai
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)NTT DATA Technology & Innovation
 
20170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#820170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#8Kohei KaiGai
 
Parquetはカラムナなのか?
Parquetはカラムナなのか?Parquetはカラムナなのか?
Parquetはカラムナなのか?Yohei Azekatsu
 
広告配信現場で使うSpark機械学習
広告配信現場で使うSpark機械学習広告配信現場で使うSpark機械学習
広告配信現場で使うSpark機械学習x1 ichi
 
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...Hadoop / Spark Conference Japan
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpuKohei KaiGai
 
Introduction new features in Spark 3.0
Introduction new features in Spark 3.0Introduction new features in Spark 3.0
Introduction new features in Spark 3.0Kazuaki Ishizaki
 
Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Yuki Gonda
 
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみpg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみMasahiko Sawada
 
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化gree_tech
 
2014 11-20 Machine Learning with Apache Spark 勉強会資料
2014 11-20 Machine Learning with Apache Spark 勉強会資料2014 11-20 Machine Learning with Apache Spark 勉強会資料
2014 11-20 Machine Learning with Apache Spark 勉強会資料Recruit Technologies
 

What's hot (20)

20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw
 
20210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.020210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.0
 
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
 
20170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#820170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#8
 
Parquetはカラムナなのか?
Parquetはカラムナなのか?Parquetはカラムナなのか?
Parquetはカラムナなのか?
 
JSONBはPostgreSQL9.5でいかに改善されたのか
JSONBはPostgreSQL9.5でいかに改善されたのかJSONBはPostgreSQL9.5でいかに改善されたのか
JSONBはPostgreSQL9.5でいかに改善されたのか
 
広告配信現場で使うSpark機械学習
広告配信現場で使うSpark機械学習広告配信現場で使うSpark機械学習
広告配信現場で使うSpark機械学習
 
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...
Project Tungsten Bringing Spark Closer to Bare Meta (Hadoop / Spark Conferenc...
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpu
 
hscj2019_ishizaki_public
hscj2019_ishizaki_publichscj2019_ishizaki_public
hscj2019_ishizaki_public
 
Introduction new features in Spark 3.0
Introduction new features in Spark 3.0Introduction new features in Spark 3.0
Introduction new features in Spark 3.0
 
Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-
 
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみpg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
 
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化
グラフデータベースNeo4Jでアセットダウンロードの構成管理と最適化
 
pg_trgmと全文検索
pg_trgmと全文検索pg_trgmと全文検索
pg_trgmと全文検索
 
2014 11-20 Machine Learning with Apache Spark 勉強会資料
2014 11-20 Machine Learning with Apache Spark 勉強会資料2014 11-20 Machine Learning with Apache Spark 勉強会資料
2014 11-20 Machine Learning with Apache Spark 勉強会資料
 

Similar to 20191211_Apache_Arrow_Meetup_Tokyo

20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10Kohei KaiGai
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_FdwKohei KaiGai
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)Kohei KaiGai
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JPKohei KaiGai
 
(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速するKohei KaiGai
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsKohei KaiGai
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstromKohei KaiGai
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化Kazunori Sato
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】Kohei KaiGai
 
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...日本マイクロソフト株式会社
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_HistoryKohei KaiGai
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7Kohei KaiGai
 
20170310_InDatabaseAnalytics_#1
20170310_InDatabaseAnalytics_#120170310_InDatabaseAnalytics_#1
20170310_InDatabaseAnalytics_#1Kohei KaiGai
 
[de:code 2019 振り返り Night!] Data Platform
[de:code 2019 振り返り Night!] Data Platform[de:code 2019 振り返り Night!] Data Platform
[de:code 2019 振り返り Night!] Data PlatformNaoki (Neo) SATO
 
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタックONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタックKentaro Ebisawa
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!NTT DATA Technology & Innovation
 
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょうDaiyu Hatakeyama
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCacheKohei KaiGai
 
Kubernetes on Alibaba Cloud
Kubernetes on Alibaba CloudKubernetes on Alibaba Cloud
Kubernetes on Alibaba Cloud真吾 吉田
 

Similar to 20191211_Apache_Arrow_Meetup_Tokyo (20)

20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP
 
(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
 
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...
M06_DX を担うエンジニア向け Data & AI Analytics プラットフォームの最適解 ~ Azure Synapse 最新機能ご紹介 ~ ...
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7
 
20170310_InDatabaseAnalytics_#1
20170310_InDatabaseAnalytics_#120170310_InDatabaseAnalytics_#1
20170310_InDatabaseAnalytics_#1
 
PostgreSQL 12の話
PostgreSQL 12の話PostgreSQL 12の話
PostgreSQL 12の話
 
[de:code 2019 振り返り Night!] Data Platform
[de:code 2019 振り返り Night!] Data Platform[de:code 2019 振り返り Night!] Data Platform
[de:code 2019 振り返り Night!] Data Platform
 
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタックONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック
ONIC2017 プログラマブル・データプレーン時代に向けた ネットワーク・オペレーションスタック
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
 
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache
 
Kubernetes on Alibaba Cloud
Kubernetes on Alibaba CloudKubernetes on Alibaba Cloud
Kubernetes on Alibaba Cloud
 

More from Kohei KaiGai

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_APIKohei KaiGai
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_countKohei KaiGai
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_IndexKohei KaiGai
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGISKohei KaiGai
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_ProcessingKohei KaiGai
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_BetaKohei KaiGai
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGaiKohei KaiGai
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - EnglishKohei KaiGai
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LTKohei KaiGai
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigDataKohei KaiGai
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA UnconferenceKohei KaiGai
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQLKohei KaiGai
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multiKohei KaiGai
 
20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdwKohei KaiGai
 
20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_ENKohei KaiGai
 

More from Kohei KaiGai (15)

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_count
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi
 
20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw
 
20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN
 

Recently uploaded

2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 

Recently uploaded (12)

2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 

20191211_Apache_Arrow_Meetup_Tokyo

  • 2.  設立: 2017年7月4日(火)  拠点: 品川区北品川5-13-15  事業内容: ✓ 高性能データ処理ソフトウェアの開発と販売 ✓ 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 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!2
  • 3. PG-Stromとは? Apache Arrow Tokyo meetup 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. ログ収集デーモン: ターゲット:IoT/M2Mログの集計・解析処理 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!4 Manufacturing Logistics Mobile Home electronics なぜPostgreSQLか?  シングルノードで処理できるならそっちの方が運用が楽  エンジニアが慣れ親しんが技術で、運用ノウハウの蓄積が豊富 JBoF: Just Bunch of Flash NVME-over-Fabric (RDMA) DB管理者 BIツール(可視化) 機械学習アプリケーション (E.g, 異常検知など) 共通データ フレーム PG-Strom
  • 6. どれ位のデータサイズを想定するか?(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,555USD by thinkmate.com (10th-Dec-2019) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!6
  • 8. GPUでI/Oを高速化する SSD-to-GPU Direct SQL Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!8
  • 9. GPUとはどんなプロセッサなのか? Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!9 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA Tesla V100 スーパーコンピュータ (東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習 “計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか? シミュレーション
  • 10. 一般的な x86_64 サーバの構成 GPUSSD CPU RAM HDD N/W Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!10
  • 12. SSD-to-GPUダイレクトSQL(1/3) CPU RAM SSD GPU PCIe PostgreSQL データブロック NVIDIA GPUDirect RDMA CPU/RAMを介することなく、 Peer-to-PeerのDMAを用いて SSD上のデータブロックを直接 GPUに転送する機能。 WHERE句 JOIN GROUP BY GPUでSQLを処理し、 データ量を削減する データ量:小 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!12
  • 13. 《要素技術》NVIDIA GPUDirect RDMA Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!13 物理アドレス空間 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
  • 14. SSD-to-GPUダイレクトSQL(2/3)– システム構成とワークロード Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!14 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
  • 15. SSD-to-GPUダイレクトSQL(3/3)– ベンチマーク結果  クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])  SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録  CPU+Filesystemベースの構成と比べて約3倍強の高速化 ➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!15 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)
  • 16. 効率的な列データストア Arrow_Fdw(Apache Arrow対応) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!16
  • 17. 背景① データはどこで生成されるのか? 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 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!17 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に! Data Import Import!
  • 18. 背景② PostgreSQLのデータ構造は結構無駄が多い Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!18 8kB HeapTuple Table Segment Block HeapTupleHeader nullmap 列A 列B 列D 列E Tuple SELECT B FROM this_table WHERE E like ‘%hoge%’; 要る?
  • 19. Apache Arrowとは(1/2) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!19 ▌特徴  列指向で分析用途向けに設計されたデータ形式  アプリケーションによらず、共通のデータ交換形式として利用可能  整数、実数、日付時刻、文字列など基本的なデータ型を定義 NVIDIA GPU PostgreSQL / PG-Strom
  • 20. 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の間で変換可能 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!20
  • 21. 《背景》FDW (Foreign Data Wrapper) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!21  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
  • 22. SSD-to-GPU Direct SQL on Arrow_Fdw(1/3) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!22 ▌なぜ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
  • 23. 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) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!23 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
  • 24. 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) のストライプ構成としては穏当な性能。 物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!24
  • 25. 《補足》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 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!25
  • 26. 《補足》PostgreSQLデータベースからArrowファイルを生成する Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!26 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()
  • 27. 《補足》PostgreSQLデータベースからArrowファイルを生成する Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!27 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]
  • 28. シングルノード構成の限界に挑む マルチGPU + SSD-to-GPU Direct + Arrow_Fdw Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!28
  • 29. ~100TB程度の ログデータを シングルノードで 処理可能に 4ユニットの並列動作で、 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の 物理データ転送性能 29 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!
  • 30. 大規模構成による検証(2/3) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!30 HPC用 4Uサーバ + GPU x4枚 + NVME-SSD x16台 による環境を構築
  • 31. 大規模構成による検証(3/3) 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 31 PCIe-SW PCIe-SW Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!! lineorder_p0 (879GB) lineorder_p1 (879GB) lineorder_p2 (879GB) lineorder_p3 (879GB) lineorder (---GB) Hash-Partition (N=4)
  • 32. ベンチマーク結果(1/4) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!32 実効データ処理スループット 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
  • 33. ベンチマーク結果(2/4) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!33 毎秒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
  • 34. ベンチマーク結果(3/4) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!34 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)
  • 35. 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) Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!35 長時間を要する集計・解析ワークロードで特に効果が顕著 (かなり長めの)お昼寝並みに 時間を要していたバッチ処理を オムツ替え程度の時間で実行。 (1時間半) (20分) (5分)
  • 36. 余談:今年の性能目標は達成できた模様 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!36
  • 37. Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!37 今後の方向性
  • 38. データ処理のライフサイクル全体を支えるプラットフォームに Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!38 device big-data summary machine- learning Insight ログデータの収集 Apache Arrow形式を 通じたデータ連携 毎秒10億件に達する 大量データ処理能力 GPUデータフレームを 通じた、機械学習アプ リとのデータ連携 大量データからの 異常検知など +
  • 39. GPUの世界 PMEMの世界 Pythonの世界 今後)GPUメモリストアと、Python処理系からの直接参照 Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!39  既にセットアップ済みのGPUデバイスメモリ領域を 他のプログラムのアドレス空間にマップし、共有/参照するための機能 ✓ 解析対象のデータを選択、GPUへのロードまでをDBMSに任せる事ができる。 ➔ 都度、Pythonスクリプトで大量のCSVデータを読み出す必要がなくなる。 Storage SQLの世界 INSERT UPDATE DELETE SELECT 機械学習 アプリケーション 機械学習 フレームワーク Zero-copy 参照 WIP Foreign Table (gstore_fdw) ✓ データ形式の変換 ✓ トランザクション制御 Arrow Data Frame Arrow Data Frame 統計解析 ロジック
  • 40. Resources Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!40 ▌リポジトリ  https://github.com/heterodb/pg-strom  https://heterodb.github.io/swdc/ ▌ドキュメント  http://heterodb.github.io/pg-strom/ ▌コンタクト  kaigai@heterodb.com  Tw: @kkaigai