AWS Black Belt Techシリーズ Amazon Redshift

17,454 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/

×