みんなが気になる

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

Vector(Standalone Database)の概要T

ime

/ C

ycl

es

to

Pro

cess

Disk

RAM

Chip

10GB2-3GB40-400MB

2-2

01

50

-25

0M

illio

ns

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 BIn 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 BIn Memory DB

ARow 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の構成

HDFSName Node Data Node Data Node Data Node

YARN

SQL on

Hadoop

EngineMapReduce Tez Spark … 3rd パーティー

HDFSName Node Data Node Data Node Data Node

YARN

3rd パーティー

Vector Hadoop SQL Editionの場合、YARNは必須ではない

Vector Hadoop SQL Editionの構成(各ノードズーム)

HDFS

Name Node Data Node Data Node Data Node

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 (Annotated Query Tree)

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(Annotated Query Tree)

Builder (Operator Tree)

Execution Engine (Data)

Rewriter

Builder (Partial Operator Tree)

Execution Engine

MPI (Annotated Query Tree)

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パーティション・テーブル

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 恵比寿)

お申込みはお手元のアンケートで！

？