Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20140620 dbts osaka_redshift_v1.0_slideshare

5,078 views

Published on

Amazon Redshift Deep Dive
presented at db tech showcase Osaka 2014
on June 20, 2014

Published in: Data & Analytics
  • Be the first to comment

20140620 dbts osaka_redshift_v1.0_slideshare

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

×