PowerPoint プレゼンテーション

© 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についてもっと勉強したい方にオススメ！

うちうみえいいちろう

内海英一郎｜@eiichirouchiumi

アマゾンウェブサービス

ジャパン株式会社

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

❤

Amazon Kinesis

❤

Java

❤

LMAX Disruptor

多くのお客様が AWS 上で

ビッグデータを利活用

T e l e c o m m u n i c a t i o n s H e a l t h c a r e H e a l t h c a r e F i n a n c i a l C l a i m s A d v e r t i s i n g N o n - P r o f i t G e n o m i c s E d u c a t i o n L A B O R A T O R Y O i l & G a s G e n o m i c s M e d i a & E n t e r t a i n m e n t M e d i a & E n t e r t a i n m e n t R i s k S i m u l a t i o n R i s k A n a l y s i s M e d i a & E n t e r t a i n m e n t F o o d

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 Jassy

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 Providers Auto 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/AmazonWe bServices/bdt305-amazon-emr-deep-dive-and-best-practices

Hearst – 250 以上のウェブサイトから

1 日 100 GB のクリックストリームを収集

Buzzing API API Ready Data Amazon Kinesis Streams Node.JS App-Proxy Clickstream Data Science Application 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/AmazonWe

そのテクノロジーや開発方法論は

日々複雑化・高度化している

Collect Store Analyze Consume

A iOS Android Web Apps Logstash Amazon RDS Amazon DynamoDB Amazon ES Amazon S3 Apache Kafka Amazon Glacier Amazon Kinesis Amazon DynamoDB Amazon Redshift Impala Pig Amazon ML Streaming Amazon Kinesis AWS Lambda A m az o n E las ti c M ap R ed uce Amazon ElastiCache S e ar ch S Q L N o S Q L C ache S tr eam P ro ces si ng B at ch In ter act iv e L o gg ing S tr eam S to rag e IoT A p pl icat io ns F ile S to rag e An alys is & V is ual iz at io n Hot Cold Warm Hot Slow Hot ML Fast Fast Amazon QuickSight Transactional Data File Data Stream Data N o teb o o ks Predictions

Apps & APIs

Mobile Apps ID E 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/AmazonWe

bServices/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

ストリームデータの収集に

利用できるサービス

収集｜ストリーム

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

データの発生頻度が高い

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 Elasticsearch Service Elasticsearch Service Elasticsearch Service

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

実装例

収集｜ ストリーム Kinesis Streams センサーは SDK で Kinesis Streams に直接データを送信

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

実装例

前処理｜

リアルタイム Lambda + Kinesis Firehose

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

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

Kinesis Streams に Lambda ファンクションを関連付け Lambda ファンクション内で 特異値を検出

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

実装例

保存｜NoSQL データベース Elasticsearch Service Elasticsearch で時系列にデータを インデックス化

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

実装例

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

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

実装例

提供｜ 可視化 Elasticsearch Service 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!