EMRでSparkをつかうときの注意点

業務の関係で、EMRで上にSparkを載せたシステム構築によくかかわっているので、

その中でつまったところなどについて記載してみました。

※本稿はHadoopやSparkに関する最低限の知識が必要です

１．EMRとは

まず、そもそもEMRについて簡単に説明すると、AWSのサービスでビッグデータ分析を簡単に実装することができるサービスのことです。

2019/09/01時点

■正式名称：ElasticMapReduce

■対応OSS：Hadoop, Spark, Hive, HBase, Phoenixなど

■AWS コンソール上でUIを使って簡単にクラスタ構成を作成できるサービス

　（クラスタ作成時に自動でVMが割り当てられる）

■最近Masterノードのマルチ構成にも対応した

■料金体系はEMR料金＋利用したVMの料金

　⇒　クラスタ作成時にVMが割り当てられるので使った分だけ支払うサービス

２．オンプレとEMRは何が違う？

Sparkに関する説明は省きます。また別の記事で説明するかもですが。。

では、SparkをオンプレからEMRに変更したときの注意点を記載していきます。

①HDFS上のデータが消えてしまう

オンプレと異なり、Sparkを利用した後EMRを削除すると、

利用していたVMがすべて消えてしまいます。

そのため、最終的なOutputデータはもちろん再利用したい中間データなども

VMのディスクではなくS3に格納する必要があります。

つまり、一度取り込めば使えるデータもクラスタ作成のたびに取り込む必要があります。

②IPアドレスが毎回異なる

EMRクラスタは毎回起動時にVMが割り当てられるため、

どのマシンにどんなIPアドレスが割り当てられるのかわかりません。

そのため、PhoenixテーブルなどMasterノードにSlaveがアクセスするときに

静的IPアドレスを利用してアクセスしにいくことができません。

③OSSのバージョンがEMRのバージョンに依存する

EMRバージョンによってSparkなどのバージョン決められています。

そのため、オンプレで利用しているSparkのバージョンと同じものが入っている

EMRのバージョンを指定する必要があります。

④追加のソフトウェアなどはブートストラップアクションでインストールする

EMRでSparkを利用してデータ分析を定期実行を実践する場合、datapipelineなどでEMRのステップ実行を利用することが多いです。

その際クラスタの作成からモジュール実行まで止まることなく進む必要があります。

そのため、VMに乗り込んで環境構築ができないため、

ブートストラップアクションで環境構築のスクリプトを準備します。

また、特に指定なき場合、ブートストラップアクションはすべてのVMで実行されます。

以上、オンプレからEMRに移行する際にひっかかりがちなところを記載してみました。

他にもいろいろあるので、適宜更新していきます。