20140620 dbts osaka_redshift_v1.0_slideshare
•
7 gefällt mir•6,520 views
Amazon Redshift Deep Dive presented at db tech showcase Osaka 2014 on June 20, 2014
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie 20140620 dbts osaka_redshift_v1.0_slideshare
Ähnlich wie 20140620 dbts osaka_redshift_v1.0_slideshare (20)
20140620 dbts osaka_redshift_v1.0_slideshare
- 1. Amazon Redshift Deep Dive アマゾン データ サービス ジャパン株式会社 事業開発部マネージャー 大久保 順 2014/06/20
- 2. 本日のアジェンダ • Amazon Web Servicesとは？ • Amazon Redshiftのアーキテクチャ • 速さを引き出すためのベストプラクティス
- 5. コンシューマー ビジネス 1億を超えるアクティブな アカウント ８カ国で展開 : 米国, 英国, ドイツ, 日本, フランス,カナダ, 中国, イタリア セラー（売り手）様 向けビジネス アマゾンの ウェブサイト上で販売 自社小売ウェブサイトに Amazonの技術を利用 フルフィルメントセンター （物流センター）の活用 IT インフラ ビジネス ウェブスケールでの クラウド基盤の提供 190以上の国にて、 数十 万に及ぶ登録アカウント
- 12. 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
- 13. 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)
- 15. リーダーノード • クライアントからのSQLエンドポイント • データ分散の管理 • クエリの実行計画生成と実行 – SQL文の実行計画をC++のコードに変換し、コンパイル – コンパイルした実行コードを各コンピュートノードに配布し、 結果を収集 – SQL文の特定の関数はリーダーノードのみで実行される http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions _leader_node_only.html
- 16. コンピュートノード • リーダーノードで生成されたコンパイル済コードを実行 し、中間結果をリーダーノードに返す – リーダーノードが最終的な集計を行い、クライアントへ結果を返す • コンピュートノードは各ノードにCPU, メモリ, ローカ ルディスクストレージを持つ。（処理能力やリソース容 量はクラスタのインスタンスタイプにより決定） – DW1 – Dense Storage Nodes ハードディスクベースのインスタンスタイプ。データ量が多い用途に向 く。 – DW2 – Dense Compute Nodes SSDベースのインスタンスタイプ。計算量が多い、またディスクI/Oが多い 用途に向く。
- 17. スライス • 各コンピュートノードのメモリとディスクスト レージは「スライス」と呼ばれる単位に分割し て管理されている • スライス数は各コンピュートノードのプロセッ サコア数と同じ • パラレルクエリ実行は、スライス毎の負荷が極 力均等になるよう分散される
- 18. • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • 行指向のストレージでは、必 要なデータを得るために全カ ラムのデータを取得する必要 がある ID Age State Amount 123 20 CA 500 345 25 WA 250 678 40 FL 125 957 37 WA 375 I/Oを減らすための仕組み
- 19. • カラムナー型ストレージで は、必要なデータだけを読 み取ることができる ID Age State Amount 123 20 CA 500 345 25 WA 250 678 40 FL 125 957 37 WA 375 I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ
- 20. 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 コマンド実行時に適する 圧縮形式を自動判定 • 自分でアナライズして圧縮形 式を決めることも可能
- 21. 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 • 各ブロックに含まれる最小値と 最大値を保持 • 必要なデータを含んでいないブ ロックは読取りをスキップ
- 22. I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • パフォーマンス向上のため、各 コンピュートノードに直結した ローカルストレージを使用し、 スキャンレートを最大化 • データの複製とバックアップは 自動的に行われる • HDD/SSD の2種類のプラット フォーム
- 23. I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • 1MB/block • 参考：RDBMSの一般的なデー タブロックサイズは、 8KB~32KB/block
- 24. 並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ
- 25. • Amazon S3, Amazon DynamoDB, 任 意のSSH接続から、パラレルにロー ディングを実施 • DDLに従い、データは自動的に分 散・ソートして格納される • ノード数に従ってスケール 並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ
- 26. • Amazon S3へのバックアップは自動的、継続的 かつ差分で取得される • スナップショット保持期間は設定可能。任意の タイミングでのスナップショット取得も可能 • DR用途向けにリージョンをまたいでバックアッ プを取得することが可能 • ストリーミング・リストアですぐにクエリ受付 可能な状態に 並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ
- 27. • リサイズ中もオンライン状態を維持 • バックグラウンドで新しいクラスタをプ ロビジョニング • 新旧ノード間でのデータコピーはパラレ ルに処理 並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ
- 28. • SQLエンドポイントの切替はDNS 更新で行われる • コンソール / API経由で実行 並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ
- 30. サポートするデータ型 • 次の種類のデータ型をサポート – 数値: 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として格納
- 31. 正しいデータ型を選ぶ • Redshiftのパフォーマンスは「如何にI/Oを最適化す るか」にかかっている • 列幅を必要以上に取らない – 例）国コードにBIGINTを使う – 例）国名にCHAR(MAX)を使う • 適切なデータ型を使う – 日付・時間にはCHARではなくTIMESTAMPやDATEを使う – 列幅が分かっている時はVARCHARよりもCHARを使う
- 32. データの分散 • Redshiftは分散型システム – クラスタは1台のリーダーノードと複数のコンピュートノードから構成される – コンピュートノードは複数のスライス（1 CPUコアあたり1つ）を持つ • データは3種類の分散方式がある – Even – ラウンドロビン方式で行を分散（デフォルト） – Key – 分散キー（指定したカラムのハッシュ）に基づいて行を分散 – All - 全てのスライスに行を複製 • クエリは全てのスライスで並列に実行 – 全てのスライスに均等にデータが分散されている時にクエリのスループットが 最も引き出される
- 33. データのソート • スライス内（＝ディスク上）では、データはソートキー順に格納さ れている – ソートキーが指定されていない場合、Redshiftは挿入された順にデータを格納する • 実行するクエリで条件句によく使う列をソートキーとして選択する – 日付、ID、等々 – 結合キーとして使うもの • ソートキーを使うことで、Redshiftは不必要なブロックを読まずに 処理を行うことができる – 例）タイムスタンプ型の列がソートキーと指定されたテーブルに対し、直近のデータだけ 抽出するクエリを実行すると、古いデータを含むブロックはスキップされる
- 34. データの圧縮 • 列方向の圧縮でパフォーマンス向上・低コスト両方のメリッ トがある • COPYコマンドは新規テーブルへのロード中にデータを自動 的に分析し、適切な形式で圧縮を行う • ANALYZE COMPRESSIONコマンドは既存のテーブルに対し 実行することで、各列に適した圧縮形式を提案する • ストレージの使われ方の情報はシステム表に格納されている
- 35. データ圧縮のアルゴリズム • ロー・エンコーディング (RAW) – 圧縮なし • バイト・ディクショナリ (BYTEDICT) – 繰り返し値に辞書を使用 • デルタ・エンコーディング (DELTA / DELTA32K) – 連続値や近い値に適する (日付時刻、順序等) • LZO – 大きな文字列に適する • モストリー・エンコーディング (MOSTLY8 / MOSTLY16 / MOSTLY32) – 分布の低い方に値が集まっている場合に有効 • ランレングス・エンコーディング (RUNLENGTH) – 同じ値が連続していることが多数ある場合に有効 • テキスト・エンコーディング (TEXT255 / TEXT32K) – テキスト値向け、含まれる単語を辞書を使用して圧縮
- 36. 制約の定義 • Redshiftはnot null, primary key, foreign key, unique valuesといった制約を実際には有効化しない • キーとユニーク制約は、オプティマイザがクエリ最 適化のヒントとして使用 • Redshiftはデータが制約通りに入っていると仮定し て動作 – 投入したデータが制約に反する場合、結果不正などの問題が起きる 可能性がある
- 37. データベースをクエリに最適化する • 各カラムを適切な形式で圧縮する • 頻繁に結合するテーブルはDISTSTYLE=ALLで全スライ スに複製し、ノード間でのデータ転送を減らす • 結合するテーブルは、結合するカラムをソートキーとす ることで、高速なマージ結合を行うことができる • テーブルの非正規化は、クエリを単純化し結合を減らす ことに役立つ。圧縮により、ストレージ消費も問題とは ならない • VACUUMとANALYZEは定期的に実行する
- 38. Redshift向けの最適化とは • DWH用途向けのデータベースであり、 OLTP向けの データベースではない – 読み込み処理に最適化されている – 大きく長いクエリを速く処理することに注力 • ペタバイト級のデータセットをサポート – 「Redshift向けに最適化する」＝「I/Oを最適化する」 • 大事なこと – 汎用的な「good design」はない – データとワークロードの特徴を押さえることが肝要
- 39. Amazon Redshiftへのデータ投入方法 AWS CloudCorporate Data center DynamoDB Amazon S3 Data Volume Amazon Elastic MapReduce Amazon 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
- 40. Amazon Redshiftへのデータ投入方法 AWS CloudCorporate Data center DynamoDB Amazon S3 Data Volume Amazon Elastic MapReduce Amazon 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
- 41. 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 ‘|’; 投入データ
- 42. テーブルのANALYZE ANALYZEコマンド データベース 全体 単一のテー ブル テーブルの 特定の列 ANALYZEコマンド は行のサンプルを 取得し、計算を 行った後に統計情 報を保存 全テーブルの全列 を定期的に ANALYZEする必要 はない 次のようによく使われる列はANALYZEを 行う • ソートやグループ化を行う • 結合する • WHERE句の条件 テーブルの統計情報を最新に保つには • クエリを実行する前にANALYZEを実 行 • データ投入や更新の後、定期的に データベース全体にANALYZEを実行 • 新しいテーブルを作ったらANALYZE を実行 統計情報
- 43. テーブルの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 各列の値はシリアルに格納されている
- 44. テーブルの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
- 45. テーブルの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コマンドを実行する ことで空きスペースが再確保され、スト レージの空き容量が増えるだけでなくパ フォーマンスも向上する。
- 46. 同時書き込み時の挙動 同じテーブルに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がロッ クを開放するまで待機
- 47. 同時書き込み時の挙動 同じテーブルに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がロッ クを開放するまで待機
- 48. 同時書き込み時の挙動 同時実行トランザクションにより デッドロックになり得るシチュエーション例 トランザクション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
- 49. データロードのベストプラクティス • データロードには極力COPYコマンドを使う • テーブル毎に1つのCOPYコマンドを使う • データは複数ファイルに分割 – 少なくともスライス数と同じ数にする – データファイルはGZIPかLZOPで圧縮 – 1ファイルあたりのサイズは1~2GBくらいが良い（経験則） • なるべく複数行まとめてINSERTする • 一括挿入(INSERT INTO…SELECTとCREATE TABLE AS)の方がパフォーマンスが良い
- 50. データロードのベストプラクティス • 後でVACUUMしなくて済むよう、データはソート キー順にロードする • ソートキー順にデータをロードしていない場合、大 量の行追加/削除/変更を行ったらVACUUMコマンド を実行する • COPYとVACUUMコマンドが使うメモリ量を増やす にはwlm_query_slot_countパラメーターで調整 • データに少なからず変更がある場合はANALYZEコマ ンドを実行し、統計情報を最新に保つ
- 51. Questions?