[db analytics showcase Sapporo 2018] B25　Hadoop上で動く世界最速のAnalytic DBをSparkと一緒に使ってみよう

* 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2018 Insight Technology, Inc. All Rights Reserved.
Hadoop上で動く世界最速のAnalytic DBを
Sparkと一緒に使ってみよう
平間大輔
株式会社インサイトテクノロジー

自己紹介
• Insight Technologyの検証隊長
• ハードウェアもソフトウェアも、big
dataの取り扱いに役立ちそうな基盤は
何でも調査対象
（でもRDBMSが主戦場）
• 上京して20年、未だに暑さと湿気に
弱い道産子

今日のテーマ

EnterpriseでもHadoopの利用が普通に

貯めたデータをどうやって分析する？
• その1：Hadoopエコシステム • その2：分析用RDBMSを併置
load data
…双方のいいとこ取りはできないの？

いいとこ取りできるやべーやつ、それが…
VectorH

世界最速DWHエンジンをHadoopに
x100
Vector
VectorH

まずはVectorについて見てみる
Vector

Actian Vectorの内部構造
Copyright © 2013 Insight Technology, Inc. All Rights
Reserved.
SQL Parser
Ingres Rewriter
Ingres Optimizer
Ingres Storage &
Executor
SQL Parser
Ingres Rewriter
Ingres Optimizer
Classic
Ingres
Storage
&
Executor
X Compiler
Vector
Rewriter
Vector
Executor
Compressed
PAX/DSM
Modify
Heavy
Modify
Add
Ingres Vector
x100

Vector(x100)エンジンの性能は
0
0.2
0.4
0.6
0.8
1
1.2
0
500000
1000000
1500000
2000000
2500000
SQL Server 2014
72 cores
2015/7/14
SQL Server 2016
72 cores
2016/7/31
SQL Server 2017
56 cores
2017/10/31
SQL Server 2017
56 cores
2018/6/12
SQL Server 2016
72 cores
2016/6/1
Actian Vector 5.0
92 cores
2016/7/31
Price/QphH
QphH
TPC-H 3000GB (Non-Clustered) Top 6 (2018年6月18日現在)
QphH Price/QphH

Vector(x100)はなぜ速い？

DWHといえば？カラムナー
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Date
Date
Date
Date
Date
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Prod ID Prod Name
Date
Date
Date
Date
Date
1ブロックには様々な
タイプのデータが格納
されているので圧縮効
率を上げにくい
1ブロックには同様の
タイプのデータが格納
されているので圧縮効
率を上げやすい
通常のDB（行指向）分析用DB（列指向）

この差はカラムナーだけではない
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000秒
TPC-H(SF=1000) クエリ実行時間
※monetdbが処理中にリソース不足でエラーとなったQ1, Q10, Q14を除いた実行時間
Vector

CPUの使い方に一日の長あり
SIMD (Single Instruction Multiple Data)
Pentium ⅢよりSSE(Streaming SIMD Extensions)として搭載され、
Sandy BridgeよりIntel AVX(Advanced Vector eXtensions)へ
・・・
・・・
・・・
・・・
・・・
Instruction
Data
Output

実行命令数の比較
27412968251
2.3858E+11
1.9685E+11
7.82182E+11
1.88149E+12 1.87184E+12
1
9 7
29
69
68
0
10
20
30
40
50
60
70
80
0.0E+00
1.0E+12
2.0E+12
Columnar DB
A
Columnar DB
B
In Memory DB
A
Rt = Instructions / (IPC * Hz * Parallelism)
Row Store DB
A
Row Store DB
B
CPUInstructions(count)
ComparisonvsVector
select
sum(l_extendedprice * l_discount) as revenue
from
lineitem -- 6億件, 80GB のデータ
where l_shipdate >= date '1996-01-01'
and l_shipdate < date '1996-01-01' + interval '1' year
and l_discount between 0.02 - 0.01 and 0.02 + 0.01
and l_quantity < 24
SIMD効果により、少ない命令数で済む
TPC-H Q6

ブランチミス数の比較
1.8E+07
1.1E+09
3.0E+08
1.1E+09
1.6E+09
7.7E+08
1
64
17
62
88
43
0
10
20
30
40
50
60
70
80
90
100
0.0E+00
1.0E+09
2.0E+09
Columnar DB
A
Columnar DB
B
In Memory DB
A
Row Store DB
A
Row Store DB
B
CPUBranch-Misses(count)
ComparisonvsVector
そもそも分岐命令数が１～２桁少ない。よってブランチミスのペナルティも少なくて済む。

その結果がクエリの高速実行に
0.48 3.44
35.58
209.45
467.36
332.56
1
7
74
434
968
689
0
200
400
600
800
1000
1200
0
50
100
150
200
250
300
350
400
450
500
Columnar DB
A
Columnar DB
B
In Memory DB
A
Row Store DB
A
Row Store DB
B
QueryElapsedTime(sec)
ComparisonvsVector
実行時間の比較

メモリよりキャッシュ
• CPUキャッシュのアクセスはRAMよりも高速
• すべてのベクトルがCPUキャッシュ内に収まるように問合せの実行プランを作成
Latency
HDD 10 – 15 ms
SSD (SATA) 0.2 – 2 ms
SSD (NVMe) 10 – 100 us
RAM 50 – 100 ns
L3 Cache 10 – 20 ns
L2 Cache 3 – 10 ns
L1 Cache 1 ns
HW各構成要素のレイテンシ比較

これらを組み合わせてx100は高速に
ベクター演算
カラムナー
データ自動圧縮CPUキャッシュ
マルチコア並列処理…
ストレージインデックス
Time/CyclestoProcess
Data Processed
DISK
RAM
CHIP
10GB2-3GB40-400MB
2-20150-250Millions

これまでのVectorの弱点：スケールアウトできない
多くのDWH向けDBでは
スケールアウトで性能向上
これまでのVectorは
スケールアップのみ！

実はVectorの代わりもあったけど...
Matrix
技術供与
買収

最終的に選んだのはこちら
VectorVectorH
(Actian Vector in Hadoop)

x100をHadoop上で動かすことに成功！
DataNode DataNode DataNode DataNode DataNode
NameNode
Vector
x100 x100 x100 x100 x100
DataNodeのうち1つが
VectorHのMasterに
VectorH DatafileVectorHの
データファイルが
HDFS上に置かれる

Hadoopの力を借りてクラスタ化！
data localityを確保し、デー
タファイルにローカルアク
セスできるようにするた
め、VectorHのMasterも
SlaveもHDFSのDataNode上
にインストールされる必要
がある。

課題のスケールアウトも
0
100
200
300
400
500
600
700
800
900
1000
Single 3 datanodes 6 datanodes 9 datanodes
秒
TPC−H (SF=1000) クエリ実行時間
ノード数を3倍にすると
速度が2倍に

でもHDFS上の偏りに注意
0
50
100
150
200
250
300
350
8 nodes 10 nodes（リバランス前） 10 nodes（リバランス後）
秒
2ノード追加してすぐに測定す
ると、ローカルにないデータを
ネットワーク越しに取りに行く
ためかえって性能が落ちる。

Hadoopエコシステムと比べてみると…
select
100.00 * sum(case
when p_type like 'PROMO%’
then l_extendedprice * (1 - l_discount)
else 0
end) / sum(l_extendedprice * (1 - l_discount)) as promo_revenue
from
lineitem,
part
where
l_partkey = p_partkey
and l_shipdate >= date '1996-01-01’
and l_shipdate < date '1996-01-01' + interval '1' month
;
onVS
Q14（TPC-Hの中では極悪度かなり低め）
VS
小規模なデモ環境(CPU:
12core x 4node)でTPC-H
(SF=10)のQ14を実行し、
Hive on TEZおよびSpark SQL
と実行時間を比較してみ
る。

出自の違いが歴然
0.764722
25.248
26.642
1
33
35
0
5
10
15
20
25
30
35
40
0
5
10
15
20
25
30
VectorH Spark SQL Hive on Tez
倍
秒
TPC-H (SF=10) Q14 実行時間
1.477118
136.996
521.968
1
93
353
0
50
100
150
200
250
300
350
400
0
100
200
300
400
500
600
VectorH Hive on Tez HIve MapReduce
倍
秒
TPC-H (SF=1000) Q14 実行時間
デモ環境の小規模データでは30倍の性能差
より大規模なデータ量では100倍近くの差
MapReduceと比較すると速度差は350倍
（Sparkはメモリ不足のため除外）

クラウドのあいつと比べよう
DWH用ベンチマークのTPC-Hで
クラウド定番のDWHである某DBと比較してみよう
VectorH
• 16vCPU, 122GB Memory, NVMe SSD
• 6ノード、8ノード、10ノード
• DB設定についてはデフォルトのまま
VS
某DB
• 32vCPU, 244GB Memory, SSD
• 3ノード、4ノード、5ノード
• 主キーの一部へDISTKEYを設定
• カラムの圧縮設定はロード時の自動設定を利用
• これまでと同様にTPC-Hで比較（使用する22クエリの実行時間を単純足し上げ）
• TPC-Hデータベースのサイズ：1TB（Scale Factor=1000)
• マシン構成が異なるため、同一CPUコア数となるようノード数を調整
• ストレージの違いによる差を減らすため、2回連続実行して2回目の結果を採用

これがVectorHを選んだ理由
0
50
100
150
200
250
300
350
400
450
96 vCPU 128 vCPU 160 vCPU
秒
Cloud DWH VectorH
(6 nodes)(3 nodes) (8 nodes)(4 nodes) (10 nodes)(5 nodes)
同一コア数では1.3～1.5倍高速に

ちょっと嫌がらせ：updateしてみる
HDFSは書き換え不可
でもVectorHは更新可能
最近のHiveも更新可能ですが…
→では速度は？
update lineitem_for_update
set l_commitdate = sysdate
where l_partkey <= 1000

ここまででわかったこと
VectorH
Hadoop上で動くけど、
性能はEnterpriseで使うDWH用RDBMSそのまま！
それが…

VectorHとSparkはより親密に
Vector & VectorHの弱点：機能が少ない！
• ユーザー定義関数(UDF)が作れない
• RDBMS以外の機能は最小限
→できないことは他でやらせる！

その1：Spark側でVectorHテーブルを使う
Spark-Vector ConnectorによりSpark側で
VectorHのテーブルを読み書き可能
• SelectおよびInsert Select文
• HiveテーブルとのJOIN可能
• SQL構文はSpark側で解釈
spark.sqlContext.sql("""CREATE TEMPORARY VIEW vector_table
USING com.actian.spark_vector.sql.DefaultSource
OPTIONS (
host "192.168.99.121",
instance "VH",
database "tpch10",
user "actian",
password "actian",
table "customer"
)""")
val result=spark.sqlContext.sql("""select n.n_name, c.*
from vector_table c
join nation n where c.c_nationkey = n.n_nationkey limit 10""")
result.show()
Spark-Vector Connectorの使用例

その2：Sparkの力を使った外部表
• Ver.5からSpark-providerサービスが登
場、Vector側からのSparkアクセスが可
能に。
• External TableとしてCSV、jsonなどSpark
が取り扱えるファイルを読み書き可能
• Hiveテーブルも認識可能
• VectorHテーブルとのJOIN可能
• SQL構文はVectorのパーサで解釈
CREATE EXTERNAL TABLE PART
(
P_PARTKEY INTEGER8 NOT NULL,
P_NAME VARCHAR(55) NOT NULL,
P_MFGR CHAR(25) NOT NULL,
P_BRAND CHAR(10) NOT NULL,
P_TYPE VARCHAR(25) NOT NULL,
P_SIZE INTEGER8 NOT NULL,
P_CONTAINER CHAR(10) NOT NULL,
P_RETAILPRICE DECIMAL(15,2) NOT NULL,
P_COMMENT VARCHAR(23) NOT NULL
)
USING SPARK
WITH REFERENCE=‘part’,
FORMAT=‘hive’

さっきのクエリを外部表で実行してみる
select
100.00 * sum(case
when p_type like 'PROMO%’
then l_extendedprice * (1 - l_discount)
else 0
end) / sum(l_extendedprice * (1 - l_discount)) as promo_revenue
from
lineitem,
part
where
l_partkey = p_partkey
and l_shipdate >= date '1996-01-01’
and l_shipdate < date '1996-01-01' + interval '1' month
;
Q14
lineitemとpartを外部表にした
もの、partだけ外部表にして
VectorH上のlineitemとJOINし
たものを実行してみる。

Hive / Sparkでは実行できないクエリも
select
nation,
o_year,
sum(amount) as sum_profit
from
(
select
n_name as nation,
extract(year from o_orderdate) as o_year,
l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
from
part,
supplier,
lineitem,
partsupp,
orders,
nation
where
s_suppkey = l_suppkey
and ps_suppkey = l_suppkey
and ps_partkey = l_partkey
and p_partkey = l_partkey
and o_orderkey = l_orderkey
and s_nationkey = n_nationkey
and p_name like '%smoke%'
) as profit
group by
nation,
o_year
order by
nation,
o_year desc
;
Q9
Hive / Sparkはextract関数がない

CSVも直接アクセス
create external table traffic_201803_sapporo (
checktime char(16),
police_code char(4),
point_no int,
point_name varchar(50),
mesh2_code char(6),
link_code char(1),
link_no int,
traffic_amount int,
link_difference int,
link_var char(6)
)
using spark
with reference='hdfs://ip121.iq.insight-tec.co.jp/user/actian/sapporo_201803.csv',
format='csv',
OPTIONS=('delimiter' = ',', 'header' = 'true')
一般道路の「断面交通量情報」をcsvから直接アクセスしてみる。
(http://public-data.jartic-raws.durasite.net/opendata.html)
checktime,police_code,point_no,point_name,mesh2_code,link_code,link_no,traffic_amount,link_difference,link_var
2018/03/01 00:00,3001,7,室）港北町伊達行,634047,2,50,0,247,201700
2018/03/01 00:00,3001,12,樽）奥沢１－１５西東,644160,2,15,3,11,201700
2018/03/01 00:00,3001,13,樽）桜１丁目東西,644160,2,8,14,15,201700
2018/03/01 00:00,3001,15,室）港北町室蘭行,634047,2,49,0,100,201700
2018/03/01 00:00,3001,22,樽）稲穂１丁目９北北,644160,2,120,7,6,201700
2018/03/01 00:00,3001,23,樽）稲穂１丁目８北北,644067,2,79,7,20,201700
2018/03/01 00:00,3001,24,樽）稲穂５丁目南北,644067,2,80,24,2,201700
2018/03/01 00:00,3001,25,樽）稲穂５－１８西西,644067,2,9,11,33,201700
2018/03/01 00:00,3001,26,千）北栄２北北,644115,2,40,19,16,201700

Hadoopが普通となったインフラの世界に新風を！

記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。
Copyright 2018 Insight Technology, Inc. All Rights Reserved.

NVMeの正しい使い方
ー高性能ドライブを正しく活かすためにー
平間大輔
株式会社インサイトテクノロジー

Insight Technologyとは
ソフトウェア
-DBパフォーマンス管理
-DBセキュリティ
-リアルタイムレプリケート
-データ分析専用プラットフォーム
ハードウェア
高速DB専用マシン
データベースコンサルティング

EnterpriseでもSSDは当たり前に
５年前現在
SSDはたしかに速いけど、書き込む
とプチフリが起きるって言うし、
書き込み回数に限界があって寿命
が短そうだし、エンタープライズ
（特にデータベース）に使うには
まだまだ早いかな。。。
時代はAll-Flash！コントローラーの
改良で書き込み速度も安定、書き込
み寿命だって通常の用途だと十分す
ぎるほど保つことがわかった！
壊れやすいHDDと比較してもずっと
安定して使える！

従来のSAS/SATAではもう限界
0
200
400
600
800
1000
1200
1400
SATA3/SAS2 HDD SATA3/SAS2 SSD SAS3 SSD
インターフェイス別HDD/SSDスループット
(1MB sequential read)
I/F速度実測値

PCI Express直結のNVMeで限界突破
0
500
1000
1500
2000
2500
3000
3500
4000
4500
SATA3/SAS2 HDD SATA3/SAS2 SSD SAS3 SSD NVMe
インターフェイス別HDD/SSDスループット
(1MB sequential read)
I/F速度実測値
※NVMeの理論値はPCI Express 3.0 x4でのもの。実測値も同じ環境。

階層がすっきり
出典:
https://www.openfabrics.org/images/eventpresos/workshops2013/2013_Workshop_Tues_1130_Akerson_NVMe_Overview.pdf
出典:
http://nvmexpress.org/about/why-nvm-express/

低レスポンスタイムを実現
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
random read random write
ミリ秒 Response time (I/O size 4kB, thread=1)
SAS2 SAS3 NVMe
(低いほうが高性能)

Queueの強化
• CPUコアごとに1つ以上のI/O Submission QueueとI/O Completion Queue、MSI-X(拡張メッセージシグ
ナル割り込み)が設定される。CPUコア間でのキュー・割り込みが共有されないためコア間でのロッ
ク待ちなく動作が可能。
• 1つ当たり64k個のコマンドをキューイングできるキューを最大64k個持つことができ、最大で2の32
乗個のコマンドをキューイング可能。(SATAは深さ32、SASは深さ256のキューが1個)
出典：http://nvmexpress.org/wp-content/uploads/2013/04/IDF-2012-NVM-Express-and-the-PCI-Express-SSD-Revolution.pdf

劇的なIOPS向上
0
100000
200000
300000
400000
500000
600000
700000
800000
IOPS
I/O size=4kBでのIOPS (threads=512)
SAS2 SAS3 NVMe

高負荷でも低レスポンスタイム
0
2
4
6
8
10
12
14
ミリ秒
Response time (I/O size 4kB, thread=512)
SAS2 SSD SAS3 SSD NVMe

Enterpriseで使うポイント①：性能
NVMeの高性能がどこに活きるのかを見極める。
• 高スループットが効果的な用途
 大量なデータの検索・集計が必要なDWHの分析処理
 OLTP処理はデータの大半がキャッシュされるので効果薄
• 高IOPS性能が効果的な用途
 多数の仮想マシンが稼働し、雑多なI/Oリクエストが常に発
生している仮想環境基盤
 同時I/Oリクエスト数が少ない環境ではSASで十分な場合も
• 低レスポンスタイムが効果的な用途
 トランザクションログをシリアルに書き込む必要があるDBの
OLTP処理
 ただしすでにSSD導入済みだと処理時間全体に占める割合は
多くない
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
4k random read
低負荷(16 threads)時のIOPS
SAS3 NVMe

スループットの差をDWHの処理で比較
0
500
1000
1500
2000
2500
SAS2 SAS3 NVMe
秒
TPC-H SF=100GB
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11
Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22

0
2000
4000
6000
8000
10000
12000
14000
SAS2 SAS3 NVMe
TPS (Transactions Per Second)
レスポンスタイムの差をOLTP処理で比較

Enterpriseで使うポイント②：データ保護・拡張性
• 実運用でデータの冗長化は必須
• NVMeは原則RAIDカードを使わない = HW RAIDを組めない
• HW RAIDを組める製品も出てきてはいますが…
• データを冗長化するためにはSW RAIDやその他のソフトウェアによる冗長
化機能が必要
• LinuxのRAID機能 (mdやLVM)
• Windowsの記憶域プール
• Oracle Databaseを使うならOracle ASM
• サーバーを複数台用意してSDS製品を使う(EMC ScaleIOなど)
• データ増加に伴って拡張が可能かも重要な判断材料
• 性能を落とさずにネットワーク越しにNVMeをドライブ可能か？

RAIDはIOPSにインパクト
0
2000
4000
6000
8000
10000
12000
1MB sequential read 1MB sequential write
NVMe４本でのスループット比較
(Threads = 128)
4本単体 4本RAID0
0
500000
1000000
1500000
2000000
2500000
3000000
4kB random read 4kB random write
NVMe 4本でのIOPS比較
(Threads = 128)
4本単体 4本RAID0

NVMeのネットワーク間通信：NVMe over Fabrics
ホスト側ターゲット側
• 従来のiSCSIではせっかくバイパスしたSCSI層
が復活してしまう
• NVMeプロトコルを直接扱い、かつRDMA
(Remote Direct Memory Access)を利用するこ
とで高速に通信が可能になる
• ただしセットアップなど取り扱いが面倒
で、まだ普及しているとはいいがたい…

NVMe-oFを手軽に管理 – KumoScale

NVMe-oF & KumoScaleの威力！
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1MB sequential read 1MB sequential write
NVMe４本、ネットワーク越しの
スループット比較 (Threads = 128)
iSCSI KumoScale
0
50000
100000
150000
200000
250000
300000
350000
400000
450000
4kB random read 4kB random write
NVMe 4本、ネットワーク越しの
IOPS比較 (Threads = 128)
iSCSI KumoScale
※イニシエータ・ターゲット間は40Gb Ethernet１本での接続のため、KumoScaleはネットワークボトルネックの状態。

NVMe-oF & KumoScaleの威力！
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
ミリ秒
iSCSI KumoScale local RAID0
0
0.2
0.4
0.6
0.8
1
1.2
ミリ秒
iSCSI KumoScale local RAID0

NVMeの時代はすでに来ている
• ローカルストレージとしてはすでに実用的に。
• ノード間通信のNVMe-oFはまだ発展途上。KumoScaleに期待。

[db analytics showcase Sapporo 2018] B25　Hadoop上で動く世界最速のAnalytic DBをSparkと一緒に使ってみよう

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [db analytics showcase Sapporo 2018] B25　Hadoop上で動く世界最速のAnalytic DBをSparkと一緒に使ってみよう

Ähnlich wie [db analytics showcase Sapporo 2018] B25　Hadoop上で動く世界最速のAnalytic DBをSparkと一緒に使ってみよう (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)