ビッグデータも世代交代の時期か

MapReduceよりApache Sparkを採用すべき理由、採用できない理由

Apache Sparkの採用が増えている。最大の魅力は、MapReduceよりも圧倒的に高速なことだという。それ以外にも、さまざまな人が多くのメリットを語る。一方、Sparkを採用しないという意見もある。なぜか？

　「MapReduce」よ、道を譲ってくれ。君はここまでよく頑張ってくれたが、今日のビッグデータ開発者が求めているのは、処理速度と簡潔性だ。

　「Apache Hadoop」（以下Hadoop）環境で稼働するフレームワークとして、最近登場した、高速処理が得意な「Apache Spark」（以下Spark）の採用が急増している。この現象は少なくとも、Sparkを前面に押し出し、ビッグデータ界の次の主流となるだろうと予測するビッグデータサプライヤーからのメッセージとなっている。

　2015年6月、米サンフランシスコで「Spark Summit」カンファレンスが開催された。その席上で米Clouderaの最高戦略責任者、マイク・オルソン氏はSparkの急成長を「息もつかせぬ勢い」と表現。顧客が求めるものが（MapReduceからSparkへと）完全に移行していることを、Hadoopディストリビューションも販売している同社の立場で実感していると報告した。

　「近いうちに、SparkがHadoop向けの汎用（はんよう）処理フレームワークの主流になるとわれわれは予測している」と同氏は話す。「一般的な目的に適したエンジンを探しているのなら、今ならMapReduceではなくSparkを選ぶだろう」

　オルソン氏はこの発言の際、言葉を慎重に選んだようだ。特に「一般的な目的」（general purpose）と限定したところにそれがうかがえる。同氏がそう表現したのは、Hadoopでは検索用の「Apache Solr」やSQLクエリ用の「Cloudera Impala」など、特殊用途向けに開発されたエンジンが活躍する領域も小さくないからだ（だから「一般的な目的」と同氏は限定した）。しかし多岐にわたるアナリティクスのワークロードを新規に作成する際に開発者が利用するフレームワークの覇権争いは、一騎打ちの様相を呈している。そしてどうやらSparkが優勢のようだ。

　これは極めて単純な話だ。Sparkは、開発者が以前から再三批判してきたMapReduceが抱える多数の問題、特にレイテンシが高いことと、バッチモードの応答の遅さに見事に対処しているからだ。

　「Hadoopが成長してきた世界の中で、MapReduceは長い間、その堅牢性に対する定評を維持してきた」と話すのは、米Hortonworksの創設者でアーキテクトのアラン・マーフィー氏だ。

　マーフィー氏はMapReduceについて、これがGoogleのラボで作られたテクノロジーであり、非常に特殊なユースケース、つまりWeb検索を処理するためのものだったと指摘する。10年以上の時間をかけてこのテクノロジーは進化を重ねてきたが、それでもビッグデータアプリケーションに対して大規模組織が求める要件を満たすには恐らく不十分だ。

　「MapReduceの長所は、複数のユースケースに対処できる柔軟性だ」と同氏は付け加える。「MapReduceが長らく使われてきたのは、これで解決できるユースケースが確かに存在するためだ。ただその処理は最適なものとはいえない。MapReduceがかつて他のテクノロジーを駆逐したように、新しいテクノロジーが登場して、MapReduceをお払い箱にする、またはこれに取って代わるのは極めて自然な流れだ」

実行速度と簡素性

　では、Sparkがそんなに優れている点はどこなのか。開発者にとっての主な利点は処理速度だ。

この記事の著者

関連記事

• 

  Internet Explorerのサポート終了でレガシーの呪縛を断ち切れるか？

• 

  FlashはHTML5に役目を譲って勇退せよ