[db tech showcase Tokyo 2015] A32:Amazon Redshift Deep Dive by アマゾン データ サービス ジャパン株式会社 八木橋徹平
•
9 recomendaciones•10,420 vistas
AWSサービスの中で、クラウド型データウェアハウスとして位置づけられているAmazon Redshiftのアーキテクチャ、最新アップデートや ユーザ事例をご紹介します。また、性能に影響するテーブルの設計についてもTipsをご紹介します。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a [db tech showcase Tokyo 2015] A32:Amazon Redshift Deep Dive by アマゾン データ サービス ジャパン株式会社 八木橋徹平
Similar a [db tech showcase Tokyo 2015] A32:Amazon Redshift Deep Dive by アマゾン データ サービス ジャパン株式会社 八木橋徹平 (20)
Más de Insight Technology, Inc.
Más de Insight Technology, Inc. (20)
Último
Último (9)
[db tech showcase Tokyo 2015] A32:Amazon Redshift Deep Dive by アマゾン データ サービス ジャパン株式会社 八木橋徹平
- 1. Amazon Redshift Deep Dive アマゾン データ サービス ジャパン 株式会社 八木橋 徹平
- 2. 自己紹介 • 名前 – 八木橋 徹平（やぎはし てっぺい） • 所属 – アマゾンデータサービスジャパン株式会社 技術統括本部ストラテジックソリューション部 ソリューションアーキテクト • 好きなAWS サービス – Amazon Redshift、Amazon Kinesis – AWS SDK（Java、Node.js）
- 3. セッションの目的 クラウド型データ・ウェアハウスであるAmazon Redshiftのアーキテクチャやチューニングのポイ ントを解説し、Redshiftの利点や最適な実装方法 をご理解いただく。
- 4. アジェンダ • 概要とアーキテクチャ • 主要アップデート • テーブル設計 • インテグレーション • ケース・スタディ • まとめ
- 5. 概要とアーキテクチャ
- 6. クラウド型データ・ウェアハウスのメリット • 初期投資が不要 – 導入のリスクは最小 – DWHに付随するその他の投資（バックアップ、運用監視など） • 最小限の運用管理 – ランニング・コストの低下 – 自動バックアップ、障害からの自動回復など • 成長予測と投資対効果 – 導入時点で数年先のデータ増加量を見通す必要がない – 投資に見合ったビジネスへの貢献があったか ＝ 価値のあるデータ 分析ができたか
- 7. Amazon Redshiftの概要 • MPP（超並列演算） – CPU、Disk・Network I/Oの並列化 – 論理的なリソースの括り 「ノードスライス」 • データの格納 – 列指向（カラムナ） – 圧縮 • 他のAWSサービスとの 親和性
- 8. MPP（超並列演算） SELECT * FROM lineitem; コンパイル・ コードの生成 と配信 CPU CPU CPU CPU CPU CPU
- 9. クエリーの並列実行 SELECT * FROM lineitem; CPU CPU CPU CPU CPU CPU SELECT * FROM part; クエリー 最大同時実行数：50
- 10. ノードスライス ノードスライス＝ メモリとディスクを CPUコアと同数に分割 した論理的な単位 CPU CPU CPU CPU CPU CPU
- 11. 列指向型 ・行指向型（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
- 12. データの平準化 CPU CPU CPU CPU CPU CPU ノード間のデータ容量 の偏りはクエリー実行 時間に影響を与える
- 14. データのロード CPU CPU CPU CPU CPU CPU COPY customer FROM /mybucket/customer/*.tbl … • スロット数と同じ 並列度でロード • バケット内のファイル数は スロットの倍数が望ましい • Amazon EMR、Amazon DynamoDB、リモートホ ストからのロードも可能
- 17. リサイズ
- 18. 主要アップデート
- 19. 新しいノード・タイプ – DS2 DS1 - Dense Storage（旧：DW1） vCPU ECU Memory(GB) Storage I/O Price / hour ds1.xlarge 2 4.4 15 2TB HDD 0.30GB/s $1.190 ds1.8xlarge 16 35 120 16TB HDD 2.40GB/s $9.520 DC1 - Dense Compute（旧：DW2） dc1.large 2 7 15 0.16TB SSD 0.20GB/s $0.314 dc1.8xlarge 32 104 244 2.56TB SSD 3.70GB/s $6.095 DS2 – Dense Storage ds2.xlarge 4 14 31 2TB 0.50GB/s $1.190 ds2.8xlarge 36 116 244 16TB 4.00GB/s $9.520
- 20. Redshiftのカスタムドライバ • Redshiftに最適化されたドライバをリリース – JDBC 4.1/4.0をサポート – ODBC3.8をサポート、2.xとも互換性あり • PostgreSQL.orgで公開されているドライバより もパフォーマンス・信頼性の観点で優れている • 関連ドキュメント http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/co nnecting-to-cluster.html
- 21. Interleaved Sort Key（１） • Sort Keyを複数のカラムに指定が可能になり、 フルスキャンを回避し、Disk I/Oを最小限に抑 えられる • 最大８つまでのSort Key列を指定できる CREATE TABLE ~ … INTERLEAVED SORTKEY (deptid, locid);
- 22. Interleaved Sort Key（２） DeptId LocId 1 A 1 B 1 C 1 D 2 A 2 B 2 C 2 D DeptId LocId 3 A 3 B 3 C 3 D 4 A 4 B 4 C 4 D Compound Sort Key Interleaved Sort Key DeptId LocId 1 A 1 B 2 A 2 B 1 C 1 C 2 D 2 D DeptId LocId 3 A 3 B 4 A 4 B 3 C 3 D 4 C 4 D DeptId = 1 -> 1 block LocId = C -> 4 block DeptId = 1 -> 2 block LocId = C -> 2 block
- 23. テーブル設計
- 24. テーブルの分散方式 • EVEN – 各レコードがスライスにラウンドロビンで分散されるため 均等にデータが蓄積される。 • DISTKEY – 明示的に指定したカラムを基準に、各レコードのスライスへの配置 が決定される。 – カラムのカーディナリティによっては、スライス間で大幅な偏りが 生じる。 • ALL – 全てのレコードが各コンピュート・ノードに配置される。
- 25. 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 各スライスに均等に分散 キーのカーディナリティに依存
- 26. EVEN vs. DISTKEY（２） • DISTKEY = p_brand tablename | slice | sum -----------+-------+--------- part | 0 | 0 part | 1 | 0 part | 2 | 0 part | 3 | 0 part | 4 | 8193350 … part | 118 | 8193342 part | 119 | 0 part | 120 | 16384823 part | 121 | 8191943 カーディナリティの低い カラムでは、データの極端な 偏りが生じる場合がある = 効率の悪いクエリー
- 27. ALL • 全レコードが各ノードの特定スライスに集約 tablename | slice | sum -----------+-------+--------- part | 0 |204800000 part | 1 | 0 part | 2 | 0 part | 3 | 0 part | 4 | 0 … part | 96 |204800000 part | 97 | 0 part | 98 | 0 … … 各ノードの先頭スライスに 全レコードが格納される。
- 28. コロケーション（１） • 関連するレコードのコロケーション – ジョイン対象となるレコードを同一ノードに集める。 • コロケーションの方法 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で作成
- 29. コロケーション（２）：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
- 31. テーブル設計のポイント - DISTKEY • 小規模なテーブル（マスター・テーブル）は ALLで作成 • ジョインを避けてテーブルを非正規化し、 EVENで作成 • 複数テーブルに対して、ジョイン対象のキーを DISTKEYで作成（コロケーション）
- 32. インテグレーション
- 33. Redshiftにおけるインテグレーション • インテグレーション ＝ ETL ＋ Upload • オンプレミス、AWSサービス間のデータ連携 • 考慮すべき点： – シングル vs. パラレル処理？ – 同期 vs. 非同期実行？ – どこでデータ変換をすべきか？
- 34. 典型的なシナリオ - バッチ • RDBMSからデータを抽出（Extract） • Amazon S3にアップロード（Upload） • Amazon EMRによるデータ変換（Transform） • Amazon Redshiftにロード（Load）
- 36. Talendのご紹介 • EclipseベースのETLツー ル – Talend Open Studio for Data Integration – OSS、無料でダウンロード 可能 • AWS（S3、Redshiftな ど）を含む様々なアダプ タを標準で実装 • Javaによるカスタム拡張 が可能
- 37. 典型的なシナリオ – ジョブの定義 Extract Upload LoadTransform Amazon S3にCSV ファイルがアップロード 済みの状態を仮定
- 38. Transformをどこで実行するか？ • AWSにアップロード前のオンプレミス環境 アップロード前にクレンジングし、転送時間の削減 オンプレ側にリソースが必要 • S3内のファイルをEMRでバッチ変換 RedshiftからTransform処理をオフロード Hadoop関連の技術を習得 • SQLで一時テーブルから本番テーブルへ Redshift内でのSQLのみで完結できる Redshiftの負荷が増加
- 39. Amazon Elastic Map Reduce（EMR） • 特徴 (http://aws.amazon.com/jp/elasticmapreduce/) – フルマネージド：クラスタの構築から構成変更、 破棄まですべてマネージ – 自動化：Amazon EMRのAPIを利用すると ジョブに合わせてクラスタを起動し、実行させ、 終了したらクラスタを破棄、というような自動 化が容易 – AWS：Amazon S3やAmazon DynamoDBか らデータの入出力が可能 フルマネージドなHadoopを提供。 運用を気にせずHadoopアプリケーションの開発や利用ができる。 Hadoop Hadoop Amazon EMRクラスタ AWSサービスとの連携
- 40. Transform（１）：Amazon EMR • Hiveによるデータ変換の例 awssummit-tokyo-2015/input Amazon EMR awssummit-tokyo-2015/output orders_input orders_output INSERT OVERWRITE TABLE orders_output SELECT O_ORDERKEY, O_CUSTKEY, O_ORDERSTATUS, O_TOTALPRICE, O_ORDERDATE, O_ORDERPRIORITY, O_SHIPPRIORITY FROM orders_input;
- 41. Transform（２）：Amazon EMR • PowershellでAWS CLIとHiveスクリプトを実行 • AWS CLIの呼出しは非同期実行であるため、 フローの中で同期実行をさせるには工夫が必要
- 42. Transform（３）：Amazon EMR $wait = "aws emr wait cluster-running --cluster-id " + $clusterid $wait_output = invoke-expression $wait :OUTER for(;;) { $describe = "aws emr describe-cluster --cluster-id " + $clusterid $describe_output = invoke-expression $describe for ($i=0; $i -lt $describe_output.length; $i++) { if (($i -eq 4) -and ($describe_output[$i] -like "*TERMINATED")){ break OUTER } } Write-Host "Sleeping..." Start-Sleep 40 } クラスタ作成待ち Hiveスクリプト 実行後、 クラスタ削除待ち
- 43. Load（１）：Amazon Redshift • ファイル一覧や正規表現をCOPYコマンドに 指定すると、コンピュート・ノードが並列に データをロード • 単一ファイルの指定では、特定のコンピュート ノードのみがS3にアクセスするため、並列ロー ドにならない • ロードに失敗したレコードは、 「stl_load_errors」表に格納される
- 44. Load（２）：Amazon Redshift ２．INSERT ~ SELECTの実行 １．COPYコマンドの実行
- 45. 設計のポイント • AWSではEMRにより変換処理を容易に実現 – S3とのデータのIn/Out – 変換処理の並列実行 – クラスタの作成・破棄 • AWS CLIからのリクエストを同期実行するには ポーリング等の工夫が必要 • 「INSERT ～ SELECT」文は、COPY同様に コンピュート・ノードで並列処理される
- 46. ケース・スタディ
- 47. MUJI Passport導入の目的 • ネット・リアルの区別なく無印良品のファンの方と コミュニケーションを図る – 複数メディアを跨ったデータの収集・解析 – ソーシャル・メディア、実店舗、インターネット • 持続的な来店客数増 -> 売上の向上 • 値引きの最小化 -> ターゲット・マーケティング
- 48. 分析関連のシステム構成
- 49. すかいらーく様 POSデータ リアルタイム解析 • 数十億件規模のPOSデータを、地図・天気・ クーポン等の周辺情報と組合せリアルタイムに 解析 • すかいらーくグループ様では国内に約3,000店舗 を展開し、年間約4億人が利用 • POSデータの取り込みが自動化され、クエリの応答速度も数十倍 まで高速化 • 従来2日間かかっていた分析業務がリアルタイムで実現 • 仮説検証のサイクルを短期間に。
- 51. Redshiftのビジネス状況 • 2013年にローンチ後、AWS史上において最速 の成長率を維持している • 様々な業種（ゲーム、広告、製造、流通 等々） や規模（スタートアップから大手企業）のお客 様において導入が進んでいる • NTT DOCOMO様やAmazon.comにおけるペタ バイト級の導入事例
- 52. まとめ
- 53. Redshiftの検討ポイント • 低リスクかつ低コストで高速・スケーラブルな データウェアハウスを容易に構築・運用できる – 無料利用枠の対象：最初の2か月間 dc1.large 750時間/月 • 性能を最大限に引き出すテーブル設計や運用を 見据えた他のAWSサービスとの連携 • スタートアップからエンタープライズにおよぶ 幅広い分野での実績
- 54. ご清聴ありがとうございました。