1 #dbts2017

Amazon RedshiftとAmazon QuickSightで実現する、長く使えるDWH作り～小規模で始めて、規模の増大に耐えられる仕組み作り～

2017年9月6日

アマゾンウェブサービスジャパン

ソリューションアーキテクト

下佐粉 昭 @simosako

2 #dbts2017

今日お伝えしたいこと

• DWHは構築するまでがまず大変– 「本当に利益を生むか分からないのに投資するの？」

• もっと大変なのはDWH構築に成功した後– サイズ・人・要望（ワークロード）が増え続ける

• 増加に対応できるインフラと仕組み作りを知ることで長く使えるDWHを構築しましょう

3 #dbts2017

自己紹介

下佐粉 昭（しもさこ あきら）@simosako

所属：アマゾン ウェブ サービス ジャパン技術統括本部 エンタープライズソリューション部ソリューションアーキテクト

好きなAWSサービス:Redshift, RDS, S3人間が運用等から解放されて楽になるサービスが好きです

4 #dbts2017

内容

• クラウド上にDWHを作ることでリスクを減らす

• 要望の多様化に対応できるインフラ

• サイズの増加への対応はスケールアウトで実現する

• 規模の増大に対応できるDWH作り - Redshiftを例に

• まとめ

• 参考資料 資料は講演後に公開予定ですhttps://www.slideshare.net/AmazonWebServicesJapan

5 #dbts2017

クラウド上にDWHを作ることでリスクを減らす

6 #dbts2017

データウェアハウス構築の課題

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築

– バックアップ＆リストア

– モニタリング

7 #dbts2017

データウェアハウス構築の課題とAWSクラウド

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築

– バックアップ＆リストア

– モニタリング

AWSクラウド

• 初期投資不要

• 利用分だけの支払い

• 安価

• いつでもやめられる

8 #dbts2017

仮想サーバ(EC2)

＝ $0.008～ / 時間 ※1

※1 2017年9月時点での東京リージョンの金額※2 2017年9月時点での価格

初期費用不要・利用した分だけの料金（一例）

BIサービス(QuickSight)

＝ $12～ ユーザ / 月 ※2

＝ $0.314～ / 時間 ※1データウェアハウス(Redshift)

9 #dbts2017

データウェアハウス構築の課題とAWSクラウド

• 投資対効果の検討が困難– 高い初期投資

– やってみないと、効果が見えない

– 巨大投資を回収する必要がある

• 運用管理の負荷が高い– 大規模サーバ構築

– バックアップ＆リストア

– モニタリング

AWSクラウド

• 数クリックでDWHが起動

• バックアップやモニタリングといった運用機能を含む

10 #dbts2017

マネージドサービスで運用の負荷を低減大規模になるほど管理範囲を小さくすることが重要に

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

オンプレミス 独自構築 on EC2 AWSマネージドサービス

お客様がご担当する作業 AWSが提供するマネージド機能

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

電源・ネットワーク

ラッキング

HWメンテナンス

OSパッチ

ミドルウェアパッチ

定形運用設計

スケールアウト設計

ミドルウェア導入

OS導入

アプリケーション作成

11 #dbts2017

分析保存

Amazon

Glacier

AmazonS3

Amazon

DynamoDB

Amazon RDS/

Aurora

AWSマネージドサービス：ビッグデータ領域

AWS GlueAmazon

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 #dbts2017

無事にDWHが構築できた！すると...

思ってもみなかったようなところで使われはじめます

• 要望の増加（多様化）

• データサイズの増加

• 利用人数の増加

13 #dbts2017

要望の多様化に対応できるインフラ

14 #dbts2017

これまで：1. ディスクが高価で上限がある

2. データはサマリーだけ、もしくは期間限定で保存

3. 処理できる内容は固定的

多様化する要望に対応するために：オリジナルデータは削除せず、全期間を残す

On AWSクラウド：1. 安価・上限無しのストレージ

2. オリジナルデータを全て残す

3. 処理対象・処理内容はビジネスに合わせて変わる

インフラ管理者の仕事：データを活用して新しい課題に素早く対応できるインフラを用意する。個別リクエストへの対応

インフラ管理者の仕事：ストレージを溢れさせず、時間内に処理が終るようにサイズや処理内容を調整する

15 #dbts2017

データレイク

• 多様なデータを一元的に保存

• データを失わない

• サイズ制限からの開放

• APIですぐにアクセスできる

センサーデータ

非構造化ファイルテキストファイル

RDBMS

データレイク

API呼び出しによる連携

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 #dbts2017

• データをデータレイクに集め、多様な分析につなげる

• 分析環境は要望別に分けることが可能

• 小さく試せて、いつでも辞められる環境をフル活用

大規模データ分析 on クラウド

収集 データレイク

（保存）

分析 可視化

データを収集し、データレイクへ格納

全期間保存共通APIでアクセス

可視化分析

AP

I

18 #dbts2017

サイズの増加への対応はスケールアウトで実現する

19 #dbts2017

スケールアウト+分散処理が鍵

• スケールアップもスケールアウトもクラウドでは容易

• …しかしスケールアップには限界がある（CPU、メモリ、ストレージ）

スケールアウト可能なテクノロジーをベースに分散処理を行うことで規模の増加に対応する

S

XL

スケールアップ

スケールアウト

20 #dbts2017

分散処理が可能なAWSの分析サービスマネージド, 標準技術, 分散処理

Amazon

Redshift

Amazon

Athena

Amazon

EMR

AWS

Glue

マネージド マネージド

DWH(RDB)

マネージドクエリ環境

マネージドHadoop環境

マネージドETL環境

標準・デファクトスタンダード

SQL標準 SQL標準 Hadoop/Spark（デファクト）

Spark（デファクト）

分散処理 ユーザ操作でノード数増加

クエリに応じて自動分散処理

ユーザ操作でノード数増加

ジョブ毎にユーザ設定でノード（DPU）増加

21 #dbts2017

DWH特化の高速RDB

ペタバイト級までスケールアウト

フルマネージド

多数の周辺ソフト; PgSQL互換性

$1,000/TB/年; 最小$0.314/時から

Amazon

Redshift

※費用は2017年9月時点での東京リージョンのものです

22 #dbts2017

RedshiftはSQLをスケールアウトで処理

SELECT *

FROM lineitem;

CPU CPU CPU CPU CPU CPU

Leaderノード

Computeノード

スライス＝メモリとディスクをノード内で分割した論理的な処理単位

コンピュートノードの追加でパフォーマンス向上（スケールアウト）

23 #dbts2017

ETL処理専用サービス

ユーザ指定でスケールアウト

フルマネージド

PySparkで処理ロジック：標準技術

ジョブ実行 $0.44/DPU-時から

AWS

Glue

※1DPUは4vCPU,16GBメモリの処理能力単位。費用は2017年9月時点での東京リージョンのものです

24 #dbts2017

クラウドではスケールアウト ≠ 高価

• Glueはジョブを分散実行

• ユーザ指定に応じてスケールアウト

• 分散処理により処理時間短縮とコストを両立できる

処理時間

8時間 処理時間

2時間

JOB16DPUに

拡張

JOB

4DPU×8時間＝32

16DPU×2時間＝32

25 #dbts2017

①データをデータレイクに集め、多様な分析につなげる

②分析はスケールアウト可能なインフラの上で分散処理

大規模データ分析 on クラウド

収集 データレイク

（保存）

分析 可視化

データを収集し、データレイクへ格納

全期間保存共通APIでアクセス

可視化

スケールアウト可能な技術

分析スケールアウト

可能な技術A

PI

26 #dbts2017

管理不要のBIサービス

高速SPICEエンジン

利用人数の増加に自動的に対応

各種データソースに接続

1ユーザ・1ヶ月あたり$12から

Amazon

QuickSight

※費用は2017年9月時点、スタンダード・エディションのもの

27 #dbts2017

分析

分析

データレイク

全体図• データレイク（S3）に全期間データを保存

• GlueやEMRでプリプロセス、非定型データの処理

• スケールアウト可能なインフラで分析処理

収集

可視化

Redshift QuickSight

EXPAmazon S3

BI＋EC2

Direct

Connect

プリプロセスGlue

全データ 変形済

Athena

EMR

28 #dbts2017

規模の増大に対応できるDWH作りRedshiftを例に

29 #dbts2017

規模の増大に対応できるDWH作り

• 基盤レベルでスケールアウト・分散できるようにしておくことが重要

• しかし全てスケールアウトでは対応しきれない– ノード数を２倍にしても、性能は最大で２倍にしかならない

• スケールアウト可能な基盤を利用しつつ、DWH(Redshift)の使用方法でも工夫が必要

30 #dbts2017

#1:偏りを無くす（最も重要）

31 #dbts2017

スケールアウトしても性能が向上しない？

スケールアウトでの性能向上とは？

ノードが増える

⇒ノードごとの処理量が減る

⇒性能向上（スループット改善）

• そのため、特定のノードに処理が偏ると性能が伸びにくくなる

スケールアウト

32 #dbts2017

スケールアウトでスループット向上 -重要なのは処理量の偏りを無くすこと

CPU CPU CPU CPU CPU CPU

特定ノードにデータが偏ると、そのノード上の処理が完了するまで他が待つ

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 #dbts2017

次にデータのネットワーク転送を検討する

自ノードに必要なデータがない場合、データ転送が発生- 単一ノード- ブロードキャスト

計算後リーダー・ノードに各ノードの結果を集約

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 #dbts2017

#2:ディスクIO量を最小にする

37 #dbts2017

均一に分散した上で、ディスクアクセスの量を最小にする事で速度を上げる

• SORTKEY– SORTKEYに応じて、ディスク上にデータが順序を守って格納

– これによりディスクIO数を削減できる

– CREATE TABLE時に指定

• CREATE TABLE t1(…) SORTKEY (c1,c2 …)

• SORTKEYの使いどころ– 頻繁に特定のカラムに対して、範囲または等式検索を行う場合

– DWH場合多くのケースで時刻列にSORTKEYを付ける

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 #dbts2017

分散スタイルもSORTKEYも表あたり１つしか指定できないのをどうするか？

• ワークロード上課題になっているクエリを中心にキーを決定

• 同じデータで、別の分散・ソートキーの表を作成することも検討– 名前の違いはBI側で吸収

• RedshiftならINSERT ... SELECTでのコピーも高速

CREATE TABLE t(

…

)

DISTSTYLE EVEN

SORTKEY (C1);

CREATE TABLE t2(

…

)

DISTKEY (C4)

SORTKEY (C2);

40 #dbts2017

ディスク使用量を削減するもう一つの方法：アクセス頻度が低いデータをS3に

• データは参照頻度に差があるのが普通（ホット or コールド）

• 頻繁にアクセスされるデータをローカルに置き、あまりアクセスされないデータはS3に置く

• S3に置いたデータはRedshift Spectrumで透過的にアクセス

Amazon

Redshift

...

1 2 3 4 N

2012年

直近データ2016年～2017年

2013年 2014年 2015年

41 #dbts2017

1 2

...

N

Amazon Redshift Spectrum

• RedshiftからS3上に置いたファイルを外部テーブルとして定義し、クエリ可能になる新機能

• ローカルディスク上のデータと組み合わせたSQLが実行可能

• Spectrum層でS3上のデータを分散処理し、Redshift側の負担を軽減

• 多様なファイルフォーマットに対応S3

各種データ（CSV, Parquet, ORC等）

Spectrum層

42 #dbts2017

#3:ワークロードごとに分割する

43 #dbts2017

ワークロードごとに分割することでシステムを安定させる

• 雑多なワークロード（SQL）が流れてくる– SQLでは簡単に膨大な演算が書ける

– 使い方によっては、必要な業務が滞ることに...

• ワークロードごとにリソースを分離する– １つのRedshiftクラスター内で制限・統制する

– 複数のRedshiftクラスターに分離する

44 #dbts2017

RedshiftのWorkload Management (WLM)

• 実行に長い時間を要するクエリーは、クラスタ全体のボトルネックとなり、他のクエリーを待たせる可能性がある

• Workload Management (WLM)は、用途別に「キュー」を作成し、利用するキューを使い分けることでワークロードを制御する仕組み

• デフォルトでは、単一のデフォルト・キュー（並列度：５）

SQL

デフォルト・キュー

実行中（５並列） ウエイト

SQL SQL SQL SQL

⑤並列SQL

45 #dbts2017

WLMの設定例メモリサイズもQueueごとに比率を設定可能

User Group A

短い時間で応答すべきクエリ長時間掛かるバッチクエリ

Long

Query Group

10並列メモリ:70%

3並列メモリ:30%

46 #dbts2017

Query Monitoring Rules (QMR)で統制する

QMR：クエリに対してルールを設定できる機能

• ルール：CPU利用率、CPU時間、ブロック読み取り数、ジョイン対象行数等多数

• アクション：LOG（記録）、HOP(別キューに転送）、ABORT（停止）

• 例）ジョイン対象の行数が10億行を超える場合はABORT

• 例）CPUを80%以上消費した状態が10分（600秒）以上続いたクエリはABORTする

47 #dbts2017

用途ごとにRedshiftクラスターを立てて負荷分散

• SpectrumでS3上のデータを複数のRedshiftクラスターから共有– もしくはETLでデータコピー

• 各クラスターのサイズやスペックは個別に調整

• 別々のAZに配置すると可用性の向上も同時に実現

共有データ

48 #dbts2017

#4:キャッシュする・事前に計算する

49 #dbts2017

キャッシュ・事前計算の有用性

• 多くのユーザは同じデータを参照する

• 多くのユーザは同じような演算結果を必要とする

⇒キャッシュと事前計算が有効

• BIサーバでキャッシュできれば簡単– BIサーバのパフォーマンスに要注意

– Amazon QuickSightではSPICEエンジンで

キャッシュが可能

キャッシュ

50 #dbts2017

QuickSightではSPICEでキャッシュと負荷分散を実現する

クエリ

表表

CSV

CSV

直接クエリ（SQL）

データソースデータのキャッシュ

• ビジュアル• ストーリー• ダッシュボード

QuickSight UI

• SPICEはQuickSightに含まれるBI用高速演算データベース

• RDBやAthenaにクエリした結果をSPICEに取り込む事が可能

Amazon Athena

Amazon Redshift

Amazon S3

51 #dbts2017

事前に計算する事で計算コストを削減する

• DWHの処理で最も間が掛かるのはジョイン処理– 巨大なデータをジョインするために時間が掛かる

• BI的な解決：目的別データマートの作成– 目的に必要なデータ範囲のみのデータセット

• RDB的な解決：マテリアライズド・ビュー– Redshiftはマテリアライズドビューが無いので事前にジョインした

結果を表に保存し、それをBIサーバから参照する

52 #dbts2017

計算済の表を別の特性のサービスに負荷分散例）マートDBをPostgreSQLで作成しRedshiftと繋ぐ

• データウェアハウスとしてRedshift

• ダッシュボードを閲覧する多数ユーザー用のデータマートとして Aurora PostgreSQL

• 両者をdblinkでつなぎ、PostgreSQL上のマテリアライズド・ビューとして実装

dblinkRedshift Aurora

PostgreSQL

53 #dbts2017

DWH側の手法：使い所（一例）

#1:偏りを無くす

#2:ディスクIO量を最小にする

#3:ワークロードごとに分割する

#4:キャッシュする・事前に計算する

データサイズの増加に対応 ◎ ◎

◎

人数の増加に対応 ◎ ◎

要求（ワークロード）の増加に対応

◎ ◎

54 #dbts2017

まとめ：長く使えるDWHを目指して

• 成功したDWHは成長し続ける– AWSマネージドサービスで、運用負荷をできるだけ下げておく– スケールアウトできるインフラにする

• 用途の増加に対応する– 元データをデータレイクに残す

• データサイズ・用途の増加に対応する– スケールアウトできるようにしておく事が重要– フロントでキャッシュする、サーバを用途別に分割する

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 #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 #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 #dbts2017