20140620 dbts osaka_redshift_v1.0_slideshare

Amazon Redshift Deep Diveアマゾンデータサービスジャパン株式会社事業開発部マネージャー大久保順 2014/06/20

本日のアジェンダ

• Amazon Web Servicesとは？

• Amazon Redshiftのアーキテクチャ

• 速さを引き出すためのベストプラクティス

Amazon Web Servicesとは？

アマゾンについて

創業：1994年7月

本社：米国ワシントン州シアトル

創業者&CEO：ジェフ・ベゾス

744.5億ドルの総売上高(2013年度)

2億1500万超のアクティブカスタマー(2013年10月時点)

コンシューマービジネス

1億を超えるアクティブなアカウント

８カ国で展開 :米国, 英国, ドイツ, 日本, フランス,カナダ, 中国,

イタリア

セラー（売り手）様向けビジネス

アマゾンのウェブサイト上で販売

自社小売ウェブサイトにAmazonの技術を利用

フルフィルメントセンター（物流センター）の活用

IT インフラビジネス

ウェブスケールでのクラウド基盤の提供

190以上の国にて、数十万に及ぶ登録アカウント

データセンターインターネット

AWS(Amazon Web Services)とは

Amazonがビジネス課題解決のために作り上げたITを

誰でもサービスとして利用できるようにしたもの

一般的にはクラウドコンピューティングと呼ばれている

AWSの特徴

オンデマンドで、必要な時に必要なだけ、初期投資ゼロ

ワンクリックで、数分後にはITリソースが手元に

貴重な人的リソースは、インフラではなくビジネス成長に集中

低価格にこだわりお客様に還元

規模の拡大とイノベーション

サービス開始から42回の値下げを実施

Amazon Redshiftのアーキテクチャ

2013年2月のローンチ以降多数の新機能を追加

• Regions – N. Virginia, Oregon, Dublin, Tokyo, Singapore, Sydney

• Certifications – PCI, SOC 1/2/3, FedRAMP, others

• Security – Load/unload encrypted files, Resource-level IAM, Temporary credentials, HSM, ECDHE for perfect forward security

• Manageability – Snapshot sharing, backup/restore/resize progress indicators, Cross-region

• Query – Regex, Cursors, MD5, SHA1, Time zone, workload queue timeout, HLL

• Ingestion – S3 Manifest, LZOP/LZO, JSON built-ins, UTF-8 4byte, invalid character substitution, CSV, auto datetime format detection, epoch, Ingest from SSH

2013年2月のローンチ以降多数の新機能を追加

Service Launch (2/14)

PDX (4/2)

Temp Credentials (4/11)

Unload Encrypted Files

DUB (4/25)

NRT (6/5)

JDBC Fetch Size (6/27)

Unload logs (7/5)

4 byte UTF-8 (7/18)

Statement Timeout (7/22)

SHA1 Builtin (7/15)

Timezone, Epoch, Autoformat (7/25)

WLM Timeout/Wildcards (8/1)

CRC32 Builtin, CSV, Restore Progress (8/9)

UTF-8 Substitution (8/29)

JSON, Regex, Cursors (9/10)

Split_part, Audit tables (10/3)

SIN/SYD (10/8)

HSM Support (11/11)

Kinesis EMR/HDFS/SSH copy, Distributed Tables, Audit

Logging/CloudTrail, Concurrency, Resize Perf., Approximate Count Distinct, SNS

Alerts (11/13)

SOC1/2/3 (5/8)

Sharing snapshots (7/18)

Resource Level IAM (8/9)

PCI (8/22)Distributed Tables, Single Node Cursor Support, Maximum Connections to 500

(12/13)

EIP Support for VPC Clusters (12/28)

New query monitoring system tables and diststyle all (1/13)

Redshift on DW2 (SSD) Nodes (1/23)

Compression for COPY from SSH, Fetch size support for single node clusters, new system tables with commit stats,

row_number(), strotol() and query termination (2/13)

Resize progress indicator & Cluster Version (3/21)

Regex_Substr, COPY from JSON (3/25)

Amazon Redshiftアーキテクチャ図

リーダーノード

• クライアントからのSQLエンドポイント

• データ分散の管理

• クエリの実行計画生成と実行– SQL文の実行計画をC++のコードに変換し、コンパイル

– コンパイルした実行コードを各コンピュートノードに配布し、結果を収集

– SQL文の特定の関数はリーダーノードのみで実行されるhttp://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions_leader_node_only.html

http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions_leader_node_only.html

コンピュートノード

• リーダーノードで生成されたコンパイル済コードを実行し、中間結果をリーダーノードに返す– リーダーノードが最終的な集計を行い、クライアントへ結果を返す

• コンピュートノードは各ノードにCPU, メモリ, ローカルディスクストレージを持つ。（処理能力やリソース容量はクラスタのインスタンスタイプにより決定）– DW1 – Dense Storage Nodesハードディスクベースのインスタンスタイプ。データ量が多い用途に向く。

– DW2 – Dense Compute NodesSSDベースのインスタンスタイプ。計算量が多い、またディスクI/Oが多い用途に向く。

スライス

• 各コンピュートノードのメモリとディスクストレージは「スライス」と呼ばれる単位に分割して管理されている

• スライス数は各コンピュートノードのプロセッサコア数と同じ

• パラレルクエリ実行は、スライス毎の負荷が極力均等になるよう分散される

• カラムナー型ストレージ

• データ圧縮

• ゾーンマップ

• 直結ストレージ

• データブロックサイズ

• 行指向のストレージでは、必

要なデータを得るために全カ

ラムのデータを取得する必要

がある

ID Age State Amount

123 20 CA 500

345 25 WA 250

678 40 FL 125

957 37 WA 375

I/Oを減らすための仕組み

• カラムナー型ストレージで

は、必要なデータだけを読

み取ることができる

ID Age State Amount

123 20 CA 500

345 25 WA 250

678 40 FL 125

957 37 WA 375



• データ圧縮






• データ圧縮




10 | 13 | 14 | 26 |…

… | 100 | 245 | 324

375 | 393 | 417…

… 512 | 549 | 623

637 | 712 | 809 …

… | 834 | 921 | 959

10

324

375

623

637

959

• 各ブロックに含まれる最小値と

最大値を保持

• 必要なデータを含んでいないブ

ロックは読取りをスキップ



• データ圧縮




• パフォーマンス向上のため、各

コンピュートノードに直結した

ローカルストレージを使用し、

スキャンレートを最大化

• データの複製とバックアップは

自動的に行われる

• HDD/SSD の2種類のプラット

フォーム



• データ圧縮




• 1MB/block

• 参考：RDBMSの一般的なデー

タブロックサイズは、

8KB~32KB/block

並列・分散処理

• クエリ

• ロード

• バックアップ/リストア

• リサイズ

• Amazon S3, Amazon DynamoDB, 任

意のSSH接続から、パラレルにロー

ディングを実施

• DDLに従い、データは自動的に分

散・ソートして格納される

• ノード数に従ってスケール


• クエリ

• ロード


• リサイズ

• Amazon S3へのバックアップは自動的、継続的

かつ差分で取得される

• スナップショット保持期間は設定可能。任意の

タイミングでのスナップショット取得も可能

• DR用途向けにリージョンをまたいでバックアッ

プを取得することが可能

• ストリーミング・リストアですぐにクエリ受付

可能な状態に


• クエリ

• ロード


• リサイズ

• リサイズ中もオンライン状態を維持

• バックグラウンドで新しいクラスタをプ

ロビジョニング

• 新旧ノード間でのデータコピーはパラレ

ルに処理


• クエリ

• ロード


• リサイズ

• SQLエンドポイントの切替はDNS

更新で行われる

• コンソール / API経由で実行


• クエリ

• ロード


• リサイズ

速さを引き出すためのベストプラクティス

サポートするデータ型

• 次の種類のデータ型をサポート– 数値: Integers up to 64 bits, fixed precision up to 128 bits, floating

point up to 64 bits

– 文字列: fixed width or varying up to 64K characters

– ブーリアン

– 日付・時刻: from 4713 BC to 5874897 AD with a precision of 1

microsecond

• 注）N[VAR]CHARとTEXTは[VAR]CHARとして格納

正しいデータ型を選ぶ

• Redshiftのパフォーマンスは「如何にI/Oを最適化するか」にかかっている

• 列幅を必要以上に取らない– 例）国コードにBIGINTを使う– 例）国名にCHAR(MAX)を使う

• 適切なデータ型を使う– 日付・時間にはCHARではなくTIMESTAMPやDATEを使う– 列幅が分かっている時はVARCHARよりもCHARを使う

データの分散

• Redshiftは分散型システム– クラスタは1台のリーダーノードと複数のコンピュートノードから構成される– コンピュートノードは複数のスライス（1 CPUコアあたり1つ）を持つ

• データは3種類の分散方式がある– Even – ラウンドロビン方式で行を分散（デフォルト）– Key – 分散キー（指定したカラムのハッシュ）に基づいて行を分散– All - 全てのスライスに行を複製

• クエリは全てのスライスで並列に実行– 全てのスライスに均等にデータが分散されている時にクエリのスループットが最も引き出される

データのソート

• スライス内（＝ディスク上）では、データはソートキー順に格納されている

– ソートキーが指定されていない場合、Redshiftは挿入された順にデータを格納する

• 実行するクエリで条件句によく使う列をソートキーとして選択する– 日付、ID、等々– 結合キーとして使うもの

• ソートキーを使うことで、Redshiftは不必要なブロックを読まずに処理を行うことができる

– 例）タイムスタンプ型の列がソートキーと指定されたテーブルに対し、直近のデータだけ抽出するクエリを実行すると、古いデータを含むブロックはスキップされる

データの圧縮

• 列方向の圧縮でパフォーマンス向上・低コスト両方のメリットがある

• COPYコマンドは新規テーブルへのロード中にデータを自動的に分析し、適切な形式で圧縮を行う

• ANALYZE COMPRESSIONコマンドは既存のテーブルに対し実行することで、各列に適した圧縮形式を提案する

• ストレージの使われ方の情報はシステム表に格納されている

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

• ロー・エンコーディング (RAW)– 圧縮なし

• バイト・ディクショナリ (BYTEDICT)– 繰り返し値に辞書を使用

• デルタ・エンコーディング (DELTA / DELTA32K)– 連続値や近い値に適する (日付時刻、順序等)

• LZO– 大きな文字列に適する

• モストリー・エンコーディング (MOSTLY8 / MOSTLY16 / MOSTLY32)– 分布の低い方に値が集まっている場合に有効

• ランレングス・エンコーディング (RUNLENGTH)– 同じ値が連続していることが多数ある場合に有効

• テキスト・エンコーディング (TEXT255 / TEXT32K)– テキスト値向け、含まれる単語を辞書を使用して圧縮

制約の定義

• Redshiftはnot null, primary key, foreign key, unique valuesといった制約を実際には有効化しない

• キーとユニーク制約は、オプティマイザがクエリ最適化のヒントとして使用

• Redshiftはデータが制約通りに入っていると仮定して動作– 投入したデータが制約に反する場合、結果不正などの問題が起きる可能性がある

データベースをクエリに最適化する

• 各カラムを適切な形式で圧縮する

• 頻繁に結合するテーブルはDISTSTYLE=ALLで全スライスに複製し、ノード間でのデータ転送を減らす

• 結合するテーブルは、結合するカラムをソートキーとすることで、高速なマージ結合を行うことができる

• テーブルの非正規化は、クエリを単純化し結合を減らすことに役立つ。圧縮により、ストレージ消費も問題とはならない

• VACUUMとANALYZEは定期的に実行する

Redshift向けの最適化とは

• DWH用途向けのデータベースであり、 OLTP向けのデータベースではない– 読み込み処理に最適化されている

– 大きく長いクエリを速く処理することに注力

• ペタバイト級のデータセットをサポート– 「Redshift向けに最適化する」＝「I/Oを最適化する」

• 大事なこと– 汎用的な「good design」はない

– データとワークロードの特徴を押さえることが肝要

Amazon Redshiftへのデータ投入方法

AWS CloudCorporate Data center

DynamoDB

Amazon S3

Data Volume Amazon Elastic

MapReduceAmazon RDS

Amazon

Redshift

Amazon

Glacier

logs / files

Source DBs

VPN

Connection

AWS Direct

Connect

S3 Multipart

Upload

AWS Import/

Export

Amazon EC2

or On-Premise

Remote

Loading

using

SSH

Amazon Redshiftへのデータ投入方法

AWS CloudCorporate Data center

DynamoDB

Amazon S3

Data Volume Amazon Elastic

MapReduceAmazon RDS

Amazon

Redshift

Amazon

Glacier

logs / files

Source DBs

VPN

Connection

AWS Direct

Connect

S3 Multipart

Upload

AWS Import/

Export

Amazon EC2

or On-Premise

Remote

Loading

using

SSH

Loading Data from S3

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

Slice 0

Slice 1

Slice 0

Slice 1

Client.txt.

1

Client.txt.

2

Client.txt.

3

Client.txt.

4

Node 0

Node 1

コンピュートノード

Copy customer from ‘s3://mydata/client.txt’

Credentials ‘aws_access_key_id=<your-access-key>; aws_secret_access_key=<your_secret_key>’

Delimiter ‘|’;

投入データ

テーブルのANALYZE

ANALYZEコマンド

データベース全体

単一のテーブル

テーブルの特定の列

ANALYZEコマンドは行のサンプルを取得し、計算を行った後に統計情

報を保存

全テーブルの全列を定期的に

ANALYZEする必要はない

次のようによく使われる列はANALYZEを行う• ソートやグループ化を行う• 結合する• WHERE句の条件

テーブルの統計情報を最新に保つには

• クエリを実行する前にANALYZEを実行

• データ投入や更新の後、定期的にデータベース全体にANALYZEを実行

• 新しいテーブルを作ったらANALYZE

を実行

統計情報

テーブルのVACUUM

1 RFK 900 Columbus MOROCCO MOROCCO AFRICA 25-989-741-2988 BUILDING

2 JFK 800 Washington JORDAN JORDAN MIDDLE EAST 23-768-687-3665 AUTOMOBILE

3 LBJ 700 Foxborough ARGENTINA ARGENTINA AMERICA 11-719-748-3364 AUTOMOBILE

4 GWB 600 Kansas EGYPT EGYPT MIDDLE EAST 14-128-190-5944 MACHINERY

1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansas

Column 0Column 1 Column 2

各列の値はシリアルに格納されている


1 RFK 900 Columbus MOROCCO MOROCCO AFRICA 25-989-741-2988 BUILDING

2 JFK 800 Washington JORDAN JORDAN MIDDLE EAST 23-768-687-3665 AUTOMOBILE

3 LBJ 700 Foxborough ARGENTINA ARGENTINA AMERICA 11-719-748-3364 AUTOMOBILE

4 GWB 600 Kansas EGYPT EGYPT MIDDLE EAST 14-128-190-5944 MACHINERY

1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansas

Column 0 Column 1 Column 2

Delete customer where column_0 = 3;

x xxx xxxxxxxxxxxxxxx


1,2,4 RFK,JFK,GWB 900 Columbus,800 Washington,600 Kansas

VACUUM Customer;

1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansasx xxx xxxxxxxxxxxxxxx

DELETE/UPDATEによって空いたスペースは、自動的に再確保・再利用されるわけではない。VACUUMコマンドを実行することで空きスペースが再確保され、ストレージの空き容量が増えるだけでなくパフォーマンスも向上する。

同時書き込み時の挙動

同じテーブルにCOPY/INSERT/DELETE/UPDATE

を同時に発行した場合

トランザクション1

トランザクション2 CUSTOMER

Copy customer from

‘s3://mydata/client.txt’…;

Copy customer from

‘s3://mydata/client.txt’…;

Session A

Session B

トランザクション1はCUSTOMERテーブルに書込ロックをかける

トランザクション2はトランザクション1がロックを開放するまで待機


同じテーブルにCOPY/INSERT/DELETE/UPDATE

を同時に発行した場合

Transaction 1

Transaction 2

CUSTOMER

Begin;

Delete one row from CUSTOMERS;

Copy…;

Select count(*) from CUSTOMERS;

End;

Begin;

Delete one row from CUSTOMERS;

Copy…;

Select count(*) from CUSTOMERS;

End;

Session A

Session B

トランザクション1はCUSTOMERテーブルに書込ロックをかける

トランザクション2はトランザクション1がロックを開放するまで待機


同時実行トランザクションによりデッドロックになり得るシチュエーション例



CUSTOMER

Begin;

Delete 3000 rows from CUSTOMERS;

Copy…;

Delete 5000 rows from PARTS;

End;

Begin;

Delete 3000 rows from PARTS;

Copy…;

Delete 5000 rows from CUSTOMERS;

End;

Session A

Session B

トランザクション1はCUSTOMER

テーブルに書込ロックをかける

PARTS

トランザクション2はPARTSテーブルに書込ロックをかける

Wait

Wait

データロードのベストプラクティス

• データロードには極力COPYコマンドを使う

• テーブル毎に1つのCOPYコマンドを使う

• データは複数ファイルに分割– 少なくともスライス数と同じ数にする

– データファイルはGZIPかLZOPで圧縮

– 1ファイルあたりのサイズは1~2GBくらいが良い（経験則）

• なるべく複数行まとめてINSERTする

• 一括挿入(INSERT INTO…SELECTとCREATE TABLE AS)の方がパフォーマンスが良い

データロードのベストプラクティス

• 後でVACUUMしなくて済むよう、データはソートキー順にロードする

• ソートキー順にデータをロードしていない場合、大量の行追加/削除/変更を行ったらVACUUMコマンドを実行する

• COPYとVACUUMコマンドが使うメモリ量を増やすにはwlm_query_slot_countパラメーターで調整

• データに少なからず変更がある場合はANALYZEコマンドを実行し、統計情報を最新に保つ

Questions?

20140620 dbts osaka_redshift_v1.0_slideshare

Data & Analytics