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.

Amazon RedshiftとAmazon QuickSightで実現する、長く使えるDWH作り

4,852 views

Published on

2017年9月6日 db tech showcase 2017での発表資料「Amazon RedshiftとAmazon QuickSightで実現する、長く使えるDWH作り」です。 http://www.db-tech-showcase.com/dbts/tokyo

Published in: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Amazon RedshiftとAmazon QuickSightで実現する、長く使えるDWH作り

  1. 1. 1 #dbts2017 Amazon RedshiftとAmazon QuickSightで 実現する、長く使えるDWH作り ~小規模で始めて、規模の増大に耐えられる仕組み作り~ 2017年9月6日 アマゾンウェブサービスジャパン ソリューションアーキテクト 下佐粉 昭 @simosako
  2. 2. 2 #dbts2017 今日お伝えしたいこと • DWHは構築するまでがまず大変 – 「本当に利益を生むか分からないのに投資するの?」 • もっと大変なのはDWH構築に成功した後 – サイズ・人・要望(ワークロード)が増え続ける • 増加に対応できるインフラと仕組み作りを知る ことで長く使えるDWHを構築しましょう
  3. 3. 3 #dbts2017 自己紹介 下佐粉 昭(しもさこ あきら) @simosako 所属: アマゾン ウェブ サービス ジャパン 技術統括本部 エンタープライズソリューション部 ソリューションアーキテクト 好きなAWSサービス:Redshift, RDS, S3 人間が運用等から解放されて楽になるサービスが好きです
  4. 4. 4 #dbts2017 内容 • クラウド上にDWHを作ることでリスクを減らす • 要望の多様化に対応できるインフラ • サイズの増加への対応はスケールアウトで実現する • 規模の増大に対応できるDWH作り - Redshiftを例に • まとめ • 参考資料 資料は講演後に公開予定です https://www.slideshare.net/AmazonWebServicesJapan
  5. 5. 5 #dbts2017 クラウド上にDWHを作ることで リスクを減らす
  6. 6. 6 #dbts2017 データウェアハウス構築の課題 • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築 – バックアップ&リストア – モニタリング
  7. 7. 7 #dbts2017 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築 – バックアップ&リストア – モニタリング AWSクラウド • 初期投資不要 • 利用分だけの支払い • 安価 • いつでもやめられる
  8. 8. 8 #dbts2017 仮想サーバ (EC2) = $0.008~ / 時間 ※1 ※1 2017年9月時点での東京リージョンの金額 ※2 2017年9月時点での価格 初期費用不要・利用した分だけの料金(一例) BIサービス (QuickSight) = $12~ ユーザ / 月 ※2 = $0.314~ / 時間 ※1データウェアハウス (Redshift)
  9. 9. 9 #dbts2017 データウェアハウス構築の課題とAWSクラウド • 投資対効果の検討が困難 – 高い初期投資 – やってみないと、効果が見えない – 巨大投資を回収する必要がある • 運用管理の負荷が高い – 大規模サーバ構築 – バックアップ&リストア – モニタリング AWSクラウド • 数クリックでDWH が起動 • バックアップやモニ タリングといった運 用機能を含む
  10. 10. 10 #dbts2017 マネージドサービスで運用の負荷を低減 大規模になるほど管理範囲を小さくすることが重要に 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運用設計 スケールアウト設計 ミドルウェア導入 OS導入 アプリケーション作成 オンプレミス 独自構築 on EC2 AWSマネージドサービス お客様がご担当する作業 AWSが提供するマネージド機能 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運用設計 スケールアウト設計 ミドルウェア導入 OS導入 アプリケーション作成 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運用設計 スケールアウト設計 ミドルウェア導入 OS導入 アプリケーション作成
  11. 11. 11 #dbts2017 分析保存 Amazon Glacier Amazon S3 Amazon DynamoDB Amazon RDS/ Aurora AWSマネージドサービス:ビッグデータ領域 AWS Glue Amazon CloudSearch Amazon EMR Amazon EC2 Amazon Redshift Amazon Machine Learning AWS IoT AWS Direct Connect 収集 Amazon Kinesis Amazon Kinesis Firehose Amazon Elasticsearch Amazon Kinesis Analytics Amazon QuickSight AWS DMS Snowball 可視化 Amazon EC2 Amazon Athena
  12. 12. 12 #dbts2017 無事にDWHが構築できた!すると... 思ってもみなかったようなと ころで使われはじめます • 要望の増加(多様化) • データサイズの増加 • 利用人数の増加
  13. 13. 13 #dbts2017 要望の多様化に対応できるインフラ
  14. 14. 14 #dbts2017 これまで: 1. ディスクが高価で上限がある 2. データはサマリーだけ、もし くは期間限定で保存 3. 処理できる内容は固定的 多様化する要望に対応するために: オリジナルデータは削除せず、全期間を残す On AWSクラウド: 1. 安価・上限無しのストレージ 2. オリジナルデータを全て残す 3. 処理対象・処理内容はビジネ スに合わせて変わる インフラ管理者の仕事: データを活用して新しい課題に素 早く対応できるインフラを用意す る。個別リクエストへの対応 インフラ管理者の仕事: ストレージを溢れさせず、時 間内に処理が終るようにサイ ズや処理内容を調整する
  15. 15. 15 #dbts2017 データレイク • 多様なデータを一元的に保存 • データを失わない • サイズ制限からの開放 • APIですぐにアクセスできる センサー データ 非構造化ファイル テキストファイル RDBMS データレイク API呼び出しによる連携
  16. 16. 16 #dbts2017 Amazon S3によるデータレイクの実現 • 上限無し:サイジング不要 • 高い耐久性:99.999999999% • 安価: • $0.025/GB/月*(スタンダード) • $0.019/GB/月*(標準-低頻度アクセス) 例)10TBの保存で約2.1万円/月** • APIアクセス • 多様な言語にライブラリを提供 • AWS各種サービスと連携 データレイク Amazon EMR (Hadoop) Amazon Redshift Amazon API Gateway Amazon S3 センサー データ 非構造化ファイル テキストファイル RDBMS * 費用は2017年9月時点での東京リージョンでの価格です ** 1USドル = 110円で、標準-低頻度アクセスでの試算 Amazon Machine Learning
  17. 17. 17 #dbts2017 • データをデータレイクに集め、多様な分析につなげる • 分析環境は要望別に分けることが可能 • 小さく試せて、いつでも辞められる環境をフル活用 大規模データ分析 on クラウド 収集 データレイク (保存) 分析 可視化 データを収集し、 データレイクへ 格納 全期間保存 共通APIでア クセス 可視化分析 API
  18. 18. 18 #dbts2017 サイズの増加への対応は スケールアウトで実現する
  19. 19. 19 #dbts2017 スケールアウト+分散処理が鍵 • スケールアップもスケールアウトも クラウドでは容易 • …しかしスケールアップには限界が ある(CPU、メモリ、ストレージ) スケールアウト可能なテクノロジーを ベースに分散処理を行うことで規模の 増加に対応する S XL スケールアップ スケールアウト
  20. 20. 20 #dbts2017 分散処理が可能なAWSの分析サービス マネージド, 標準技術, 分散処理 Amazon Redshift Amazon Athena Amazon EMR AWS Glue マネージド マネージド DWH(RDB) マネージド クエリ環境 マネージド Hadoop環境 マネージド ETL環境 標準・デファク トスタンダード SQL標準 SQL標準 Hadoop/Spark (デファクト) Spark (デファクト) 分散処理 ユーザ操作で ノード数増加 クエリに応じて 自動分散処理 ユーザ操作で ノード数増加 ジョブ毎にユー ザ設定でノード (DPU)増加
  21. 21. 21 #dbts2017 DWH特化の高速RDB ペタバイト級までスケールアウト フルマネージド 多数の周辺ソフト; PgSQL互換性 $1,000/TB/年; 最小$0.314/時から Amazon Redshift ※費用は2017年9月時点での東京リージョンのものです
  22. 22. 22 #dbts2017 RedshiftはSQLをスケールアウトで処理 SELECT * FROM lineitem; CPU CPU CPU CPU CPU CPU Leaderノード Computeノード スライス= メモリとディスクを ノード内で分割した論 理的な処理単位 コンピュートノードの追 加でパフォーマンス向上 (スケールアウト)
  23. 23. 23 #dbts2017 ETL処理専用サービス ユーザ指定でスケールアウト フルマネージド PySparkで処理ロジック:標準技術 ジョブ実行 $0.44/DPU-時 から AWS Glue ※1DPUは4vCPU,16GBメモリの処理能力単位。費用は2017年9月時点での東京リージョンのものです
  24. 24. 24 #dbts2017 クラウドではスケールアウト ≠ 高価 • Glueはジョブを分散実行 • ユーザ指定に応じてスケールアウト • 分散処理により処理時間短縮とコストを両立できる 処理時間 8時間 処理時間 2時間 JOB 16DPUに 拡張 JOB 4DPU×8時間 =32 16DPU×2時間 =32
  25. 25. 25 #dbts2017 ①データをデータレイクに集め、多様な分析につなげる ②分析はスケールアウト可能なインフラの上で分散処理 大規模データ分析 on クラウド 収集 データレイク (保存) 分析 可視化 データを収集し、 データレイクへ 格納 全期間保存 共通APIでア クセス 可視化 スケールアウト 可能な技術 分析 スケールアウト 可能な技術API
  26. 26. 26 #dbts2017 管理不要のBIサービス 高速SPICEエンジン 利用人数の増加に自動的に対応 各種データソースに接続 1ユーザ・1ヶ月あたり$12から Amazon QuickSight ※費用は2017年9月時点、スタンダード・エディションのもの
  27. 27. 27 #dbts2017 分析 分析 データレイク 全体図 • データレイク(S3)に全期間データを保存 • GlueやEMRでプリプロセス、非定型データの処理 • スケールアウト可能なインフラで分析処理 収集 可視化 Redshift QuickSight EXP Amazon S3 BI+EC2 Direct Connect プリプロセス Glue 全データ 変形済 Athena EMR
  28. 28. 28 #dbts2017 規模の増大に対応できるDWH作り Redshiftを例に
  29. 29. 29 #dbts2017 規模の増大に対応できるDWH作り • 基盤レベルでスケールアウト・分散できるよう にしておくことが重要 • しかし全てスケールアウトでは対応しきれない – ノード数を2倍にしても、性能は最大で2倍にしかならない • スケールアウト可能な基盤を利用しつつ、 DWH(Redshift)の使用方法でも工夫が必要
  30. 30. 30 #dbts2017 #1:偏りを無くす(最も重要)
  31. 31. 31 #dbts2017 スケールアウトしても性能が向上しない? スケールアウトでの性能向上とは? ノードが増える ⇒ノードごとの処理量が減る ⇒性能向上(スループット改善) • そのため、特定のノードに処理が偏 ると性能が伸びにくくなる スケールアウト
  32. 32. 32 #dbts2017 スケールアウトでスループット向上 - 重要なのは処理量の偏りを無くすこと CPU CPU CPU CPU CPU CPU 特定ノードにデータが偏る と、そのノード上の処理が 完了するまで他が待つ
  33. 33. 33 #dbts2017 Redshift - ディストリビューションの選択 ALL Node 1 Slice 1 Slice 2 Node 2 Slice 3 Slice 4 全ノードにデータ をコピー KEY(DISTKEY) Node 1 Slice 1 Slice 2 Node 2 Slice 3 Slice 4 同じキーを同じ場所に Node 1 Slice 1 Slice 2 Node 2 Slice 3 Slice 4 EVEN ラウンドロビンで均一分散 (※デフォルト) CREATE TABLE t(…) DISTSTYLE { EVEN | KEY | ALL } スケールアウト性能を出すため、基本はEVEN
  34. 34. 34 #dbts2017 次にデータのネットワーク転送を検討する 自ノードに必要なデータ がない場合、データ転送 が発生 - 単一ノード - ブロードキャスト 計算後リーダー・ノー ドに各ノードの結果を 集約
  35. 35. 35 #dbts2017 ネットワーク転送量 vs データの偏り • DISTKEYやALLはジョインやグ ルーピング処理のネットワーク 転送量を小さくできる • しかしDISTKEYはデータの偏 りを生む場合がある • 特にカーディナリティが低い列 や、NULLが多い列に注意 • まずはEVENで均一に分散させ、 業務上必要なものだけ DISTKEYやALLを検討 ALL Node 1 Slice 1 Slice 2 Node 2 Slice 3 Slice 4 全ノードにデータ をコピー KEY(DISTKEY) Node 1 Slice 1 Slice 2 Node 2 Slice 3 Slice 4 同じキーを同じ場所に
  36. 36. 36 #dbts2017 #2:ディスクIO量を最小にする
  37. 37. 37 #dbts2017 均一に分散した上で、 ディスクアクセスの量を最小にする事で速度を上げる • SORTKEY – SORTKEYに応じて、ディスク上にデータが順序を守って格納 – これによりディスクIO数を削減できる – CREATE TABLE時に指定 • CREATE TABLE t1(…) SORTKEY (c1,c2 …) • SORTKEYの使いどころ – 頻繁に特定のカラムに対して、範囲または等式検索を行う場合 – DWH場合多くのケースで時刻列にSORTKEYを付ける
  38. 38. 38 #dbts2017 SORTKEY の例 • orderdate 列をSORTKEY に指定した場合: 2017/07/17 2017/07/18 2017/07/18 2017/07/19 … I0101 I0203 I0002 I0200 ・・・ 2017/08/20 2017/08/21 2017/08/22 2017/08/22 … I0020 I0021 I0022 I0023 orderdate…orderid SELECT * FROM orders WHERE orderdate BETWEEN ‘2017-08-01’ AND ‘2013-07-31’; クエリで必要なデータが固まっているた めディスクアクセス回数が減少
  39. 39. 39 #dbts2017 分散スタイルもSORTKEYも表あたり1つしか指定でき ないのをどうするか? • ワークロード上課題になっている クエリを中心にキーを決定 • 同じデータで、別の分散・ソート キーの表を作成することも検討 – 名前の違いはBI側で吸収 • RedshiftならINSERT ... SELECTでのコピーも高速 CREATE TABLE t( … ) DISTSTYLE EVEN SORTKEY (C1); CREATE TABLE t2( … ) DISTKEY (C4) SORTKEY (C2);
  40. 40. 40 #dbts2017 ディスク使用量を削減するもう一つの方法: アクセス頻度が低いデータをS3に • データは参照頻度に差があるの が普通(ホット or コールド) • 頻繁にアクセスされるデータを ローカルに置き、あまりアクセ スされないデータはS3に置く • S3に置いたデータはRedshift Spectrumで透過的にアクセス Amazon Redshift ... 1 2 3 4 N 2012年 直近データ 2016年~2017年 2013年 2014年 2015年
  41. 41. 41 #dbts2017 1 2 ... N Amazon Redshift Spectrum • RedshiftからS3上に置いたファイル を外部テーブルとして定義し、クエ リ可能になる新機能 • ローカルディスク上のデータと組み 合わせたSQLが実行可能 • Spectrum層でS3上のデータを分散 処理し、Redshift側の負担を軽減 • 多様なファイルフォーマットに対応 S3 各種データ (CSV, Parquet, ORC等) Spectrum層
  42. 42. 42 #dbts2017 #3:ワークロードごとに分割する
  43. 43. 43 #dbts2017 ワークロードごとに分割することで システムを安定させる • 雑多なワークロード(SQL)が流れてくる – SQLでは簡単に膨大な演算が書ける – 使い方によっては、必要な業務が滞ることに... • ワークロードごとにリソースを分離する – 1つのRedshiftクラスター内で制限・統制する – 複数のRedshiftクラスターに分離する
  44. 44. 44 #dbts2017 RedshiftのWorkload Management (WLM) • 実行に長い時間を要するクエリー は、クラスタ全体のボトルネック となり、他のクエリーを待たせる 可能性がある • Workload Management (WLM)は、 用途別に「キュー」を作成し、利 用するキューを使い分けることで ワークロードを制御する仕組み • デフォルトでは、単一のデフォル ト・キュー(並列度:5) SQL デフォルト・キュー 実行中(5並列) ウエイト SQL SQL SQL SQL ⑤並列 SQL
  45. 45. 45 #dbts2017 WLMの設定例 メモリサイズもQueueごとに比率を設定可能 User Group A 短い時間で応答すべきクエリ長時間掛かるバッチクエリ Long Query Group 10並列 メモリ:70% 3並列 メモリ:30%
  46. 46. 46 #dbts2017 Query Monitoring Rules (QMR)で統制する QMR:クエリに対してルールを設定できる機能 • ルール:CPU利用率、CPU時間、ブロック 読み取り数、ジョイン対象行数等多数 • アクション:LOG(記録)、HOP(別キュー に転送)、ABORT(停止) • 例)ジョイン対象の行数が10億行を超える 場合はABORT • 例)CPUを80%以上消費した状態が10分 (600秒)以上続いたクエリはABORTする
  47. 47. 47 #dbts2017 用途ごとにRedshiftクラスターを立てて負荷分散 • SpectrumでS3上のデー タを複数のRedshiftクラ スターから共有 – もしくはETLでデータコピー • 各クラスターのサイズや スペックは個別に調整 • 別々のAZに配置すると可 用性の向上も同時に実現 共有データ
  48. 48. 48 #dbts2017 #4:キャッシュする・事前に計算する
  49. 49. 49 #dbts2017 キャッシュ・事前計算の有用性 • 多くのユーザは同じデータを参照する • 多くのユーザは同じような演算結果を必要とする ⇒キャッシュと事前計算が有効 • BIサーバでキャッシュできれば簡単 – BIサーバのパフォーマンスに要注意 – Amazon QuickSightではSPICEエンジンで キャッシュが可能 キャッシュ
  50. 50. 50 #dbts2017 QuickSightでは SPICEでキャッシュと負荷分散を実現する クエリ 表表 CSV CSV 直接クエリ(SQL) データソース データのキャッシュ • ビジュアル • ストーリー • ダッシュボード QuickSight UI • SPICEはQuickSightに含まれるBI用高速演算データベース • RDBやAthenaにクエリした結果をSPICEに取り込む事が可能 Amazon Athena Amazon Redshift Amazon S3
  51. 51. 51 #dbts2017 事前に計算する事で計算コストを削減する • DWHの処理で最も間が掛かるのはジョイン処理 – 巨大なデータをジョインするために時間が掛かる • BI的な解決:目的別データマートの作成 – 目的に必要なデータ範囲のみのデータセット • RDB的な解決:マテリアライズド・ビュー – Redshiftはマテリアライズドビューが無いので事前にジョインした 結果を表に保存し、それをBIサーバから参照する
  52. 52. 52 #dbts2017 計算済の表を別の特性のサービスに負荷分散 例)マートDBをPostgreSQLで作成しRedshiftと繋ぐ • データウェアハウスとしてRedshift • ダッシュボードを閲覧する多数ユーザー用のデータマートとして Aurora PostgreSQL • 両者をdblinkでつなぎ、PostgreSQL上のマテリアライズド・ビューとして実装 dblink Redshift Aurora PostgreSQL
  53. 53. 53 #dbts2017 DWH側の手法:使い所(一例) #1:偏りを無く す #2:ディスクIO 量を最小にす る #3:ワークロー ドごとに分割 する #4:キャッシュ する・事前に 計算する データサイズ の増加に対応 ◎ ◎ ◎ 人数の増加に 対応 ◎ ◎ 要求(ワーク ロード)の増 加に対応 ◎ ◎
  54. 54. 54 #dbts2017 まとめ:長く使えるDWHを目指して • 成功したDWHは成長し続ける – AWSマネージドサービスで、運用負荷をできるだけ下げておく – スケールアウトできるインフラにする • 用途の増加に対応する – 元データをデータレイクに残す • データサイズ・用途の増加に対応する – スケールアウトできるようにしておく事が重要 – フロントでキャッシュする、サーバを用途別に分割する
  55. 55. 55 #dbts2017 参考情報 (1/2) • Amazon Redshift – ホーム・ページ(ドキュメント、価格等) • https://aws.amazon.com/jp/redshift/ – パフォーマンスチューニングテクニック Top 10 • http://aws.typepad.com/sajp/2015/12/top-10-performance-tuning-techniques-for- amazon-redshift.html – テーブル設計詳細ガイド • http://aws.typepad.com/sajp/2016/12/amazon-redshift-engineerings-advanced- table-design-playbook-preamble-prerequisites-and-prioritization.html – dblinkを利用して、Amazon RedshiftとRDS PostgreSQLのデータをジョインする • http://aws.typepad.com/sajp/2016/06/join-amazon-redshift-and-amazon-rds- postgresql-with-dblink.html
  56. 56. 56 #dbts2017 参考情報 (2/2) • Amazon QuickSight – ホーム・ページ(ドキュメント、価格等) • https://quicksight.aws/ – GA時の概要紹介記事 • https://aws.amazon.com/jp/blogs/news/amazon-quicksight-now-generally- available-fast-easy-to-use-business-analytics-for-big-data/ • AWS Glue – ホーム・ページ(ドキュメント、価格等) • https://aws.amazon.com/jp/glue/ – GA時の概要紹介記事 • https://aws.amazon.com/jp/blogs/news/launch-aws-glue-now-generally- available/
  57. 57. 57 #dbts2017 内容についての注意 • 本資料では2017年9月6日時点のサービス内容および価格についてご説明しています。最 新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 • 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格 に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 • 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、 別途消費税をご請求させていただきます。 • AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.
  58. 58. 58 #dbts2017

×