Amazon Redshift Deep Dive

アマゾン データ サービス ジャパン 株式会社

八木橋 徹平

自己紹介

• 名前– 八木橋 徹平（やぎはし てっぺい）

• 所属– アマゾンデータサービスジャパン株式会社技術統括本部ストラテジックソリューション部ソリューションアーキテクト

• 好きなAWS サービス– Amazon Redshift、Amazon Kinesis– AWS SDK（Java、Node.js）

セッションの目的

クラウド型データ・ウェアハウスであるAmazonRedshiftのアーキテクチャやチューニングのポイントを解説し、Redshiftの利点や最適な実装方法をご理解いただく。

アジェンダ

• 概要とアーキテクチャ

• 主要アップデート

• テーブル設計

• インテグレーション

• ケース・スタディ

• まとめ

概要とアーキテクチャ

クラウド型データ・ウェアハウスのメリット

• 初期投資が不要– 導入のリスクは最小

– DWHに付随するその他の投資（バックアップ、運用監視など）

• 最小限の運用管理– ランニング・コストの低下

– 自動バックアップ、障害からの自動回復など

• 成長予測と投資対効果– 導入時点で数年先のデータ増加量を見通す必要がない

– 投資に見合ったビジネスへの貢献があったか ＝ 価値のあるデータ分析ができたか

Amazon Redshiftの概要

• MPP（超並列演算）– CPU、Disk・Network

I/Oの並列化– 論理的なリソースの括り「ノードスライス」

• データの格納– 列指向（カラムナ）– 圧縮

• 他のAWSサービスとの親和性

MPP（超並列演算）

SELECT *

FROM lineitem;コンパイル・コードの生成と配信

CPU CPU CPU CPU CPU CPU

クエリーの並列実行

SELECT *

FROM lineitem;

CPU CPU CPU CPU CPU CPU

SELECT *

FROM part;

クエリー最大同時実行数：50

ノードスライス

ノードスライス＝メモリとディスクをCPUコアと同数に分割した論理的な単位

CPU CPU CPU CPU CPU CPU

列指向型

・行指向型（RDBMS） ・列指向型（Redshift）

orderid name price

1 Book 100

2 Pen 50

…

n Eraser 70

orderid name price

1 Book 100

2 Pen 50

…

n Eraser 70

データの平準化

CPU CPU CPU CPU CPU CPU

ノード間のデータ容量の偏りはクエリー実行時間に影響を与える

データの転送

自ノードに必要なデータがない場合、データ転送が発生- 単一ノード- ブロードキャスト

リーダー・ノードに各ノードの結果を集約

データのロード

CPU CPU CPU CPU CPU CPU

COPY customer

FROM /mybucket/customer/*.tbl …• スロット数と同じ並列度でロード

• バケット内のファイル数はスロットの倍数が望ましい

• Amazon EMR、AmazonDynamoDB、リモートホストからのロードも可能

クラスタの作成

クラスタの詳細

クラスタのノード構成

スナップショット（自動 ＆ カスタム）

自動スナップショット

カスタム・スナップショット

リサイズ

主要アップデート

新しいノード・タイプ – DS2

DS1 - Dense Storage（旧：DW1）

vCPU ECU Memory(GB) Storage I/O Price / hour

ds1.xlarge 2 4.4 15 2TB HDD 0.30GB/s $1.190

ds1.8xlarge 16 35 120 16TB HDD 2.40GB/s $9.520

DC1 - Dense Compute（旧：DW2）

dc1.large 2 7 15 0.16TB SSD 0.20GB/s $0.314

dc1.8xlarge 32 104 244 2.56TB SSD 3.70GB/s $6.095

DS2 – Dense Storage

ds2.xlarge 4 14 31 2TB 0.50GB/s $1.190

ds2.8xlarge 36 116 244 16TB 4.00GB/s $9.520

Redshiftのカスタムドライバ

• Redshiftに最適化されたドライバをリリース– JDBC 4.1/4.0をサポート

– ODBC3.8をサポート、2.xとも互換性あり

• PostgreSQL.orgで公開されているドライバよりもパフォーマンス・信頼性の観点で優れている

• 関連ドキュメントhttp://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/connecting-to-cluster.html

Interleaved Sort Key（１）

• Sort Keyを複数のカラムに指定が可能になり、フルスキャンを回避し、Disk I/Oを最小限に抑えられる

• 最大８つまでのSort Key列を指定できる

CREATE TABLE ~…INTERLEAVED SORTKEY (deptid, locid);

Interleaved Sort Key（２）

DeptId LocId

1 A

1 B

1 C

1 D

2 A

2 B

2 C

2 D

DeptId LocId

3 A

3 B

3 C

3 D

4 A

4 B

4 C

4 D

Compound Sort Key Interleaved Sort Key

DeptId LocId

1 A

1 B

2 A

2 B

1 C

1 C

2 D

2 D

DeptId LocId

3 A

3 B

4 A

4 B

3 C

3 D

4 C

4 D

DeptId = 1 -> 1 block

LocId = C -> 4 block

DeptId = 1 -> 2 block

LocId = C -> 2 block

テーブル設計

テーブルの分散方式

• EVEN– 各レコードがスライスにラウンドロビンで分散されるため均等にデータが蓄積される。

• DISTKEY– 明示的に指定したカラムを基準に、各レコードのスライスへの配置が決定される。

– カラムのカーディナリティによっては、スライス間で大幅な偏りが生じる。

• ALL– 全てのレコードが各コンピュート・ノードに配置される。

EVEN vs. DISTKEY（１）

• EVEN • DISTKEY=p_partkeyselect trim(name) tablename, slice, sum(rows)

from stv_tbl_perm where name='part'

group by name, slice

order by slice;

tablename | slice | sum

-----------+-------+---------

part | 0 | 1600000

part | 1 | 1600000

…

part | 126 | 1600000

part | 127 | 1600000

tablename | slice | sum

-----------+-------+---------

part | 0 | 1596925

part | 1 | 1597634

…

part | 126 | 1610452

part | 127 | 1596154

各スライスに均等に分散 キーのカーディナリティに依存

EVEN vs. DISTKEY（２）

• DISTKEY = p_brandtablename | slice | sum

-----------+-------+---------

part | 0 | 0

part | 1 | 0

part | 2 | 0

part | 3 | 0

part | 4 | 8193350

…

part | 118 | 8193342

part | 119 | 0

part | 120 | 16384823

part | 121 | 8191943

カーディナリティの低いカラムでは、データの極端な偏りが生じる場合がある= 効率の悪いクエリー

ALL

• 全レコードが各ノードの特定スライスに集約tablename | slice | sum

-----------+-------+---------

part | 0 |204800000

part | 1 | 0

part | 2 | 0

part | 3 | 0

part | 4 | 0

…

part | 96 |204800000

part | 97 | 0

part | 98 | 0

…

…

各ノードの先頭スライスに全レコードが格納される。

コロケーション（１）

• 関連するレコードのコロケーション– ジョイン対象となるレコードを同一ノードに集める。

• コロケーションの方法1. ジョインに使用するカラムをDISTKEYとして作成 または

2. 分散方式 ALLでテーブルを作成（マスター・テーブルなど）

select sum(l_extendedprice* (1 - l_discount)) as revenue

from lineitem, part

Where (p_partkey = l_partkey …

1. それぞれをDISTKEYとして作成

または2. テーブルをALLで作成

コロケーション（２）：DISTKEY

6200995 | almond pale linen | Manufacturer#3| Brand#32

part

lineitem

5024338535 | 6200995 | 0.01 |0.08 | A | F |1992-01-02 | 1992-02-14

2201039 | almond pale linen | Manufacturer#1| Brand#11

part

lineitem

121932093 | 2201039 | 0.05 |0.43 | D | E |1994-07-11 | 1994-08-23

コロケーション（３）：ALL

part

lineitem

part

lineitem

l_partkey l_partkey

p_partkey p_partkey

更新：全ノードにレプリケーションクエリー：ジョインはローカルで完結

テーブル設計のポイント - DISTKEY

• 小規模なテーブル（マスター・テーブル）はALLで作成

• ジョインを避けてテーブルを非正規化し、EVENで作成

• 複数テーブルに対して、ジョイン対象のキーをDISTKEYで作成（コロケーション）

インテグレーション

Redshiftにおけるインテグレーション

• インテグレーション ＝ ETL ＋ Upload

• オンプレミス、AWSサービス間のデータ連携

• 考慮すべき点：– シングル vs. パラレル処理？

– 同期 vs. 非同期実行？

– どこでデータ変換をすべきか？

典型的なシナリオ - バッチ

• RDBMSからデータを抽出（Extract）

• Amazon S3にアップロード（Upload）

• Amazon EMRによるデータ変換（Transform）

• Amazon Redshiftにロード（Load）

典型的なシナリオ - バッチ

オンプレDC

Redshift

orders1.csv

1,pencil,100,15-06-01

2,eraser,50,15-06-02

…

・・・ordersN.csv

30,pen,150,15-06-28

31,book,50,15-06-29

…

・レコードの抽出（1,400万件）・複数の均等なCSVファイルへ分割

パラレル・アップロード

EMR

・データのフィルタリング

サマリーテーブル

ファクトテーブル

・ファクトテーブルへのコピー・サマリーテーブルへの集計

Talendのご紹介

• EclipseベースのETLツール– Talend Open Studio for

Data Integration– OSS、無料でダウンロード可能

• AWS（S3、Redshiftなど）を含む様々なアダプタを標準で実装

• Javaによるカスタム拡張が可能

典型的なシナリオ – ジョブの定義

Extract

Upload

LoadTransform

Amazon S3にCSV

ファイルがアップロード済みの状態を仮定

Transformをどこで実行するか？

• AWSにアップロード前のオンプレミス環境アップロード前にクレンジングし、転送時間の削減

オンプレ側にリソースが必要

• S3内のファイルをEMRでバッチ変換RedshiftからTransform処理をオフロード

Hadoop関連の技術を習得

• SQLで一時テーブルから本番テーブルへRedshift内でのSQLのみで完結できる

Redshiftの負荷が増加

Amazon Elastic Map Reduce（EMR）

• 特徴 (http://aws.amazon.com/jp/elasticmapreduce/)

– フルマネージド：クラスタの構築から構成変更、破棄まですべてマネージ

– 自動化：Amazon EMRのAPIを利用するとジョブに合わせてクラスタを起動し、実行させ、終了したらクラスタを破棄、というような自動化が容易

– AWS：Amazon S3やAmazon DynamoDBからデータの入出力が可能

フルマネージドなHadoopを提供。運用を気にせずHadoopアプリケーションの開発や利用ができる。

Hadoop

Hadoop

Amazon EMRクラスタ

AWSサービスとの連携

Transform（１）：Amazon EMR

• Hiveによるデータ変換の例

awssummit-tokyo-2015/input

Amazon EMR

awssummit-tokyo-2015/output

orders_input orders_output

INSERT OVERWRITE TABLE

orders_output

SELECT

O_ORDERKEY,

O_CUSTKEY,

O_ORDERSTATUS,

O_TOTALPRICE,

O_ORDERDATE,

O_ORDERPRIORITY,

O_SHIPPRIORITY

FROM orders_input;

Transform（２）：Amazon EMR

• PowershellでAWS CLIとHiveスクリプトを実行

• AWS CLIの呼出しは非同期実行であるため、フローの中で同期実行をさせるには工夫が必要

Transform（３）：Amazon EMR

$wait = "aws emr wait cluster-running --cluster-id " + $clusterid

$wait_output = invoke-expression $wait

:OUTER for(;;) {

$describe = "aws emr describe-cluster --cluster-id " + $clusterid

$describe_output = invoke-expression $describe

for ($i=0; $i -lt $describe_output.length; $i++)

{

if (($i -eq 4) -and ($describe_output[$i] -like "*TERMINATED")){

break OUTER

}

}

Write-Host "Sleeping..."

Start-Sleep 40

}

クラスタ作成待ち

Hiveスクリプト実行後、

クラスタ削除待ち

Load（１）：Amazon Redshift

• ファイル一覧や正規表現をCOPYコマンドに指定すると、コンピュート・ノードが並列にデータをロード

• 単一ファイルの指定では、特定のコンピュートノードのみがS3にアクセスするため、並列ロードにならない

• ロードに失敗したレコードは、「stl_load_errors」表に格納される

Load（２）：Amazon Redshift

２．INSERT ~ SELECTの実行

１．COPYコマンドの実行

設計のポイント

• AWSではEMRにより変換処理を容易に実現– S3とのデータのIn/Out

– 変換処理の並列実行

– クラスタの作成・破棄

• AWS CLIからのリクエストを同期実行するにはポーリング等の工夫が必要

• 「INSERT ～ SELECT」文は、COPY同様にコンピュート・ノードで並列処理される

ケース・スタディ

MUJI Passport導入の目的

• ネット・リアルの区別なく無印良品のファンの方とコミュニケーションを図る– 複数メディアを跨ったデータの収集・解析

– ソーシャル・メディア、実店舗、インターネット

• 持続的な来店客数増 -> 売上の向上

• 値引きの最小化 ->ターゲット・マーケティング

分析関連のシステム構成

すかいらーく様 POSデータ リアルタイム解析

• 数十億件規模のPOSデータを、地図・天気・クーポン等の周辺情報と組合せリアルタイムに解析

• すかいらーくグループ様では国内に約3,000店舗を展開し、年間約4億人が利用

• POSデータの取り込みが自動化され、クエリの応答速度も数十倍まで高速化

• 従来2日間かかっていた分析業務がリアルタイムで実現

• 仮説検証のサイクルを短期間に。

NTT DOCOMO様 統合DWHプロジェクト

http://www.slideshare.net/minoruetoh/nttr4public

Redshiftのビジネス状況

• 2013年にローンチ後、AWS史上において最速の成長率を維持している

• 様々な業種（ゲーム、広告、製造、流通 等々）や規模（スタートアップから大手企業）のお客様において導入が進んでいる

• NTT DOCOMO様やAmazon.comにおけるペタバイト級の導入事例

まとめ

Redshiftの検討ポイント

• 低リスクかつ低コストで高速・スケーラブルなデータウェアハウスを容易に構築・運用できる– 無料利用枠の対象：最初の2か月間 dc1.large 750時間/月

• 性能を最大限に引き出すテーブル設計や運用を見据えた他のAWSサービスとの連携

• スタートアップからエンタープライズにおよぶ幅広い分野での実績

ご清聴ありがとうございました。