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.

AWS Black Belt Techシリーズ Amazon Redshift

20,540 views

Published on

AWS Black Belt Tech Webinar 2014
(旧マイスターシリーズ)

Amazon Redshift

Published in: Technology

AWS Black Belt Techシリーズ Amazon Redshift

  1. 1. Amazon Redshift AWS  Black  Belt  Tech  Webinar  2014  (旧マイスターシリーズ) アマゾンデータサービスジャパン株式会社 技術本部  エンタープライズ部 ⼋八⽊木橋  徹平
  2. 2. Agenda •  Amazon  Redshiftとは? –  Amazon  Redshiftのアーキテクチャ •  主要アップデート •  設計・チューニング⼿手法 •  国内事例例のご紹介 •  まとめ
  3. 3. Amazon  Redshiftとは?
  4. 4. Amazon  Redshiftの位置づけ •  データ・ストアの特性に応じた使い分け Amazon  DynamoDB Amazon  RDS Amazon  ElastiCache Amazon  Redshift SQL NoSQL•  低レンテンシ •  インメモリ •  3拠点間での レプリケーション •  SSDに永続化 •  トランザク ション処理理 •  汎⽤用技術 •  集計・分析処理理 •  ⼤大容量量データ
  5. 5. Amazon  Redshiftのアーキテクチャ •  MPP(超並列列演算) –  CPU、Disk・Network  I/Oの並列列化 –  論論理理的なリソースの括り「ノードスライス」 •  データの格納 –  列列指向(カラムナ) –  圧縮 •  データの通信 –  コンピュート・ノード間の通信 –  各コンピュート・ノードからリーダー・ノードへの通信 –  他のAWSサービスとの通信
  6. 6. アーキテクチャ:MPP(超並列列演算) SELECT * FROM lineitem; コンパイル・ コードの⽣生成 と配信 CPU CPU CPU CPU CPU CPU リーダーノード コンピュート ノード
  7. 7. アーキテクチャ:クエリーの並列列実⾏行行 SELECT * FROM lineitem; CPU CPU CPU CPU CPU CPU SELECT * FROM part; クエリー 最⼤大同時実⾏行行数:50
  8. 8. アーキテクチャ:ノードスライス ノードスライス= メモリとディスクを CPUコアと同数に分割 した論論理理的な単位 CPU CPU CPU CPU CPU CPU
  9. 9. アーキテクチャ:列列指向 •  ⾏行行指向(RDBMS) •  列列指向(Redshift) orderid name price 1 Book 100 2 Pen 50 … n Eraser 70 orderid name price 1 Book 100 2 Pen 50 … n Eraser 70
  10. 10. データの平準化 CPU CPU CPU CPU CPU CPU ノード間のデータ容量量 の偏りはクエリー実⾏行行 時間に影響を与える
  11. 11. データの転送 ⾃自ノードに必要なデータ がない場合、データ転送 が発⽣生 -‐‑‒  単⼀一ノード -‐‑‒  ブロードキャスト リーダー・ノードに 各ノードの結果を集約
  12. 12. 主要アップデート
  13. 13. 新しいノードタイプ  –  DW2 •  性能・費⽤用対効果の⾼高いSSDベースの ストレージオプションを追加 DW1 - Dense Storage vCPU ECU Memory(GB) Storage I/O Price / hour dw1.xlarge 2 4.4 15 2TB HDD 0.30GB/s $1.250 dw1.8xlarge 16 35 120 16TB HDD 2.40GB/s $10.000 DW2 - Dense Compute dw2.large 2 7 15 0.16TB SSD 0.20GB/s $0.330 dw2.8xlarge 32 104 244 2.56TB SSD 3.70GB/s $6.400 NEW
  14. 14. 無料料利利⽤用枠と3年年RIの値下げ •  2か⽉月の無料料トライアル期間に、  dw2.largeを 毎⽉月  730時間ご利利⽤用いただけます(クラスタ構 成も可能)。 •  BI、Data  Integrationパートナー様が提供する 無料料トライアル –  http://aws.amazon.com/redshift/partners •  アジアパシフィックで3年年RIが25%以上値下げ NEW
  15. 15. 分散⽅方式  –  ALL •  EVEN、DISTKEYに加え、3つ⽬目の分散⽅方式 •  各コンピュート・ノードに対象テーブル内の 全てのレコードがレプリケートされる。 •  マスター・テーブル等のレコード数が少ない テーブル向き •  主にジョインの⾼高速化に効果を発揮 *  詳細は「設計・チューニング」のセクションで説明します。
  16. 16. 結果セットのサイズ(1) •  カーソル毎に結果セットを保存 1 2 3 ・・・ n 結果セット カーソル  SELECT  *  FROM  …
  17. 17. 結果セットのサイズ(2) •  結果セットの最⼤大サイズが変更更可能に –  max_̲cursor_̲result_̲set_̲size:MB単位 A B C D dw1.8xlarge 450GB  *  4 =  1800GB A dw1.8xlarge 225GB  *  8 =  1800GB C B D E G F H サイズの変更更= カーソル数の変更更
  18. 18. 結果セットのサイズ(3) •  ⼤大きな結果セットにカーソルは推奨しない –  ⼤大量量のデータをリーダー・ノードで⼀一旦集約・出⼒力力(I/O) •  UNLOADコマンドを使ってS3に出⼒力力 •  Fetch  sizeパラメータを使って、カーソルから 取得するレコード数を制御 •  ノード・タイプ毎の結果セットのデフォルト値 http://docs.aws.amazon.com/redshift/latest/mgmt/working-‐‑‒with-‐‑‒ parameter-‐‑‒groups.html#max-‐‑‒cursor-‐‑‒result-‐‑‒set-‐‑‒size-‐‑‒param
  19. 19. 圧縮タイプ  -‐‑‒  LZO •  カラムの新しい圧縮エンコーディング(LZO) のサポート •  ⽂文字列列型に対する効果的な圧縮として⾃自動選択 –  圧縮エンコーディングが指定されていないカラムへの 初回COPY時 •  S3上のLZOP形式の圧縮ファイルからCOPY
  20. 20. COPYコマンドの拡張(1) •  MANIFESTファイルにより、特定のファイル群 をS3バケットからCOPYできる。 { "entries": [ {"url":"s3://mybucket-alpha/2013-10-04-custdata", "mandatory":true}, {"url":"s3://mybucket-alpha/2013-10-05-custdata", "mandatory":true}, {"url":"s3://mybucket-beta/2013-10-04-custdata", "mandatory":true}, {"url":"s3://mybucket-beta/2013-10-05-custdata", "mandatory":true} ] }
  21. 21. COPYコマンドの拡張(2) •  JSONファイルのCOPY –  データ構造の⾃自動認識識あるいはJSONPathによる定義 •  Amazon  EMRへの対応 copy sales from 'emr:// j-1H7OUO3B52HI5/myoutput/part*' credentials 'aws_access_key_id=<access-key-id>;aws_secret_access_key=<secret-access- key>'; クラスタID HDFSのパス
  22. 22. Cross-‐‑‒Region  COPY •  別リージョン内のS3バケットやDynamoDB テーブルからのCOPYが可能に。 copy customer from 's3://mybucket/customer/customer.tbl.' credentials ‘aws_access_key_id=<access-key-id>;aws_secret_access_key=<secret-access- key>’ gzip delimiter '|' region 'us-east-1';
  23. 23. Cross-‐‑‒Regionスナップショット •  既存クラスタのスナップ ショットを別クラスタに 作成 •  リテンション・ピリオドの 指定も可能(最⼤大35⽇日) •  リージョン間のデータ転送 費⽤用が発⽣生
  24. 24. 設計・チューニング⼿手法
  25. 25. テーブル設計:分散⽅方式 •  EVEN –  各レコードがスライスにラウンドロビンで分散されるため 均等にデータが蓄積される。 •  DISTKEY –  明⽰示的に指定したカラムを基準に、各レコードのスライスへの配置 が決定される。 –  カラムのカーディナリティによっては、スライス間で⼤大幅な偏りが ⽣生じる。 •  ALL –  全てのレコードが各コンピュート・ノードに配置される。
  26. 26. EVEN  vs.  DISTKEY •  EVEN •  DISTKEY=p_̲partkey   select trim(name) tablename, slice, sum(rows) from stv_tbl_perm where name='part' group by name, slice order by slice; tablename | slice | sum -----------+-------+--------- part | 0 | 1600000 part | 1 | 1600000 … part | 126 | 1600000 part | 127 | 1600000 tablename | slice | sum -----------+-------+--------- part | 0 | 1596925 part | 1 | 1597634 … part | 126 | 1610452 part | 127 | 1596154 各スライスに均等に分散 キーのカーディナリティに依存
  27. 27. コロケーション(1) •  関連するレコードのコロケーション –  ジョイン対象となるレコードを同⼀一ノードに集める。 •  コロケーションの⽅方法 1.  ジョインに使⽤用するカラムをDISTKEYとして作成  または 2.  分散⽅方式  ALLでテーブルを作成(マスター・テーブルなど) select  sum(l_extendedprice* (1 - l_discount)) as revenue from lineitem, part Where (p_partkey = l_partkey … 1.  それぞれをDISTKEYとして作成 または 2.  テーブルをALLで作成
  28. 28. コロケーション(2):DISTKEY 6200995  |  almond  pale  linen   |  Manufacturer#3|  Brand#32 part lineitem 5024338535  |    6200995  |  0.01   |0.08  |  A                        |  F                         |1992-‐‑‒01-‐‑‒02  |  1992-‐‑‒02-‐‑‒14 2201039  |  almond  pale  linen   |  Manufacturer#1|  Brand#11 part lineitem 121932093  |    2201039  |  0.05   |0.43  |  D                        |  E                         |1994-‐‑‒07-‐‑‒11  |  1994-‐‑‒08-‐‑‒23
  29. 29. コロケーション(3):ALL part lineitem part lineitem l_partkey l_partkey p_partkey p_partkey 更更新:全ノードにレプリケーション クエリー:ジョインはローカルで完結
  30. 30. 設計のポイント  –  分散⽅方式 •  ⼩小規模なテーブル(マスター・テーブル)は ALLで作成 •  ジョインを避けてテーブルを⾮非正規化し、 EVENで作成 •  複数テーブルに対して、ジョイン対象のキーを DISTKEYで作成(コロケーション)
  31. 31. Workload  Management •  ⻑⾧長期実⾏行行クエリーは、クラスタ全体のボトル ネックとなり、短期実⾏行行クエリーを待たせる 可能性がある。 •  クエリー並列列度度の上限を設けた複数のキューを 定義 •  クエリーを指定されたキューにルーティング
  32. 32. WLMの実装(1) User Group A Short-running queueLong-running queue Long Query Group
  33. 33. WLMの実装(2) 1 5
  34. 34. WLMの効果 •  キュー単位でクエリー並列列度度を保障 –  メモリのアロケーションも指定可能 •  特定ユーザ(群)によるクラスタ占有を回避 –   最⼤大クエリー実⾏行行時間による制御も可能 •  並列列度度の増加は、必ずしも性能の向上には つながらない  -‐‑‒>  リソース競合の可能性
  35. 35. 性能⽐比較(1) 1 5 クライアント・アプリ:49スレッド並列列 SQL⽂文:完全に同⼀一のクエリー⽂文字列列 WLMキューの並列列数:1,10,25,35,49
  36. 36. 性能⽐比較(2) 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 実⾏行行時間  vs.  クエリー並列列度度 並列度1 並列度10 並列度25 並列度35 並列度49 ⾼高並列列度度  ≠  性能向上
  37. 37. 国内事例例のご紹介
  38. 38. 良良品計画様  MUJI  Passport •  ネット・リアルの区別なく無印良良品のファンの⽅方と コミュニケーションを図る –  複数メディアを跨ったデータの収集・解析 –  ソーシャル・メディア、実店舗、インターネット •  持続的な来店客数増  ->  売上の向上 •  値引きの最⼩小化  -> ターゲット・マーケティング
  39. 39. 分析関連のシステム構成
  40. 40. すかいらーく様  POSデータ  リアルタイム解析 •  数⼗十億件規模のPOSデータを、地図・天気・ クーポン等の周辺情報と組合せリアルタイムに 解析 •  すかいらーくグループ様では国内に約3,000店舗 を展開し、年年間約4億⼈人が利利⽤用 •  POSデータの取り込みが⾃自動化され、クエリの応答速度度も数⼗十倍 まで⾼高速化 •  従来2⽇日間かかっていた分析業務がリアルタイムで実現 •  仮説検証のサイクルを短期間に。
  41. 41. NTT  DOCOMO様  統合DWHプロジェクト http://www.slideshare.net/minoruetoh/nttr4public
  42. 42. まとめ •  スタートアップ企業からエンタープライズまで 幅広くご採⽤用 •  無料料利利⽤用枠でRedshiftクラスタの構築が可能に •  ノード数の増加やスケールアップに頼らない チューニング –  テーブルの設計 –  Workload  Management
  43. 43. 参考資料料 •  ドキュメント –  https://aws.amazon.com/jp/documentation/redshift/ •  フォーラム –  https://forums.aws.amazon.com/forum.jspa? forumID=155&start=0 •  新機能アナウンスメント –  https://forums.aws.amazon.com/thread.jspa? threadID=132076&tstart=25
  44. 44. Webinar資料料の配置場所 •  AWS  クラウドサービス活⽤用資料料集 –  http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/

×