[AWSマイスターシリーズ] Amazon Redshift

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

AWS マイスターシリーズ

Amazon Redshift

2013.07.16

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

ソリューションアーキテクト八木橋徹平


2

アジェンダ

Amazon Redshift とは？

Amazon Redshift の管理

テーブル設計とデータのロード

チューニング・ポイント

まとめ


3

アジェンダ





まとめ


4

AWSの様々なサービスお客様のアプリケーション

認証 AWS IAM

モニタリング Amazon

CloudWatch

Web管理画面 Management

Console

デプロイと自動化 AWS Elastic Beanstalk AWS Cloud Formation

AWS OpsWorks

IDEプラグイン Eclipse

Visual Studio

ライブラリ & SDKs Java, PHP, .NET, Python, Ruby,

node.js

Development &

Administration

AWS グローバルインフラ Geographical Regions, Availability Zones, Points of Presence AZ Region

ネットワーク & ルーティング Amazon VPC / Amazon Elastic Load Balancer / Amazon Route 53 /AWS Direct Connect

Infrastructure

Service

コンピュータ処理 Amazon EC2

Auto Scale

ストレージ Amazon S3 Amazon EBS

Amazon Glacier AWS Storage Gateway

データベース Amazon RDS

Amazon DynamoDB Amazon ElastiCache

Amazon Redshift

コンテンツ配信 Amazon CloudFront

メッセージ Amazon SNS Amazon SQS Amazon SES

分散処理 Elastic MapReduce

検索エンジン Amazon Cloud Search

トランスコード Amazon Elastic Transcoder

ワークフロー管理 Amazon SWF

Application

Service


5

AWS のグローバルインフラストラクチャ

US West (Northern

California)

US East (Northern

Virginia)

EU (Ireland)

Asia

Pacific (Singapore)

Asia

Pacific (Tokyo)

GovCloud (US ITAR

Region)

US West (Oregon)

South

America (Sao Paulo)

AWS Regions

AWS Edge Locations

• US East、US West、EU に続き第４番目のリージョンとして６/５からTokyo リージョンでもAmazon Redshift が利用可能に

• hs1.xlarge、hs1.8xlarge でクラスタ構築が可能

Asia

Pacific (Sydney)


6

AWS の各種データサービス

Amazon RDS

OLTP 用フルマネージドのSQLデータベースサービス

Amazon DynamoDB

高速、予測可能かつ拡張性の高いフルマネージドNoSQL データベースサービス

Amazon Redshift

データウェアハウス用フルマネージド、超並列、カラムナ型（列指向型）データベースサービス

Amazon EMR

拡張性の高い、Hadoop のフルマネージドサービス


7

なぜマネージド・データベースなのか？

backup & recovery, data load & unload

performance tuning 25% 40%

5% 5%

scripting & coding security planning

install, upgrade, patch and migrate

documentation, licensing & training

付加価値の高い

ビジネス・業務に注力


8

Amazon Redshift の概要

Data Warehouse as a Service – 分析用に整理された大量の統合業務データの管理サービス（フルマネージドサービス）

拡張性：数TB ～数PB まで拡張可能

高速：カラムナ型、超並列演算(MPP)

低額：インスタンスの従量課金（初期費用、ライセンス費用不要）


9

行型 vs. カラムナ型

DWH にはカラムナ型のデータベースが用いられる。

orderid name qty

1 Book 100

2 Pen 50

…

n Eraser 70

orderid name qty

1 Book 100

2 Pen 50

…

n Eraser 70

行型 – トランザクション処理向きカラムナ型 – 分析処理向き


10

アーキテクチャ

リーダーノードを経由してクエリーを実行

各コンピュートノードで演算が並列実行

各コンピュートノードにローカルストレージを保持

コンピュートノードはhs1.xlとhs1.8xlから選択

BIツール

リーダーノード

コンピュートノード



JDBC/ODBC

10GigE Mesh

SQL エンドポイント: • クエリーの並列化 • 結果を生成

クエリー実行ノード • “N” スケールアウト

を実現 • ローカルディスク

S3, DynamoDB, EMRとの統合


11

ノード・タイプ

High Storage Extra Large (XL) DW Node: • CPU: 2 virtual cores • ECU: 4.4 • Memory: 15 GiB • Storage: 3 HDD with 2 TB of local attached storage • Network: Moderate • Disk I/O: Moderate • API: dw.hs1.xlarge

High Storage Eight Extra Large (8XL) DW Node: • CPU: 16 virtual cores • ECU: 35 • Memory: 120 GiB • Storage: 24 HDD with 16 TB of local attached storage • Network: 10 Gigabit Ethernet with support for cluster placement groups • Disk I/O: Very High • API: dw.hs1.8xlarge


12

クラスタの拡張性

シングルノード (2TB)

クラスター 2 – 32ノード（4TB – 64TB)

クラスター 2 – 100ノード（32TB – 1.6PB)

Extra Large Node (XL)

8 Extra Large Node (8XL)


13

アジェンダ





まとめ


14


自動化 or 最小限の管理作業

• Amazon Redshift は最小限の管理作業を必要とする。

• 例：

• クラスタの作成、リサイズとリストア – Management Consoleから

全て操作可能

• 障害からの回復 – ノードの自動プロビジョニング、データの回復

データの耐久性

• 全てのデータは、ローカル・ディスクに保存され、別ノードにもミラーリングされる。

• 各ノードは、複数のディスク装置から構成

• Amazon S3 上に自動 or 手動のスナップショット


15

クラスタ作成の事前準備

Classic-EC2 またはVPC 内にクラスタ作成が可能

VPC 内に作成する場合、「Cluster Subnet Group」を事前に作成

クラスタの作成先となるアベイラビリティ・ゾーンを指定


16

クラスタの作成（１）

Amazon Redshift の管理メニューから「Launch Cluster」クリック後、詳細を入力

クラスタ名

データベース名

ポート番号

管理ユーザ名


17

クラスタの作成（２）

ノード・タイプとクラスタのサイズを選択

インスタンス・タイプ

クラスタのタイプノード数


18

クラスタの作成（３）

セキュリティ、ネットワーク環境の設定

データベースの暗号化

VPC の指定 Cluster Subnet Group の指定

Security Group の指定 • 最後の確認画面で「Launch Cluster」を

クリックするだけで、クラスタ作成が開始！


19

クラスタのリサイズ

クラスタのサイズ変更も容易


20

アジェンダ





まとめ


21

テーブル設計

最適なSORTKEY の選択

• SORTKEY に応じてデータをディスク上に順次格納

• クエリー・オプティマイザはSORTKEY に基づいた最適な実行計画を構築

最適なDISTKEY の選択

• DISTKEY はコンピュート・ノード間におけるデータの配置を決定

最適な圧縮タイプの選択

• 複数の圧縮アルゴリズムから選択

制約の定義

• プライマリキー制約と外部キー制約は、実行計画の作成時にヒントとして利用される。


22

SORTKEY の選択

SORTKEY • SORTKEY に応じて、ディスク上にデータが順次格納

• クエリー・オプティマイザはソート順序を考慮し、最適なクエリー・プランを構築

Tips • 頻繁に特定のカラムに対して、範囲または等式検索を行う場合、

SORTKEY として指定

-> 検索対象外のブロックをスキップ

• 頻繁にジョインを行う場合、該当カラムをSORTKEY およびDISTKEY として指定

-> ハッシュ・ジョインの代わりにソート・マージ・ジョインが選択される


23

SORKEY の例

orderdate 列をSORTKEY に指定した場合：

2013/07/17

2013/07/18

2013/07/18

2003/07/19

…

I0001

I0002

I0003

I0004

・・・

2013/08/20

2013/08/21

2013/08/22

2013/08/22

…

I0020

I0021

I0022

I0023

orderdate … orderid

SELECT * FROM orders WHERE

orderdate BETWEEN ‘2013-08-01’ AND

‘2013-08-31’;

クエリーに関係のないデータ・ブロックはスキップし、該当するブロックだけを読込む


24

DISTKEY の選択

DISTKEY • DISTKEY は、どのようにテーブル内のデータがコンピュート・

ノード間に分散されるかを決定

• 目指すべきゴール

• ノードやスライス間で可能な限り、均一にデータを配分

-> 偏ったデータ配分は、特定ノードの負荷を増加させ、全体の処理の遅延につながる可能性がある。

• ジョイン時のデータ転送を極小化するために、データをコロケーションさせる

分散方式 : CREATE TABLE ~ DISTSTYLE EVEN | KEY

• Even distribution：ラウンド・ロビンでデータを分散

• Key distribution：DISTKEYに基づいてデータが分散


25

DISTKEY の例

関連するデータをコロケートさせジョインを高速化


26

圧縮タイプの選択（１）

データ圧縮により1回のディスクI/Oで読み込めるデータ件数を増やす

• Redshiftでは1MBのブロック・サイズを採用

• データ解凍時にCPUを消費

「analyze compression」コマンドにより、最適な圧縮アルゴリズムを提示

analyze compression listing;

Table | Column | Encoding

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

listing | listid | delta

listing | sellerid | delta32k

listing | eventid | delta32k

listing | dateid | bytedict

listing | numtickets | bytedict

listing | priceperticket | delta32k

listing | totalprice | mostly32

listing | listtime | raw


27

圧縮タイプの選択（２）

データ圧縮のアルゴリズム

• RAW：非圧縮

• BYTEDICT：反復される値にディクショナリを使用

• DELTA/DELTA32K：連続する値の最適化（datetimes、sequenceなど）

• MOSTLY8、MOSTLY16、MOSTLY32：大半の値が低い範囲のビットの桁に集中している場合に最適化

• RUNLENGTH：同一の値が連続する場合に最適化

• TEXT255/TEXT32K：テキスト内の単語にディクショナリを使用


28

データ圧縮の例

orderdate 列にDELTA エンコーディングを適用：

2013/08/20

2013/08/21

2013/08/22

2013/08/22

…

I0020

I0021

I0022

I0023

orderdate … orderid

2013/08/20

1

1

0

…

I0020

I0021

I0022

I0023

全てのレコードが4バイトのDATE型として格納されるのではなく、前のレコードとの差分を表す数値として格納される。

注意：上記はあくまで概念を説明する図になり、実際はテーブル作成後、エンコーディングの変更はできません。


29

制約の定義

主キーや外部キー制約はあくまで情報として取り扱われ、制約自体は施行されない

クエリー・プランナーが実行計画の構築時にヒントとして利用

注意事項

• プランナーは制約が定義されている場合、常にデータが妥当であると認識する（例：一意や外部キーとして参照可）。

• 不整合なデータは、誤ったクエリー結果を返す可能性がある

• データの妥当性が確実である場合のみ制約を定義


データの挿入

30

AWSの様々なサービスからデータのロードが可能

• Amazon S3からの各ノードへの並列データロード

• Amazon DynamoDBからの挿入

• Amazon EMR（予定）

• ロードの際に発生したエラーをトラッキング

スタースキーマやインデックスは不要

RDBMSと比較し、x 2 – 4の圧縮率

• 複数の圧縮アルゴリズムの採用

• 自動圧縮機能


データの挿入

Amazon S3からデータのローディング

31

% psql --host=mydb.wetyuioop.us-east-1.redshift-

dev.amazonaws.com --port=5439 –username=admin --

dbname=mydb

mydb=# copy customer from 's3://data/customer.tbl.1'

credentials

'aws_access_key_id=XXXXYYYYZZZZ;aws_secret_acc

ess_key=abcdefghijklmn' delimiter '|';


32

アジェンダ





まとめ


パフォーマンス・チューニング時の

考慮事項

どのようにパフォーマンス・ネックを特定するか？

• EXPLAIN コマンドの使用、SVL_QUERY_SUMMARY、SVL_QUERY_REPORT テーブル

• クエリー・プランの解析、場合によりクエリーの書換え

どのくらいリソースを消費してきるか？

• クエリーの中間結果を出力するためのディスクI/O

• メモリー消費量の分析

• スキーマの再設計、SORTKEY やDISTKEY

クエリーが他のクエリーの完了を待っているか？

• クエリーの実行時間を特定し、優先度を決定

• 複数のキューを定義し、適宜クエリーに割当てる。

33


クエリーの解析（１）

EXPLAIN コマンド

EXPLAIN プランから： • クエリーの実行ステップ

• 各ステップでどのオペレーションが実行されるか

• 各ステップでどのテーブル・カラムが使用されるか

• 各ステップでどのくらいのデータを処理する必要があるか

34

explain select avg(datediff(day, listtime, saletime)) as avgwait from sales, listing

where sales.listid = listing.listid;

QUERY PLAN

XN Aggregate (cost=6350.30..6350.31 rows=1 width=16)

-> XN Hash Join DS_DIST_NONE (cost=47.08..6340.89 rows=3766 width=16)

Hash Cond: ("outer".listid = "inner".listid)

-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=12)

-> XN Hash (cost=37.66..37.66 rows=3766 width=12)

-> XN Seq Scan on sales (cost=0.00..37.66 rows=3766 width=12)


クエリーの解析（２）

大量データを更新した場合、ANALYZEコマンドを実行し、統計情報を更新。クエリープランが変わる可能性も。

STL_EXPLAIN テーブル（実行済みクエリー）

SVL_QUERY_SUMMARY と SVL_QUERY_REPORT 内に更に詳細情報が含まれる

35

analyze lineitem;

select query,nodeid,parentid,substring(plannode from 1 for 30),

substring(info from 1 for 20) from stl_explain

where query=10 order by 1,2;

query | nodeid | parentid | substring | substring

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

10 | 1 | 0 | XN Aggregate (cost=6350.30... |

10 | 2 | 1 | -> XN Merge Join DS_DIST_NO | Merge Cond: ("outer"

10 | 3 | 2 | -> XN Seq Scan on lis |

10 | 4 | 2 | -> XN Seq Scan on sal |


クエリーの解析（３）

Management Consoleから確認

• 各クエリーの詳細と負荷を確認することが可能

36


Workload management（１）

長期実行されるクエリーは、短期実行クエリーをキュー内に待たせることがある。

想定されないパフォーマンス劣化により、ユーザー・エクスペリエンスが下がる可能性がある。

デフォルトでは、Redshiftクラスタは単一のキューで構成されている。

37

Running Default queue


Workload management（２）

用語と概要

38

User Group A

Short-running queue

Short

Query Group

Long-running queue

Long

Query Group


複数キューの定義（１）

クエリーが別のクエリーの完了を待っているかを特定

• 短期・長期実行のクエリーを特定し、優先順位を付ける。

Management Consoleから新規キューを定義

39


複数キューの定義（２）

クエリーのワークロードは全コンピュート・ノードに分散される。

• 並列度の増加は、リソース競合（CPU、メモリ、ディスクI/O）により必ずしも性能を向上するとは限らない。

• 他のクエリーを待たせ、実行中クエリーを先に終了させるほうが、全体のスループットは向上する場合もある。

40


クエリーの割当て例

ユーザー・グループに割当て

クエリー・グループに割当て

41

create group usergroupA;

create user userA in group usergroupA password 'Password1';

set query_group to ‘ShortQueryGroup’;

select count(*) from lineitem;

reset query_group;


42

アジェンダ





まとめ


43

Amazon Redshift の利点

初期費用が不要

• DWHに必要なDiskを割当て、利用した分だけ課金

拡張性

• ノード追加することにより、データ格納領域を容易に拡張することができる

運用管理が非常に容易

• Management Console からクラスタの作成、リサイズ、バックアップ、リストアが全て行える

Documents

[AWSマイスターシリーズ] Amazon Redshift