Modernizing Big Data Workload Using Amazon EMR & AWS Glue

© 2020, Amazon Web Services, Inc. or its Affiliates.
Noritaka Sekiyama
Big Data Architect, AWS Glue & Lake Formation
2020/3/5
Modernizing Big Data Workload
Using Amazon EMR & AWS Glue

⾃⼰紹介
関⼭宜孝
Big Data Architect
AWS Glue & Lake Formation
• 5年間 AWS サポートにて技術⽀援を担当
• 2019年からプロダクト開発チームにジョイン
• GlueとLake Formationに関する
ユーザーに近い部分の開発を担当
@moomindani moomindaniNoritakaS-AWS
Forum

アジェンダ
• バッチジョブのモダン化
• 伝統的なバッチジョブの課題
• AWS における Hadoop/Spark ジョブの考え⽅
• EMR によるバッチジョブのモダン化
• Glue によるバッチジョブのモダン化
• ストリーミング処理の進化
• ストリーム処理のユースケース
• EMR におけるストリーム処理
• Glue におけるストリーム処理
• デモ (Spark, Hudi, EMR, Glue Data Catalog)

データの収集・活⽤とデータレイク
OLTP ERP CRM LOB
データウェアハウス
ビジネス
インテリジェンス
データレイク
10011000010010101
11001010101110010
10100001011111011
010
00111100101100101
10
0100011000010
デバイス Web センサー SNS
カタログ
機械学習
アドホック
クエリ
ビッグデータ
処理
インタラク
ティブ
リアルタイム

バッチ処理とストリーミング処理
バッチ処理バッチ処理
ストリーム処理
バッチ処理
収集変換分析
収集変換分析
保存

Batch Job Modernization
バッチジョブのモダン化

伝統的なバッチジョブの課題
• HDFS ストレージのメンテンスの課題
• Hadoop のバージョンアップに追従できない
• ディスクの追加・交換に時間がかかる
• 古い Pig/Hive/MR ジョブのメンテナンスと移⾏の課題
• パフォーマンス不⾜
メンテできず塩漬け
された古のHadoop
HDFS
App

AWS における Hadoop/Spark ジョブの考え⽅
• ⼊⼒も出⼒もストレージには Amazon S3 を活⽤する
• ジョブに使⽤するクラスタには状態やデータを持たせない
• ノード数・スペックを固定せず、実⾏時間の要件を優先する
⼀時的に
起動した
クラスタ
S3
HDFS
App

⼊⼒も出⼒もストレージには Amazon S3 を活⽤する
• 空き容量管理とメンテナンスからの解放
• HDFS の空き容量が不⾜した場合、従来はノードやディスクの追加が
必要だった
• S3 はマネージドサービスのため、これらのメンテナンス作業が不要
• 耐障害性、可⽤性を向上しつつ、ストレージコストを削減
• HDFS は⼀時ストレージとして併⽤可能
• Spark/Hive/DistCp 等により HDFS・S3 間でデータを移動

参考: HDFS が適したワークロード・データ
• 極めて⾼い I/O パフォーマンスが必要な場合
• データのアクセス頻度が⾼い場合
• ⼀時データを配置する場合
• ⾼い整合性が必要な場合
• S3 の結果整合性が許容できず、いずれの対処⽅法*も許容できない場合
• データ保管と I/O のコストを固定したい場合
• ノード間のネットワーク帯域が1G以下の場合
• この程度のネットワーク帯域の場合、ネットワークがボトルネックにな
りやすいため、HDFS によるデータローカリティが効く
• データ配置先の機器の物理的な配置をコントロールしたい場合
*EMRでの結果整合性の影響への緩和⽅法はこちら︓https://www.slideshare.net/ssuserca76a5/hcj2019-Hadoop-sparks3/25

参考: S3 が適したワークロード・データ (1/2)
• 極めて⾼い可⽤性・耐障害性が必要な場合
• 耐障害性︓ 99.999999999%
• 可⽤性︓99.99%
• アクセス頻度の低いコールドデータを⻑期間保存する場合
• “S3 標準” 以外に、”標準 –IA” 等の安価なストレージクラスも利⽤可能
• データサイズに対するコストを抑えたい場合
• 同じサイズの HDFS に⽐べてサイズ単価のコストが⼩さい
（外部の試算では 1/5 以下)
• データサイズが巨⼤または⼤きく増え続ける場合
• ストレージ容量の限界がないため、空き容量等の管理が不要

参考: S3 が適したワークロード・データ (2/2)
• コンピューティング⽤クラスタとストレージを分離したい場合
• 処理が終わったクラスタを廃棄してもデータは S3 上に残る
• 複数のクラスタ/アプリケーションから共⽤したい場合
• 複数の Hadoop/Spark クラスタから同⼀のファイルシステムを使⽤
• EMR, Glue, Athena, Redshift Spectrum, Hadoop/Spark on EC2 等
• (Hadoop の仕組み以外を含めて) セキュリティを⼀元管理したい場合
• IAM, S3 バケットポリシー, S3 Access points, VPC Endpoint, Glue
Data Catalog, Lake Formation 等

ジョブに使⽤するクラスタには状態やデータを持たせない
• パフォーマンス向上をしつつ、コストを削減
• 必要なときに必要なサイズのクラスタを起動して処理する
• 処理が終わったらクラスタをすぐ消す
• バージョンアップ・メンテナンスからの解放
• 既存のクラスタをバージョンアップするのは⼤変
• 既存のクラスタを削除して、新しいバージョンの新規クラスタを起動
するのは⾮常にスムーズ

ノード数・スペックを固定せず、実⾏時間の要件を優先する
• クラウドではノード数・スペックを固定する必要がない
• これらを固定してクラスタを利⽤するのはオンプレミスの考え
• クラウドでは、必要に応じてノード数・スペックを調整するべき
• バッチ処理の SLA は多くの場合、完了予定⽇時に間に合うかどうか
• 処理に時間がかかってこの完了予定⽇時を過ぎた場合、後続のクエリ
やレポーティング等のビジネスに影響を与えてしまう
• 優先すべきは（ノード数固定ではなく）実⾏時間
• 実⾏時間に対する課⾦＝⾼速に処理すれば安くなる
• 仮にノードを増やしても、処理がその分早く終わればコストは同じか、
さらに安くなる可能性すらある

Amazon EMR
簡単に利⽤可能
クラスタを数分で起動
低コスト
秒単位の課⾦
多様な OSS に対応
新しいバージョンに積極的に対応
マネージドフレームワーク
監視や管理が簡単
セキュア
設定を有効化するだけ
フレキシブル
設定を柔軟にコントロール

Amazon EMR
• 20 の OSS プロジェクト
• Apache Hadoop
• Hive
• Spark
• HBase
• Presto
• TensorFlow
etc.

EMR 上でバッチジョブを実⾏する⽅法
• アプリケーション固有のインタフェース
• Hadoop クライアント
• HiveServer2
• spark-submit
• Livy, etc.
• EMR Step API
• EMR コンソール
• AWS CLI / SDK
• AWS サービス
• Step Functions

EMR によるバッチジョブのモダン化
• スポットインスタンスによるコスト最適化
• EMR Spark ランタイム
• EMR Step の並列実⾏
• Step Functions によるワークフロー管理
• マネージドリサイズ (プライベートベータ)

スポットインスタンスによるコスト最適化
10 ノードクラスタ
実⾏時間: 14 時間
Cost = 1.0 * 10 * 14 = $140

スポットインスタンスを
10ノード追加

20 ノードクラスタ
実⾏時間: 7 時間
Cost = 1.0 * 10 * 7 = $70
= 0.5 * 10 * 7 = $35
Total $105

結果
実⾏時間 50 %削減
( 14時間 à 7時間)
コスト 25% 削減
($140 à $105)

停⽌が許容できない
ノードにオンデマンド
コスト削減に
スポットインスタンス

停⽌が許容できない
ノードにオンデマンド
コスト削減に
スポットインスタンス
Savings Plan により
最⼤ 60%のコスト削減

EMR Spark ランタイム
• Sparkに最適化したランタイム
• ⾼いパフォーマンス
• 導⼊前のEMRより2.6 倍⾼速
• 3rdパーティマネージドSpark
より1.6倍⾼速
• 低コスト
• 3rdパーティマネージドSpark
より1/10のコスト
*TPC-DS 3TB ベンチマーク結果
( 6ノード, c4.8xlarge クラスタ, EMR 5.28, Spark 2.4
10,164
16,478
26,478
0 5,000 10,000 15,000 20,000 25,000 30,000
Spark with EMR (with
runtime)
3rd party Managed Spark
(with their runtime)
Spark with EMR (without
runtime)
104クエリの合計実⾏時間 (秒)

EMR のバージョンを上げるだけで⾼速化・コスト削減
427.68
113.13
169.41
46.28
0.00
50.00
100.00
150.00
200.00
250.00
300.00
350.00
400.00
450.00
Runtime for 102 TPC-DS queries Geomean for 104 TPC-DS queries
合計実⾏時間 (分)
EMR 5.16 with Spark 2.4 EMR 5.28 with Spark 2.4
2.5x
2.4x

⻑時間クエリで平均約5倍の⾼速化
.5X
5.5X
10.5X
15.5X
20.5X
25.5X
30.5X
35.5X
q72
q25
q17
q80
q98
q15
q54
q6
q29
q40
q13
q9
q49
q24b
q24a
q11
q85
q74
q78
q16
q23a
q4
q94
q64
q23b
q14a
q75
q14b
q5
q95
q28
q97
q50
q93
q67
Speedup
Query number

短時間クエリで平均約2倍の⾼速化
1X
2X
3X
4X
5X
6X
7X q2
q38
q87
q88
q59
q76
q84
q65
q58
q99
q51
q81
q96
q35
q62
q1
q57
q44
q30
q83
q39a
q39b
q47
q66
q90
q8
q22
q10
q69
q86
q77
q21
q43
q70
q26
q18
q89
q91
q34
q53
q46
q31
q63
q3
q79
q73
q36
q7
q60
q48
q92
q27
q19
q33
q56
q71
q32
q68
q52
q55
q42
q61
q12
q45
q20
Relativespeedup(RuntimeinEMR5.16comparedtoRuntimeinEMR5.28)
Query number

ジョブ開始時間 - Executor 割り当ての最適化
0.9x
1.0x
1.1x
1.2x
1.3x
1.4x
1.5x
0 200 400 600 800 1000 1200 1400
Job Runtime (Seconds)

プラン/最適化 – 動的パーティションプルーニング
1x
2x
4x
8x
TPC-DS Queries

クエリ実⾏ – データプリフェッチ
0%
5%
10%
15%
20%
25%
TPC-DS Queries

EMR Spark ランタイムにおける最適化
• コンフィグ
• CPU/ディスク、Driver/Executor 設定、Java ヒープ/GC、ネイティ
ブオーバーヘッド、インスタンスデフォルト
• プラン/最適化
• パーティションプルーニング、JOIN順の⼊れ替え等
• クエリ実⾏
• データのプリフェッチ
• ジョブ開始
• Executor の割り当ての最適化

EMR Step の並列実⾏
• これまで
• すべての Step は直列実⾏
• 前の Step が終わらないと次の Step は開始されない
• 現在
• Step を並列実⾏可能に
• スケジューリングは YARN にまかせる

Step Functions によるワークフロー管理
コンソールによ
る可視化
JSON または
Python で定義
実⾏の監視

Step Functions によるオートメーション
1. クラスタの作成・スケー
ル・変更
2. ステップの追加、キャン
セル、並列実⾏
3. 同期・⾮同期ステップ
4. 例外/失敗のハンドル
5. クラスタのスケールアウ
ト/スケールイン
6. クラスタの再利⽤
7. クラスタの削除

マネージドリサイズ（プライベートベータ）
• ⾃動的にクラスタをリサイズする完全マネージドな仕組み
• 設定不要（最⼩と最⼤を決めるだけ）
• 素早いリサイズ
• ワークロードによって20-60%程度のコストを削減
• Auto Scaling との違い
• Auto Scaling: カスタムメトリクスにもとづいた DIY Scaling
• マネージドリサイズ: 完全マネージドなオプション

AWS Glue
様々なデータソースのメタデータを収集・活⽤した、
フルマネージドでサーバーレスな分散処理サービス

AWS Glue の特徴
AWS Glue
サーバーレス柔軟な起動⽅法
コードに集中
データソースの
メタデータ管理
VPC内からのアクセス
他のAWSサービスと
容易に連携
Notebookでの開発セキュア

Glue によるバッチジョブのモダン化
• ランタイム: Spark ジョブと Python Shell ジョブ
• ETL に適したスキーマ・オン・ザ・フライ
• 多数のスモールファイルによる影響の緩和
• 繰り返しのジョブ実⾏を⽀えるジョブブックマーク

ランタイム: Spark ジョブと Python Shell ジョブ
AWS Glue
Python Shell
AWS Glue
Apache Spark
• 実⾏時間の制限なし
• 並列分散処理が得意
• Glue ETL関数群を利⽤可能
• 主なユースケース
• ⼤量データのETL・分析
• 実⾏時間の制限なし
• Lambdaに⽐べてメモリ量が多い
• 1GBまたは16GB
• Pandas等のライブラリが利⽤可能
• 主なユースケース
• ⼩中規模データのETL
• RedshiftやEMR、Athenaに対するSQL
ベースの分析
⼩・中規模処理
クエリ実⾏
⼤規模処理

Apache Spark で ETL する際によくある課題
DataFrame
データをテーブル構造で扱うための Spark のデータ構造
データをロードする前にスキーマを指定する必要がある
Col_a Col_b Col_c
1
2
3
・・・
・・・
1,000,000
“1000001”
“1000002”
bigint(数値型)
string(⽂字列)
同⼀カラムに異なる型が混在
DataFrame のスキーマ推定は限定的で、推定した型が適していない場合がある
実世界の煩雑なデータの ETL には、スキーマの不⼀致を細かく制御する必要がある

DynamicFrame とは
• Spark DataFrame と似た Glue 特有のデータ表現
• Spark で ETL する際によくある課題を解決するために設計
• DataFrame と DynamicFrame 間で相互に変換可能
• データをロード時する際にスキーマ定義が不要
• ”Schema on the Fly” を採⽤
• 複数の型の可能性を残して、後から選択可能(Choice型)

Spark DataFrame と Glue DynamicFrame の違い
• Spark DataFrame
• SparkSQL のコアデータ構造
• 構造化テーブルのために設計
• 事前にスキーマ定義が必要
• 各⾏は同⼀の構造
• SQL による分析に最適
• Glue DynamicFrame
• DataFrame に似たデータ構造
• 半構造化データのために設計
• 事前のスキーマ定義が不要
• 例: JSON, Avro, Apache logs
• ETL 処理に最適

Choice 型
• DynamicFrame の列に複数の型を発⾒した場合は Choice 型となる
struct
root
|-- uuid: string
|
|-- device id: choice
| |-- long
| |-- string
project
(型を廃棄する)
cast
(単⼀の型にキャストする)
make_cols
(すべての型を別の列に保持する)
deviceid: choice型
long string long long long stringlong
deviceid deviceid deviceid deviceid_long deviceid_string
long
deviceid
make_struct
(struct型にする)
string
long と string の両⽅のデータ型を持つ
例: 数値の 1234 と⽂字列の ”1234” が同じカラムに存在

多数のスモールファイルによる影響の緩和
• DynamicFrame によるファイルのグルーピング
• Spark Driver によるファイルのリスティングの最適化

繰り返しのジョブ実⾏を⽀えるジョブブックマーク
• ブックマーク機能
• ジョブの実⾏状態を保持
• Timestamp を⾒て処理済みデータを再度処理しないように回避
• 処理結果のデータをターゲットに重複出⼒しないように回避
• 定常的にETL処理が必要な場合において有効
s3://path_to_prefix/
|-- file 1 (updated: 2020/03/05 15:00)
|-- file 2 (updated: 2020/03/05 10:00)
|-- file 3 (updated: 2020/03/05 13:00)
s3://path_to_prefix/
|-- file 1 (updated: 2020/03/05 15:00)
|-- file 2 (updated: 2020/03/05 10:00)
|-- file 3 (updated: 2020/03/05 13:00)
|-- file 4 (updated: 2020/03/05 14:30)
実⾏ (2020/03/05 14:00) 実⾏ (2020/03/05 15:00)
new
□
□
□
☑
☑
☑
□

Glue におけるバッチ処理へのアップデート
• Reduced start times for AWS Glue Spark jobs (Public Preview)

バッチジョブにおける EMR と Glue の使い分け
• ワークロード
• EMR: 汎⽤
• Glue: ETL に強い
• ランタイム
• EMR: MR/Hive/Spark/Presto..
• Glue: Spark only
• カスタマイズ性 vs メンテナンス性
• EMR: 柔軟にカスタマイズ可能
• Glue: マネージドサービスのためメンテナンス要らず

Stream Processing Evolution
ストリーミング処理の進化

ストリーム処理のユースケース
• ストリーミングデータ挿⼊
• 挿⼊、更新、削除のキャプチャ
• ストリーミング ETL
• リアルタイム分析

ストリーミングデータ挿⼊
• イベントストリームはあらゆるところに
• ⼤量の時系列データ
• 重複は分析を複雑化してしまう
• S3 への⾼速なデータ挿⼊が必要
• スキーマの管理、チェックポイント
• 書き込み vs 読み取りに最適化した
ストレージフォーマット
• バランスのとれたアプローチが重要
• ファイルサイズを管理
• データの到達時間と順序を保存
インプレッション
Apache Kafka
Amazon S3
フィールド型
event_id string
datestr string
time long

挿⼊、更新、削除のキャプチャ
• データベースに保管された⼤量のデータ
• ほとんど変更ストリームに流れる
• 変更ストリームをS3に反映
• バルクロードはスケールしない
• UPSERT が困難
• トランザクション性
• データの品質はシビアな懸念点
• データベースと近い保証が必要
INSERT,
UPDATE,
DELETE
キャプチャ
反映
Amazon S3
Data Lake
カラム型
userID int
country string
last_modified long
… …
ユーザー

Apache Hudi (incubating)
Queries
Hudi Spark
データソース

Apache Hudi for Amazon EMR
データプライバシー規約の準拠
リアルタイムストリームの読み取り、変更のキャプチャ
遅れて到着したデータの再評価
履歴の追跡とロールバック
Apache Hudi
オープンソースの、データレイクのためのビルディングブロック

Hudi の特徴
• UPSERT 対応
• ロールバック、セーブポイント
• スナップショットアイソレーション
• ファイルサイズとレイアウトの管理
• ⾏・カラムデータのコンパクション
• データリネージ
• Spark, Hive, Presto に対応

Glue におけるストリーム処理
• Streaming ETL (Public Preview)

Demo
Apache Spark, Apache Hudi, EMR,
Glue Data Catalog

関連スライド
https://www.slideshare.net/ssuserca76a5/hcj2019-hadoop-sparks3
https://www.slideshare.net/ssuserca76a5/effective-data-lakeshttps://www.slideshare.net/ssuserca76a5/running-apache-spark-on-aws

まとめ
• バッチジョブのモダン化
• 伝統的なバッチジョブの課題
• AWS における Hadoop/Spark ジョブの考え⽅
• EMR によるバッチジョブのモダン化
• Glue によるバッチジョブのモダン化
• ストリーミング処理の進化
• ストリーム処理のユースケース
• EMR におけるストリーム処理
• Glue におけるストリーム処理
• デモ (Spark, Hudi, EMR, Glue Data Catalog)

Q&A

Modernizing Big Data Workload Using Amazon EMR & AWS Glue

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Modernizing Big Data Workload Using Amazon EMR & AWS Glue

Similar a Modernizing Big Data Workload Using Amazon EMR & AWS Glue (20)

Más de Noritaka Sekiyama

Más de Noritaka Sekiyama (8)

Modernizing Big Data Workload Using Amazon EMR & AWS Glue