More Related Content Similar to 20191211_Apache_Arrow_Meetup_Tokyo (20) More from Kohei KaiGai (15) 20191211_Apache_Arrow_Meetup_Tokyo2. 設立: 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
9. GPUとはどんなプロセッサなのか?
Apache Arrow Tokyo meetup 2019 ~ PostgreSQLだってビッグデータ処理したい!!9
主にHPC分野で実績があり、機械学習用途で爆発的に普及
NVIDIA Tesla V100
スーパーコンピュータ
(東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習
“計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか?
シミュレーション
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)
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]
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分)
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