db-tech-showcase-sapporo-b24-20150911p

B:24 Amazon Redshift

石川　覚ソリューションアーキテクトクラスメソッド株式会社

Ⓒ Classmethod, Inc.

2015年09月11日

事例でわかるデータ分析基盤の活用～ Amazon Redshift の最新動向

db tech showcaseSapporo HOKKAIDO SEP 10-11, 2015

1

#dbts2015 #be_crazy_about_db_tech

石川覚（いしかわさとる）

2Ⓒ Classmethod, Inc.

メーカー系SE、VoIP関連ベンチャー企業を経て

CMに2014/06 join

札幌出身、東京に８年

Linux, Java, MySQL, Redshift マイブームは統計学、R

クラスメソッド株式会社ソリューションアーキテクト


ブログ

ブログ： http://dev.classmethod.jp/

http://dev.classmethod.jp/


アジェンダデータベース利用の変化

AWSが提供するビックデータソリューション

Amazon Redshift の解説

データ分析基盤の構成要素データ分析基盤の導入事例

Amazon Redshift 導入のポイント

Amazon Redshift の最新動向

まとめ


データベース利用の変化～DBに求められたこと、これから求められること～

RDBとは、行とカラムで構成される二次元のデータ構造で管理するデータベースで、ACIDという特性を持つ

ACID特性とは、関連する複数の処理を一つの処理単位にまとめて管理するトランザクション処理に求められる4つの特性


ACIDなRDB

RDBは、データベースに対して、SQL言語による柔軟な条件指定ができる

RDBの普及に伴い、データストアは全て「一貫性」であるのが当たり前となった

Atomicity：原子性

Consistency：一貫性

Isolation：独立性

Durability：耐久性

高可用性：冗長化データのコピーを複数のノードに持ち、仮にノードの障害を起こしても、障害時に切り替えて処理を引き継ぐ

高拡張性：シャーディング複数のノードを用意し、データごとに受け持つノードを分けることで、性能を確保する


非機能要件の高まり -「可用性」と「拡張性」データ更新時に、全ノードに変更が行き渡り、一貫性を保証するのが大変一貫性と、高可用性・高拡張性の両立には大きな困難が伴う

NoSQLは、SQLデータベース以外のデータベースを表し、BASE

（Basically Available・Soft state・Eventually consistent）という特性を持つ


BASEなNoSQL

key Valueによる高速なデータアクセスが可能一方、インデックスによる範囲検索はできない

高い可用性更新は非同期で反映結果整合性

KVS（key Value Store）

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


AWSのDB関連サービス


AWSが提供するビックデータソリューション

AWSサービス - 約50以上のサービス


AWSサービスの全体像


Amazon Redshift の解説


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

PostgreSQLとほぼ互換

- PostgreSQL8.0.2がベース

- PostgreSQLのツールやODBC/JDBCでも接続可能

- 多くのBIツールがサポート

旧ParAccel(Actian)のDWHがベース

- 2012年7月に旧ParAccelの技術ラインセンスを獲得

- DBエンジンは旧ParAccel技術がベース


Redshiftの技術的バックグラウンド


クラスタの構成Leader Node - SQL Endpoint - メタデータの管理 - クエリ実行の連携

Compute Nodes - カラムナ・ストレージをローカルに保持 - クエリーを並列実行 - S3, DynamoDB, EMR, SSHを経由して、

- データのロード・アンロード、 - バックアップ・リストア

２つのHWプラットフォーム

- データ処理に最適化した - DC1 SSD 0.16TB~326TBまでスケール

- DC2 HDD 2TB~2PBまでスケール

各Compute Nodeはスライスに分けられる

- スライスはCPUコア毎分けられる

- DC1：largeは2スライス、　　　　　8xlargeは32スライス

- DC2：xlargeは4スライス、　　　8xlargeは36スライス

各スライス毎にメモリ、CPU、　　　　ディスクが割り当てられる

ワークロード単位を各スライスが　　　並列に実行する


コンピュートノードとスライス

1. 分析データ(ファイル)をS3に置く

2. ETL処理する

3. ETL後データ(ファイル)をS3に置く

4. COPYコマンドでデータを高速ロード

5. Analyze&Vacuumを実行（必要に応じて）

6. BIツール経由でSQLを投入して利用開始


基本的な利用の流れ

分析データ ETL

EC2/EMRS3

データ（ETL済み）

Redshift

データ

S3 BIツール (Tableau)

分析

Analyze&Vacuumを実行管理者


データのロード(COPY)COPY from S3 - S3に置いてそのファイルをRedshiftに取込む

- ETL済みのデータ

COPY from EC2 - EC2上のファイルをRedshiftに取込む

- マニフェストファイルはS3に事前に置く必要がある

- VPC内でデータを渡せる

その他のデータソース

- DynamoDB、EMR(Elastic Map Reduce)、Treasure Data


データ分析基盤の構成要素


データ分析基盤の構成要素既存システムからのデータ収集

（構造化データ）

POS

Desktop

(Kinesis)

DWH (Redshift)

(S3)

(EC2)

(Tableau Server

on EC2)

Web


Amazon Redshift データ分析基盤の導入事例

全国のスーパーやドラックストアなどのPOSデータを中心にデータ分析

PCのデータベースでは限界

増え続けるデータに対して効率よく収集し分析する基盤の構築が必要


資生堂様 - POSデータ分析基盤

テンプレートを用いて、約1か月間でデータ分析を開始

分析対象のレコード件数を数十億件規模に拡大し、地域別・ブランド別・店舗別・商品別・日月別といった様々な角度から分析


資生堂様 - POSデータ分析基盤

ETL

Analyze&Vacuum

COPY＆マート

「調べたいこと」や「やりたいこと」などを話しかけると、その言葉の意図を読み取り、情報やサービス、端末機能の中から最適な回答を返します。短周期かつ高速なデータ分析を行い、機能追加や改善に繋げ、利用機会拡大を目指す処理時間の短縮、機能追加や変更の際の対応の容易さ、ビジュアル分析しやすいビュー


NTTドコモ様 - しゃべってコンシェル

データ分析基盤の設計とアプリの開発を担当

これまで数時間掛かっていた分析処理を15分に短縮

データの種類や分析項目が増えても、クラウドのメリットを活かしてサーバー環境を柔軟にスケールできるようになりました


NTTドコモ様 - しゃべってコンシェル

回転寿司のすし皿に ICタグを取り付けてセンサーで取得

一日当たり平均で数百万件、レーン上を流れる寿司情報をリアルタイムにクラウド上に転送

売上管理や、店舗での業績管理や需要予測に活用したい


あきんどスシロー様リアルタイム収集と分析

設計と構築を担当し、約1ヶ月間でリリース

注文情報、着席状況、需要予測情報とデータブレンディング各店舗の寿司の売上情報だけでなく、来店状況やオペレーション状況をほぼリアルタイムで把握する事が可能

すし皿に取り付けられたICチップをセンサーで読み取り、リアルタイム収集



すし皿に取り付けられたICチップをセンサーで読み取り、リアルタイム収集



Producer

GoFのProducer-Consumerパターン N対Nの可用性と拡張性を担保

Consumer


他にも多数の事例を紹介

http://classmethod.jp/cases/

事例とともに、システム構成がご覧になれます


Amazon Redshift 導入のポイント


主キー・ソートキーの指定主キー

- RDBと同様に一意に識別できるキーを指定する

ソートキー - 主キーに加えて、集計したい列を順に追加 - ファクトテーブルは日付など増加する値が一般的外部キー、一意キー - 必要に応じて設定する

制約は有効にならないが、クエリプランナーによって利用されるので設定したほうが良い圧縮分析(ANALYZE COMPRESSION)の判定に利用される


分散キーの選定EVEN - 各レコードをラウンドロビンでスライスに蓄積する

DISTKEY - 各レコードの明示的に指定したカラム(一つのみ)のハッシュ値に基づきスライスにデータを蓄積する

ALL - 全てのノードにデータを蓄積する

クラスタ内のスライスに対し、均等にデータを配置するジョイン対象となるテーブルとのコロケーション考慮するデータサイズが小さなマスタテーブルやディメンションはALL ファクトテーブルはDISTKEYを指定、不可能な場合はEVEN


列圧縮タイプデータ投入済みテーブルの分析して推奨列エンコーディングをレポート出力 - ANALYZE COMPRESSIONの例エンコードタイプキーワード

raw（非圧縮） RAWバイトディクショナリ BYTEDICTデルタ DELTA

DELTA32KLZO LZOmostlyn MOSTLY8

MOSTLY16MOSTLY32

ランレングス 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 を指定すると推奨列エンコードで再作成される


一般的なRDBとの相違点主キー制約、一意制約、外部キー制約は違反してもエラーにならない - 重複したキーのデータが投入される

サポートしているデータ型が11種類のみ

- TEXT型など内部的にVARCHARに勝手に置き換えられる

文字コードはUTF-8のみ

- VARCHARやCHARサイズ指定はバイト指定

- 4バイト以内のUTF-8


同時実行数・カーソル数の最適化最大接続・実行・カーソル数の相関

実行時間 vs クエリー並列度

クラスタ WLMのキュー最大同時接続数 500以下ー最大クエリ同時実行数 50以下(15以下が推奨値) 50以下(15以下が推奨値)最大同時実行カーソル数クラスタの最大クエリ同時実行数以下ー

ベストプラクティスは15以下の同時実行レベルを使用すること


Amazon Redshift 最新動向～ 2015 夏


ノードタイプの名称変更・追加高密度ストレージノードタイプ（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


ノードタイプの追加・名称変更

ds2はds1(dw1)と比較して

価格据え置きスペック２倍

スペックの変更点


ノードタイプの追加・名称変更

ノーコスト、ノーリスク、ハイパフォーマンス！

ds1(dw1)ご利用の方はぜひノードタイプをds2に

性能の検証結果

ds1(dw1)のリザーブドインスタンスの下取りもしています。


ノードタイプの追加・名称変更ノードタイプの変更

ノードタイプの変更も数クリック

endpoint 及びリーダーノード

Private IPに変更なし

リーダーノードのPublic IPは変更される移行している間は、通常よりも負荷が高くなり、データの参照のみ、更新はできない移行に要する時間は使用済みのディスク量に依存します

新しく追加されたソートキーのオプション

最大8つまでのSort Key列を指定でき、それぞれフェアに扱われる


Interleaved Sortkey

従来のソートキー： Compound Sortkey

新しいのソートキー：Interleaved Sortkey


Interleaved SortkeyInterleaved Sortkeyが有効なケース

– どのキーがWHERE句で指定されるか絞り切れないケース

– 複数キーのAND条件で検索されるケース

データマートのテーブルにINTERLEAVED SORTKEYを指定することで、 M-OLAP(Multi Dementional OLAP)ほどの重い事前集計が不要で、

M-OLAPのような高速かつ柔軟なデータディスカバリが実現


Interleaved Sortkey計測時間の計測

複合キーの最初のキーでは、 Compound Sortkeyが

明らかに速い

複合キーの二番目のキーでは、 Compound Sortkeyは

ブロックスキャンのため遅いが、Interleaved Sortkeyは速い


Interleaved Sortkey運用時の考慮

– VACUUM REINDEXが必須 (VACUUM FULLではダメ)

– 大きなテーブルのVACUUM REINDEXは時間を要する

– 初期のテーブルに対してINSERT INTO … SELECTでデータ挿入しても、ソートされない

Interleaved Sortkeyは、あまり大きくないテーブルや、頻繁に更新しないテーブルに対して利用に向いている


動的ワークロードマネジメント(WLM)WLM(Workload Management) - ロングクエリ実行中に他のクエリが全く返ってこない問題の改善するためキューを分けて並列実行する仕組み

- 目的別にキューを作成し、キューに対してメモリ(%)やタイムアウト時間、並列実行数などを指定

ユーザグループとクエリグループの２種類最大で8つのキューで、うち１つはデフォルトキュー

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


動的ワークロードマネジメント(WLM)

動的変更



今回の環境(dc1.large シングルクラスタ構成)では、 availableになるまで150秒ほど時間を要する

メモリの割当てを20%から80%に変更した結果



限られたリソースを積極的に効率良く使うことができるようになり、クラスタ数が大きくなるとこのようなチューニングは費用対効果が高い

処理時間を40%短縮メモリを80%にするとディスクのRead IOPSとWrite IOPSに対する負荷が低下

Amazon Redshift 専用 ODBC/JDBC のリリース

Query Visualization for Amazon Redshift Avroフォーマットのデータロードをサポート

LISTAGG関数/LISTAGG Window関数


その他のトピック

Amazon Redshift 専用 ODBC/JDBC のリリース

Query Visualization for Amazon Redshift Avroフォーマットのデータロードをサポート

LISTAGG関数/LISTAGG Window関数


その他のトピック

10月には re:Invent 2015が開催新機能が登場します（例年通りだと）


まとめ


まとめデータのアクセス要件に合致した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

B:24 Amazon Redshift


db tech showcaseSapporo HOKKAIDO SEP 10-11, 2015

#dbts2015 #be_crazy_about_db_tech

Data & Analytics

db-tech-showcase-sapporo-b24-20150911p