Running Apache Spark on AWS

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Noritaka Sekiyama
2019.9.26
Running Apache Spark on AWS
db tech showcase Tokyo 2019

⾃⼰紹介
関⼭宜孝
Big Data Architect
AWS Glue and Lake Formation
• 約 5年間 AWS サポートにて技術⽀援を担当
• 2019.8 からプロダクトチームにジョイン
• AWS でデータレイクを構築するための
アーティファクトの実装や
アーキテクティングの⽀援を担当
@moomindani

本セッションの狙い
AWS クラウド上で Apache Spark を使いこなすための
便利機能、チューニング、実装と仕組み、
使い分けのベストプラクティスを学ぶ

本セッションで話さないこと
Apache Spark で Amazon S3 を使いこなす⽅法
https://www.slideshare.net/ssuserca76a5/hcj2019-hadoop-sparks3

アジェンダ
Spark on Amazon EMR
• マルチマスター構成での Spark 活⽤
• メモリ管理のベストプラクティス
• EMR における Spark の改善
Spark on AWS Glue
• Glue における Spark の拡張
• Spark ジョブのオーケストレーション

AWS 上で Apache Spark を利⽤する選択肢
Spark on Amazon EC2
Spark on Amazon EMR
Spark on AWS Glue
Amazon EC2 Amazon EMR AWS Glue

Spark on Amazon EMR

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

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

Spark on Amazon EMR
- マルチマスター構成での Spark 活⽤

マルチマスターがリリースされるまで
EMR の主な⽤途︓⼀時稼働クラスタ
• バッチジョブ等のために⼀時的に起動するクラスタ
• クラスタでの処理完了後、データを S3 に出⼒することを推奨
常時稼働クラスタとしての利⽤上の制約
• マスターノードに問題が発⽣するとクラスタ全体がダウン
アドホックなクエリやストリームデータ処理での利⽤に制限があった
マスターノード x 1
YARN Resource Manager
HDFS NameNode
コアノード x N
YARN Node Manager
HDFS DataNode
タスクノード x N
YARN Node Manager

EMR マルチマスター
マスターノードを複数台構成として、問題が発⽣すると
スタンバイノードにフェイルオーバーする構成
• マスターノードが SPOF でなくなり、⾼い可⽤性をもった
常時稼働クラスタとしての活⽤が可能に
• アドホッククエリ、ストリーム処理などにも利⽤可能
EMR クラスタを冗⻑構成で幅広いシーンに利⽤可能に
マスターノード x 3
HDFS NameNode
コアノード x N
YARN Node Manager
HDFS DataNode
タスクノード x N
YARN Node Manager

EMR マルチマスターの起動
マスターノードが 3台起動される

yarn コマンドでステータス確認
$ yarn rmadmin -getAllServiceState
ip-172-31-27-205.ec2.internal:8033 active
ip-172-31-25-209.ec2.internal:8033 standby
マスターノード #1
HDFS NameNode HDFS NameNode HDFS NameNode
Active Standby Standby

hdfs コマンドでステータス確認
$ hdfs haadmin -getAllServiceState
Active Standby

EMR マルチマスターのフェイルオーバー
実験
• spark-submit コマンドで円周率の計算ジョブを投⼊
• Active の YARN Resource Manager が稼働しているインス
タンスを Terminate

$ spark-submit --deploy-mode cluster --class org.apache.spark.examples.SparkPi
/usr/lib/spark/examples/jars/spark-examples.jar 1000000
…
19/09/11 07:41:24 INFO Client: Application report for
application_1568118970273_0006 (state: RUNNING)
Broadcast message from root@ip-172-31-27-205
(unknown) at 7:41 ...
The system is going down for halt NOW!
Broadcast message from root@ip-172-31-27-205
(unknown) at 7:41 ...
The system is going down for halt NOW!
Connection to ec2-3-92-144-27.compute-1.amazonaws.com closed by remote host.
Connection to ec2-3-92-144-27.compute-1.amazonaws.com closed.

19/09/11 07:43:51 INFO ipc.Client: Retrying connect to server: ip-172-31-27-
205.ec2.internal/172.31.27.205:8033. Already tried 0 time(s); retry policy is
RetryUpToMaximumCountWithFixedSleep(maxRetries=1, sleepTime=1000 MILLISECONDS)
19/09/11 07:43:51 WARN ipc.Client: Failed to connect to server: ip-172-31-27-
205.ec2.internal/172.31.27.205:8033: retries get failed due to exceeded maximum
allowed retries number: 1
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
...
at org.apache.hadoop.yarn.client.cli.RMAdminCLI.main(RMAdminCLI.java:1027)
ip-172-31-27-205.ec2.internal:8033 Failed to connect: Call From ip-
172-31-25-142/172.31.25.142 to ip-172-31-27-205.ec2.internal:8033 failed on connection
exception: java.net.ConnectException: Connection refused; For more details see:
http://wiki.apache.org/hadoop/ConnectionRefused

観察
• 新規のマスターノードが⾃動で起動

観察
• yarn コマンドでステータス確認
Standby Standby Active

観察
• yarn コマンドでアプリケーションのステータス確認
$ yarn application –list
Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):1
Application-Id Application-Name Application-Type User Queue State Final-State Progress
application_1568118970273_0006 SparkPi SPARK hadoop default RUNNING UNDEFINED 10%
66.ec2.internal:35817

Spark on Amazon EMR
- メモリ管理のベストプラクティス

メモリ関連のよくあるトラブル
Out of Memory Error, Java Heap Space
WARN TaskSetManager: Loss was due to
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError: Java heap space

Out of Memory Error, Exceeding Physical Memory
Error: ExecutorLostFailure Reason: Container killed by
YARN for exceeding limits. 12.4 GB of 12.3 GB physical
memory used. Consider boosting
spark.yarn.executor.memoryOverhead. Error:
ExecutorLostFailure Reason: Container killed by YARN
for exceeding limits. 4.5GB of 3GB physical memory
used limits. Consider boosting
spark.yarn.executor.memoryOverhead.

Out of Memory Error, Exceeding Virtual Memory
Container killed by YARN for exceeding memory limits.
1.1gb of 1.0gb virtual memory used. Killing container.

Out of Memory Error, Exceeding Executor Memory
Required executor memory (1024+384 MB) is above the
max threshold (896 MB) of this cluster! Please check
the values of 'yarn.scheduler.maximum-allocation-mb'
and/or 'yarn.nodemanager.resource.memory-mb

参考︓Apache Spark on EMR の仕組み
マスターノード
Name Node
Resource
Manager
Disk
コアノード
Data
Node
Node Manager
Disk
コアノード
Data
Node
Node Manager
Worker
Disk
コアノード
Data
Node
Node Manager
Spark
Driver
Disk
コアノード
Data
Node
Node Manager
Spark
Executor
Spark
Executor
Spark
Executor
Spark
Executor
Spark
Executor
Spark
Executor
Spark
Executor
EMR クラスタ
Spark
Client

メモリ関連のよくあるトラブルの原因
Spark Executor インスタンス・Executor のメモリ量、コア数や並列
度が、データの規模に対して適切でない
Spark Executor の物理メモリ量が YARN コンテナに割り当てられた
メモリ量を超えた
• 実⾏したクエリがメモリインテンシブな処理を含んでいて
Spark Executor メモリとメモリオーバーヘッドを⾜した値が不⼗分
⎼ 例︓キャッシング、シャッフリング、集約 (reduceByKey, groupBy)
• Spark Executor メモリとメモリオーバーヘッドを⾜した値が
yarn.scheduler.maximum-allocation-mb を超えた
Spark Executor インスタンス上で GC 等の処理を実⾏するためのメ
モリが利⽤可能でない

最適なインスタンスタイプとノード数の選択
インスタンスタイプ・ファミリ
• メモリインテンシブ︓R
• CPU インテンシブ︓C
• CPU/メモリバランス型︓M
インスタンス・ノード数
• ⼊⼒データセットのサイズ
• アプリケーションの実⾏時間や頻度の要件

Spark on YARN のメモリ構造

パラメータチューニング
Maximize Resource Allocation (EMR 固有オプション)
• Spark Executor で最⼤のコンピューティングとメモリリソースを
利⽤可能となるように計算
• 戦略︓インスタンスごとにひとつの Spark Executor を起動
パラメータ説明
spark.default.parallelism RDD のデフォルトパーティション数
(YARN コンテナで使⽤可能な CPU コア数の 2倍に⾃動設定)
spark.driver.memory Driver プロセスのメモリ量
spark.executor.memory Executor プロセスごとのメモリ量
spark.executor.cores 各 Executor が使⽤する CPU コア数
spark.executor.instances Executor 数
(spark.dynamicAllocation.enabled が
明⽰的に true に設定されていない限り⾃動設定)

ユースケース例
• ⼊⼒データセット︓ S3 上に配置された数千ファイル、計 200 TB
• EMR クラスタ︓
⎼ マスター︓r5.12xlarge
⎼ コア︓r5.12xlarge x 19ノード
※r5.12xlarge: 48 vCPU, 384GB RAM

パラメータ解説値
spark.executor.cores 経験則から 5 vcore を設定 5 vcore
spark.executor.memory [インスタンス毎の Executor 数]
([インスタンス毎の vcore 数] - 1)/ spark.executors.cores
= (48 - 1)/ 5 = 47 / 5 ≒ 9
[Executor 毎の合計メモリ量]
[インスタンス毎のメモリ量]/ [インスタンス毎の Executor 数]
= 383 / 9 ≒ 42
spark.executor.memory
= [Executor 毎の合計メモリ量] * 0.9 ≒ 37
37 GB
spark.yarn.executor.memoryOverhead [Executor 毎の合計メモリ量] * 0.1 ≒ 5 5 GB
spark.driver.memory spark.executor.memory を流⽤ 37 GB
spark.driver.cores spark.executor.cores を流⽤ 5 vcore
spark.executor.instances ([インスタンス毎の Executor 数] * [コアノード数]) -1(Driver)
= 9 * 19 -1 = 170
170
spark.default.parallelism spark.executor.instances * spark.executors.cores * 2
= 170 * 5 * 2 = 1700
1700

Spark on Amazon EMR
- EMR における Spark の改善

EMR における Spark の改善
2019.6.11 EMR 5.24.0 (Hadoop 2.8.5, Spark 2.4.2)
• Dynamic partition pruning
• Flatten scalar subqueries
• DISTINCT before INTERSECT
2019.7.17 EMR 5.25.0 (Hadoop 2.8.5, Spark 2.4.3)
• Bloom filter join
• Optimized join reorder
2019.8.8 EMR 5.26.0 (Hadoop 2.8.5, Spark 2.4.3)
2019.9.5 EMR 6.0.0 beta (Hadoop 3.1.0, Spark 2.4.3)
2019.9.23 EMR 5.27.0 (Hadoop 2.8.5, Spark 2.4.4)

Dynamic partition pruning
スキャン対象のパーティションを削減
• Spark SQL 実⾏時にパーティションを動的に選択して読み
込むことで、データの読み取り量を削減し、実⾏時間を短縮
• バニラ Spark 2.4.2 の元来の pushdown に加えて実装
• EMR 5.24 にて導⼊ (EMR 5.26 以降でデフォルト有効)
⎼ spark.sql.dynamicPartitionPruning.enabled

おさらい︓テーブルパーティション
Spark SQL は Hive のテーブル定義を使⽤する
Hive 形式でパーティショニングされた⼊⼒データを扱う場合、
クエリに必要なパーティションだけを読み込む
• 不要なパーティションをスキップしてデータスキャン量を削減
my-app-bucket/Sales/year=2010/month=2/day=1/iOS.csv
my-app-bucket/Sales/year=2010/month=2/day=1/Android.csv
...
SELECT avg(age) FROM t WHERE year=2019 AND month=9 AND day=26

Dynamic partition pruning
Spark 2.4.2 の pushdown
partition_col = 5
partition_col IN (1,3,5)
partition_col between 1 and 3
partition_col = 1 + 3
EMR 5.24 の pushdown
select ss.quarter, ss.region, ss.store, ss.total_sales
from store_sales ss, store_regions sr
where ss.region = sr.region
and sr.country = 'North America'

Flatten scalar subqueries
特定条件のサブクエリを含むクエリを効率化
• 同⼀のテーブルに対する Scalar サブクエリを含む Spark SQL
実⾏時に Optimizer が Scalar サブクエリをフラット化
⎼ spark.sql.optimizer.flattenScalarSubqueriesWithAggregates.enabled

Flatten scalar subqueries
Optimize 前のクエリ
select (select avg(age) from students /* Subquery 1 */
where age between 5 and 10) as group1,
(select avg(age) from students /* Subquery 2 */
where age between 10 and 15) as group2,
(select avg(age) from students /* Subquery 3 */
where age between 15 and 20) as group3
select c1 as group1, c2 as group2, c3 as group3
from (select avg (if(age between 5 and 10, age, null)) as c1,
avg (if(age between 10 and 15, age, null)) as c2,
avg (if(age between 15 and 20, age, null)) as c3 from students);
Optimize 後のクエリ

DISTINCT before INTERSECT
できるだけ Shuffle を回避
• INTERSECT を含む Spark SQL 実⾏時に INTERSECT のの⼦
要素に DISTINCT を追加
→Sort Merge Join を Broadcast Hash Join に変換
⎼ spark.sql.optimizer.distinctBeforeIntersect.enabled

参考︓Spark SQL における JOIN
Shuffle Hash Join
• Shuffle してからパーティションごとに JOIN
Sort Merge Join
• Shuffle してソートしてからパーティションごとに JOIN
• すべてのデータをあらかじめ読む必要をなくする
Broadcsat Hash Join
• JOIN 対象のテーブルに⼗分⼩さいテーブルがある場合、その
テーブルをすべての Executor ノードにブロードキャストする
• Broadcast したテーブルをパーティションごとに JOIN

(select item.brand brand from store_sales, item
where store_sales.item_id = item.item_id)
intersect
(select item.brand cs_brand from catalog_sales, item
where catalog_sales.item_id = item.item_id)
select distinct brand from
left semi join
on brand <=> cs_brand
• spark.sql.optimizer.distinctBeforeIntersect.enabled = false

intersect
select brand from
(select distinct item.brand brand from store_sales, item
left semi join
(select distinct item.brand cs_brand from catalog_sales, item
on brand <=> cs_brand
• spark.sql.optimizer.distinctBeforeIntersect.enabled = true

EMR ベンチマーク (5.24 vs 5.16)
TPC-DS 3TB
• マスター: 1 c4.8xlarge
• コア: 5 c4.8xlarge

EMR ベンチマーク (5.24 vs 5.16)

Bloom filter join
JOIN の前にフィルタリング
• Bloom filter を使って JOIN 対象の⼀⽅を事前フィルタリ
ングすることでクエリを⾼速化
⎼ spark.sql.bloomFilterJoin.enabled
Bloom filter
• 空間効率の⾼い確率的なデータ構造
• 要素が集合のメンバーであるかをチェックするのに使⽤

Bloom filter join
Bloom filter による効果が期待できるクエリ
select count(*)
from sales, item
where sales.item_id = item.id
and item.category in (1, 10, 16)

Optimized join reorder
テーブルの JOIN の順番を最適化
• Spark デフォルトでは左から右に並んでいるとおり JOIN
• この設定を有効化すると、⼩さい JOIN を先に実⾏して計算量の
⼤きい JOIN を後回しにするかたちで JOIN の順番を⼊れ替え
⎼ spark.sql.optimizer.sizeBasedJoinReorder.enabled

Optimize 前
1. store_sales (⼤) と store_returns (⼤) を JOIN
2. store を JOIN
3. items を JOIN
select ss.item_value, sr.return_date, s.name, i.desc,
from store_sales ss, store_returns sr, store s, item i
where ss.id = sr.id and ss.store_id = s.id
and ss.item_id = i.id and s.country = 'USA'

Optimize 後
1. store_sales (⼤) と store を JOIN
(store はフィルタをもち store_returns より⼩さいため)
2. store_returns (⼤) を JOIN
3. items を JOIN
select ss.item_value, sr.return_date, s.name, i.desc,
from store_sales ss, store_returns sr, store s, item i
where ss.id = sr.id and ss.store_id = s.id
and ss.item_id = i.id and s.country = 'USA'

Spark on AWS Glue

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

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

サーバーレス Apache Spark 実⾏環境
AWS Glue は
サーバーレス Apache Spark 実⾏環境
としても利⽤可能
x

Spark on AWS Glue
- Glue における Spark の拡張

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型)

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

struct
Choice 型
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 の列に複数の型を発⾒した場合は Choice 型となる

DynamicFrame の内部
レコードごとのスキーマ定義が可能、事前のスキーマ定義が不要
再構造化、タグ付け、変更が容易
場合によっては DataFrame Row よりコンパクト
単⼀パスで多数のフローを実⾏可能
{“id”:”2489”,
“type”: ”CreateEvent”,
”payload”: {“creator”:…}, …}
DynamicRecord
typeid typeid
DynamicFrame スキーマ
typeid
{“id”:4391,
“type”: “PullEvent”,
”payload”: {“assets”:…}, …}
typeid
{“id”:”6510”,
“type”: “PushEvent”,
”payload”: {“pusher”:…}, …}
id

Glue Parquet Writer
Glue 独⾃のカスタム Parquet
Writer による書き込み⾼速化
• 標準の Parquet Writer:
⎼ スキーマを設定 -> ⾏グループを
書き込む
• Glue Parquet Writer:
1. 列の書き込みを開始
(必要な場合フィールドを追加)
2. 最初の⾏グループを閉じ、ス
キーマを書き込む
⾏グループ 1
⾏グループ 2
列 1
列 2
列 1
列 2
…
…
⾏グループメタデータ
(スキーマを含む)

DynamicFrame のパフォーマンス
Parquet への変換
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Day Month Year
DynamicFrame DataFrame
Data size (# files)
24 744 8699
構成
• 10 DPU
• Apache Spark 2.2
ワークロード
• JSON から Parquet への変換
• DynamicFrame では Glue Parquet
Writer を使⽤
(Sec.)

継続的データ処理の効率化
ブックマーク機能
• ジョブの実⾏状態を保持
⎼ Timestamp を⾒て処理済みデータを再度処理しないように回避
⎼ 処理結果のデータをターゲットに重複出⼒しないように回避
• 定常的にETL処理が必要な場合において有効
S3 prefix
|-- file 1 (updated: 2019/09/25 15:00)
|-- file 2 (updated: 2019/09/26 10:00)
|-- file 3 (updated: 2019/09/26 13:00)
S3 prefix
|-- file 1 (updated: 2019/09/25 15:00)
|-- file 2 (updated: 2019/09/26 10:00)
|-- file 3 (updated: 2019/09/26 13:00)
|-- file 4 (updated: 2019/09/26 14:30)
Run (2019/09/26 14:00) Run (2019/09/26 15:00)
□
□
□
☑
☑
☑
□
new

多数のスモールファイルの取り扱い
DynamicFrame による
ファイルのグルーピング
Driver によるファイルの
リスティングの最適化

Glue におけるメモリチューニング
ジョブごとに Worker Type を設定
• DPU: ジョブ実⾏時に割り当てる処理能⼒
⎼ 1 DPU= 4 vCPU, 16GB RAM
Worker
Type
DPU数
/ノード
Executor数
/ノード
メモリ
/Executor
標準 1 2 5.5GB
G.1X 1 1 12GB
G.2X 2 1 24GB
標準
Executor
Mem:5.5GB
ノード
Executor
Mem:5.5GB
DPU
G.1X
ノード
DPU
G.2X
ノード
DPU
DPU
Executor
Mem:24GB
Executor
Mem:12GB

Glue Data Catalog を⽤いた Spark SQL 活⽤
Data Catalog: Hive 互換のマネージドメタストアサービス
Spark SQL で Jupyter Notebook から対話的に分析

Spark on AWS Glue
- Spark ジョブのオーケストレーション

Glue ワークフロー
ジョブ等の DAG を⽣成するオーケストレーション機能
• ワークフローの状況をモニタリングすることや、エラー時の
トラブルシューティングを視覚的に確認可能
クローラー、トリガー、ジョブを追加処理結果を確認可能
ワークフロー作成画⾯処理結果確認画⾯

Spark on EMR と Spark on Glue の使い分け
Spark on Amazon EMR
• 汎⽤ワークロード
• カスタマイズ可能な環境が必要な場合
• Spark 以外の分散処理エンジンを併⽤したい場合
• Spark (Structured) Streaming を使いたい場合
Spark on AWS Glue
• 汎⽤/ETL ワークロード
• サーバーレス/マネージド環境を希望する場合
• マネージドなワークフローを構築したい場合

Thank you!
右の QR コードから
本セッションのアンケートに
ご協⼒いただけますと⼤変幸いです

Running Apache Spark on AWS

More Related Content

What's hot

Similar to Running Apache Spark on AWS

More from Noritaka Sekiyama

Running Apache Spark on AWS