amazon s3を中心とするデータ分析のベストプラクティス
TRANSCRIPT
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