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

アマゾン ウェブ サービス ジャパン株式会社

ソリューションアーキテクト内海英一郎

2016 年 6 月 3 日

ビッグデータ 101

AWS で始めるビッグデータパイプラインの設計と実装

TwitterでAWS Summitに参加しよう!

公式アカウント@awscloud_jpをフォローしたお客様に

フリクションボールペンをプレゼント！

【配布場所】ロビーや展示会場のコンパニオンが配布中！お気軽にお声かけください。

AWS Black Belt Online Seminarのご案内

AWSJ の Tech メンバーがAWSに関する様々な事を日本語で紹介・解説する無料のオンラインセミナー

AWSについてもっと勉強したい方にオススメ！

AWS イベント 検索

うちうみえいいちろう

内海英一郎｜@eiichirouchiumi

アマゾンウェブサービスジャパン株式会社

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

❤ Amazon Kinesis

❤ Java

❤ LMAX Disruptor

多くのお客様が AWS 上でビッグデータを利活用

Te lecommun icat ions Hea l thcare

Hea l thcare

F inanc ia l C la imsAdver t i s i ng

Non-Pro f i t

Genomics

Educat ion

LABORATORY

Oi l & Gas Genomics Med ia &

Ente r ta inment

Med ia &

Ente r ta inment

R isk S imu la t ion

Risk Ana lys i s Med ia &

Ente r ta inment

Food

AdRoll – 50 ミリ秒以下のレスポンスで1 日 600 億のインプレッションを処理

us-west-2

ELB

ELB

Bidders

Ad Servers

us-east-1

Bidders

Ad Servers

eu-west-1

ap-southeast-1

ap-northeast-1

Kinesis

S3

60B

Events/Day

600k

Files/Day

SQS

SQS

SQS

SQS

Machine

Learning

Analytics

Dynamic

Creatives

Profiles

DynamoDB

us-west-2

DynamoDB

us-east-1

DynamoDB

eu-west-1

DynamoDB

ap-southeast-1

DynamoDB

ap-northeast-1

ELB

ELB

Bidders

Ad Servers

ELB

ELB

Bidders

Ad Servers

ELB

ELB

Bidders

Ad Servers

ELB

ELB

AWS Summit 2015 | San Francisco –Keynote with Andy Jassyhttps://youtu.be/JRODD1_jBww

FINRA – 5 ペタバイト超のストレージで1 日最大 750 億イベントを処理・分析

EMR is Ubiquitous in our architecture

Data Marts

(Amazon

Redshift)

Query Cluster

(EMR)

Query Cluster

(EMR)

Auto Scaled

EC2

Analytics

App

Normalization

ETL Clusters

(EMR)

Batch Analytic

Clusters

(EMR)

Adhoc Query

Cluster (EMR)

Auto Scaled

EC2

Analytics

App

Users Data

ProvidersAuto Scaled

EC2

Data

Ingestion

Services

Optimization

ETL Clusters

(EMR)

Shared Metastore

(RDS)

Query Optimized

(S3)

Auto Scaled EC2

Data

Catalog

& Lineage

Services

Reference Data

(RDS)

Shared Data Services

Auto Scaled

EC2

Cluster Mgt

& Workflow

Services

Source of

Truth (S3)

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

Rahul Pathak, AWS

Scott Donaldson, FINRA

Clayton Kovar, FINRA

October 2015

Amazon EMR Deep Dive

& Best Practices

BDT305

http://www.slideshare.net/AmazonWebServices/bdt305-amazon-emr-deep-dive-and-best-practices

Hearst – 250 以上のウェブサイトから1 日 100 GB のクリックストリームを収集

Buzzing API

APIReadyData

Amazon KinesisStreams

Node.JS App-Proxy

Clickstream

Data ScienceApplication

Amazon Redshift

ETL on EMR

Users to Hearst Properties

Final 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

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

Rick McFarland, Chief Data Scientist, Hearst Corporation

Adi Krishnan, Principal Product Manager, AWS

April 2016

Getting Started with

Amazon Kinesis

http://www.slideshare.net/AmazonWebServices/getting-started-with-amazon-kinesis

そのテクノロジーや開発方法論は日々複雑化・高度化している

Collect Store Analyze Consume

A

iOS Android

Web Apps

Logstash

Amazon RDS

Amazon DynamoDB

AmazonES

AmazonS3

ApacheKafka

AmazonGlacier

AmazonKinesis

AmazonDynamoDB

Amazon Redshift

Impala

Pig

Amazon ML

Streaming

AmazonKinesis

AWSLambda

Am

azon E

last

ic M

apR

educe

AmazonElastiCache

Sear

ch

S

QL N

oSQ

L C

ache

Str

eam

Pro

cess

ing

Bat

ch

Inte

ractive

Logg

ing

Str

eam

Sto

rage

IoT

Appl

icat

ions

File

Sto

rage

Anal

ysis

& V

isual

izat

ion

Hot

Cold

Warm

Hot

Slow

Hot

ML

Fast

Fast

Amazon

QuickSight

Transactional Data

File Data

Stream Data

Note

books

Predictions

Apps & APIs

Mobile

Apps

IDE

Search Data

ETL

Reference Architecture

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

Siva Raghupathy, Principal Solutions Architect, Amazon Web Services

October 2015

BDT310

Big Data Architectural

Patterns and Best Practices

on AWS

http://www.slideshare.net/AmazonWebServices/bdt310-big-data-architectural-patterns-and-best-practices-on-aws

本セッションのテーマ

アーキテクチャ全体のモデリング

AWS サービスを選択する際の着眼点

典型的なユースケースの実装方法

モデリング

最も抽象的な概念から始める

データの断片

価値を持った情報

データの断片を価値を持った情報に変えること問題領域

データを収集するステージ

収集

データソースへのインターフェースを提供

情報を提供するステージ

提供

情報利用者へのインターフェースを提供

データを保存するステージ

保存

繰り返し利用されるデータを蓄積・保持

収集したデータを処理するステージ

前処理

収集したデータを保存用に変換・登録

保存したデータを処理するステージ

後処理

保存したデータを提供用に変換・展開

ストリームデータの収集

収集｜ストリーム

ペイロードサイズが小さい

データの発生頻度が高い

ファイルデータの収集

収集｜ファイル

ペイロードサイズが大きい

データの発生頻度が低い

収集したデータのリアルタイム処理

前処理｜リアルタイム

データを収集した時点で処理

レイテンシー重視

収集したデータのバッチ処理

前処理｜バッチ

収集したデータをまとめて処理

スループット重視

関連データベースへの保存

保存｜関連データベース

ハードスキーマ

アクセスパターンの制約なし

NoSQL データベースへの保存

保存｜NoSQL データベース

ソフトスキーマ

アクセスパターンの制約なし

サーチエンジンへの保存

保存｜サーチエンジン

ソフトスキーマ

全文検索やスコアリング

データウェアハウスへの保存

保存｜データウェアハウス

ハードスキーマ

大容量データの複雑な問い合わせに最適化

ストリームストレージへの保存

保存｜ストリームストレージ

スキーマフリー

データの到着順に一定期間のウィンドウを保持

データレイクへの保存

保存｜データレイク

スキーマフリー

後から自由に処理

保存したデータの機械学習処理

後処理｜機械学習

保存したデータへのアルゴリズム適用

予測が主用途

保存したデータの問い合わせ処理

後処理｜問い合わせ

保存したデータの抽出・比較や並び替え

分析が主用途

可視化による情報の提供

提供｜可視化

人間向けのインターフェース

スプレッドシートやグラフ

API による情報の提供

提供｜API

コンピューター向けのインターフェース

HTTP 経由の JSON や XML

サービスの選択

サービスの選択における指針

機能的特性と性能的特性の両面から最適なサービスを見極めましょう

Right Tools for the Job

Managed Services First

インフラの運用を AWS に任せてアプリケーションの開発に集中しましょう

ストリームデータの収集に利用できるサービス

収集｜ストリーム

ペイロードサイズが小さい

データの発生頻度が高い

Amazon Kinesis Streams

Amazon Kinesis Firehose

ファイルデータの収集に利用できるサービス

収集｜ファイル

ペイロードサイズが大きい

データの発生頻度が低い

Amazon S3

AWS Import/Export Snowball

収集したデータのリアルタイム処理に利用できるサービス

AWS Lambda

Amazon EMR

前処理｜リアルタイム

データを収集した時点で処理

レイテンシー重視

収集したデータのリアルタイム処理に利用できるサービス

Amazon Kinesis Firehose

前処理｜リアルタイム

データを収集した時点で処理

レイテンシー重視

収集したデータのバッチ処理に利用できるサービス

Amazon EMR

AWS Data Pipeline

前処理｜バッチ

収集したデータをまとめて処理

スループット重視

関連データベースとして利用できるサービス

Amazon RDS

保存｜関連データベース

ハードスキーマ

アクセスパターンの制限なし

NoSQL データベースとして利用できるサービス

Amazon DynamoDB

Amazon Elasticsearch Service

保存｜NoSQL データベース

ソフトスキーマ

アクセスパターンの制限なし

サーチエンジンとして利用できるサービス

Amazon CloudSearch

Amazon Elasticsearch Service

保存｜サーチエンジン

ソフトスキーマ

全文検索やスコアリング

データウェアハウスとして利用できるサービス

Amazon Redshift

保存｜データウェアハウス

ハードスキーマ

大容量データの複雑な問い合わせに最適化

ストリームストレージとして利用できるサービス

Amazon Kinesis Streams

保存｜ストリームストレージ

スキーマフリー

データの到着順に一定期間のウィンドウを保持

データレイクとして利用できるサービス

Amazon S3

保存｜データレイク

スキーマフリー

後から自由に処理

保存したデータの機械学習処理に利用できるサービス

Amazon Machine Learning

Amazon EMR

後処理｜機械学習

保存したデータへのアルゴリズム適用

予測が主用途

保存したデータの問い合わせ処理に利用できるサービス

Amazon EMR

後処理｜問い合わせ

保存したデータの抽出・比較や並び替え

分析が主用途

Amazon QuickSight

保存したデータの問い合わせ処理に利用できるサービス

Amazon RDS

後処理｜問い合わせ

保存したデータの抽出・比較や並び替え

分析が主用途

Amazon DynamoDB

保存したデータの問い合わせ処理に利用できるサービス

Amazon Elasticsearch Service

後処理｜問い合わせ

保存したデータの抽出・比較や並び替え

分析が主用途

Amazon CloudSearch

保存したデータの問い合わせ処理に利用できるサービス

Amazon Redshift

後処理｜問い合わせ

保存したデータの抽出・比較や並び替え

分析が主用途

可視化による情報の提供に利用できるサービス

Amazon EMR

Amazon Elasticsearch Service

提供｜可視化

人間向けのインターフェース

スプレッドシートやグラフ

可視化による情報の提供に利用できるサービス

Amazon QuickSight

提供｜可視化

人間向けのインターフェース

スプレッドシートやグラフ

API による情報の提供に利用できるサービス

Amazon API Gateway

提供｜API

コンピューター向けのインターフェース

HTTP 経由の JSON や XML

AWS Lambda

実装例

ユースケース 1リアルタイムモニタリング

数千のセンサーが毎秒アップロードするデータをリアルタイムにダッシュボード上でモニタリングしたい。ただし、モニタリングの対象とするデータは特異値を含むものに限定する。データは JSON 形式で、特異値の判定ロジックは □□ だ。まずは、特異値を含むデータの発生件数がどのように推移しているのかだけでも時系列で把握できると助かるのだが。。。

ユースケース 1リアルタイムモニタリング

数千のセンサーが毎秒アップロードする JSON データ

リアルタイム

特異値の検出

ダッシュボードで件数を時系列にモニタリング

リアルタイムモニタリングのモデリング例

後処理｜問い合わせ

提供｜可視化

収集｜ストリーム

前処理｜リアルタイム

保存｜NoSQL データベース

リアルタイムモニタリングのサービス選択例

後処理｜問い合わせ

提供｜可視化

収集｜ストリーム

前処理｜リアルタイム

保存｜NoSQL データベース

Kinesis Streams

Lambda + Kinesis Firehose

ElasticsearchService

ElasticsearchService

ElasticsearchService

リアルタイムモニタリングの実装例

収集｜ストリーム

Kinesis Streams

センサーは SDK で Kinesis Streams に直接データを送信

リアルタイムモニタリングの実装例

前処理｜リアルタイム

Lambda + Kinesis Firehose

Kinesis Firehose に特異値を含んだレコードを再送信

Kinesis Firehose が Elasticsearchにデータをロード

Kinesis Streams に Lambda ファンクションを関連付け

Lambda ファンクション内で特異値を検出

リアルタイムモニタリングの実装例

保存｜NoSQL データベース

ElasticsearchService

Elasticsearch で時系列にデータをインデックス化

リアルタイムモニタリングの実装例

後処理｜問い合わせ

ElasticsearchService

Elasticsearch で問い合わせを処理し結果を返却

リアルタイムモニタリングの実装例

提供｜可視化

ElasticsearchService

Kibana で時系列に折れ線グラフを表示しデータを一定間隔で更新

ユースケース 2ログアナリティクス

データサイエンティストがアプリケーションのアクセスログを分析してみたいと言っている。ログファイルは日付が変わった後に前日分が送られてくるのだが、すぐに数百 TB 程度のストレージを消費するだろう。とりあえず、ワークベンチからアドホックなクエリーを実行してログに含まれる範囲の情報を確認できればいいらしい。急いで環境を用意してもらえないか？

ユースケース 2ログアナリティクス

日次でファイルを受信

数百 TB のストレージ

分析範囲はログに含まれる情報のみ

ワークベンチからアドホックにクエリーを実行

ログアナリティクスのモデリング例

後処理｜問い合わせ

提供｜可視化

収集｜ファイル

前処理｜バッチ

保存｜データレイク

ログアナリティクスのサービス選択例

後処理｜問い合わせ

提供｜可視化

収集｜ファイル

前処理｜バッチ

保存｜データレイク

S3

Data Pipeline + EMR

S3

EMR

EMR

ログアナリティクスの実装例

収集｜ファイル

S3

アプリケーションは定期的にCLI で S3 にログファイルを送信

ログアナリティクスの実装例

前処理｜バッチ

Data Pipeline + EMR

ロードしたログを ORC 形式でS3 上の Hive テーブルに再コピー

Data Pipeline からHiveActivity を起動

ログファイルをテキスト形式でHive テーブルへロード

ログアナリティクスの実装例

保存｜データレイク

S3

ORC 形式で S3 上のHive テーブルにログを保持

ログアナリティクスの実装例

EMR

HiveQL で S3 上のHive テーブルを問い合わせ

後処理｜問い合わせ

ログアナリティクスの実装例

提供｜可視化

EMR

Hue でスプレッドシート上にHiveQL 問い合わせの結果を表示

ユースケース 3ラムダアーキテクチャ

ウェブサーバー上のアクセスログからサイト訪問者のセグメントを特定したい。アクセスログは対象となるウェブサーバーから常時収集する。セグメントを更新するタイミングはリアルタイムと日次の 2 種類だ。リアルタイムでの更新時にはロジック □□ で高速に低精度の予測を行い、日次での更新時にはロジック □□で 1 日分のログ全体から時間をかけて高精度の予測を行う。予測したセグメント情報はユーザー単位に保存しておき、自社内にある様々なアプリケーションからいつでも利用できるようにしたい。よろしく頼んだよ。

ユースケース 3ラムダアーキテクチャ

ウェブサーバーのアクセスログを常時収集

リアルタイム更新と日次のバッチ更新

ユーザー単位にセグメント情報を保存

様々なアプリケーションからいつでも利用

ラムダアーキテクチャのモデリング例

後処理｜問い合わせ

提供｜API

収集｜ストリーム

保存｜NoSQL データベース

前処理｜リアルタイム + バッチ

ラムダアーキテクチャのサービス選択例

後処理｜問い合わせ

提供｜API

収集｜ストリーム

前処理｜リアルタイム + バッチ

保存｜NoSQL データベース

Kinesis Streams

Lambda + Data Pipeline + EMR

DynamoDB

DynamoDB

API Gateway + Lambda

ラムダアーキテクチャの実装例

収集｜ストリーム

Kinesis Streams

Kinesis エージェントから Kinesis Streams にログレコードを送信

ラムダアーキテクチャの実装例

Lambda前処理｜リアルタイム

DynamoDB のセグメント情報をアップデート

Kinesis Streams に Lambda ファンクションを関連付け

Lambda ファンクション内でセグメントを判定

ラムダアーキテクチャの実装例

Data Pipeline + EMR

前処理｜バッチ

HiveQL で Kinesis Streams を問い合わせてセグメントを判定

HiveQL で DynamoDB にセグメント情報をインポート

Kinesis Streams と DynamoDB にHive テーブルをマッピング

Data Pipeline からHiveActivity を起動

ラムダアーキテクチャの実装例

保存｜NoSQL データベース

DynamoDB

ユーザーの識別子をハッシュキーにしてセグメント情報を保持

ラムダアーキテクチャの実装例

後処理｜問い合わせ

DynamoDB

DynamoDB で問い合わせを処理し結果を返却

ラムダアーキテクチャの実装例

提供｜API

API Gateway + Lambda

DynamoDB の問い合わせ結果をJSON 文字列へ変換して返却

API Gateway でセグメント情報提供用の REST API を定義・公開

Lambda ファンクションで HTTP 要求を DynamoDB 呼び出しに変換

本セッションのふりかえり

アーキテクチャ全体のモデリング

AWS サービスを選択する際の着眼点

典型的なユースケースの実装方法

Thank You!AWS Big Data Blog｜http://blogs.aws.amazon.com/bigdata/