[db tech showcase Tokyo 2017] E35: 12台でやってみた！DWHソフトウェアアプライアンス Db2 Warehouse ～ DWH + Docker +Spark 統合による機械学習基盤としての価値～ by 株式会社インサイトテクノロジー平間大輔

* 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
12台でやってみた！
DWHソフトウェアアプライアンス Db2 Warehouse
～実機検証編～
平間大輔
株式会社インサイトテクノロジー
ビッグデータ・ソリューション事業部

自己紹介
• Apple II発売の日に生まれた40歳
• 前職...肩書はDBA、実態は何でも屋
• 現在...DBコンサルタントとして入社、現状は何でも検証屋

なぜ検証したの？
興味を持った理由は...
機能
がっつり！
dockerで
簡単デプロイ！
IA Server
＋
共有ストレージ

でも、
速くないと、
使いたくないよね...。

12台で検証だ！
10 TB
GPFS (共有リソース)用
x 12台
Cisco UCS C220M4 CPU ：Xeon(R) E5-2670 v3(12 core, 2.30GHz) * 2 CPU
Mem ：384GB (16GB x 24 枚)
Interface ：OnBorad NIC x 2 port (1G)
VIC x 2 port (10G)
FC x 2 port (8G)
x 1台
FlashSystem 900
Flash Module ： 2.9TB x 6
Interface ：FC x 8 port (16G)
様から以下の機器がお借りできたので、これで検証を実施。
検証1：
DWH用ベンチマークのTPC-Hを1TBのデータで実行。
ノードを増やして性能がスケールするかも検証。
検証2：
Sparkとの通信をソケット通信と一般的なJDBC接続とで
比較してみる。

手始めに1セッションでスケールアウト
3node 6node 12node
実行時間
TPC-H 1セッション単独実行
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
TPC-Hの22個のクエリを順番に実行し、実行時間を単純に足してみた（単位がないのは大人の事情です...）。
ノードを増やすと確かにスケールアウトしているが...。
気になる...！
これ、なに？

極端に遅いクエリ、高いI/O使用率
0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
使用率(%)
実行時間
3node単体クエリ実行（チューニング前）
合計 / result 平均 / cpu_util 平均 / io_util
ワーキングメモリ
が足りなくなり、
ストレージへの
writeが大量発生！

メモリチューニングで高速化
0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
使用率(%)
実行時間
3node単体クエリ実行（チューニング後）
合計 / result 平均 / cpu_util 平均 / io_util
チューニングレスとは言うけれど、いざとなったらチューニングも可能。
基本的な手順はBLU Accelerationでのチューニングと同様。
※注意
目盛りの単位は
前ページの1/10で
す。
Hyper ThreadingがONなので
50%前後のCPU使用率となっ
ているが、実際はほぼCPUリ
ソースを使い切っている状態

結果、きれいにスケールアウト
3node (チューニング後) 6node 12node
実行時間
TPC-H 1セッション単独実行
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

複数セッション同時実行だと...
3node (チューニング済み) 6node 12node
実行時間
TPC-H 20セッション同時実行（1セッション当たりの平均）
1セッション
単独実行時の
15倍
1セッション
単独実行時の
30倍
1セッション
単独実行時の
12倍
この辺りまでは
チューニングで
速くなりそう
• 1セッションの20倍の負荷をかけても1クエリ当たりの実行時間は15倍前後で安定。
• それを超えているのであればリソース不足。チューニング or スケールアウトを考えるべし。

Sparkからの接続は、Socket ? JDBC ?
#!/usr/bin/python
# -*- coding: utf-8 -*-
from pyspark.sql import SparkSession
from com.ibm.idax.spark.examples.utilities.helper import initializationDashDB
if __name__ == '__main__':
sparkSession = SparkSession ¥
.builder ¥
.getOrCreate()
df = sparkSession.read ¥
.format("com.ibm.idax.spark.idaxsource") ¥
.options(dbtable="LINEITEM") ¥
.options(mode="SOCKET") ¥
.load()
resultOrderBy = df.select("L_ORDERKEY", "L_PARTKEY", "L_SUPPKEY","L_LINENUMBER").orderBy("L_ORDERKEY")
print resultOrderBy.show()
sparkSession.stop()
※JDBC接続の場合、接続するコードは以下に変更。
df = sparkSession.read ¥
.format("com.ibm.idax.spark.idaxsource") ¥
.options(dbtable="LINEITEM") ¥
.options(url="jdbc:db2:BLUDB") ¥
.options(mode="JDBC") ¥
.load()

Socket通信で1.7倍（参考値）
1.0
1.7
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
JDBC Socket
倍
実行時間
LINEITEMテーブル検索速度
（データ量800GB、60億レコード)
検索時間速度（倍）
• 同一クラスタにDb2 WarehouseとSparkが
同居した環境ではネットワークオーバー
ヘッドがほとんどないが、それでも1.7倍
高速となった。
• さらに、接続時にDB側のPartition情報を
指定することで、接続が最適化され高速
化するらしい（知りませんでした...）。
• Partition指定を行い、かつDb2 Warehouse
とSparkクラスタが分離した構成であれ
ば、50倍速くなった例もあるらしい。
（やってみたかった...）

検証を終えて...
結果について
• おおむね、リソースが足りていればきれいにスケールした。
• 実行速度も良好（公開できないのが残念ですが）。
• スケールアウトは設定を変えてdockerコンテナを作り直すだけなので簡単。
• 実は最初からノード数が何ノードでも60パーティションに分けてデータを管理しているため、ノード追加
時はその割り当てを変更するだけ。
• ある程度チューニングの余地があったのは個人的にはうれしい（「チューニングレス」のうたい文
句からは外れますが...）
今後検証を進めるなら...
• 「機能」部分を全然見ていなかったのでチェックしたい。
（Netezzaとの互換性はどれくらい？など）
• 「共有ストレージ」に工夫の余地あり？
• SDSなどでローカルストレージを束ねる構成もあり → 弊社のInsight Qubeで挑戦してみたい。

[db tech showcase Tokyo 2017] E35: 12台でやってみた！DWHソフトウェアアプライアンス Db2 Warehouse ～ DWH + Docker +Spark 統合による機械学習基盤としての価値 ～ by 株式会社インサイトテクノロジー 平間大輔

More Related Content

What's hot

Similar to [db tech showcase Tokyo 2017] E35: 12台でやってみた！DWHソフトウェアアプライアンス Db2 Warehouse ～ DWH + Docker +Spark 統合による機械学習基盤としての価値 ～ by 株式会社インサイトテクノロジー 平間大輔

More from Insight Technology, Inc.