Mapreduce2.0

次世代Hadoopの開発が進んでいる。現状の推移では、少なくとも分散クラウドでの「OSSインフラ」としてはHadoopが最有力候補であることは間違いない。クラウド上での分散処理基盤での技術競争ではGoogleやAmazonが相当抜きんでいる現在、それに対抗しうる可能性があるOSSはHadoopの潮流の延長線上にしか考えられない。その形としてHadoop-MapReduce2.0があるように見える。現在の状態で自分なりの次世代Hadoopの理解をまとめておく。基本的に全部は見切れていないので、そのあたりはあしからず。基本的に次世代Hadoopの仕組みは大きく二つの要素からなる

現在のところの柱はHDFSとMapreduce2.0の二つだ。

まずMapReduce。これは従来の「MapReduce」というものからはほど遠い。むしろ「任意」の分散処理実行フレームワークにたいして、適切なリソースを配分する包括的な仕組みという風に理解した方がよい。その中では今現在のMapReduceは、想定されている分散処理実行フレームワークの一つでしない。（一つでしかないが、後方互換性は最大限保証されるだろう。）現在のところは、MapReduce以外の実行フレームワークはBSPやMPIといったものが想定されている。ただし、後述するがおそらくこれに限定されるものではない。

このMpaReduce2.0は、まず、大きく二つの要素からなる。すなわち、リソース管理とアプリケーション管理になる。リソース管理は、分散環境上の様々なリソースを実行フレームワーク側が利用しやすいように一定の形に整えて、提供すると同時に、その維持管理を行う。また、アプリケーション管理は、指定されたアルゴリズムの実行フレームワークに対して、実際の投入されるアプリケーションのライフサイクル管理、もっと直裁的にいうと生死管理等を含むモニタリングを提供する。なお、ここでのアプリケーションは当面はjobまたは複数のjobからなるDAG（もはやDAGという言葉は一般的に使われている）を指すのだが、おそらく非同期処理を一般を指すことになるだろう。この二つの機能の組み合わせにより、分散処理が実行されるアーキテクチャになっている。従前のHadoopではJobTrackerとTaskTrackerの二つの機能で、MapReduceだけのサポートであったことを考えると、劇的な変化というよりもまったく別物とみる方が正しい。なお、JobTrackerとTaskTrackerという言葉完全に消えている。以下に詳細にみていく

1-1　リソース管理(Resource Manager)
分散処理基盤の様々なリソースを一定の単位にして管理し、適切なアプリケーション実行に必要な資源を提供する。主要な機能は、SchedulerとApplicationsManager（whitepaper上）の二つに集約されている。
まず、もって「基本単位」を見ていく。これは、container(resource container)というコンセプトでまとめられている。
http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-api/src/main/java/org/apache/hadoop/yarn/api/records/Container.java

まさに古くて新しい技術という印象。最近ではlxcというのも注目されていますが、要はリソース（CPU/メモリー/ディスクIO）をまとめてパーティショニングする仕組みですね。知っている人は、http://h50146.www5.hp.com/products/software/oe/hpux/component/vse/prm/といえば思い出す人もいるかと。

なお現状のv1.0ではメモリーのみの適用でどうみても今後に期待。
http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-api/src/main/java/org/apache/hadoop/yarn/api/records/Resource.java
containerというアナロジーで見ると、確実に「分散ノードを統合した仮想OS」という位置づけになりつつあることが容易に想定される。なお、containerから想像されるとおり、おそらく実行効率は相当高いはず。（というか高くすることを狙っていると思われる）

つぎに、Schedulerは、分散ノードからレポートされたcontainerを必要なアプリケーションの実行にどんどん割り当てる機能をもつ。従前のHadoopでのschedulerに近いが、もっとローレベルな感じに近い。
http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/YarnScheduler.java
スケジューラーの割り当てロジックはプラガブルになっている。

1-2　アプリケーション管理(ApplicationMasterとそれを司るlib群)
もう一つの構成要素は(whitepaperでいうところの)ApplicationsManagerである。（実際の実装は、ApplicationsManagerではなく、ApplicationMasterLauncher, ApplicationMasterService等になっているようだ。この辺りはかなり流動的に見える。）アプリケーションのスタートシーケンスは、jobないしDAGが実行要求を出したときに、Schedulerから一定のcontainerが割り当てられる。これに基づいて、アプリケーションに対応するApplicationMasterが、ResourceManagerから生成される。この時点からアプリケーションのライフサイクルが始まる。現行のHadoopMapReduceの問題点の一つに、jobの死活管理が甘いというところがあった。これはjob実行中にjobTrackerが死んだ場合Taskが死に切れないということが発生することがある。このような問題に対応する手段として、ライフサイクル管理が導入されている。ApplicationMasterは生存中はハートビートをResoruceManagerに送り続けることになる。

アプリケーションのベースはApplicationMasterという「フレームワーク」に依っていると言える。すべてのjobに対になったApplicationMasterが実行時に1対1で生成される。（正確には実行可能時のようだ）このApplicationMasterが指定された処理を実際に行う。実体は分散Shellであり、処理を割り当てられたContainerへリソースを提供を保証しているNodeManagerに対して、処理を依頼する。
http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell/src/main/java/org/apache/hadoop/yarn/applications/distributedshell/ApplicationMaster.java

大枠は以上の通りである。何が従前のMapreduceと違うかといえば、まず根本的なアーキテクチャを変更している。インフラ的には様々な分散クラウドの先行実装を参考している点も異なる。Containerはmesosでも利用されている手法でもあり,細かなリソース管理をやっていくという方針がより明確になってきている。その次の違いは、実行フレームワークを分離しているという点になる。MapReduce以外にBSP等が使えるということだけではなく、自分なりの分散アルゴリズムを実装することが可能になっている。効率が良いかどうかは別だが、特定のドメインで有効な修正を、一定のアルゴリズムに施すということが可能になるので、うまく使えば相当有用性があがる。

個別実装は例えば、mesos/spark-yarnという形で、BSPをyarn上のApplicationMasterで実装している例もある。
mesos/spark-yarn
https://github.com/mesos/spark-yarn

2 HDFS〜HDFS Federation
まずなんというか完全にMapreduce2.0とは分離している。従来のHadoopでは、HDFSとMapReduceは表裏一体だったが、MapReduce2.0ではかなり位置付けが異なっている。HDFS Federationはわりと素直に、「分散しているファイルシステムを透過的に一つのファイルシステムとして管理できる」というHDFSそのままに、可用性や管理レベルをあげる事に終始している感じになっている。レイヤーとして、さらに高機能を狙うというよりも現行のレイヤーでの、堅牢性・ユーザビリティを向上させることに重きをおいてる感じだ。ただし管理レイヤーの整理を行っており、きれいなレイヤリング・アーキテクチャになっている。とはいえ、MapReduce2.0がかなりの変更があったことと比べると、相当地味な印象もあり、きわめて好対照に見える。まぁいわゆる正常進化というものではないかと思う。

正常進化ということでは、従って、そもそもの課題が何でそれに対してどのように解決していくか、という点から来たるべきHDFS Federationを概観する。現行HDFSの問題点は、SPoF・マルチテナント・全体的なキャパシティの拡大・appendの向上になる。今のところ見れているのは特にマルチテナントとキャパシティの拡大の部分になる。

抜本的に手を入れているのがNameNodeの拡張になっている。端的にいうと機能を明確に分離して、複数のNameNodeでの稼働を確保している。従前の方法ではこれはDataNodeクラスターをパーティショニングするしか方法がなかったので、大幅な改良といえる。まずNameNodeが担っていた機能を明示的に整理している。すなわち、名前空間の制御とデータブロックの制御の分離だ。従前ではNameNodeで一体化していた両者を分離し、レイヤーを明確に分けている。特にデータブロックの制御を分離し、BlockPoolとして独立して扱っている。各NameNodeに対応するBlockPoolをOneForOneでひもづけて、名前空間から見たデータブロックの管理を透過的に行えるようにしている。物理ブロックサイドから見れば、自分が対応しているBlockPoolとだけ会話すればよい仕組みになっている。ブロックプールを別サーバーで管理することも検討しているようだ。いずれにしろBigDataといいつつも現行のHadoopでは、ある臨界点を越えると一気に制御が面倒になるという点をカバーアップしているようにも見える。

その他、HAやらHbaseとの兼ね合いやらいろいろあるようではあるが、ちょっともうちょっとゆっくり見ていく予定。

参考サイトは以下になる

H社のピッチ
http://www.slideshare.net/hortonworks/apache-hadoop-023

http://www.hortonworks.com/an-introduction-to-hdfs-federation/

http://www.slideshare.net/hortonworks/nextgen-apache-hadoop-mapreduce

HDFS-HAはこちら

https://issues.apache.org/jira/browse/HDFS-1623

んでこっちはMR2

https://issues.apache.org/jira/browse/MAPREDUCE-279?attachmentSortBy=dateTime#attachmentmodule

https://issues.apache.org/jira/secure/attachment/12486023/MapReduce_NextGen_Architecture.pdf