amazon s3を中心とするデータ分析のベストプラクティス

1

Amazon S3を中心とするデータ分析のベストプラクティス

Ryosuke IwanagaAmazon Web Services Japan

Solutions Architect

2016.10

2

Agenda

• データレイクとAmazon S3

• データ分析のためのAmazon EMR

• 【事例】データ分析で作る新しい価値

3

データウェアハウス

4

データウェアハウスを中心としたデータ分析

Databases

Logs

Data WarehouseBI

Report

5

データウェアハウスを利用する利点

• スキーマが定義されている

• データの型も強制できる

• どんなデータもあって、共通のセキュリティモデルで利用

• アクセスするツールが簡単、エコシステムが安定

• トランザクション

6

課題1: 入ってくるデータの量と質の変化

Databases

Logs

Data WarehouseBI

Report

Events

Media

7

課題2: データを利用する側の量と質の変化

Databases

Logs

Data Warehouse

BI

Report

Lab

Realtime

Machine

Learning

8

データのサイロ化

9

データのサイロ化の課題

• スケーラビリティの課題は解消しない– 要求が10倍になったら、サイロ数が10倍になる？？

• どこにどのデータがあるか分からない– 途中で場所が変わったら更にカオスに

• サイロをまたいだ分析が困難– 同じデータを複数サイロに重複して持つと、無駄や同期が課題に

10

データレイク

11

データレイクを中心としたデータ分析

Data Lake

………

12

データレイクのメリット

• ストレージと計算処理の分離– それぞれ独立してスケールできるので最適化しやすい

• Single Source of Truth– データレイクにあるものを正とすれば良い

• 様々なinput/output手法に対応– in/outが独立、ETLも独立できるので、後からの拡張がスムーズ

13

データレイク – Hadoop (HDFS)をストレージとして

Search

Access

QueryProcess

Archive

14

Transaction

s

データレイク – Amazon S3をストレージとして

Search

Access

QueryProcess

Archive

Amazon RDS

Amazon DynamoDB

AmazonElasticsearch

Service

AmazonGlacier

Amazon S3

Amazon Redshift

Amazon Elastic

MapReduce

Amazon Machine Learning

Amazon ElastiCache

15

何でも保存できる (オブジェクトストレージ)

スケール可能 / 弾力的

99.999999999% の耐久性 (イレブン・ナイン)

実質的に無限のインバウンド帯域

とても低いコスト: $0.03/GB-月; $30.72/TB-月

全てのAWSサービスにとって仮想的なデータレイヤ

Amazon S3

16

クロスリージョンレプリケーション

Amazon CloudWatch メトリクスAWS CloudTrail サポート

VPCエンドポイントfor Amazon S3

Amazon S3 バケット数上限引き上げ

イベント通知

全リージョンで新規作成後の読み取り一貫性

Amazon S3の進化

17

S3のストレージクラスの選択肢

標準

アクティブデータ アーカイブデータ低頻度アクセスデータ

標準 - 低頻度アクセス Amazon Glacier

18

どうやってアクセスする？

• ETL等を経て、他のDB/DWHへ取り込む– Pros: DB/DWHの強力な機能が利用できる

– Cons: ETL処理が必要になる、スケールに限界がある

• 直接S3にアクセスする– Pros: S3に置いた瞬間にアクセスできる、スケールは無限

– Cons: レイテンシに多少ペナルティがある

19

S3上のペタバイト級のデータ群を、Hiveテーブルとして利用する

hive> CREATE EXTERNAL TABLE airdelays (yr INT,quarter INT,month INT,flightdate STRING,uniquecarrier STRING,airlineid INT,. . .div5tailnum STRING)PARTITIONED BY (year STRING)ROW FORMAT DELIMITEDFIELDS TERMINATED BY ','LINES TERMINATED BY '\n'LOCATION 's3://flightdelays-kls/csv’;

データがあるS3のバケット:

S3上のデータをテーブルとして見えるようにHiveに指

示する

hive> describe airdelays;OKyr intquarter intmonth intflightdate string . . . div5wheelsoff string div5tailnum string year string

# Partition Information# col_name data_type comment

year string Time taken: 0.169 seconds, Fetched: 115 row(s)

Hiveはテーブルを知ることができる:

20

s3://bucket/logs

/file001

/file002

/file003

/file004

/file005

/file006

/file007

/file008

R

R

R

M

M

M

M1,aaa,...2,bbb,......

SQLを使ってS3に直接アクセスするCREATE TABLE logs...

Metastore

SELECT …FROM logs...

21

S3のパフォーマンス: レンジGET vs データ局在性?

GET Range 128-192MB

GET Range 0-64MB

GET Range 64-128MB

GET Range (n-64)-nMB

ワーカーノード

S3オブジェクト

(大きめのファイル

)

22

ID Age State

123 20 CA

345 25 WA

678 40 FL

999 21 WA

行指向 vs 列指向フォーマット

123 20 CA 345 25 WA 678 40 FL 999 21 WA

123 345 678 999 20 25 40 21 CA WA FL WA

ROW FORMAT

COLUMN FORMAT

23

ストレージのパフォーマンス: S3 vs HDFS at Netflix

http://techblog.netflix.com/2014/10/using-presto-in-our-big-data-platform.html

24

ユースケース

我々はクラウドベースのデータウェアハウスの"source of truth"としてS3を利用しています。取っておく価値のあるデータは全てS3に保存されています。この中には、我々のログデータパイプライン(Ursula)によって、(Netflixが組み込まれた)テレビやパソコン、そしてモバイルデバイスから毎時間取得される数十億ものイベントストリームに加えて、AegisthusパイプラインのCassandraから産まれるディメンションデータも含まれています。

“

”

Source: http://techblog.netflix.com/2013/01/hadoop-platform-as-service-in-cloud.html

Eva TseDirector, Big Data Platform

25

我々のBig Dataの規模感

トータル ~25PB のデータウェアがAmazon S3に

読み出し ~10% (データ/日)

書き込み ~10% (読み出しデータ/日)

~ 5500億イベント/日

~ 350のアクティブなプラットフォームユーザ

26

クラウドアプリ

Kafka Ursula

CassandraAegisthus

ディメンションデータ

イベントデータ

15分

日次

Amazon S3

SSテーブル

データパイプライン

27

データ分析のためのAmazon EMR

28

データ処理を単純化してみる

収集 保存 処理/分析 利用

データ 答え

答えを出すまでの時間(レイテンシ)は?

スループットは?

費用は?

29

データ処理/分析に必要なこと

• 常に新しくなる分散処理エコシステムへの対応– バージョンアップ、新プロダクト、カスタマイズ

• 簡単にスケールできること– データに応じて、利用者数に応じて

• データレイクとの連携– データレイクのデータをネイティブに扱える

30

スケール可能なHadoopクラスタをサービスとして

Hadoop, Hive, Spark, Presto, Hbase, etc.

簡単に利用でき、完全にマネージド

オンデマンド、予約、スポットの価格

HDFS, S3, Amazon EBSのファイルシステム

エンドツーエンドのセキュリティ

Amazon EMR

31

EMRノード

Master instance group

EMR cluster

Task instance groupCore instance group

HDFS HDFS

32

なぜEMR？

• 豊富なアプリケーションが簡単に利用可能– 高速なアップデートで業界最新に追従

• クラスタ作成から終了まで全てを自動化

• 低コストで運用可能

33

Storage S3 (EMRFS), HDFS

YARNCluster Resource Management

BatchMapReduce

InteractiveTez

In MemorySpark

ApplicationsHive, Pig, Spark SQL/Streaming/ML, Mahout, Sqoop H

Base

/

Ph

oen

ix

Pre

sto

Hue (SQL Interface/MetastoreManagement)

Zeppelin (Interactive Notebook)Ganglia (Monitoring)

HiveServer2/Spark Thriftserver(JDBC/ODBC)

Amazon EMR サービス

34

Amazon EMR Release (2015/07以降)

• Release 4.0.0 – 2015/07• Release 4.1.0 – 2015/09• Release 4.2.0 – 2015/11• Release 4.3.0 – 2016/01• Release 4.4.0 – 2016/03• Release 4.5.0 – 2016/04• Release 4.6.0 – 2016/04• Release 4.7.1 – 2016/06• Release 4.7.2 – 2016/07• Release 5.0.0 – 2016/08

• 約12ヶ月間で10回のリリース

• 進化の早いHadoopエコシステムに追従していくため

35

アプリケーションの変更履歴 (〜5.0.0)

36

EMR 5.0 - Applications

37

カスタムアプリケーションもBigtopで

https://blogs.aws.amazon.com/bigdata/post/TxNJ6YS4X6S59U/Building-and-Deploying-Custom-Applications-with-Apache-Bigtop-and-Amazon-EMR

38

なぜEMR?: 自動化

EC2 Provisioning Cluster Setup Hadoop Configuration

Installing Applications

Job submissionMonitoring and Failure Handling

39

Amazon EMRならではの使い方

• 必要な時だけクラスタ起動– 消せばお金はかからない– 処理が終わったら自動で消える設定も可能

• データは全てAmazon S3– クラスタを消してもデータは消えない

– データを貯める段階ではクラスタ不要

t

40

$0.27 $0.29$0.50

1b 1c1a

8XL

$0.30 $0.16$0.214XL

$0.07 $0.08$0.082XL

$0.05 $0.04$0.04XL

$0.01 $0.04$0.01L

C3

$1.76

On

Demand

$0.88

$0.44

$0.22

$0.11

各インスタンスファミリー

各インスタンスサイズ

各アベイラビリティゾーン

各リージョン

全てが別々のSpot Market

Spot Market

41

なぜEMR?: ストレージとコンピュートの分離

Amazon Kinesis

(Streams, Firehose)

Hadoop Jobs

Persistent Cluster – Interactive Queries

(Spark-SQL | Presto | Impala)

Transient Cluster - Batch Jobs

(X hours nightly) – Add/Remove Nodes

ETL Jobs

Hive External Metastore

i.e Amazon RDS

Workload specific clusters

(Different sizes, Different Versions)

Amazon S3 for Storage

create external table t_name(..)...

location s3://bucketname/path-to-file/

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Scott Donaldson, Senior Director

Clayton Kovar, Principal Architect

EMR と

対話的な分析

最大で750億件の

イベントが

毎日5 PBを超えるストレージ

投資家を保護する

マーケットを清廉に保つ

アメリカの99%の株取引と70%のオプションを監視している

マーケットの再構築は10兆ものノードとエッジが含まれる

大きく考える

EMRは我々のアーキテクチャ上でユビキタス

データマート(Amazon Redshift)

クエリクラスタ(EMR)

クエリクラスタ(EMR)

Auto ScaledEC2

分析アプリ

正規化ETLクラスタ(EMR)

バッチ分析クラスタ(EMR)

アドホッククエリクラスタ

(EMR)

Auto ScaledEC2

分析アプリ

ユーザ データ提供者

Auto ScaledEC2

データ投入

サービス

最適化ETLクラスタ(EMR)

共有Metastore(RDS)

クエリ最適化(S3)

Auto Scaled EC2

データカタログ&派生

サービス

参照データ(RDS)

共有データサービス

Auto ScaledEC2

クラスタ管理&ワークフロー

サービス

生データ(S3)

Hive on EMR/S3で十分戦える

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Abhishek Sinha, Amazon Web Services

Gaurav Agrawal, AOL Inc

October 2015

BDT208

A Technical Introduction to

Amazon EMR

AOLデータプラットフォームアーキテクチャ 2014

データの統計と洞察

クラスタサイズ2 PB

自前のクラスタ100ノード

行データ/日2-3 TB

データ保持期間13-24ヶ月

AOLデータプラットフォームアーキテクチャ2015

12

2

34

56

50

EMR+S3のベストプラクティス

• データをまずはS3に着地させる– 生データ

• ETLを回して、必要なデータを生成– 集計済データ、クエリ最適化データ等

• 計算処理は必要に応じてEMRクラスタを複数利用– コンピュートとストレージの分離

– いつでもエンジン切替、バージョンアップ等が可能

51

リアルタイム分析

52

Lambda Architecture

Amazon Kinesis

Amazon EMR

+

Amazon S3

http://lambda-architecture.net/

53

【事例】データ分析で作る新しい価値

The Life of a ClickHow Hearst Publishing Manages Clickstream AnalyticsRick McFarland April 2016

The Evolution of“Chasing the Customer”

PastNear Past

Now!

Survey Websites Every Electronic Device

100–1000 Responses 1 MM–1 BN Trillions

1 Week Daily Seconds

Survey Data Clickstream Data “Lifestream” Data

Collection

Volume

Speed

Description “Thoughtstream” Data?

When will it stop?

Nanobots?

Won’t matter!

Future?

Hearst Data Services in Action

Product initiative led by all editors at Hearst

Buzzing@Hearst

バズりによるビジネス価値

• 我々の読者からの記事に対する素早いフィードバック

• メディアを超えて、人気の記事を定期的に再配信する(例えばトレンドになっている新聞記事は雑誌にも取り上げられる)

• 記事を書く編集者に、我々の読者により関係のある情報や、どのチャネルがより我々の読者に記事を読んでもらえるかという情報を与える

• 究極的には、定期的な価値を生み出す

• ページビューが25%上がれば、定期的な価値につながる訪問者が15%増加する

• スループット目標: 250以上の世界中のHearst所有メディアからデータを送る

• レイテンシ目標: クリックからツールへの反映が5分以下

• 変更速度: クリックストリームへ簡単に新しいデータフィールドを追加できる

• データサイエンスチームが定義する特有のメトリクス(例えば標準偏差や回帰)の要求

• データレポートは1時間分から1週間分までの期間が選べる

• フロントエンドはゼロから開発されるので、APIを通して開発チームの特有の要求に応じてデータが提供される

そして最も大事なことは、既存サイトの運用に影響があってはいけない！

バズりのためのエンジニアリングの必要条件は…

初期に作ったものHearst全体の静的なClickstream

Hearst所有サイトのユーザ

会社のデータセンタ

Netezzaデータウェアハウス

Clickstream 1日1回

約30 GB/日の基本的なweb logデータ

(例: リファラ, URL, ユーザエージェント,

クッキー, 等)

アドホックなSQLベースの

レポーティングと分析

Clickstreamデータの取り込み

Amazon Kinesis

Node.JS App-Proxy

Kinesis S3 App –KCL Libraries

Users to Hearst

Properties

Clickstream

“Raw JSON”

Raw Data

Tip全サイトにJavaScriptをデプロイするためにTag managerを利用する

Phase

1

Phase

2a データ処理 1.0

ETL on Amazon EMR

Clean Aggregate DataRaw Data

“Raw JSON”

母国語内部的にHadoopが処理基盤として選ばれたが、その理由はAmazon EMRでの作成が簡単だったのと、Pigの書き方を知っていたから。

50以上のUDFがPythonで書かれているが、それは我々がPythonを知っていたから。

Phase

2b データ処理 2.0: Spark Streaming

Amazon Kinesis

Node.JS App-Proxy

Users to Hearst Properties

Clickstream

ETL on EMR

Clean Aggregate Data

コスト削減のためにSpotインスタンスを利用

Reminders

達成Apache Sparkで実装することでHearstのデータチームがScalaを学べた

Phase

3a データサイエンスを本物に

Data Science on EC2Amazon Kinesis ETL on EMR

Clean Aggregate Data API-Ready Data

SAS on Amazon EC2を選択データ編集と、回帰の様な複雑なデータサイエンス

テクニックの両方を使える様に

この方式でデータサイエンスを行うと、完了までに3-5分かかる

Phase

3b データサイエンス: 開発と本番

Amazon Kinesis

Data Science“Production”

Amazon Redshift

ETL on EMR

Data Science “Development”

on EC2

Run Once per Day

Models

Agg Data

Clean Aggregate Data API-Ready Data

Statistical Models

Tip

データサイエンスモデルをS3に保存し、それらをAmazon Redshiftに適応

データサイエンス分割モデリングと本番を分割し本番はAmazon Redshiftへ

データサイエンスの処理時間は100秒に短縮!

Buzzing API

APIReadyData

Amazon KinesisStreams

Node.JS App-Proxy

Clickstream

Data ScienceApplication

Amazon Redshift

ETL on EMR

Users to Hearst Properties

最終的なHearst Data Pipeline

LATENCY

THROUGHPUT

Milliseconds 30 Seconds 100 Seconds 5 Seconds

100 GB/Day 5 GB/Day 1 GB/Day 1 GB/Day

Agg Data Models

Firehose

S3

我々の学びのまとめ

Yesterday

Today

Tomorrow

Amazon Kinesis

Amazon Kinesis

Amazon Kinesis

S3 EMR-Pig

Spark-Scala

PySpark + SparkR

Amazon Redshift

EC2-SASS3

S3

S3EMR to

Amazon ES

Amazon ES

Amazon ES

1 hr

< 5 min

< 2 min

Transport Storage ETL Storage Analysis Storage Exposure Latency

Clickstreamsはビジネスにおける新しい"データの通貨"

少ない力でより多くのことが本当にできる

大きなチームは不要:

2-3人のフルタイムエンジニアのチーム

で達成できる

…もしくはめったにみつからない貴重な人材1人で

68

参考情報

69

AWS Big Data Blog

• https://blogs.aws.amazon.com/bigdata/– 最新の事例、アーキテクチャ、サービス、ソリューションが毎週投稿される

• 最新投稿例– Real-time Stream Processing Using Apache Spark Streaming and Apache

Kafka on AWS– Amazon EMR-DynamoDB Connector Repository on AWSLabs GitHub– Encrypt Data At-Rest and In-Flight on Amazon EMR with Security

Configurations– Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics– Writing SQL on Streaming Data with Amazon Kinesis Analytics – Part 2– Integrating IoT Events into Your Analytic Platform– Processing VPC Flow Logs with Amazon EMR

70

日本からの投稿例: SmartNews

https://blogs.aws.amazon.com/bigdata/post

/Tx2V1BSKGITCMTU/How-SmartNews-

Built-a-Lambda-Architecture-on-AWS-to-

Analyze-Customer-Behavior-an

71

まとめ

72

Summary

• Amazon S3でデータレイク

• Amazon EMRでコンピュートとストレージ分離

• 新たなビジネス価値の創出を加速可能

73