Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

sparksql-hive-bench-by-nec-hwx-at-hcj16

8,014 views

Published on

SparkSQL and Hive on Tez, LLAP Benchmark

Published in: Software

sparksql-hive-bench-by-nec-hwx-at-hcj16

  1. 1. 新郷 美紀 NEC 蒋 逸峰 Solutions Engineer, Hortonworks ビッグデータ可視化 の性能を徹底検証 〜SparkSQL、Hive on Tez、Hive LLAPを用いた既存RDBデータ 処理の特徴〜
  2. 2. Agenda • 初めに • 背景 • クラウドDWH と Hiveとの比較 • 性能改善 – SparkSQL – Hive on Tez – Hive LLAP • まとめ Page. 2
  3. 3. はじめに • Hortonworks、NECの両社が本資料の内容を 保障するものではございません。 • 資料中、“大人の事情”で詳細を記載できな い部分があります。ご了承ください • つきましては、きわどい質問はご容赦ください。 Page. 3
  4. 4. 発表者 氏名: 新郷 美紀 略歴: ビッグデータ歴2年。当社の1ラックに700サーバ以上搭載可能な 大規模システムのソリューション検討でHadoop, Sparkと出会う。 以降、ビッグデータソリューションアーキテクトとして活動。 分散処理系と、分析基盤系のソリューションのアーキテクチャ検 討・実装。 今の注力技術はSparkとラムダ・アーキテクチャ。 現在、Open Data Platform Initiativesのメンバーとしても活動中。 趣味: ルネッサンス時代のヨーロッパの音楽を聴いたりと絵を見ること。 バッハよりジョスカンが好き。ラッセンよりフェルメールが好き。 Page. 4
  5. 5. 発表者代理 所属:NEC ソリューションイノベータ 名前:家志 門太(やし もんた) CGやったり もんた(@___monta___) FPGAやったりインフラSEやったり
  6. 6. 背景
  7. 7. データ Page. 7 10^5倍
  8. 8. 増え続けるデータ 4ZB DATAINTERNET OF ANYTHING 44ZB DATA TOMORROW Page. 8
  9. 9. 商用 サポートSIベンダ コミュニティ 活用の機運が高まっている Page. 9
  10. 10. 本題
  11. 11. 実案件でのご相談 商用DWHをOSSで置き換えられないか? DWH Page. 11
  12. 12. 実用性の検証方法 評価用の環境にて同じクエリを実行 Page. 12 DWH
  13. 13. 評価対象のデータ スタースキーマの評価用データを準備 LINEORDER Table CUSTOMER Table SUPPLIER Table PART Table DATE_DIM Table データ作成プログラム:dbgen http://www.cs.umb.edu/%7Eponeil/dbgen.zip C_CUSTKEY C_NAME ・・・他 全8項目 S_SUPPKEY S_NAME ・・・他 全7項目 D_DATEKEY D_DATE ・・・他 全17項 P_PARTKEY P_NAME ・・・他 全9項目 LO_ORDERKEY LO_LINENUMBER LO_CUSTKEY LO_PARTKEY LO_SUPPKEY LO_ORDERDATE ・・・ 他 全17項目 51億件/515.8GB 2,500万件/2.3GB 170万件/139.8MB 2.5千件/224.6KB 200万件/165.4MB Page. 13
  14. 14. Tableauの設定 テーブルの連携と、処理/可視化を簡単に設定 Page. 14
  15. 15. Tableauの設定 テーブルの連携と、処理/可視化を簡単に設定 Page. 15
  16. 16. DWH Hive DWH 評価環境 概略 評価環境のソフトウェアスタック HDP Version 2.3.4 JDK 1.8 CentOS7.2 物理サーバ JDK 1.8 CentOS7.2 物理サーバ JDK 1.8 CentOS7.2 物理サーバ Yarn、HDFS Hive on Tez(標準) サーバサーバ 大人の事情 により・・・ サーバサーバ Page. 16
  17. 17. 評価環境のハードウェアスペック DWH Hive 評価環境概略 Atom C2730(1.7GHz) 32GB SSD 128GB 2.5GbE Xeon 約4Ghz相当 × 2 15GB SSD 160GB 10GbE × 1 4ノード Page. 17 2U 1シャーシ ( 40 micro modular server)
  18. 18. クエリ内容 Tableauから投入するクエリ PARTテーブルのレコードを3/92に絞り 込んだのち4マスタ連携 ・ヒット件数2.1億件 ・集計結果75件 クエリ1 クエリ2 PARTテーブルのレコードを3/92に絞り 込んだのち2マスタ連携 ・ヒット件数2.1億件 ・集計結果75件 Page. 18
  19. 19. 評価結果 0 200 400 600 800 1,000 1,200 1,400 1,600 1,800 クエリ1(4マスタ結合) クエリ2(2マスタ結合) 処理時間(秒) DWHと “デフォルト設定”のHive性能比較 ×4.0倍 ×7.7倍 Faster 遅い 遅い Page. 19
  20. 20. 性能改善
  21. 21. Hortonworks Japanとの会話 「Hadoop Conferenceでこの性能改 善について発表しませんか」 のお誘い ※この時点で1か月前 Page. 21
  22. 22. 性能比較の環境 3つの環境で比較 データ ウェアハウス Page. 22 SQL 環境 サーバ サーバ サーバ サーバ Hive環境
  23. 23. SQL Page. 23
  24. 24. SQL Sparkの評価構成 Hadoop HDP Version 2.3.4 JDK 1.8 CentOS7.2 物理サーバ JDK 1.8 CentOS7.2 物理サーバ JDK 1.8 CentOS7.2 物理サーバ Yarn、HDFS Spark 1.5.2 Hive(thrift server) 1.2.1 Page. 24
  25. 25. SQL 評価結果まとめ 0 100 200 300 400 500 600 700 800 900 1,000 ヒット件数 多 (51億件) ヒット件数 中 (2.1億件) ヒット件数 少 (25百万件) 処理時間(秒) DWHとSparkSQLの比較 DWH SparkSQL Page. 25 4マスタ連携 42% 75% 70%
  26. 26. SQL 評価結果まとめ 0 100 200 300 400 500 600 ヒット件数 多 (51億件) ヒット件数 中 (2.1億件) ヒット件数 少 (25百万件) 処理時間(秒) DWHとSparkSQLの比較 DWH SparkSQL Page. 26 2マスタ連携 48% 73% 67%
  27. 27. SQL サーバ負荷状況
  28. 28. SQL チューニングポイント(Thrift Serverの起動引数) 項目 設定項目 意味 デフォルト 設定値 エグゼキュータ の並行処理数 --num-executors エグゼキュータの処理プロセス 数 --num-executors 2 --num-executors 76 --executor-cores エグゼキュータの1プロセスあた り、何スレッドで処理をするかの 設定数 --executor-cores 1 --executor-cores 4 エグゼキュータ のメモリ量 --executor-memory エグゼキュータの1プロセスが使 用するメモリ量の設定 1GB 10GB ドライバのメモ リ量 --driver-memory ドライバのプロセスが使用する メモリ量の設定 1GB 20GB ブロードキャス ト結合 spark.sql.autoBroa dcastJoinThreshold 指定値より小さいサイズのテー ブルを全エグゼキュータに配布 しハッシュ結合を行う。それによ り、シャッフルは行われない。 10MB 512MB パーティション 数 spark.sql.shuffle.p artitions Joinや集計時のPartitioin数。 200 2000 データフォー マット Parquet カラムベースのデータ格納方式 を指定 - - Page. 28
  29. 29. Hadoop SQL エグゼキュータ/ドライバの設定値 管理ノード Slave node Slave node ドライバ エグゼキュータ エグゼキュータ SparkContext メモリ容量 --executor-memory 割り当てるコア数 --executor-cores メモリ容量 --driver-memory エグゼキュータ エグゼキュータの数 --num-executors Page. 29
  30. 30. SQL ブロードキャスト結合パラメータの効果 デフォルト時のDAG パラメータ設定時のDAG Page. 30
  31. 31. SQL spark.sql.shuffle.partitionsの効果 Page. 31 0 100 200 300 400 500 600 700 200 500 1000 1500 2000 2500 3000 3500 4000 処理時間(秒) spark.sql.shuffle.partitions 設定値 4マスタ連携 2マスタ連携 (default)
  32. 32. SQL データフォーマット(Parquet) の効果 0 100 200 300 400 500 600 デフォルト設定 Parquet指定 読み込みデータ量(GB) 0 0.5 1 1.5 2 2.5 3 デフォルト設定 Parquet指定 処理時間(分) 90%カット 50%カット Page. 32
  33. 33. 所感 • Driverのメモリ設定も重要 • 今回は「CHCHE TABLE XXX」は効果なし。 • 1.5以降は「spark.sql.tungsten.enabled」はデ フォルトでenable
  34. 34. 自己紹介 蒋 逸峰(しょう いつほう / Yifeng Jiang) • Solutions Engineer, Hortonworks • Apache HBase本の作者 • 日本に来て10年経ちました… • 趣味は山登り • Twitter: @uprush Page. 34
  35. 35. Apache Hive Page. 35
  36. 36. Hive on Tez / LLAP Hiveの評価構成 Hadoop HDP Latest Build JDK 1.8 CentOS6.7 物理サーバ JDK 1.8 CentOS6.7 物理サーバ JDK 1.8 CentOS6.7 物理サーバ Yarn、HDFS Tez / LLAP Hive Page. 36
  37. 37. Hive on Tez / LLAP 評価結果まとめ(4マスタ連携) Page. 37 0 100 200 300 400 500 600 700 800 900 1000 ヒット件数 多(51億件) ヒット件数 中(2.1億件) ヒット件数 少(2.5千万件) 処理時間(秒) DWHとHive on Tez / LLAPの比較(4マスタ連携) DWH Hive on Tez Hive LLAP
  38. 38. Hive on Tez / LLAP 評価結果まとめ(2マスタ連携) Page. 38 0 100 200 300 400 500 600 ヒット件数 多(51億件) ヒット件数 中(2.1億件) ヒット件数 少(2.5千万件) 処理時間(秒) DWHとHive on Tez / LLAPの比較(2マスタ連携) DWH Hive on Tez Hive LLAP
  39. 39. Hive クエリの実行 Hiveクエリ実行の流れ • Hive にデータをロード [ 超重要 ] • クライエント側の実行 [ 正しくやれば 0s ] • オプティマイゼーション [HiveServer2] [~ 0.1s] • メタデータ問合せ [Hcatalog, Metastore] [ Hive 0.14~ は非常に速い ] • Application Master 作成 [4-5s] • Container のアロケーション [3-5s] • クエリを分散実行エンジン上に実行 YARN and HDFSClient Beeline / BI tool JDBC/ODBC Metastore Metastore DB HiveServer2 Server #2 Tez AM Tez Container / LLAP … Tez Container / LLAP Page. 39
  40. 40. Hive チューニング Hiveの基本チューニングポイント • Hiveにデータをロード – パーティション – ORCとしてストア • クエリ実行 – 分散実行エンジン: Tez / LLAP (MR使っている方は今すぐ Tezへ切替を!) – Cost Based Optimizer (CBO) – Vectorized Query Execution Page. 40
  41. 41. Hive データロード 正しいロードはすべての基礎 • パーティションを切る • ORCに変換 ただ3つのステップ 1. CSV/JSONファイルをHDFSに 2. Text形式のHive外部テーブルを作 成し、CSV/JSONフォルダにロケー ションを指定 3. TextデータをORCテーブルに変換 3-1) ORC table作成 CREATE TABLE orc_lineorder( key INT, linenumber INT, customer INT, ... ) PARTITIONED BY (orderdate STRING) STORED AS ORC; 3-2) Text データを ORC に変換 INSERT INTO orc_lineorder PARTITION (orderdate) SELECT key, linenumber, …, orderdate from csv_lineorder; Page. 41
  42. 42. Hiveパーティション パーティションあり パーティションなし 143 Map tasks 2 Map tasks パーティション項目が絞込条件で 必要のないデータ読込みをスキップ WHERE ((part.color IN ('black', 'blue', 'brown')) AND (customer.nation IN ('ALGERIA', 'ARGENTINA', 'BRAZIL'))) Page. 42
  43. 43. 0 50 100 150 200 250 Before After 処理時間 (秒) 0 100 200 300 400 500 600 Text ORC HDFS READ (GB) ORC ファイルフォーマット Hadoopのカラム型ファイルフォーマット ORC の効果 83%カット 53%カット Page. 43
  44. 44. CBOの効果 • データ統計をみてDAGを自動的に調整 • 最適な実行プランを自動生成 Map Join に変換 Reduce数 が1009から 97に減少 CBO なし CBO あり Page. 44
  45. 45. CBOの効果 • CBO を有効にした場合、処理が18%高速 • 複雑なクエリは特に有効 – 例:BIツールで生成されたジョイン多数のクエリ 0 100 200 300 400 500 600 700 800 Hive LLAP Hive LLAP (CBO enabled) 処理時間(秒) CBOあり/なしの比較 (4マスタ連携、51億件ヒット) 18%カット Page. 45
  46. 46. Apache Tez アプリケーションのための分散処理フレームワーク • エンドユーザーではなく、フレームワークやアプリケーション開発のためのフレー ムワーク • Hive on Tez, Pig on Tez, Cascading on Tez, … MapReduceでの経験や教訓をもとに • パフォーマンスの大幅な向上 • HDFSに中間データを出力しなくてもOK • バッチだけでなくインタラクティブな処理にも • ペタバイト規模までスケール Run on YARN • クラスタのリソースを有効に活用 Page. 46
  47. 47. Tez チューニング Tez の基本チューニングポイント • Application Master 作成 [4-5s] – Tez セッションの暖機運転 – Tez セッションの再利用 • Container アロケーション [3-5s] – Tez container の再利用 • Tez container サイズ – Container の数(即ち同時実行数)が変わる Page. 47
  48. 48. Tez Container 再利用 • 処理完了のcontainerをキープし、次のタスクが来たらすぐ処 理できる仕組み • 同じセッションのタスクのみ • 今回は逆効果  – 毎回Tableauを立て直したうえでの評価 – セッションが異なるため効果なし – アイドルのcontainerがリソースを専有し、新しいクエリがリソース待ち 状態が発生 • クライエント側のコネクションの使い回しが大事 Page. 48
  49. 49. Tez Container再利用の効果 • Container 再利用が有効の場合、処理が数十秒〜2分速い • J/ODBC Pool(使い回し) を利用するアプリは特に有効 – 例:JDBC Poolを有効にした BI ツールやAPIサーバーなど 0 100 200 300 400 500 600 700 ヒット件数 多(51億件) ヒット件数 中(2.1億件) ヒット件数 少(2.5千万件) 処理時間(秒) Tez Container Reuseの比較 Hive Beeline (container reuse) Tableau (non-reuse this time) Page. 49
  50. 50. Hive LLAP Page. 50
  51. 51. Hive LLAP HDFS LLAPは複数のYARN Container上でデーモンとし て動作し、Tezタスクの高速化を行う Node Hive Query Contain er Contain er Contain er Contain er LLAP LLAP LLAP LLAP LLAP = Live Long and Prosper Live Long And Process YARN Cluster Container デーモン上 でのクエリ フラグメント の実行 インメモリ のキャッ シュ Page. 51
  52. 52. LLAPによるクエリ実行 1. Hiveserver2がクエリ受付 2. Hiveserver2がクエリのコンパイル と最適化を実行 3. 各クエリはそれぞれ別のTez AMに よって処理が受け付けられる 4. Hive(Tez)アプリケーションの実行 開始 5. Hiveがクエリフラグメントの実行場 所を決定 (LLAP, Tez Container, AM) HiveServer Query/AM Controller Client(s) YARN Cluster AM1 llapd llapd llapd Container AM1 Container AM1 llapd Container AM2 AM2 Page. 52
  53. 53. Hive LLAPのメリット スケーラブルな処理フレームワークであるTezに対し て、LLAPは以下のパフォーマンスメリットを提供する • クエリ実行までの準備時間の短縮 • カラムナ型で保持するキャッシュ • デーモン(永続)プロセスの利点を活かした最適化 – JIT, concurrent I/O, etc. Page. 53
  54. 54. まとめ Page. 54
  55. 55. 性能結果まとめ 今回の検証では • SparkSQLは平均的にいい 感じ • Hive on Tezも速い、特に ヒット件数少ない場合は優 秀 • LLAPはヒット件数少ない場 合、Hive on Tezより更に倍 速い 0 100 200 300 400 500 600 700 800 900 1000 ヒット件数 多(51 億件) ヒット件数 中(2.1 億件) ヒット件数 少(2.5 千万件) 処理時間(秒) 性能比較まとめ(4マスタ連携) DWH Hive on Tez Hive LLAP SparkSQL 0 100 200 300 400 500 600 ヒット件数 多(51 億件) ヒット件数 中(2.1 億件) ヒット件数 少(2.5 千万件) 処理時間(秒) 性能比較まとめ(2マスタ連携) DWH Hive on Tez Hive LLAP SparkSQL Page. 55
  56. 56. まとめ やっぱりSpark / Hadoopいいね • SparkSQL いいね! • Hive on Tez も速いですね! • LLAPはHiveを更に高速化させていく それぞれ特徴あるSQLエンジン • まず試してみよう • 特徴を理解したうえでの検証・利用が重要 今後やってみたいこと ・Xeon系CPUでの評価(atomとの特性の違い確認) ・マルチユーザでの評価 Page. 56
  57. 57. ご清聴ありがとうございました
  58. 58. 付録 Page. 58
  59. 59. 評価用テーブル詳細 CUSTOMER表 C_CUSTKEY C_NAME C_ADDRESS C_CITY C_NATION C_REGION C_PHONE C_MKTSEGMENT SUPPLIER表 S_SUPPKEY S_NAME S_ADDRESS S_CITY S_NATION S_REGION S_PHONE PART表 P_PARTKEY P_NAME P_MFGR P_CATEGORY P_BRAND1 P_COLOR P_TYPE P_SIZE P_CONTAINER DATE_DIM表 D_DATEKEY D_DATE D_DAYOFWEEK D_MONTH D_YEAR D_YEARMONTHNUM D_YEARMONTH D_DAYNUMINWEEK D_DAYUNMINMONTH D_DAYNUMINYEAR D_MONTHNUMINYEAR D_WEEKNUMINYEAR D_SELLINGSEASON D_LASTDAYINWEEFL D_LASTDAYINMONTHFL D_HOLIDAYFL D_WEEKDAYUFL LINEORDER表 LO_ORDERKEY LO_LINENUMBER LO_CUSTKEY LO_PARTKEY LO_SUPPKEY LO_ORDERDATE LO_ORDERPRIORITY LO_SHIPPRIORITY LO_QUANTITY LO_EXTENDEDPRICE LO_ORDTOTALPRICE LO_DISCOUNT LO_REVENUE LO_SUPPLYCOST LO_TAX LO_COMMITDATE LO_SHIPMODE ※OLTPではなく、DWH用途での利用を想定しているためスタースキーマのテーブルを使用 Page. 59
  60. 60. 評価で用いたSQL 4マスタ連携 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."supplier" "supplier" ON ("lineorder"."lo_suppkey" = "supplier"."s_suppkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") INNER JOIN "public"."dwdate" "dwdate" ON ("lineorder"."lo_orderdate" = "dwdate"."d_datekey") WHERE (("customer"."c_nation" IN ('ALGERIA', 'ARGENTINA', 'BRAZIL')) AND ("part"."p_color" IN ('black', 'blue', 'brown'))) GROUP BY 1, 2 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."supplier" "supplier" ON ("lineorder"."lo_suppkey" = "supplier"."s_suppkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") INNER JOIN "public"."dwdate" "dwdate" ON ("lineorder"."lo_orderdate" = "dwdate"."d_datekey") GROUP BY 1, 2 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."supplier" "supplier" ON ("lineorder"."lo_suppkey" = "supplier"."s_suppkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") INNER JOIN "public"."dwdate" "dwdate" ON ("lineorder"."lo_orderdate" = "dwdate"."d_datekey") WHERE ("part"."p_color" IN ('black', 'blue', 'brown')) GROUP BY 1, 2 ヒット件数 多 (51億件) ヒット件数 中 (2.1億件) ヒット件数 少 (25百万件) Page. 60
  61. 61. 評価で用いたSQL 2マスタ連携 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") WHERE (("customer"."c_nation" IN ('ALGERIA', 'ARGENTINA', 'BRAZIL')) AND ("part"."p_color" IN ('black', 'blue', 'brown'))) GROUP BY 1, 2 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") GROUP BY 1, 2 SELECT "customer"."c_nation" AS "c_nation", "part"."p_color" AS "p_color", SUM("lineorder"."lo_revenue") AS "sum_lo_revenue_ok" FROM "public"."lineorder" "lineorder" INNER JOIN "public"."customer" "customer" ON ("lineorder"."lo_custkey" = "customer"."c_custkey") INNER JOIN "public"."part" "part" ON ("lineorder"."lo_partkey" = "part"."p_partkey") WHERE ("part"."p_color" IN ('black', 'blue', 'brown')) GROUP BY 1, 2 ヒット件数 多 (51億件) ヒット件数 中 (2.1億件) ヒット件数 少 (25百万件) Page. 61
  62. 62. Data Platform for Hadoopの概要 バッチ処理/リアルタイム処理と多様なデータ分析に対応可能な『ビッグデータ分 析共通基盤』を、事前検証済みで提供し、迅速な導入を実現 ① バッチ処理とリアルタイム処理 に対応 大規模データの分散処理に適した「Apache™ Hadoop®」とインメモリ処理を効率的に行い、 リアルタイムな処理を可能にする「Apache™ Spark®」により大規模データのバッチ処理か らリアルタイム処理までを実現 ② 構造データ、非構造データ 両方の処理に最適 ③ 事前検証による迅速な導入 と安定した運用 大規模データを元来のデータ構造のま まで蓄積。データ活用の際には、アプ リケーションの用途に合わせてデータ 構造を指定しながら読みだすことがで きるため、データ活用の自由度を拡大 必要なハードウェアとソフトウェアを組み 合わせ、事前に設計(サイジングとチュー ニング含む)・検証・構築した統合型シス テムで提供。導入期間の短縮とプラット フォーム品質の安定を両立し、トータルコ ストの削減に貢献 リリース情報(国内)2016年2月出荷開始
  63. 63. 設置環境、利用用途に応じて2つのモデルを提供 ▌ インメモリ・ビッグデータ分析、クラウド基盤に 最適なプラットフォーム ▌ 世界最高クラスの高密度・省電力サーバ ラックあたりコア数: 3,536個 (Xeonコア) ラックあたりメモリ容量: 37TB ラックあたりSSD容量: 293TB ラックあたりの ネットワーク帯域: 19.5Tbps ラックあたりコア数: 5,600個 (Atomコア) ラックあたりメモリ容量: 22TB ラックあたりSSD容量: 90TB ラックあたりの ネットワーク帯域: 18.8Tbps CPU・メモリ・ネットワーク強化! 電力/性能向上! 1ラックに 572 サーバ 66% 省スペース* 50% 省電力* 46ノード/2Uシャーシ インテル® Atom™ 44ノード/3Uシャーシ インテル® Xeon® D Micro Modular Server (Atom™) Scalable Modular Server (Xeon® D) New *1Uラックサーバ比
  64. 64. DX 1000の特長 省電力 高並列・高密度 Traditional servers *1:Based on all the servers with Atom C2000 and 2.5GbEther *2: A total of network bandwidth of all downlinks in the rack *3:RMS :Rack Management System 700 servers per rack 75% less space 75% less energy 5600 processor cores per rack 22TB of memory per rack 90TB of SSD storage per rack Networking*2 3.5Tbps per rack • サーバ向けIntel® AtomTMプロセッサー C2000シリーズの採用やSSDの標準搭 載等により、クラス最高レベル*1の高集積/省電力化を実現 • CPU性能とバランスのとれた2.5GbitEthernetをいち採用。10GbEtherにくらべ電 力を抑えながら、スケールアウト型のビッグデータ分析基盤で求められる高速ネ ットワーク環境を実現 *1:Atom C2000搭載,2.5GbEtherNW対応機種において *2:サーバ当たりNW帯域×サーバ台数 Page. 64
  65. 65. DX 2000の特長 ベネフィット  リアルタイムな業績把握 による迅速な経営判断  ビッグデータ分析基盤の 新規導入、運用に伴う コスト低減により、投資 効果を最大化  スケーラブルなサーバ 増設により、増大する データ量にも柔軟に対応 大量のデバイスから収集される多種多様なデータをリアルタイムに処理し、 新たな付加価値を創出するビッグデータ分析基盤に最適な高集積サーバ。 特長 ①リアルタイム分析を支える高性能 インメモリ分散処理に適した内部構造によ り、従来システムで数時間要する分析を 数秒~数分で実行 *1 ②迅速導入と安心のサポート 最新分散処理OSSミドル(Hadoop)を検証 済みで提供し導入期間を 50%短縮 *2 ③低運用コスト 省電力、省スペース化によりデータ センターの運用コスト30%削減 *3 Scalable Modular Server “DX2000” 高集積サーバ ・最新Xeon® D 採用 ・44サーバ/3U ・高速ネットワークを集約 *1: 一般ラックサーバで構築した従来システムとの比較。NEC試算。 *2: 通常のシステム設計、構築、検証を行う場合との比較。NEC試算。 *3: 1Uラックサーバとの比較。NEC試算。

×