この状況は以前にもあった。Hadoopが一般的になるにつれて、その長所は当たり前のものとなり、短所が注目を集めるようになった。この現象はHadoopに限ったことではなく、他の主要テクノロジーでも見られるものだ。だが、実のところ、Hadoopにとって大きなネックになっているのはHadoopのファイルシステムやAPIではない。HadoopオリジナルのMapReduceコンポーネントだ。Hadoopフレームワークのバージョン2.0ではMapReduceの代替プログラミングモデルに門戸が開かれている。だが、この問題を引き起こしているのはMapReduceだ。

不安定なMapReduce

　Googleで考案されたバッチ処理ベースのMapReduceはWeb検索に最適なプログラミングアプローチだ。だが同意を得られるのは、ここまでだろう。プログラミングは困難で、多くの分析アプリケーションには適していない。また、リアルタイムの処理を実現することは不可能など問題が山積みしている。ある意味、MapReduceはHadoopという巨大なフレームワークの不安要素だといえるだろう。

　選択の余地がないとき、MapReduceの欠点はそれほど目立たなかった。Hadoopが2014年夏に低迷期を迎えた裏には、データ処理に関する興味深い新しい代替プログラミングモデルの存在がある。

　2014年の6月と7月には「Spark Summit」および「Google I/O」というカンファレンスが開催された。これらのカンファレンスは、大げさに騒ぎ立てられているHadoopの宣伝について考え直す機会を与えた。

　Spark Summitではデータ処理システム「Apache Spark」が注目を集めた。必然的な結果として、Hadoopがスポットライトを浴びることはなかった。

　Apache Sparkは、米カリフォルニア大学バークレー校で開発されているソフトウェアだ。ここ数年間で浸透しているが、その勢いが増したのは最近だ。その非バッチ処理と高水準なプログラミングインタフェースがMapReduceの代替プログラミングモデルを探している人を魅了している。Apache SparkはHadoopで実行できる。だが「Apache Cassandra」や米Amazonの「Amazon S3」などのシステムでも直接実行可能だ。

　Apache Sparkについては、あるうわさが飛び交っている。データ業界のアナリスト、カート・モナッシュ氏は次のように語る。「次世代の並列パラダイムの最有力候補はSparkで採用されているものだという見方が強まっている。Sparkにはデータストリーミングについて特別な将来性がある。これは動的なデータ（高速データ）の操作や機械学習の操作を特徴とする多くの次世代のビッグデータアプリケーションが取り組んでいる分野だ」

　2014年6月末に開催されたGoogle I/Oカンファレンスでは、MapReduceの面目がつぶれる事態が発生した。広義ではHadoopの面目も含まれる。MapReduceの生みの親であるGoogleが、現在は自社でMapReduceを使用していないと発言したのだ。それと同時に、MapReduceの競合となる「Google Cloud Dataflow」アプリケーションフレームワークを紹介した。

　Cloud Dataflowの製品管理のリーダーを務めるトム・カーショー氏によると、Cloud Dataflowはデータを迅速に移行し、同氏が望むMapReduceの処理能力を向上するという。

　「MapReduceは過度に単純化されている。MapReduceのジョブはアセンブルが難しい単位で実行される。一方、Cloud Dataflowでは、論理的にまとめることが可能なコンポーネントを作成する」と同氏はいう。これはHadoop 2.0のリソースマネジャー「Yarn」に関するうわさと大差ないように思える。だが、開発者はGoogleが発信する情報には聞く耳を持つ。

どん底にあるHadoop

　皮肉にも、GoogleがMapReduceベースのHadoopの競合Cloud Dataflowを展開するのと時期を同じくして、Googleは同フレームワークの利用者にHadoop／MapReduceプラットフォームのサポートを提供する。だが、Hadoop／MapReduceプラットフォームの最盛期は過ぎているように思える。

　2014年9月上旬に開催された「TDWI BI Summit」では、コンサルティングと執筆活動を行っているデイビット・リンシカム氏が、GoogleによるMapReduceの回避について次のように言及している。「多くの人がHadoopについて考え直している。これが2014年の夏に見られた見解の総括になるだろう」

　これが公平なのかといわれれば、公平ではないだろう。Hadoopでは、MapReduceへの依存から脱却する新しいアーキテクチャが採用されている。2013年に見られたHadoop 2.0に関する騒動の背後にあるのはMapReduceに多くの制限が存在する事実に対する承認だった。

　Yarnが導入されたのも、このためだ。Hadoopには歴史がある。そのため「設置基盤」というレガシーの問題を抱えている。既存の全てのMapReduceアプリが一晩でリアルタイムの処理に対応したアプリに書き直されるのかは疑問に思うところだ。だが、恐らくそのようなことはないだろう。

　Hadoopはリアルタイムの動作に対応するように拡張しながら、設置基盤を維持するという古典的な問題を抱えることになる。より多くのHadoop 2.0アプリケーションが作成および公開されるにつれて、Hadoopはどん底から這い上がり、一息付けるようになるだろう。だが、ある程度の時間が必要になるのは必至だ。