Db2 Warehouse (旧名：dashDB Local)は、Dockerコンテナベースで提供され、DWHとSparkを統合した新しいコンセプトを持った製品です。本セッションでは、「Db2 Warehouse 実機検証やってみた! シリーズ」として、ネットワールド様、インサイトテクノロジー様が実施されたDb2 Warehouse 検証結果のご紹介に加え、DWH基盤だけではない、機械学習分析基盤としてのDb2 Warehouseの価値をご紹介します。

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

2. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
自己紹介
• Apple II発売の日に生まれた40歳
• 前職...肩書はDBA、実態は何でも屋
• 現在...DBコンサルタントとして入社、現状は何でも検証屋

3. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
なぜ検証したの？
興味を持った理由は...
機能
がっつり！
dockerで
簡単デプロイ！
IA Server
＋
共有ストレージ

4. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
でも、
速くないと、
使いたくないよね...。

5. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
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接続とで
比較してみる。

6. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
手始めに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個のクエリを順番に実行し、実行時間を単純に足してみた（単位がないのは大人の事情です...）。
ノードを増やすと確かにスケールアウトしているが...。
気になる...！
これ、なに？

7. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
極端に遅いクエリ、高い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が大量発生！

8. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
メモリチューニングで高速化
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リ
ソースを使い切っている状態

9. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
結果、きれいにスケールアウト
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

10. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
複数セッション同時実行だと...
3node (チューニング済み) 6node 12node
実行時間
TPC-H 20セッション同時実行（1セッション当たりの平均）
1セッション
単独実行時の
15倍
1セッション
単独実行時の
30倍
1セッション
単独実行時の
12倍
この辺りまでは
チューニングで
速くなりそう
• 1セッションの20倍の負荷をかけても1クエリ当たりの実行時間は15倍前後で安定。
• それを超えているのであればリソース不足。チューニング or スケールアウトを考えるべし。

11. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
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()

12. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
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倍速くなった例もあるらしい。
（やってみたかった...）

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

14. * 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.
記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。
Copyright 2017 Insight Technology, Inc. All Rights Reserved.