1. 新郷 美紀
NEC
蒋 逸峰
Solutions Engineer, Hortonworks
ビッグデータ可視化
の性能を徹底検証
〜SparkSQL、Hive on Tez、Hive LLAPを用いた既存RDBデータ
処理の特徴〜

2. Agenda
• 初めに
• 背景
• クラウドDWH と Hiveとの比較
• 性能改善
– SparkSQL
– Hive on Tez
– Hive LLAP
• まとめ
Page. 2

3. はじめに
• Hortonworks、NECの両社が本資料の内容を
保障するものではございません。
• 資料中、“大人の事情”で詳細を記載できな
い部分があります。ご了承ください
• つきましては、きわどい質問はご容赦ください。
Page. 3

4. 発表者
氏名：
新郷 美紀
略歴：
ビッグデータ歴2年。当社の1ラックに700サーバ以上搭載可能な
大規模システムのソリューション検討でHadoop, Sparkと出会う。
以降、ビッグデータソリューションアーキテクトとして活動。
分散処理系と、分析基盤系のソリューションのアーキテクチャ検
討・実装。
今の注力技術はSparkとラムダ・アーキテクチャ。
現在、Open Data Platform Initiativesのメンバーとしても活動中。
趣味：
ルネッサンス時代のヨーロッパの音楽を聴いたりと絵を見ること。
バッハよりジョスカンが好き。ラッセンよりフェルメールが好き。
Page. 4

5. 発表者代理
所属：NEC ソリューションイノベータ
名前：家志 門太（やし もんた）
CGやったり
もんた（@___monta___）
FPGAやったりインフラSEやったり

6. 背景

7. データ
Page. 7
10^5倍

8. 増え続けるデータ
4ZB
DATAINTERNET
OF
ANYTHING
44ZB
DATA
TOMORROW
Page. 8

9. 商用
サポートSIベンダ
コミュニティ
活用の機運が高まっている
Page. 9

10. 本題

11. 実案件でのご相談
商用DWHをOSSで置き換えられないか？
DWH
Page. 11

12. 実用性の検証方法
評価用の環境にて同じクエリを実行
Page. 12
DWH

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. Tableauの設定
テーブルの連携と、処理/可視化を簡単に設定
Page. 14

15. Tableauの設定
テーブルの連携と、処理/可視化を簡単に設定
Page. 15

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. 評価環境のハードウェアスペック
DWH Hive
評価環境概略
Atom C2730(1.7GHz）
32GB
SSD 128GB
2.5GbE
Xeon 約4Ghz相当 × 2
15GB
SSD 160GB
10GbE × １
4ノード
Page. 17
2U 1シャーシ
（ 40 micro modular server）

18. クエリ内容
Tableauから投入するクエリ
PARTテーブルのレコードを3/92に絞り
込んだのち4マスタ連携
・ヒット件数2.1億件
・集計結果75件
クエリ１ クエリ2
PARTテーブルのレコードを3/92に絞り
込んだのち2マスタ連携
・ヒット件数2.1億件
・集計結果75件
Page. 18

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. 性能改善

21. Hortonworks Japanとの会話
「Hadoop Conferenceでこの性能改
善について発表しませんか」
のお誘い
※この時点で1か月前
Page. 21

22. 性能比較の環境
３つの環境で比較
データ
ウェアハウス
Page. 22
SQL
環境
サーバ
サーバ
サーバ
サーバ
Hive環境

23. SQL
Page. 23

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. SQL
評価結果まとめ
0
100
200
300
400
500
600
700
800
900
1,000
ヒット件数 多
(51億件)
ヒット件数 中
(2.1億件)
ヒット件数 少
(25百万件)
処理時間（秒）
DWHとSparkSQLの比較
DWH SparkSQL Page. 25
４マスタ連携
42%
75% 70%

26. SQL
評価結果まとめ
0
100
200
300
400
500
600
ヒット件数 多
(51億件)
ヒット件数 中
(2.1億件)
ヒット件数 少
(25百万件)
処理時間（秒）
DWHとSparkSQLの比較
DWH SparkSQL Page. 26
２マスタ連携
48%
73% 67%

27. SQL
サーバ負荷状況

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. Hadoop
SQL
エグゼキュータ/ドライバの設定値
管理ノード Slave node Slave node
ドライバ
エグゼキュータ エグゼキュータ
SparkContext
メモリ容量
--executor-memory
割り当てるコア数
--executor-cores
メモリ容量
--driver-memory エグゼキュータ
エグゼキュータの数
--num-executors
Page. 29

30. SQL
ブロードキャスト結合パラメータの効果
デフォルト時のDAG パラメータ設定時のDAG
Page. 30

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 設定値
４マスタ連携
２マスタ連携
(default)

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. 所感
• Driverのメモリ設定も重要
• 今回は「CHCHE TABLE XXX」は効果なし。
• 1.5以降は「spark.sql.tungsten.enabled」はデ
フォルトでenable

34. 自己紹介
蒋 逸峰（しょう いつほう / Yifeng Jiang）
• Solutions Engineer, Hortonworks
• Apache HBase本の作者
• 日本に来て１０年経ちました…
• 趣味は山登り
• Twitter: @uprush
Page. 34

35. Apache Hive
Page. 35

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. Hive on Tez / LLAP
評価結果まとめ（４マスタ連携）
Page. 37
0
100
200
300
400
500
600
700
800
900
1000
ヒット件数 多(51億件) ヒット件数 中(2.1億件) ヒット件数 少(2.5千万件)
処理時間（秒）
DWHとHive on Tez / LLAPの比較（４マスタ連携）
DWH Hive on Tez Hive LLAP

38. Hive on Tez / LLAP
評価結果まとめ（２マスタ連携）
Page. 38
0
100
200
300
400
500
600
ヒット件数 多(51億件) ヒット件数 中(2.1億件) ヒット件数 少(2.5千万件)
処理時間（秒） DWHとHive on Tez / LLAPの比較（２マスタ連携）
DWH Hive on Tez Hive LLAP

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. Hive チューニング
Hiveの基本チューニングポイント
• Hiveにデータをロード
– パーティション
– ORCとしてストア
• クエリ実行
– 分散実行エンジン: Tez / LLAP (MR使っている方は今すぐ
Tezへ切替を！)
– Cost Based Optimizer (CBO)
– Vectorized Query Execution
Page. 40

41. Hive データロード
正しいロードはすべての基礎
• パーティションを切る
• ORCに変換
ただ３つのステップ
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. Hiveパーティション
パーティションあり
パーティションなし
143 Map
tasks
2 Map
tasks
パーティション項目が絞込条件で
必要のないデータ読込みをスキップ
WHERE ((part.color IN ('black', 'blue', 'brown')) AND
(customer.nation IN ('ALGERIA', 'ARGENTINA', 'BRAZIL')))
Page. 42

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. CBOの効果
• データ統計をみてDAGを自動的に調整
• 最適な実行プランを自動生成
Map Join
に変換
Reduce数
が1009から
97に減少
CBO なし CBO あり
Page. 44

45. CBOの効果
• CBO を有効にした場合、処理が18%高速
• 複雑なクエリは特に有効
– 例：BIツールで生成されたジョイン多数のクエリ
0
100
200
300
400
500
600
700
800
Hive LLAP Hive LLAP (CBO enabled)
処理時間（秒）
CBOあり／なしの比較
（４マスタ連携、５１億件ヒット）
18%カット
Page. 45

46. Apache Tez
アプリケーションのための分散処理フレームワーク
• エンドユーザーではなく、フレームワークやアプリケーション開発のためのフレー
ムワーク
• Hive on Tez, Pig on Tez, Cascading on Tez, …
MapReduceでの経験や教訓をもとに
• パフォーマンスの大幅な向上
• HDFSに中間データを出力しなくてもOK
• バッチだけでなくインタラクティブな処理にも
• ペタバイト規模までスケール
Run on YARN
• クラスタのリソースを有効に活用
Page. 46

47. Tez チューニング
Tez の基本チューニングポイント
• Application Master 作成 [4-5s]
– Tez セッションの暖機運転
– Tez セッションの再利用
• Container アロケーション [3-5s]
– Tez container の再利用
• Tez container サイズ
– Container の数（即ち同時実行数）が変わる
Page. 47

48. Tez Container 再利用
• 処理完了のcontainerをキープし、次のタスクが来たらすぐ処
理できる仕組み
• 同じセッションのタスクのみ
• 今回は逆効果 
– 毎回Tableauを立て直したうえでの評価
– セッションが異なるため効果なし
– アイドルのcontainerがリソースを専有し、新しいクエリがリソース待ち
状態が発生
• クライエント側のコネクションの使い回しが大事
Page. 48

49. Tez Container再利用の効果
• Container 再利用が有効の場合、処理が数十秒〜２分速い
• 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. Hive LLAP
Page. 50

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. 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. Hive LLAPのメリット
スケーラブルな処理フレームワークであるTezに対し
て、LLAPは以下のパフォーマンスメリットを提供する
• クエリ実行までの準備時間の短縮
• カラムナ型で保持するキャッシュ
• デーモン（永続）プロセスの利点を活かした最適化
– JIT, concurrent I/O, etc.
Page. 53

54. まとめ
Page. 54

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
千万件)
処理時間（秒）
性能比較まとめ（４マスタ連携）
DWH
Hive on Tez
Hive LLAP
SparkSQL
0
100
200
300
400
500
600
ヒット件数 多(51
億件)
ヒット件数 中(2.1
億件)
ヒット件数 少(2.5
千万件)
処理時間（秒）
性能比較まとめ（２マスタ連携）
DWH
Hive on Tez
Hive LLAP
SparkSQL
Page. 55

56. まとめ
やっぱりSpark / Hadoopいいね
• SparkSQL いいね！
• Hive on Tez も速いですね！
• LLAPはHiveを更に高速化させていく
それぞれ特徴あるSQLエンジン
• まず試してみよう
• 特徴を理解したうえでの検証・利用が重要
今後やってみたいこと
・Xeon系CPUでの評価（atomとの特性の違い確認）
・マルチユーザでの評価
Page. 56

57. ご清聴ありがとうございました

58. 付録
Page. 58

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. 評価で用いた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. 評価で用いた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. Data Platform for Hadoopの概要
バッチ処理/リアルタイム処理と多様なデータ分析に対応可能な『ビッグデータ分
析共通基盤』を、事前検証済みで提供し、迅速な導入を実現
① バッチ処理とリアルタイム処理
に対応
大規模データの分散処理に適した「Apache™
Hadoop®」とインメモリ処理を効率的に行い、
リアルタイムな処理を可能にする「Apache™
Spark®」により大規模データのバッチ処理か
らリアルタイム処理までを実現
② 構造データ、非構造データ
両方の処理に最適
③ 事前検証による迅速な導入
と安定した運用
大規模データを元来のデータ構造のま
まで蓄積。データ活用の際には、アプ
リケーションの用途に合わせてデータ
構造を指定しながら読みだすことがで
きるため、データ活用の自由度を拡大
必要なハードウェアとソフトウェアを組み
合わせ、事前に設計（サイジングとチュー
ニング含む）・検証・構築した統合型シス
テムで提供。導入期間の短縮とプラット
フォーム品質の安定を両立し、トータルコ
ストの削減に貢献
リリース情報（国内）2016年2月出荷開始

63. 設置環境、利用用途に応じて２つのモデルを提供
▌ インメモリ・ビッグデータ分析、クラウド基盤に
最適なプラットフォーム
▌ 世界最高クラスの高密度・省電力サーバ
ラックあたりコア数: 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. 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® AtomＴＭプロセッサー C2000シリーズの採用やSSDの標準搭
載等により、クラス最高レベル*1の高集積/省電力化を実現
• CPU性能とバランスのとれた2.5GbitEthernetをいち採用。10GbEtherにくらべ電
力を抑えながら、スケールアウト型のビッグデータ分析基盤で求められる高速ネ
ットワーク環境を実現
*1:Atom C2000搭載,2.5GbEtherNW対応機種において
*2:サーバ当たりNW帯域×サーバ台数
Page. 64

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試算。