Hadoop1系の問題

唐突ですが、いきなりブログを始めます。
自分で調べたこと、感じたことを一つ一つ書きます。


最初の記事として、Hadoop1系(Apache Hadoop)の問題について少々書きます。
Apache Hadoopについては、http://hadoop.apache.org/ などご覧ください。

これまでのHadoop

俗に言うHadoop1系では、分散ファイルシステムであるHDFSと分散処理フレームワークMapReduceの
2つの構成要素でHadoopが構成されていました。特にMapReduceは、以下の要素があります。 * JobTracker : MapReduceジョブをタスク単位に分割、タスクを割り当てる、TaskTrackerを管理する * TaskTracker : mapタスクやreduceタスクを実行する、ハートビートをJobTrackerに送信する

TaskTrackerのmap処理を実行するmapスロットとreduce処理を実行するreduceスロットの2つのスロットを予め定義します。 MapReduceジョブは、map処理とreduce処理に分解され、設定されているスロットに割り当てて処理を実行していました。

Hadoop1系のMapReduceフレームワークの問題

この構成を数台程度の環境で利用する場合には全く問題にはなりませんが、一定数(4桁)以上のサーバでHadoopクラスタを運用する場合に色々と問題が見えてきました。

  • リソース管理とMapReduceジョブ管理をJobTrackerで扱うことによるオーバーヘッド

TaskTrackerからの定期的なハートビート通信(最短0.X秒間隔)の受信はもちろん、MapReduceジョブを実行する場合のタスク制御についてもJobTrackerは扱います。
加えて、多数のジョブを同時並行的に実行するとJobTrackerの処理が限界に達することになりました。

  • リソースを十分活用できない

TaskTrackerは事前にmapスロット数/reduceスロット数を定義してTaskTrackerを実行します。mapスロット数/reduceスロット数は利用者が直接設定します。 通常は、CPUのコア数に沿って設定し、複数ジョブを同時実行する場合にmapタスクとreduceタスクが同時に実行することを考慮するため、mapスロット数/reduceスロット数も余裕を持って設定します。
つまり、"mapスロット数 < CPUコア数"、"reduceスロット数 < CPUコア数" のような設定でしょうか。

このような場合、mapタスクしか実行しないケースでは、CPUのリソースを十分利用できないと言えます。
もちろんタスクに割り当てるメモリサイズもスロット数を意識しているため、メモリも十分利用できないでしょう。

その他にも、Apache Giraphはmapタスクのみで処理を実行する。OozieのPigジョブは、一度MapReduceジョブを実行してmapタスク内でPigスクリプトを実行する、といった特殊な実行が必要というようなことも問題としてあるようです(HadoopWorldの発表より)。

これらの問題を解決するために

性能面、機能面で見えてきた問題を解決する仕組みとして、YARNと呼ばれる仕組みが開発されてきました。
特にJobTrackerの持つリソース管理とジョブ管理の分離、スレーブサーバのリソースを活用する仕組み、汎用アプリケーションの実行といった点が新たなる仕組みです。

YARNについては次の記事で説明します。