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億を超えるアクティブなアカウント
8カ国で展開 :米国, 英国, ドイツ, 日本, フランス,カナダ, 中国,
イタリア
セラー(売り手)様向けビジネス
アマゾンのウェブサイト上で販売
自社小売ウェブサイトに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
コンピュートノード
• リーダーノードで生成されたコンパイル済コードを実行し、中間結果をリーダーノードに返す– リーダーノードが最終的な集計を行い、クライアントへ結果を返す
• コンピュートノードは各ノードに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
I/Oを減らすための仕組み
• カラムナー型ストレージ
• データ圧縮
• ゾーンマップ
• 直結ストレージ
• データブロックサイズ
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
Slides not intended for redistribution.
I/Oを減らすための仕組み
• カラムナー型ストレージ
• データ圧縮
• ゾーンマップ
• 直結ストレージ
• データブロックサイズ
• COPY コマンド実行時に適する
圧縮形式を自動判定
• 自分でアナライズして圧縮形
式を決めることも可能
I/Oを減らすための仕組み
• カラムナー型ストレージ
• データ圧縮
• ゾーンマップ
• 直結ストレージ
• データブロックサイズ
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
• 各ブロックに含まれる最小値と
最大値を保持
• 必要なデータを含んでいないブ
ロックは読取りをスキップ
I/Oを減らすための仕組み
• カラムナー型ストレージ
• データ圧縮
• ゾーンマップ
• 直結ストレージ
• データブロックサイズ
• パフォーマンス向上のため、各
コンピュートノードに直結した
ローカルストレージを使用し、
スキャンレートを最大化
• データの複製とバックアップは
自動的に行われる
• HDD/SSD の2種類のプラット
フォーム
I/Oを減らすための仕組み
• カラムナー型ストレージ
• データ圧縮
• ゾーンマップ
• 直結ストレージ
• データブロックサイズ
• 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
各列の値はシリアルに格納されている
テーブルの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 0 Column 1 Column 2
Delete customer where column_0 = 3;
x xxx xxxxxxxxxxxxxxx
テーブルのVACUUM
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がロックを開放するまで待機
同時書き込み時の挙動
同時実行トランザクションによりデッドロックになり得るシチュエーション例
トランザクション1
トランザクション2
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?
Top Related