クラウド サービス (PaaS) でペタバイト級のデータ分析が可能な Azure SQL Data Warehouse。 今回、多様な製品でのデータ ウェアハウス構築の経験が豊富なシステム サポート様を迎え、リアルなシステムで本当に使える Azure SQL Data Warehouse のチューニングの勘所をお伝えします! 受講対象: Azure SQL Data Warehouse でパフォーマンスに悩んでいる方、DWH 製品を検討中の方、別製品からの移行を検討中の方に最適なセッションです。 関連リソース 1: Azure SQL Data Warehouse (https://azure.microsoft.com/ja-jp/services/sql-data-warehouse/) 関連リソース 2: 株式会社システムサポート (https://www.sts-inc.co.jp/) 関連リソース 3: Microsoft Japan Data Platform Tech Sales Team Blog (https://blogs.msdn.microsoft.com/dataplatjp/) 製品/テクノロジ: Microsoft Azure/SQL Server/クラウド/ビッグ データ/運用 西村 哲徳 日本マイクロソフト株式会社 クラウド & ソリューション ビジネス統括本部 データ プラットフォーム & クラウド技術部 データ プラットフォーム ソリューション アーキテクト 山口 正寛 株式会社システムサポート クラウドコンサルティング事業部 シニアマネージャー

4. センサー/デバイス
非構造化データ
並列分散処理
機械学習
Cognitive
Services
画像・音声認識など
Power BI
センサー/デバイス
データ受信
リアルタイム
ストリーム処理
Microsoft Azure（クラウド）
非構造化・構造化
データストレージ
ETL
（収集・変換・集約）
DWH
（データ格納） 分析、R統計解析
レポート
Integration
Services Analysis
Services
Reporting
Services
（オンプレ）
Relational
Database
R Server/
SQL R
WEBダッシュボード・
セルフサービスBI

5. 計算
ノード
計算
ノード
制御
ノード
アプリから
の接続
データ処理 (結合、フィルタ等)
計算
ノード
計算
ノード
制御
ノード
計算
ノード
計算
ノード
計算ノード追加で性能向上

6. 計算
ノード
計算
ノード
制御
ノード
計算
ノード
計算
ノード
30 ストレージ/計算ノード 15 ストレージ/計算ノード
計算
ノード
計算
ノード
制御
ノード

8. 初期環境構築
計算ノード数変更
災害対策
バックアップ
リカバリ
ディスクの多重化
セキュリティ
• 管理画面で数クリックで作成、変更
• 自動でローカルに三重化
• 自動で8時間ごとにスナップショット
• 7日間保持
• 管理画面で数クリックで設定
• 24時間ごとに他リージョンに転送
• 管理画面で数クリックで設定
• 暗号化、SQL インジェクション検出等
• ファイアウォール、監査

9. • 負荷に応じてノード追加、削除でコスト最適化
• 停止中は、ストレージ使用量のみの課金
停止中は非課金
追加、削除も数分程度で
簡単に可能

10. 遅いSQL特定
プランの確認
リソース使用率

11. SQL Data Warehouse の監視に使用する主な動的管理ビュー

13. 口

14. ETL
可視化
[Demo]
Blob Storage
SQL Data Warehouse
Link
Link
Virtual Machine1
Event Hubs
Virtual Machine2
import
Send
Query
Automation
Japan East
HTTP, WebSocket
データ生成（IoTデバイス想定)

15. ・超並列分散処理（ MPP ）
・クラスター化列ストアインデックス
・標準で Premium Storage(SSD)
・etc・・・
大量データを高速に処理可能

16. そもそも高速な SQL Data Warehouse で
チューニングは必要なのか？

17. 0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
5.00
1000DWU 2000DWU
チューニング前後の性能比較（QphH@1000GB）
チューニング前 チューニング後
TPC-H （売上分析データウェアハウス）のデータモデル
1000 DWU の QphH@1000GB の値を1とした時の相対比率（値が大きくなれば高速）
・処理の高速化 ・コスト削減
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
5.00
1000DWU 2000DWU
チューニング前後の性能比較（QphH@1000GB）
チューニング前 チューニング後
2倍
2.5倍

18. ⇒Yes!! チューニングしたほうがよい！！

22. ボトルネック 対策
ノード間データ移動
（DMS）
ディストリビューション
ストレージI/O ディストリビューション・INDEX・テーブルの種別
CPU ディストリビューション・テーブルの種別・
統計情報

23. ・ EXPLAIN による実行計画の取得
・ DMV ・ Azure Portal による情報収集

24. チューニングの５割が決まる

25. 均一にすべてのストレージに分散
ランダムに分散
指定されたキーのハッシュ値で分散
同じキーは同じストレージに分散
Id User Tran
123 Bob 3000
324 Sue 110
324 Sue 40000
45 George 60
154 Sally 990
123 Bob 230
Id User Tran
123 Bob 3000
324 Sue 110
324 Sue 40000
45 George 60
154 Sally 990
123 Bob 230
ハッシュ関数
Dist1 Dist2 Dist3 Dist4Dist1 Dist2 Dist3 Dist4

26. テーブル結合時の両テーブルの結合キーで使用
GROUP BY,DISTINCT,HAVING で使用されるキーで使用
データの偏りのある列、WHERE 句で使用される列
では使用しない
⇒選択条件１～３を合わせて考える

27. LINEITEM HASH( [PARTKEY] )
[PARTKEY] NOTNULL INT
PART HASH( [PARTKEY] )
[PARTKEY] NOTNULL BIGINT
select sum( [EXTENDEDPRICE] ) from [LINEITEM],[PART]
where [PARTKEY] = [PARTKEY];

28. LINEITEM HASH( [PARTKEY] )
[PARTKEY] NOTNULL INT
PART HASH( [PARTKEY] )
[PARTKEY] NOTNULL INT
select sum( [EXTENDEDPRICE] ) from [LINEITEM],[PART]
where [PARTKEY] = [PARTKEY];

29. select sum( [EXTENDEDPRICE] ) from [LINEITEM],[PART]
where [PARTKEY] = [PARTKEY];
・HASH KEYを一致させることで、実行時間は約54倍の性能向上
0
0.2
0.4
0.6
0.8
1
1.2
HASH KEY 不一致（ DMS ） HASH KEY 一致
0
0.2
0.4
0.6
0.8
1
1.2
HASH KEY 不一致（ DMS ） HASH KEY 一致

30. HASH KEY不一致
HASH KEY一致

31. LINEITEM HASH( [DATE] )
[DATE] NOTNULL INT
select sum( [EXTENDEDPRICE] ) from [LINEITEM]
where [DATE] = '1992-01-01';

32. ・結合キー、GROUP BY句のキー（選択条件１、２）
・WHERE句で使用されるキーでは使用しない
・カーディナリティ―の低いキーでは使用しない
（選択条件３）
⇒チューニングの５割はここで決まる

33. 少量のデータへのアクセスを最適化

34. SQL Data Warehouseは、データウェアハウスの分析クエリを高速に処理する
クラスタ化 列ストア インデックスを標準で採用
・大量行のスキャン、集計処理を高速に処理
・高いデータ圧縮より、ストレージ容量、ディスクI/Oを削減
⇒非クラスタ化 セカンダリ インデックス

35. 0
0.2
0.4
0.6
0.8
1
1.2
セカンダリインデックス無 セカンダリインデックス有
select * from LINEITEM where ORDERKEY=489290050;
・クエリ結果は以下の通り
・結果
0
0.2
0.4
0.6
0.8
1
1.2
セカンダリインデックス無 セカンダリインデックス有

36. 処理はもっと早くなる

37. クラスター化 列ストア インデックスなど多くのテーブル型で利用可能
ほとんどの場合で、パーティション分割は日付列で実装される
データのメンテナンス性の向上
処理対象の絞り込みによるパフォーマンスの向上
⇒パーティション化で遅くなることも

39. ⇒パフォーマンスが最適

40. クラスタ化 列ストア インデックスのパフォーマンスが最適化されるテーブル
6,000万件以上のテーブル
列ストアインデックスの最適件数 ストレージ数

41. ⇒１パーティションあたり 6000万件以上必要
パーティションを細かくしすぎない！！

42. 同一セッション内でのみ参照可能
セッションをログオフすると自動で削除
リモートストレージにデータは格納せず、ローカルストレージを使うため高速

44. ■性能問題の50％はディストリビューションの問題。
■少ない件数を取得する時は非クラスター化インデックスを使う。
■パーティションは細かくしすぎない。
■中間テーブルはすべて一時テーブルに変換。
■統計情報の取得は絶対。取り忘れずに注意。
⇒処理の高速化とコストの削減

45. ETL
可視化
[Demo]
Blob Storage
SQL Data Warehouse
Link
Link
Virtual Machine1
Event Hubs
Virtual Machine2
import
Send
Query
Automation
Japan East
HTTP, WebSocket
データ生成（IoTデバイス想定)

46. セッションアンケートにご協力ください
 専用アプリからご回答いただけます。
decode 2017
 スケジュールビルダーで受講セッションを
登録後、アンケート画面からご回答ください。
 アンケートの回答時間はたったの 15 秒です!

47. Ask the Speaker のご案内
本セッションの詳細は『Ask the Speaker Room』各コーナーカウンタにて
ご説明させていただきます。是非、お立ち寄りください。

48. © 2017 Microsoft Corporation. All rights reserved.
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。