Dbts2015 tokyo vector_in_hadoop_vortex
5 likes7,872 views
db tech showcase 2015
![セミナーの紹介
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 恵比寿)
お申込みはお手元のアンケートで！](https://image.slidesharecdn.com/dbts2015tokyovectorinhadoopvortex-150611093207-lva1-app6891/85/Dbts2015-tokyo-vector_in_hadoop_vortex-33-320.jpg)
Dbts2015 tokyo vector_in_hadoop_vortex
- 1. みんなが気になる Vector Hadoop SQL Edition (Vortex) の仕組みとパフォーマンス - High Performance SQL on Hadoop - 新久保 浩二
- 2. アジェンダ • VectorやVector Hadoop SQL Editionの概要 • Vector Hadoop SQL Editionのアーキテクチャー • Vector Hadoop SQL Editionの特徴のいくつかをピックアップ • 簡単な疑似ベンチマークの結果 • 2015年の製品ロードマップ
- 3. 質問 • Hadoopを知っている人 • Hadoopを使っている人 • MapReduceを書いたことがある人 • Databaseを知っている人 • Databaseを使っている人 • SQLを書いたことがある人 100% 36% 7% 100% 100% 86% 0% 20% 40% 60% 80% 100% 120% 本セッションの参加者の回答結果を集計
- 4. SQL on Hadoop 概況 http://blogs.gartner.com/merv-adrian/2015/02/22/which-sql-on-hadoop-poll-still-says-whatever-but-dbms-providers-gain/ 今日はココの話
- 5. 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
- 6. 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には未対応
- 7. Vector
- 8. 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の効率化 と運用の簡略化が可能 システムの持つリソースを最大限活用可能
- 9. 他のデータベースとの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
- 10. 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
- 11. Vector Hadoop SQL Editiondoop SQ
- 12. Vector Hadoop SQL Editionの構成 HDFS Name Node Data Node Data Node Data Node YARN SQL on Hadoop Engine MapReduce Tez Spark … 3rd パーティー HDFS Name Node Data Node Data Node Data Node YARN 3rd パーティー Vector Hadoop SQL Editionの場合、YARNは必須ではない
- 13. 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
- 14. 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
- 15. Vectorのパフォーマンスをスケールアウト Vector Hadoop SQL Editionのコンセプトは、 単体で超高速なVectorの並列性をマルチコアレベルから、 マルチコア・マルチノードレベルに拡張する点。
- 16. Vector Hadoop SQL Editionのアーキテクチャー上、全ノードのCPUは非常に効 率良く使われるが、以下のポイントを考慮する必要がある。 ① HDFSへのI/O性能は大丈夫か？ • HDFSのデータのローカリティを確保できるのか？ (I/Oがネットワーク越しになる可能性が高くパフォーマンスへのペナルティが大きい) ② 結合オペレーションのネットワーク転送の制御は大丈夫か？ • テーブルの結合などで、効率の良いローカルノード内での結合を行えるか？ • どうしても発生するテーブルのブロードキャストに対して対策はあるのか？ (どうしてもInternode Communicationが避けられない場合、MPI通信はNative InfiniBand という奥の手もあるが…) Vector Hadoop SQL Editionでの考慮点 YES YES
- 17. 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 ① ②
- 18. データブロックのローカリティを確保する戦略① ① 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
- 19. データブロックのローカリティを確保する戦略① 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);
- 20. データブロックのローカリティを確保する戦略① カスタム 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>
- 21. データブロックのローカリティを確保する戦略② ② 結合オペレーションのネットワーク転送の制御は大丈夫か？ テーブルの結合などで、効率の良いローカルノード内での結合を行えるか？ どうしても発生するテーブルのブロードキャストに対して対策はあるのか？ 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
- 22. HASHキーが不適切な HASHパーティション・テーブル HASHキーが適切な HASHパーティション・テーブル データブロックのローカリティを確保する戦略② 不必要なデータの 配布 Vector (Hadoop SQL Edition)のプロファイリングツールからの抜粋 ネットワーク上を無駄なデータが 送受信されず、ローカルで結合が 完結
- 23. 分析クエリーと”更新可能”な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
- 24. 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上の ファイルにマージ 読み取り時は、各 レイヤーをマージ
- 25. パフォーマンスの比較 ２つのパターンのパフォーマンスを比較 ① 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など)のサポートは、次期リリースにて予定(詳細はロードマップにて)
- 26. パフォーマンスの比較① 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(秒)
- 27. パフォーマンスの比較① 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(秒)
- 28. パフォーマンスの比較② 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%)
- 29. 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)
- 30. 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
- 31. 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での正式な動作保障を確認したい場合は、弊社までご連絡ください！)
- 32. Express Editionの紹介 http://www.actian.com/product-downloads/ - 無料 - Up to 500GB (Vortex) - Community Support - Enterprise Editionより 1世代前のバージョン
- 33. セミナーの紹介 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 恵比寿) お申込みはお手元のアンケートで！
- 34. ？