MapReduceは今後どうなるのか？
2012年の現在、割と悩んでいるのでメモっておく。
年度末ぐらいに再調査の予定。・・なので暫定ですよ。
まず前提として、現行のHadoopの実行フレームワークであるMapReduceは、実行効率は決して良くはないです。この辺が割と辛い。
とはいえ、大規模並列処理を一般的に行うという観点での品質や取り回しを考えた場合、”結果として”非常にバランスがとれており、普及している。その上で、このMapReduceですが、今後の見通しについては、潮流は今のところ二つに割れているよう見える。ので、その辺のメモ。
■YARN
一つの方向性は、現在のHadoop2.0系で実装されているMapReduce2.0、というか、MapReduceとは別の実行基盤を利用するという方向ですね。すなわちBSPや、MPIを利用する。要は、今までの並列処理の成果をそのまま利用しましょう、という流れに近い。
MapReduce2.0＝YARNについては、一応、MapReduceは速くはなりますよということですが、現状のRMはなかなか未成熟でナイーブで、後発なのになぜか先発のMesosの劣化版という状態かなと。パフォーマンスは現状のMRと同等または多少は良くなるという水準にとどまる印象が強い。したがってあくまで別の実行アルゴリズムがMapReduceと同一の基盤上が動きますよという形で、「現時点では」とらえた方が良いと思います。
そこで、MapReduce以外の実行アルゴリズム（例えばBSP）についてですが、実行効率という点では、今までの研究や経験があることもあり、理論的にはMapReduceよりも効率がよい。というか、現行のHadoop MapReduceは、Map-Shuffle-Reduceの実行順序の強制にしろ、結合にしてもトリッキーなことをいろいろとやる必要があり、並列性確保の容易性と実効性能のトレードオフでは、容易性に振りすぎている部分があります。
もともと、ある程度ナイーブな実装であることは、普及という意味ではよかったが、あれやこれややるのには相対的に機動性は落ちます。（大抵の利用がHiveやPigになっているのは周知の通りですね。）
というわけで、別の実行アルゴリズムを想定していく、というのは理論的な方向性としては間違ってはいないとは思われる。が、実際のHadoop上の実行基盤であるYARNは、あまりにもキャッチオールな方に行き過ぎた感もあり、正直、もう少し、練り込みなり、作り込みがあったほうが良かったな、と。まぁ、迫りくるHadoop関連のファンドの圧力に対抗するには、ベンダーサイドもこの状態で引っ張り出すしかなかったという感じかと。・・・ただ、なんども言いますがちゃんとできるのであれば、理論的にはこちらがもっとも効率が良い。
■改良版MapReduce
さて、しかしながら、実はもう一つの方向性があって、あくまでMapとReduce（とSort）の組み合わせだけで処理を行う、という方向です。つまり現状のMapReduceは欠陥だらけなので、もっと手を入れたり、工夫したりすることでもっと行けるだろう、という考え方。
現状のHadoop実装ではありませんが、あくまで現行のMapReduceの領域で考えていくという方向性ですね。こちらは一般的に使える具体的なフレームワーク実装が広く出ているというわけではありません。が、現在のR＆Dの潮流はこちらに向いているように見えます。(VLDB 2012で通った論文でMapReduceは凄い量だったですが、YARNはゼロという惨状は見過ごすべきではないでしょう。)
強引ではありますが、各種の処理を無理矢理MapとReduceにしましょう、という試みも各所で見られますし、また、例えば、MapとReduce(Fold)とSort(Shuffle)の組み合わせや自由度を上げるという方向性もあるでしょう。
関数型のパラダイムを見るまでもなく、 MapとFoldと自在に使えるのであれば、ある程度の処理は、それなりにできてしまいます。一種の麻薬のような万能性も一部では見られますね。ループをぐるぐる回すよりも圧倒的に品質・見通しもよいことは簡単にわかる上に、並列処理との相性も悪くないのは折り紙付きです。
もっと汎用的にMapReduceのユーザービリティを上げていったらどうか？という方向性で考える場合、多分、下手をすると実行基盤は現状のHadoopである必要もないかもしれません。このあたりは、なにかまったく別の実行基盤が出てくる可能性もなくはないです。まぁ、なんとも言えませんが。
■現状のMapReduceの延長なのか、HybridなYARNの方向なのか？
個人的には流れを決めていくのは永続化層の有り様だと思います。現状のMapReduceのくびきは、間違いなくHDFSです。現状の各拡張もHDFSの拡張やリプレースという方向が散見されるのは周知のとおりです。
HDFSの抽象化や拡張は、普通に考えれば現状のMapReduceとの後方互換性を維持した形で、その枠組みを拡大していくことに寄与するはずです。（YARNはもっと別のものを一足飛びに導入する手法に振っています。）
特にHDFSの有り様については、相当な議論と進展があると思います。実際、いままでのHadoopの主要な論点の一つは「HDFSが駄目すぎる」というのは、衆目の一致するところではありました。それを受けて、共有ストレージを土台にするとか、C++で再実装するとか、はたまた特定のクラウド上の基盤を利用するとか、そもそもHDFSそのもの実装に手をいれるとか、いろいろな方向がありますし、また実際に行われています。
こういった試みの上位では、まちがいなく現状のMapReduceの様々な側面での非効率性がクローズアップされるでしょう。そこではMapReduceの枷をどうはずすか、という議論が現れるような気がします。この辺りがちょっと気になる。
また、これらの再実装はYARNとはある意味で、時期的な競争になるかと。どちらが先にまともな実装になるか？そういう観点。
■んで、どうしますか？
ということで、使う側的は「ある意味模様眺め」という事にならざるを得ない。慌ててYARNに飛びつく必要もないし、また先走ってオレオレMapReduceの独自拡張をしていく必要もない。
むしろやるべきことは現行のMapReduceの問題点は何で、何ができて、何ができないのか？ また、何をすればできるようになるのか？という点を押さえるということかと。
もっとも大事な点は「そもそもどのような問題を解決するための道具立てなのか？」ということを再認識することでしょう。この辺はもう一度、ゆっくり再考はしておきたい感じです。ま、Hadoopやビッグデータな流れも一服感もでているので、そーゆー時期かと。
ま、そんな感じで、少し先をみるフェーズになってきている感じです。
とりあえず簡単なメモ。
