Amazon EMR

は、、Hive、Presto/、HBase などのオープンソースのビッグデータのフレームワークを、AWS 上で手早く動かすマネージドのサービスです。のクラスター、、の3つの動かし方があり、数 TB〜PB の変換やログの処理を、細かい調整をしながら実行できます。DEA では、ノードの種類と、EMR Serverless との選び分け、との使い分け、との選び分けが出題されます。

Point

EMR は以前 Elastic MapReduce と呼ばれていました。MapReduce は分散処理の古典的な方式です。
HDFS = Hadoop Distributed File System は、クラスターのノードのディスクにデータを分散して置くファイルシステムです。
EMRFS は、EMR から S3 を HDFS のように読み書きする仕組みです (s3:// で指定)。
和訳
- Ephemeral: 一時的な、はかない
- Weblio英和辞書「ephemeral」

概要

デプロイの方式	内容	向くケース
on	EC2 インスタンスのクラスターを作る。インスタンスの種類や設定を細かく選べる	長時間動く大規模な処理、細かい調整、HBase など特定のアプリケーション
EMR Serverless	や Hive のジョブを投げるだけで、サービスが必要な資源を用意して終われば解放する	クラスター管理をしたくない、ジョブ単位で使う
EMR on	既存の Amazon EKS クラスターの上で Spark のジョブを動かす	Kubernetes で他のアプリケーションと資源を共有したい

試験では、 (で運用最小) と EMR (オープンソースの幅広さと調整の自由度) のどちらを選ぶか、EMR ならどの方式とどのインスタンスの買い方にするかを判断します。

主要技術

①ノードの種類 (EMR on EC2) ⚠️ 頻出

ノード	役割		スポットの適否
プライマリノード	クラスターの管理、タスクの割り当て	—	向かない (落ちるとクラスターが止まる)
コアノード	タスクの実行と HDFS へのデータの保存	あり	慎重に (落ちると HDFS のデータを失うおそれ)
タスクノード	タスクの実行だけ	なし	向く (落ちてもデータを失わない)

プライマリノードを3台にする構成 (複数プライマリノード) にすると、プライマリノードの障害でクラスターが止まりにくくなります。

⚠️ 頻出: 「コストを下げるためにを使いたい。処理が中断してもデータを失いたくない」は、タスクノードをスポット、プライマリとコアを (またはリザーブド) にします。

②インスタンスグループとインスタンスフリート

方式	内容	向くケース
インスタンスグループ	ノードの種類ごとに1つのを指定する	単純な構成
インスタンスフリート	ノードの種類ごとに複数のインスタンスタイプと、とスポットの目標容量を指定する。割り当て戦略で、空いているスポットのプールから選ぶ	スポットの中断に強くしたい、容量を確保しやすくしたい

スポットの容量が足りないときにオンデマンドへ切り替える設定もでき、スポットを多用するクラスターではインスタンスフリートが向きます。

③スケーリングとクラスターのライフサイクル

機能	内容
マネージドスケーリング	負荷に合わせて、指定した最小・最大の範囲でノード数を自動調整する
一時的なクラスター (transient)	ジョブ (ステップ) を流し、終わったらクラスターを自動で終了する
長時間稼働のクラスター	対話的な分析や常時の処理のために動かし続ける
自動終了 (アイドルタイムアウト)	一定時間アイドルならクラスターを終了し、消し忘れの費用を防ぐ
ステップ	クラスターへ投入する作業の単位 ( のジョブ、Hive のスクリプト)。から .sync で完了を待てる

データをに置いておけば、クラスターを終了してもデータは残ります。処理のたびにクラスターを作って捨てる一時的なクラスターは、コストの点で有利です。

④HDFS と EMRFS (S3) ⚠️ 頻出

保管先	特徴	向くケース
(コアノードのや)	速いが、クラスターを終了すると消える	処理の途中の一時データ、繰り返し読む中間結果
()	クラスターと独立して残る。複数のクラスターや・と共有できる	入力と出力の永続的な保管

S3 は強い書き込み後の読み取り整合性を持つため、以前の EMRFS の整合性ビューは不要です。コアノードの EBS ボリュームは、HDFS や一時データのための容量として使います。

⚠️ 頻出: 「クラスターを終了してもデータを残し、他のサービスからも使いたい」は S3 (EMRFS) に置きます。HDFS はクラスターとともに消えます。

⑤アプリケーションとメタストア

アプリケーション	用途
	バッチの変換、、ストリーミング (Structured Streaming)
Apache Hive	(HiveQL) による大規模なバッチ処理
Presto /	対話的な SQL クエリ
Apache HBase	大規模なキーと値の低遅延アクセス
/ /	上のテーブルの更新・削除

テーブルの定義 (メタストア) は、 Data Catalog をとして使うと、クラスターを作り直しても定義が残り、やとも共有できます。既存の Hive メタストアを使い続けたい場合は、やの外部メタストアにします。

⑥EMR Serverless

項目	内容
アプリケーション	か Hive と、のリリースバージョンを指定して作る
ジョブの実行	ジョブを投げると、必要なワーカーを用意し、段階ごとに増減し、終われば解放する
事前初期化容量	ワーカーを温めておき、ジョブを数秒で開始する (対話的な処理や時間に厳しいジョブ)
上限	アプリケーションの最大容量を決めて、費用を抑える
自動の開始・停止	アイドルになるとアプリケーションを止め、費用を抑える

⑦大量のログの処理とコスト

数 TB のログを毎日処理するような用途では、次の組み合わせでコストを抑えます。

手段	効果
一時的なクラスター +	必要な時間だけ動かす
タスクノードにスポット、インスタンスフリート	計算の単価を下げる
Graviton (Arm) のインスタンス	価格性能比を上げる
マネージドスケーリング	ピーク以外の時間のノードを減らす
列指向の形式とパーティション	読み取り量を減らす
Serverless	クラスターの待機時間の費用をなくす

⑧Glue との選び分け ⚠️ 頻出

観点
運用	。クラスターの概念がない	ならクラスターを管理。Serverless なら管理不要
フレームワーク	(と Python shell)	Spark、Hive、Presto/、HBase、など
調整の自由度	ワーカーの種類と数が中心	、Spark の設定、ブートストラップアクションなど細かく
コストの工夫	Flex、オートスケーリング	スポット、リザーブド、Graviton、一時的なクラスター
向くケース	新規の、運用最小	既存の Hadoop/Spark の移行、非常に大規模、特殊なフレームワーク

試験対策

①判断マトリクス

問題文のキーワード	選ぶ構成
の Hadoop/ を最小の変更で移行	on
Spark のジョブを、クラスター管理なしで	EMR Serverless (または )
既存ので Spark を動かす	EMR on EKS
スポットでコスト削減、データを失わない	タスクノードをスポット
スポットの中断に強く、容量を確保しやすく	インスタンスフリート
ジョブのたびに作って終われば消す	一時的なクラスター +
消し忘れのクラスターの費用を防ぐ	自動終了 (アイドルタイムアウト)
クラスターを消してもテーブル定義を残す	Glue Data Catalog をに
対話的な	Presto/ (または )
ジョブを数秒で開始したい (Serverless)	事前初期化容量
プライマリノードの障害で止めたくない	複数プライマリノード

②よくある誤答

コアノードやプライマリノードをスポットにすること。中断でのデータやクラスター全体を失うおそれがあります。
永続的なデータを HDFS だけに置くこと。クラスターの終了で消えます。
新規の小さなに on を選ぶこと。運用負荷の点でや EMR Serverless が優れます。
の整合性ビューを今も必要と考えること。は強い整合性を持ちます。

概要