Dbts2015 tokyo vector_in_hadoop_vortex

みんなが気になる
Vector Hadoop SQL Edition (Vortex)
の仕組みとパフォーマンス
- High Performance SQL on Hadoop -
新久保浩二

アジェンダ
• VectorやVector Hadoop SQL Editionの概要
• Vector Hadoop SQL Editionのアーキテクチャー
• Vector Hadoop SQL Editionの特徴のいくつかをピックアップ
• 簡単な疑似ベンチマークの結果
• 2015年の製品ロードマップ

質問
• Hadoopを知っている人
• Hadoopを使っている人
• MapReduceを書いたことがある人
• Databaseを知っている人
• Databaseを使っている人
• SQLを書いたことがある人
100%
36%
7%
100% 100%
86%
0%
20%
40%
60%
80%
100%
120%
本セッションの参加者の回答結果を集計

SQL on Hadoop 概況
http://blogs.gartner.com/merv-adrian/2015/02/22/which-sql-on-hadoop-poll-still-says-whatever-but-dbms-providers-gain/
今日はココの話

Vortex
Analytics Workbench
Open SourceのKNIMEにアドオンする形式のHadoop上のデータを使用したETLや分析が可能にな
るワークベンチ。DataFlow Engineと合わせて使用する。
DataFlow Engine
Hadoop上のデータを非MapReduceで高速に処理可能な独自の分散実行エンジン。上記のワーク
ベンチと組み合わせることで、コーディング無しにETL、分析ワークフローの作成が可能。
Vector Hadoop SQL Edition
Hadoop上のデータをSQLで処理可能なSQL実行エンジン
SQL Vector Hadoop SQL Edition
Hadoop上のデータをSQLで処理可能なSQL実行エンジン。高速なVectorをHadoop上でスケール
アウト可能。
SQL
VortexとVector Hadoop SQL Edition

Vector Hadoop SQL Editionの特徴
• HDFS上のデータを直接SQLでアクセス(Hadoop 2.0以降をサポート*1)
• 分散実行エンジンはMapReduceではなく独自実装
• VectorのパフォーマンスをHadoopクラスター上の全ノードで実現
• VectorでHDFSのスケーラビリティと高可用性を活用
• Vectorのカラムナー＆圧縮フォーマットをそのままHDFS上で実現
• データブロックのローカリティを確保する戦略
• 分析クエリーとACID対応の”更新可能”なDML文のサポート
• YARNによるリソースマネージメント
*1) MapRについてはMapR 4.0以降をサポート。ただし現バージョン(Vector Hadoop SQL Edition 4.1)
ではMapRのYARNには未対応

Vector(Standalone Database)の概要
Time/CyclestoProcess
Disk
RAM
Chip
10GB2-3GB40-400MB
2-20150-250Millions
Vector処理の活用
CPU Cacheの活用
カラムナーデータベース
データの自動圧縮
ストレージインデックス
マルチコア並列処理
CPU使用効率を高めるためにVector(SIMD)
処理を活用
CPU使用効率を高めるためにCPU Cacheを
有効活用
クエリー処理に必要なI/Oのみ実行するため、無駄なI/Oが発生させ
ないデータ構造
データの自動圧縮により、ストレージ使用効率の向上と、I/O量の
削減、および圧縮によるキャッシュ効率を飛躍的に高める
自動的に作成されるストレージインデックスにより、I/Oの効率化
と運用の簡略化が可能
システムの持つリソースを最大限活用可能

他のデータベースとのCPU命令数の比較
1
9 7
29
102
68
0
20
40
60
80
100
120
0.0E+00
5.0E+11
1.0E+12
1.5E+12
2.0E+12
2.5E+12
3.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
CPU
Instructions
Vectorとの
比較(倍)
昨年のdb tech showcase 2014 “Actian Vectorで得られるBIにおける真のパフォーマンスとは”より抜粋
http://www.slideshare.net/kshinkub/db-tech-showcase2014a14actian-vectorbi-36004866
select
sum(l_extendedprice * l_discount) as revenue
from
lineitem ← (80GB , 6億件)
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

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.0E+00
5.0E+01
1.0E+02
1.5E+02
2.0E+02
2.5E+02
3.0E+02
3.5E+02
4.0E+02
4.5E+02
5.0E+02
Columnar DB A Columnar DB B
In Memory DB
A
Row Store DB A Row Store DB B
Rt=Instructions / (IPC * Hz * Parallelism)
Parallelismは各データベースのEditionやデータの状況にもよ
るので、あくまでも参考値です。
Elapsed Time(秒) Vectorとの
比較(倍)
他のデータベースとの応答時間の比較
昨年のdb tech showcase 2014 “Actian Vectorで得られるBIにおける真のパフォーマンスとは”より抜粋
http://www.slideshare.net/kshinkub/db-tech-showcase2014a14actian-vectorbi-36004866

Vector Hadoop SQL Editiondoop SQ

Vector Hadoop SQL Editionの構成
HDFS
Name Node Data Node Data Node Data Node
YARN
SQL on
Hadoop
Engine
MapReduce Tez Spark … 3rd パーティー
HDFS
YARN
3rd パーティー
Vector Hadoop SQL Editionの場合、YARNは必須ではない

Vector Hadoop SQL Editionの構成(各ノードズーム)
HDFS
Vector-H
master
Vector-H
Worker(x100)
Vector-H
Worker(x100)
Vector-H
Worker(x100)
HDFS I/O APIHDFS I/O API
JDBC/ODBC
All to All MPI (Infiniband ready)
Ethernet

Vector Hadoop SQL Editionの構成(さらにズーム)
Data Node(Vector-H Master)
JDBC/ODBC
Data Node (1 .. N)
Vector-H Master
Vector-H Worker(x100) Vector-H Worker(x100)
SQL Parser (Parse Tree)
Optimizer (Query Plan)
Cross Complier (x100 Algebra)
Distributed Rewriter
(Annotated Query Tree)
Builder (Operator Tree)
Execution Engine (Data)
Rewriter
Builder (Partial Operator Tree)
Execution Engine
MPI
MPI
(Partial Result Set)
MPI
(Internode Communication)
Buffer Manager (I/O) Buffer Manager

Vectorのパフォーマンスをスケールアウト
Vector Hadoop SQL Editionのコンセプトは、
単体で超高速なVectorの並列性をマルチコアレベルから、
マルチコア・マルチノードレベルに拡張する点。

Vector Hadoop SQL Editionのアーキテクチャー上、全ノードのCPUは非常に効
率良く使われるが、以下のポイントを考慮する必要がある。
① HDFSへのI/O性能は大丈夫か？
• HDFSのデータのローカリティを確保できるのか？
(I/Oがネットワーク越しになる可能性が高くパフォーマンスへのペナルティが大きい)
② 結合オペレーションのネットワーク転送の制御は大丈夫か？
• テーブルの結合などで、効率の良いローカルノード内での結合を行えるか？
• どうしても発生するテーブルのブロードキャストに対して対策はあるのか？
(どうしてもInternode Communicationが避けられない場合、MPI通信はNative InfiniBand
という奥の手もあるが…)
Vector Hadoop SQL Editionでの考慮点
YES
YES

Vector Hadoop SQL Editionでの考慮点
Data Node(Vector-H Master)
JDBC/ODBC
Data Node (1 .. N)
Vector-H Master
Vector-H Worker(x100) Vector-H Worker(x100)
SQL Parser (Parse Tree)
Optimizer (Query Plan)
Cross Complier (x100 Algebra)
Distributed Rewriter
Builder (Operator Tree)
Execution Engine (Data)
Rewriter
Builder (Partial Operator Tree)
Execution Engine
MPI
MPI
(Partial Result Set)
MPI
(Internode Communication)
Buffer Manager (I/O) Buffer Manager
①
②

データブロックのローカリティを確保する戦略①
① HDFSへのI/O性能は大丈夫か？
HDFSのデータのローカリティを確保できるのか？
HASHパーティション・テーブルカスタム Block Placement
- Table A Hash #1
- Table B Hash #1
- Table A Hash #2
- Table B Hash #2
- Table A Hash #3
- Table B Hash #3
例)
Partition数=4
HDFS Replication Factor=2
A #1 A #1A #2 A #2A #3
Node #1 Node #2 Node #3
- Table A Hash #4
- Table B Hash #4
A #3
Node #4
A #4A #4
B #1 B #1B #2B #3 B #3B #4 B #4B #2

HASHパーティション・テーブル
単一のカラムもしくは複数のカラムを指定して、パーティション数を指定する。
パーティション化できる種類はHASHのみサポート。
HASHパーティションなので、ある程度、値が分散しているほうが望ましい(Primary KeyやForeign Key)
など。また、パーティション数の推奨値は以下の計算式で求める。
パーティション数 = ノード数 * 物理コア数/ノード
パーティション・テーブルのサンプル)
create table sample_table
(column_1 int primary key
,column_2 varchar(100)
) WITH PARTITION=(HASH on column_1 16 PARTITIONS);

カスタム Block Placement
各ノードが担当するHASH値を割り当てる。
HASH値に該当するHDFS上のファイルのレプリカを自身が保持するようNameノードにヒントを与える。
• 現時点でカスタムBlock PlacementはHadoop2.2のみサポート。2.4～2.6は次期リリース以降でサポート予定
• 現時点でカスタムBlock Placementは手動での設定が必要(Nameノードに必要なjarの配置とhdfs-site.xmlの編集)
• カスタムBlock PlacementはYARNが有効になっている環境のみサポート
hdfs-site.xmlに以下のプロパティを設定)
<configuration>
<property>
<name>dfs.block.replicator.classname</name>
<value>org.apache.hadoop.hdfs.server.blockmanagement.VWBlockPlacementPolicy</value>
</property>
</configuration>

データブロックのローカリティを確保する戦略②
② 結合オペレーションのネットワーク転送の制御は大丈夫か？
テーブルの結合などで、効率の良いローカルノード内での結合を行えるか？
どうしても発生するテーブルのブロードキャストに対して対策はあるのか？
HASHパーティション・テーブルレプリケーション・テーブル
同一のHASHキーを持つテーブルの結合に関して
ローカル結合となる。通常HASHキーは
Primary/Foreignキーに設定する。
Node #1
A @Hash#1
B @Hash#1
Node #2
A @Hash#2
B @Hash#2
Node #3
A @Hash#3
B @Hash#3
JOIN JOIN JOIN
どうしてもHASHキーを設定できない結合の場合、
結合対象が小さい(マスターのような)場合は、全
ノードにレプリケーションして配置して、ブロー
ドキャストを抑えつつローカル結合とする。
Node #1
A @Hash#1
B @ALL
Node #2
A @Hash#2
B @ALL
Node #3
A @Hash#3
B @ALL
JOIN JOIN JOIN

HASHキーが不適切な
HASHキーが適切な
データブロックのローカリティを確保する戦略②
不必要なデータの
配布
Vector (Hadoop SQL Edition)のプロファイリングツールからの抜粋
ネットワーク上を無駄なデータが
送受信されず、ローカルで結合が
完結

分析クエリーと”更新可能”なDML文のサポート
分析クエリー
Vector Hadoop SQL EditionはVector同様にSQL-92レベルのフルサポートとCUBE、ROLLUP、LAG、
LEAD、GROUPING SET、およびWindow関数をサポートしています。
サポートしているSQL関数は以下のドキュメントで確認可能です。
http://docs.actian.com/#b78023t22329n/s-1/s6421/s6422/s6422b343149/s6422b343169
SQL
更新可能なDMLのサポート
Vector Hadoop SQL EditionはHDFS上のデータであっても、ACIDトランザクション、MVCCを備え、
DML(INSERT、UPDATE、DELETE)を実行することが可能です。DMLはVectorの持つPDT(Positional Delta
Tree)と呼ばれるインメモリデータ構造により実現されています。
* ただし、3rdパーティーのレプリケーション製品のように、Vector Hadoop SQL Editionに定常的かつ大量にDMLを発行する場合は、
パフォーマンスについて考慮が必要になる場合があります
* DELETEを実行してもHDFS上の使用領域が減少するわけではないので、ストレージに使用率を下げたい場合は定期的なメンテナンス
が必要になります
DML

Positional Delta Tree(PDT)
Positional Delta Tree(PDT)の仕組み
Vectorの更新には、２つのタイプが存在します。
- BULK更新処理
- BATCH更新処理
BULK更新処理とはローダーにより一括データ投入や、
INSERT … SELECT * FROM xのような処理を意味します。
BATCH更新処理とは、一件ごとのINSERT、UPDATEや
DELETEを意味します。
BATCH処理の場合は、PDTと呼ばれるメモリー上のデータス
トアにて処理され、永続的なストレージ(この場合はHDFS上)
には、非同期で書き出されます。
HDFSは追記のみ可能ですので、Vectorも更新データは追記
のみ行い。追記時にマージ処理が行われます。
PDT
HDFS DATA LOG
READ
PDT
WRITE
PDT
① commit
② PDTと同時に
Transactionログに書
き出し
③ WRITE PDTのしき
い値によりREAD
PDTに移動
④ READ PDTのしき
い値によりHDFS上の
ファイルにマージ
読み取り時は、各
レイヤーをマージ

パフォーマンスの比較
２つのパターンのパフォーマンスを比較
① Impalaと比較してのパフォーマンス
② Vector-Hのノード数を変えて、スケーラビリティの比較
■ 使用したテスト環境は全てAWSのhi1.4xlargeインスタンス
- Impalaは最新版(2.2)を使用するためEC2上のCDH5.4上に構築
(データフォーマットはParquet)
- Vector-HはAmazon Elastic MapReduce(EMR) Hadoop 2.2上に構築
(データフォーマットはVector独自のカラムナー＋圧縮フォーマット
現時点で他のフォーマットは未サポート*1)
■ 使用したデータはTPC-H 500GB相当。クエリーはTPC-Hに準ずる22種類
*1) 他のデータフォーマット(ORCFileやParquetなど)のサポートは、次期リリースにて予定(詳細はロードマップにて)

パフォーマンスの比較①
0.00
200.00
400.00
600.00
800.00
1000.00
1200.00
1400.00
1600.00
1800.00
2000.00
q1 q2 q3 q4 q5 q6 q7 q8 q9 q10 q11 q12 q13 q14 q15 q16 q17 q18 q19 q20 q21 q22
疑似TPC-H@500/5Nodes(Impalaの1800秒は、30分待っても返ってこなかったもの)
Impala 2.2 Vector-H 4.1
19,580秒(Impala 2.2) vs. 172秒(Vector-H)
Avg. x114
Elapsed time(秒)

パフォーマンスの比較①
1,580秒(Impala 2.2) vs. 63秒(Vector-H)
Avg. x25
0.00
100.00
200.00
300.00
400.00
500.00
600.00
700.00
q1 q2 q6 q8 q11 q13 q14 q15 q16 q17 q20 q22
疑似TPC-H@500/5Nodes(正常に返ってきたもののみ)
Impala 2.2 Vector-H 4.1Elapsed time(秒)

パフォーマンスの比較②
0.00
20.00
40.00
60.00
80.00
100.00
120.00
140.00
160.00
180.00
200.00
5 10 15
ノード数によるスケーラビリティElapsed time(秒)
Node数
172秒 126秒(73%) 96秒(56%)

Vector Hadoop SQL Edition のロードマップ①
パフォーマンスの最適化
・さらなるクエリー速度の向上
・I/O効率の最適化(外部表)
DataFlowのより密な統合
外部表のサポート
YARNのより密な最適化
セキュリティの向上
Hadoop管理の統合
・ソート処理の効率化
・DataFlow処理の効率化
・DataFlowのロード処理の高速化
(現在のようなHDFS上への一時データ作成を廃止)
・Flat file(TEXT), SequenceFile, ORCFile or Parquet
フォーマットを外部表としてサポート
・YARNのリソース使用率の最適化
・動的なノードのバランシング(ノード障害時など)
・カラムレベルの暗号化(AES 128,192,256)
・クエリーレベルの監査
・デプロイ作業におけるAmbariとの統合
2015年上半期 (Version 4.2)

Vector Hadoop SQL Edition のロードマップ②
ベンチマークの公表
・VectorおよびVector-HにてTPCベンチマークの公表
クラウドでの動作・管理
Vectorブロックフォーマット
の公開
ユーザー定義関数のサポート
セキュリティの向上
さらなるパフォーマンス向上
・Private Cloud(OpenStack & vCloud)への最適化
(合わせてPublic Cloudへの最適化も予定 – Phase2)
・直接Vectorのデータファイルにアクセス可能なAPIを
提供予定(Phase1->Read, Phase2 -> Read/Write)
・Phase1としてSpark
・Phase2としてMatrixのようなC++
・粒度を指定可能な監査(例ユーザー別、テーブル別)
・Hadoopのセキュリティ(Knox, Sentry)の統合
・パフォーマンスの継続的な向上
・同時実行性の継続的な向上
2015年下半期
TPC UDF

EMR上でVector-Hをインストールする際のTips
- sshの設定を変更
- Vector Hadoop SQL Editionでは、Workerの自動インストール時にsshを使用します。
- その際、パスワード認証のみですので、sshd_configをパスワード認証可能に設定しておいてください。
- また、sshd_configでrootユーザーのssh接続(パスワード認証)を有効にしておいてください。
- rootのパスワードを設定すべし
- 上記のssh接続(WorkerノードでOSユーザーの作成等)のために、rootのパスワードを設定しておいてください。
- EMRの場合、Installerの自動並列度は1になってしまうので、手動で変えるべし
- Installerではほぼ、デフォルトで問題ないですが、EMRの場合max_parallelismの値が1と取得されるため、
手動で、Install画面で、インスタンス内のコア数を入れるようにしてください。
- YARN enableでインストールした場合は、以下のパーミッションを変えるべし
- YARNをenable(デフォルト:disable)に設定した際は以下のディレクトリに起動ユーザーで書き込み権限が必要です。
/mnt/var/lib/hadoop/tmp 、 /mnt/var/em/raw
- 言い忘れましたが…
- EMRは、Actian社の推奨Hadoopディストリビューションには入っていません！
(どうしても、EMRでの正式な動作保障を確認したい場合は、弊社までご連絡ください！)

Express Editionの紹介
http://www.actian.com/product-downloads/
- 無料
- Up to 500GB (Vortex)
- Community Support
- Enterprise Editionより
1世代前のバージョン

セミナーの紹介
2015年6月30日 14:00 – 17:30
@EBiS 303カンファレンスルーム(恵比寿)
参加費: 無料
URL: http://www.insight-tec.com/events-seminars/20150630_bpa.html
プログラム
[キーノート] ビッグデータプロジェクトを加速させるための仕組みと運用
-米国の最新フレームワーク動向とデータアドミニストレータの役割の変化-
特定非営利活動法人ヘルスケアクラウド研究会理事博士(医薬学) 笹原英司様
[ユーザ事例] 1000万人規模の医療ビッグデータ活用までの道のり
メディカル・データ・ビジョン株式会社 EBM事業部長中村正樹様
データ分析に最適な基盤とは？
-コスト/スピードでビジネスバリューを得るために-
株式会社インサイトテクノロジー CTO 石川雅也
BigData Project Accelerator
医療業界の最先端事例から学ぶプロジェクトを加速させる要因
2015年6月30日(火) 14:00 – 17:30
@ EBiS303 カンファレンスルーム (in 恵比寿)
お申込みはお手元のアンケートで！

Dbts2015 tokyo vector_in_hadoop_vortex

More Related Content

What's hot

Viewers also liked

Similar to Dbts2015 tokyo vector_in_hadoop_vortex

More from Koji Shinkubo

Dbts2015 tokyo vector_in_hadoop_vortex