Help us understand the problem. What is going on with this article?

大規模データについて第3回~EMR開発_基礎編~

More than 5 years have passed since last update.

今回から開発編ということで、いままで開発で得た
EMR開発の実践的なところを紹介していきます!

開発編を1回で記事にしてしまうとボリュームが多すぎてしまうので、
基礎編、実装編 と分けることにしました。
早速ですが、 投稿スケジュールを以下に変更させていただきます;;

・11月上旬 ~EMR開発基礎編~
・11月下旬 ~EMR開発
実装編~
・12月上旬 ~EMR開発_運用編~
・12月下旬 〜Redshiftについて

今回は、基礎編と題しましてEMR開発における
土台 の部分について書きたいと思います。

はじめに

先ずは、EMRを動かすために必要なものを一通り

・AWSアカウント
・アカウントに紐づくアクセスキー/シークレットキー
・処理対象のデータ
・Hadoopを動かすためのMapReduceコード(Hive/Pigの場合は不要)
・CLIツール(Webコンソールでも代用可能)

以上です、簡単に始められますw

もっと詳しく知りたい方は、以下にAWSの説明ページがありますので参照ください。
http://docs.aws.amazon.com/ja_jp/ElasticMapReduce/latest/DeveloperGuide/emr-what-is-emr.html

本連載では実践的なトピックに焦点を絞るため、
一般的な説明は省略させていただきます。

データフロー

早速、EMR運用の現状を紹介いたします。
先ずは、大規模データ処理の詳細図(データフロー)を参照ください。

大規模データ処理_第3回_1.png

処理の流れ

 0.前処理(EMRをスムーズに実行させるため、直前or日次でインプットファイルを整形する)
 1.バッチサーバから引数を指定してEMR起動する
 2.EMR処理(リソース足りない場合は増強する)
 3.後処理(EMRアウトプットを出力要件に整形する)

処理詳細

EMR処理環境について

  • バッチサーバ(EC2)
    • Linux(CentOS)
    • CLI(シェルスクリプトからのEMR制御)

オンプレ同様のごく一般的なLinuxサーバです。
EMRが特定リージョンのVPC上で動くので、そこからアクセスできる設定にする必要があります。

EMRの起動オプションについて

  • subnet

    VPC配下のsubnetIDを指定。

  • region

    ap-northeast-1 (東京リージョン)

  • num-instances

    基本2を指定してマスタ、スレーブ1台づつ起動。
    足りない場合は後で、 spotインスタンス を追加します。

  • slave-instance-type
    Hadoopスレーブインスタンスのタイプを設定します。
    メインでMR処理を実行するサーバなので強めのインスタンスタイプを設定します。
    ここでのパフォーマンスは、 「弱いインスタンス多数」<「強いインスタンス少数」
    となるのでならべく強めのインスタンスを設定したほうが良いです。

  • master-instance-type

    Hadoopマスタインスタンスのタイプを設定します。
    それほどリソースを必要としません。 m1.medium で十分です。

  • hadoop-version

    Hadoopは日々進化しているので出来るだけ 最新版 を使いましょう。
     ...もちろん事前に動作確認を!

  • bootstrap-action
    マスタ、スレーブサーバの負荷状態を見るために ganglia が有用です。
    bootstrap-actionに以下を指定するだけで利用できます。
    新しくローンチした処理の効率はこれで見るようにしています。

    s3://elasticmapreduce/bootstrap-actions/install-ganglia

EMRのclusterタイプについて

  • カスタムJar
    選択肢として、Hive、ストリーム、HBase…等が用意されてますが、
    MapReduceの自由度から、我々がEMRで動かしているモジュールは
    全て カスタムJar になっています。
    オンプレHadoopの一部では開発の容易さをとってHiveを使っています。
    一般的には、以前AWSのセミナーで聞いたところでは、
    EMR利用の70%程度はHiveという話でした。

実行制御ツールについて

  • WebConsole
    AWS管理画面から遷移するwebページです。
    基本的に重く、使い勝手はそれほどよくないです。(悪口では無いです。)
    先日の改修で良くなったようですが...
    JobFlowのチェック(一覧で見る)には便利です。

  • CLI
    Linuxサーバ(バッチ)からEMRの制御に使います。詳細はコチラから
    EMRマニュアルではRuby版のインストール手順がありますが、上記のPython版の方が軽いです。

設計について

設計について、ポイント毎にまとめます。

大量データを処理する

  • データは圧縮する!

    s3費用、処理速度(EMR)にも影響が出ます。
    必ず圧縮しましょう!!

  • inputデータはあらかじめ データを切り分けておく

    読み込みデータ量削減のために集計単位のkeyごとにログをあらかじめ
    分割しておくとコストを圧縮出来ます。
    不必要なデータを取り込んだまま処理してしまうと無駄なmapタスクが起動してしまいます。

  • 小容量のinputファイルは、 S3distCp でまとめる。

    inputファイル1つに対して、最低でも1つ以上のMapタスクが立ち上がるので、
    inputが小容量ファイル多数となる処理は避けるべきです。
    S3DistCp についてはこちら。

  • EMR参照専用DBを作る。

    DB接続が必要な処理では、 EMR参照専用DBを用意した方がよいです。
    分散処理なのでEMRから同時多発的に参照が発生します。  

安定的なシステム運用のために

  • オペレーションコストを低く抑える
    大量データを扱うからこそ平常時はもちろん、リカバリ時も手間がかからないようにすることが大切です。
    不具合が起きたときのリカバリも必要最低限のオペレーションで出来るようにしておくのが理想です。

  • 前処理、後処理について
    必要ですが、EMRで処理できない(難しい)もののみ処理するべきです。
    分散処理ではないので、ここを作り込んでも本末転倒です。
    inputデータの分割、統合、outputデータのexcel化、outputデータ文字コード変換...

開発時に参照する情報

大規模データについてのリンク

「大規模データについていろいろやってみます!(第1回)」
「大規模データについて第2回~EMR(Hadoop)について、なぜEMRなのか〜」
「大規模データについて第3回~EMR開発_基礎編〜」
「大規模データについて第4回~EMR開発_実践編〜」
「大規模データについて第5回~EMR開発_運用編〜」
「大規模データについて第6回~Redshift編〜」

f81@github
Fringe81のエンジニアが頑張って執筆ちゅうです! Scala の修行を始めました。 みなさま、温かい目で見守ってください。
fringe81
Fringeは、最新のテクノロジーとプロフェッショナルによるサービスにより、社会課題に仮説を立てて市場に広げていくことで、数十年という長期的なスパンで価値を生み出し続け、より良い世界を創る集団です。 既存の領域に限らず、時流を読み、仮説を生み出し、テクノロジーの力で優れたサービスを生み出し続けます。
https://www.fringe81.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away