db tech showcase sapporo 2015 20115-09-11, Session B24

1. B:24 Amazon Redshift
石川 覚 ソリューションアーキテクト
クラスメソッド株式会社
Ⓒ Classmethod, Inc.
2015年09月11日
事例でわかるデータ分析基盤の活用
∼ Amazon Redshift の最新動向
db tech showcase
Sapporo HOKKAIDO SEP 10-11, 2015
1
#dbts2015 #be_crazy_about_db_tech

2. 石川 覚（いしかわ さとる）
2Ⓒ Classmethod, Inc.
メーカー系SE、VoIP関連ベンチャー企業を経て
CMに2014/06 join
札幌出身、東京に８年
Linux, Java, MySQL, Redshift
マイブームは 統計学、R
クラスメソッド株式会社
ソリューションアーキテクト

3. 3Ⓒ Classmethod, Inc.
ブログ
ブログ： http://dev.classmethod.jp/

4. 4Ⓒ Classmethod, Inc.
アジェンダ
データベース利用の変化
AWSが提供するビックデータソリューション
Amazon Redshift の解説
データ分析基盤の構成要素
データ分析基盤の導入事例
Amazon Redshift 導入のポイント
Amazon Redshift の最新動向
まとめ

5. Ⓒ Classmethod, Inc.
データベース利用の変化
∼DBに求められたこと、これから求められること∼

6. RDBとは、行とカラムで構成される二次元のデータ構造で管理するデータベース
で、ACIDという特性を持つ
ACID特性とは、関連する複数の処理を一つの処理単位にまとめて管理するトラン
ザクション処理に求められる4つの特性
6Ⓒ Classmethod, Inc.
ACIDなRDB
RDBは、データベースに対して、
SQL言語による柔軟な条件指定
ができる
RDBの普及に伴い、データストアは全て「一貫性」であるのが当たり前となった
Atomicity：原子性
Consistency：一貫性
Isolation：独立性
Durability：耐久性

7. 高可用性：冗長化
データのコピーを複数のノードに持ち、
仮にノードの障害を起こしても、障害
時に切り替えて処理を引き継ぐ
高拡張性：シャーディング
複数のノードを用意し、データごとに
受け持つノードを分けることで、性能
を確保する
7Ⓒ Classmethod, Inc.
非機能要件の高まり -「可用性」と「拡張性」
データ更新時に、全ノードに
変更が行き渡り、一貫性を保
証するのが大変
一貫性と、高可用性・高拡張
性の両立には大きな困難が伴
う

8. NoSQLは、SQLデータベース以外のデータベースを表し、BASE
（Basically Available・Soft state・Eventually consistent）という
特性を持つ
8Ⓒ Classmethod, Inc.
BASEなNoSQL
key Valueによる高速なデータ
アクセスが可能
一方、インデックスによる範囲
検索はできない
高い可用性
更新は非同期で反映
結果整合性
KVS（key Value Store）

9. AWSでは、データベース特性や非機能要件に対応したDB関連サービス
が多数提供されています
9Ⓒ Classmethod, Inc.
AWSのDB関連サービス

10. Ⓒ Classmethod, Inc.
AWSが提供する
ビックデータソリューション

11. AWSサービス - 約50以上のサービス
11Ⓒ Classmethod, Inc.
AWSサービスの全体像

12. Ⓒ Classmethod, Inc.
Amazon Redshift の解説

13. 13Ⓒ Classmethod, Inc.
Amazon Redshiftの特長
クラウド内で完全に管理された、ペタバイト規模のDWHサービス
バックアップ、パッチ適用、モニタリング、ディスク・ノード障害自動復旧
大容量：160GB∼1.6PB
高速：カラムナ型＋列圧縮、超並列演算(MPP)、シェアードナッシング
インスタンスの従量課金(ライセンス不要)

14. PostgreSQLとほぼ互換
- PostgreSQL8.0.2がベース
- PostgreSQLのツールやODBC/JDBCでも接続可能
- 多くのBIツールがサポート
旧ParAccel(Actian)のDWHがベース
- 2012年7月に旧ParAccelの技術ラインセンスを獲得
- DBエンジンは旧ParAccel技術がベース
14Ⓒ Classmethod, Inc.
Redshiftの技術的バックグラウンド

15. 15Ⓒ Classmethod, Inc.
クラスタの構成
Leader Node
- SQL Endpoint
- メタデータの管理
- クエリ実行の連携
Compute Nodes
- カラムナ・ストレージをローカルに保持
- クエリーを並列実行
- S3, DynamoDB, EMR, SSHを経由して、
- データのロード・アンロード、
- バックアップ・リストア
２つのHWプラットフォーム
- データ処理に最適化した
- DC1 SSD 0.16TB~326TBまでスケール
- DC2 HDD 2TB~2PBまでスケール

16. 各Compute Nodeはスライスに分けられる
- スライスはCPUコア毎分けられる
- DC1：largeは2スライス、
8xlargeは32スライス
- DC2：xlargeは4スライス、
8xlargeは36スライス
各スライス毎にメモリ、CPU、
ディスクが割り当てられる
ワークロード単位を各スライスが 並
列に実行する
16Ⓒ Classmethod, Inc.
コンピュートノードとスライス

17. 1. 分析データ(ファイル)をS3に 置く
2. ETL処理する
3. ETL後データ(ファイル)をS3に 置く
4. COPYコマンドでデータを高速ロード
5. Analyze&Vacuumを実行（必要に応じて）
6. BIツール経由でSQLを投入して利用開始
17Ⓒ Classmethod, Inc.
基本的な利用の流れ
分析データ ETL
EC2/EMRS3
データ
（ETL済み）
Redshift
データ
S3 BIツール
(Tableau)
分析
Analyze&Vacuumを実行管理者

18. 18Ⓒ Classmethod, Inc.
データのロード(COPY)
COPY from S3
- S3に置いてそのファイルをRedshiftに取込む
- ETL済みのデータ
COPY from EC2
- EC2上のファイルをRedshiftに取込む
- マニフェストファイルはS3に事前に置く必要がある
- VPC内でデータを渡せる
その他のデータソース
- DynamoDB、EMR(Elastic Map Reduce)、Treasure Data

19. Ⓒ Classmethod, Inc.
データ分析基盤の構成要素

20. 20Ⓒ Classmethod, Inc.
データ分析基盤の構成要素
既存システムからのデータ収集
（構造化データ）
POS
Desktop
(Kinesis)
DWH
(Redshift)
(S3)
(EC2)
(Tableau Server
on EC2)
Web

21. Ⓒ Classmethod, Inc.
Amazon Redshift
データ分析基盤の導入事例

22. 全国のスーパーやドラックストアなどのPOSデータを中心
にデータ分析
PCのデータベースでは限界
増え続けるデータに対して効率よく収集し分析する基盤の
構築が必要
22Ⓒ Classmethod, Inc.
資生堂様 - POSデータ分析基盤
テンプレートを用いて、約1か月間でデータ分析を開始
分析対象のレコード件数を数十億件規模に拡大し、地域別・ブランド
別・店舗別・商品別・日月別といった様々な角度から分析

23. 23Ⓒ Classmethod, Inc.
資生堂様 - POSデータ分析基盤
ETL
Analyze&Vacuum
COPY＆マート

24. 「調べたいこと」や「やりたいこと」などを話しかけると、そ
の言葉の意図を読み取り、情報やサービス、端末機能の中から
最適な回答を返します。
短周期かつ高速なデータ分析を行い、機能追加や改善に繋げ、
利用機会拡大を目指す
処理時間の短縮、機能追加や変更の際の対応の容易さ、ビジュ
アル分析しやすいビュー
24Ⓒ Classmethod, Inc.
NTTドコモ様 - しゃべってコンシェル
データ分析基盤の設計とアプリの開発を担当
これまで数時間掛かっていた分析処理を15分に短縮
データの種類や分析項目が増えても、クラウドのメリットを活かしてサー
バー環境を柔軟にスケールできるようになりました

25. 25Ⓒ Classmethod, Inc.
NTTドコモ様 - しゃべってコンシェル

26. 回転寿司のすし皿に ICタグを取り付けてセンサーで取得
一日当たり平均で数百万件、レーン上を流れる寿司情報
をリアルタイムにクラウド上に転送
売上管理や、店舗での業績管理や需要予測に活用したい
26Ⓒ Classmethod, Inc.
あきんどスシロー様 リアルタイム収集と分析
設計と構築を担当し、約1ヶ月間でリリース
注文情報、着席状況、需要予測情報とデー
タブレンディング
各店舗の寿司の売上情報だけでなく、来店
状況やオペレーション状況をほぼリアルタ
イムで把握する事が可能
すし皿に取り付けられたIC
チップをセンサーで読み取
り、リアルタイム収集

27. 27Ⓒ Classmethod, Inc.
あきんどスシロー様 リアルタイム収集と分析
すし皿に取り付けられたIC
チップをセンサーで読み取
り、リアルタイム収集

28. 28Ⓒ Classmethod, Inc.
あきんどスシロー様 リアルタイム収集と分析
Producer
GoFのProducer-Consumerパターン
N対Nの可用性と拡張性を担保
Consumer

29. 29Ⓒ Classmethod, Inc.
他にも多数の事例を紹介
http://classmethod.jp/cases/
事例とともに、
システム構成が
ご覧になれます

30. Ⓒ Classmethod, Inc.
Amazon Redshift 導入のポイント

31. 31Ⓒ Classmethod, Inc.
主キー・ソートキーの指定
主キー
- RDBと同様に一意に識別できるキーを指定する
ソートキー
- 主キーに加えて、集計したい列を順に追加
- ファクトテーブルは日付など増加する値が一般的
外部キー、一意キー
- 必要に応じて設定する
制約は有効にならないが、クエリプランナーによって利用され
るので設定したほうが良い
圧縮分析(ANALYZE COMPRESSION)の判定に利用される

32. 32Ⓒ Classmethod, Inc.
分散キーの選定
EVEN
- 各レコードをラウンドロビンでスライスに蓄積する
DISTKEY
- 各レコードの明示的に指定したカラム(一つのみ)のハッシュ値に基づ
きスライスにデータを蓄積する
ALL
- 全てのノードにデータを蓄積する
クラスタ内のスライスに対し、均等にデータを配置する
ジョイン対象となるテーブルとのコロケーション考慮する
データサイズが小さなマスタテーブルやディメンションはALL
ファクトテーブルはDISTKEYを指定、不可能な場合はEVEN

33. 33Ⓒ Classmethod, Inc.
列圧縮タイプ
データ投入済みテーブルの分析して推奨列エンコーディングをレポート出力
- ANALYZE COMPRESSIONの例 エンコードタイプ キーワード
raw（非圧縮） RAW
バイトディクショナリ BYTEDICT
デルタ DELTA
DELTA32K
LZO LZO
mostlyn MOSTLY8
MOSTLY16
MOSTLY32
ランレングス RUNLENGTH
テキスト TEXT255
TEXT32K
labdb=> ANALYZE COMPRESSION users COMPROWS 1000000;
Table | Column | Encoding
-------+---------+----------
users | id | delta32
users | name | lzo
users | age | bytedict
(3 行)
最も圧縮率の高いエンコードタイプで速いものではない
エンコードタイプを設定してテーブルの再作成して、データをCOPYコ
マンドで再投入する必要があり
COPYコマンドでCOMPUPDATE ON COMPROWS n を指定すると推
奨列エンコードで再作成される

34. 34Ⓒ Classmethod, Inc.
一般的なRDBとの相違点
主キー制約、一意制約、外部キー制約は違反してもエラーにならない
- 重複したキーのデータが投入される
サポートしているデータ型が11種類のみ
- TEXT型など内部的にVARCHARに勝手に置き換えられる
文字コードはUTF-8のみ
- VARCHARやCHARサイズ指定はバイト指定
- 4バイト以内のUTF-8

35. 35Ⓒ Classmethod, Inc.
同時実行数・カーソル数の最適化
最大接続・実行・カーソル数の相関
実行時間 vs クエリー並列度
クラスタ WLMのキュー
最大同時接続数 500以下 ー
最大クエリ同時実行数 50以下(15以下が推奨値) 50以下(15以下が推奨値)
最大同時実行カーソル数 クラスタの最大クエリ同時実行数以下 ー
ベストプラクティス
は15以下の同時実
行レベルを使用する
こと

36. Ⓒ Classmethod, Inc.
Amazon Redshift 最新動向
∼ 2015 夏

37. 37Ⓒ Classmethod, Inc.
ノードタイプの名称変更・追加
高密度ストレージノードタイプ（HDD）
- より大容量のデータストレージが必要な場合
高密度コンピューティングタイプ（SSD）
- パフォーマンス重視の作業負荷用に最適化
vCPU
メモリ[GiB]
（スライス）
ストレージ
（スライス）
I/O
dc1.large 2
15
(7.5)
0.16TB SSD
(0.08TB SSD)
0.20GB/s
dc1.8xlarge 32
244
(7)
2.56TB SSD
(0.08TB SSD)
3.70GB/s
ds2.xlarge 4
31
(7.75)
2TB HDD
(1TB HDD)
0.50GB/s
ds2.8xlarge 36
244
(6.77)
16TB HDD
(1TB HDD)
4.00GB/s

38. 38Ⓒ Classmethod, Inc.
ノードタイプの追加・名称変更
ds2はds1(dw1)と
比較して
価格据え置き
スペック２倍
スペックの変更点

39. 39Ⓒ Classmethod, Inc.
ノードタイプの追加・名称変更
ノーコスト、ノーリスク、
ハイパフォーマンス！
ds1(dw1)ご利用の方はぜひ
ノードタイプをds2に
性能の検証結果
ds1(dw1)の
リザーブドインスタンスの
下取りもしています。

40. 40Ⓒ Classmethod, Inc.
ノードタイプの追加・名称変更
ノードタイプの変更
ノードタイプの変更も
数クリック
endpoint 及びリーダーノード
Private IPに変更なし
リーダーノードのPublic IPは
変更される
移行している間は、通常より
も負荷が高くなり、データの
参照のみ、更新はできない
移行に要する時間は使用済み
のディスク量に依存します

41. 新しく追加されたソートキーのオプション
最大8つまでのSort Key列を指定でき、それぞれフェアに扱われる
41Ⓒ Classmethod, Inc.
Interleaved Sortkey
従来のソートキー：
Compound Sortkey
新しいのソートキー：
Interleaved Sortkey

42. 42Ⓒ Classmethod, Inc.
Interleaved Sortkey
Interleaved Sortkeyが有効なケース
– どのキーがWHERE句で指定されるか絞り切れないケース
– 複数キーのAND条件で検索されるケース
データマートのテーブルにINTERLEAVED SORTKEYを指定することで、
M-OLAP(Multi Dementional OLAP)ほどの重い事前集計が不要で、
M-OLAPのような高速かつ柔軟なデータディスカバリが実現

43. 43Ⓒ Classmethod, Inc.
Interleaved Sortkey
計測時間の計測
複合キーの最初のキーでは、
Compound Sortkeyが
明らかに速い
複合キーの二番目のキーでは、
Compound Sortkeyは
ブロックスキャンのため遅いが、
Interleaved Sortkeyは速い

44. 44Ⓒ Classmethod, Inc.
Interleaved Sortkey
運用時の考慮
– VACUUM REINDEXが必須 (VACUUM FULLではダメ)
– 大きなテーブルのVACUUM REINDEXは時間を要する
– 初期のテーブルに対してINSERT INTO … SELECTでデー
タ挿入しても、ソートされない
Interleaved Sortkeyは、あまり大きくないテーブルや、
頻繁に更新しないテーブルに対して利用に向いている

45. 45Ⓒ Classmethod, Inc.
動的ワークロードマネジメント(WLM)
WLM(Workload Management)
- ロングクエリ実行中に他のクエリが全く返ってこない問
題の改善するためキューを分けて並列実行する仕組み
- 目的別にキューを作成し、キューに対してメモリ(%)や
タイムアウト時間、並列実行数などを指定
ユーザグループとクエリ
グループの２種類
最大で8つのキューで、
うち１つはデフォルト
キュー

46. Dynamic と Static の区別が用意され、Dyamic Parameter は
Redshift を再起動せずにパラメータ変更が可能になりました。
Dynamic Parameter
Concurrency(並列実行数)
Percent of memory to use (メモリ使用量)
Static Parameter
User groups
User group wildcard
Query groups
Query group wildcard
Timeout
46Ⓒ Classmethod, Inc.
動的ワークロードマネジメント(WLM)

47. 動的変更
47Ⓒ Classmethod, Inc.
動的ワークロードマネジメント(WLM)
今回の環境(dc1.large シングル
クラスタ構成)では、 availableに
なるまで150秒ほど時間を要する

48. メモリの割当てを20%から80%に変更した結果
48Ⓒ Classmethod, Inc.
動的ワークロードマネジメント(WLM)
限られたリソースを積極的に効率良く使うことができるようになり、
クラスタ数が大きくなるとこのようなチューニングは費用対効果が高い
処理時間を40%短縮
メモリを80%にする
とディスクのRead
IOPSとWrite IOPS
に対する負荷が低下

49. Amazon Redshift 専用 ODBC/JDBC のリリース
Query Visualization for Amazon Redshift
Avroフォーマットのデータロードをサポート
LISTAGG関数/LISTAGG Window関数
49Ⓒ Classmethod, Inc.
その他のトピック

50. Amazon Redshift 専用 ODBC/JDBC のリリース
Query Visualization for Amazon Redshift
Avroフォーマットのデータロードをサポート
LISTAGG関数/LISTAGG Window関数
50Ⓒ Classmethod, Inc.
その他のトピック
10月には re:Invent 2015が開催
新機能が登場します（例年通りだと）

51. 51Ⓒ Classmethod, Inc.
まとめ

52. 52Ⓒ Classmethod, Inc.
まとめ
データのアクセス要件に合致したDBを見極め、最適なAWSのサービスを組合せる
- ACIDで高可用性が求められる業務データ 、柔軟な条件指定が必要
- Amazon RDS（Oracle、MySQL、PostgreSQL、SQL Server）
- Amazon RDS for Aurora（ElasticなRDBサービス）
- BASEだがレイテンシやスケールが必須 、KeyValue指定でデータ取得
- Amazon ElastiCache (Memcached、Redis)
- Amazon DynamoDB（ElasticなKVSサービス）
- 大量の非構造化データの分析
- Amazon EMR（Elastic Map Reduce）
- 大量の構造化データの分析、検索、BIツールの連携
- Amazon Redshift（ElasticなDWHサービス）
- 大量のファイルの保存
- Amazon S3（Elasticなファイルサービス）
Amazon Redshift は、性能・
運用・コストの点で優れ、
大規模な構造化データの管理・
分析に最も適したサービス

53. ご静聴ありがとうございました。
スライドは後日ブログで公開します。
53
B:24 Amazon Redshift
Ⓒ Classmethod, Inc.
db tech showcase
Sapporo HOKKAIDO SEP 10-11, 2015
#dbts2015 #be_crazy_about_db_tech