MTI3NjI1MjkwODkyNDgzMDM4_x

写真拡大 (全2枚)

最近注目を集めているが、幾つかの点で問題も

Hadoopはホットだ、だがその従兄弟であるSparkは更にホットな存在だ。

Sparkは5年前のApache Hadoopの様な存在で、バークレー大 AMP研で生まれた、Hadoopのエコシステムで動くMapReduceに代わる高速データ処理エンジンだ。これは（MapReduceの様な）バッチ処理および、ストリーミングやインタラクティブ・クエリーといった新しいワークロードや、機械学習やグラフ処理でよく見られる反復アルゴリズムの処理に対応している。

サンフランシスコに拠点を構えるTypesafeは、私が去年記事で触れたJava開発者に対するよく知られたアンケート調査のスポンサーであり、Scala、Playフレームワーク、Akkaのコマーシャルな支援者だ。最近行われたSparkについてのアンケート調査では、2000人以上（正確には2136人）の開発者からの回答が得られた。そこから以下三点の結論が導き出された。

  1. 人々のSparkに対する関心及びその浸透は急激な成長を見せている。Google Trendsもこれを裏付けている。アンケートでは回答者のうち71%が少なくともSparkについて評価ないしリサーチを行ったことがあり、35%は現在利用している、もしくは利用する予定があるという。
  2. より高速なデータ処理とイベントストリーミングは企業にとっての関心事だ。Sparkの機能のうちでも郡を抜いて興味を集めているのは、MapReduceをはるかに凌ぐ処理能力（回答者の78%がこのことについて触れている）と、MapReduceでは処理できないイベントストリーム処理（66%以上が触れている）についてだ。
  3. 巷でよく言われる浸透の妨げになっている要因は、主な要因ではない。Sparkの利用の妨げになっている点について聞いた所、回答者からはSparkについての経験の不足と、詳細なドキュメントの不足（特により高度なアプリケーションのシナリオおよびパフォーマンスチューニングについて）という答えが寄せられた。彼らはSparkで知られている一般的に不足している部分や、メッセージキューやDB処理のためのその他のミドルウェアとの連携についても触れた。商業的なサポートの不足（これはHadoopでも言えることだ）も懸念の１つだ。最後に何人かの回答者たちは、自分の務める会社が今の所ビッグデータのソリューションを必要としていないからとも答えた。

Typesafeのビッグデータ製品/サービスのアーキテクト、ディーン・ワンプラー（@deanwampler）に、Sparkの台頭についての彼の考えを聞いた。ワンプラーは最近収録したトークで、Spark/Scalaが企業で最も人気のあるビッグデータ処理エンジンとして、MapReduce/Javaに取って代わるものになっているのはなぜかという事について語っている。

Sparkの現在

ディーン・ワンプラー

ReadWrite（RW）: Sparkを使い出そうとする人々にとって、最もよくあるハードルとは？

ワンプラー（DW）： 主に専門家や、内容のある例を含んだドキュメントの調達です。多くの人たちはジョブやクラスターをどの様に管理し、チューニングしたらいいかを知りません。Sparkの商業的なサポートは充実しておらず、デプロイにYARNを使わないものだと、それは更に顕著です。しかしHadoopの場合であっても、サポートは未だに限定的なものです。

Sparkはまだまだ色んな意味で成熟してません。Spark SQLやSpark Streamingなどの新しいモジュールなどは特にそうです。HadoopやMapReduceのような古いツールの場合、その成熟や専門家たちがドキュメントを残すのにより多くの時間がありました。これらの問題全ては比較的近いうちに人々の取り組みにより解決されることです。

RW: 「どれでSparkを使ってるの？」と質問する人がよくいます。極めて幅広いリソース管理方法があるなか、スタンドアローン・クラスターや、YARN、Mesosなどどれを使っているのかという意味なのでしょう。
業界はビッグデータクラスターを単体で走らせるようになると思いますか？ それともゆくゆくはその他のアプリケーションと連動して稼働させるようになると思いますか？

DW: ほとんどの団体ではまだ台数の少ない大きなクラスターを使うことになるでしょう。監視するクラスターが少なくて済むからです。MesosやYARNの場合、このアプローチが好まれます。方やSparkの場合は、特定の問題のための小さなクラスターの構築に向いています。例えばTwitterからの入力を受ける場合、ストリーミングの負荷に対応できるようにクラスターをチューニングしたいと思うでしょう。例えばデータウェアハウジングを行うための大きいクラスターに整形されたデータを流すような用途です。

Sparkの今後

RW: オペレーション面において、SparkはMapReduceと異なりますか？

DW: バッチジョブではほぼ同じですが、ストリーミングジョブの場合は異なる問題が浮かび上がります。

典型的なバッチジョブではSparkであれMapReduceであれ、走行させるジョブを投げ、YARNやMesosからリソースを引っ張ってきて、ジョブが終わるとこれらリソースは解放されます。しかしSparkのストリーミングの場合、ジョブは継続的に走ります。なのでジョブが死んだ際のデータロスを防ぐ為に、より強力なリカバリーが必要となります。

リソース割り当ても問題の一つです。バッチジョブの場合、ジョブが終わるまでリソース割り当てを固定出来ますが（注釈:YARNやMesosでも動的割り当てはすでに可能になっている）、長い時間走るジョブがある場合、リソースに遊びが出来るのを回避したり、負荷が高い時に割り当てを増やしたりする為に、より動的なリソース管理が必要となってきます。

つまりスケールが自動的に調整され、それに応じてリソース割り当ても変更されることが望ましいのです。これは簡単ではありませんし、人の手による解決も難しい問題です。

RW: ScalaとSparkの連携について話を伺います。Sparkを使うに当たって、Scalaの知識は必要になりますか？ Sparkを使うほとんどの人たちはScalaについてもよく知っています。またScalaのユーザーはSparkを好む傾向がある人たちなのでしょうか、それともSparkにはScalaユーザーを引き寄せる作用があるのでしょうか？

DW: SparkはScalaで書かれており、またScalaに人を流入させてもいます。大抵の場合、彼らはビッグデータ畑での経験があり、開発者の場合はJava、データサイエンティストの場合はPythonやRを使ったことがある人たちです。

いいことに、SparkはScala、Java、Pythonをサポートしており、これにRも加わります。というわけでSparkを使う為にScalaに移行する必要は無いのです。

その他の言語でのAPIサポートには遅れがありますが、そのギャップはほぼ埋まっています。原則として最高のパフォーマンスはScalaかJavaで実装することで得られ、コードが簡潔で済むのはScalaかPython実装した時です。結果としてSparkはScalaに人をいざなっているわけですが、それでもScalaのエキスパートである必要はありません。

SparkがScalaの主流な機能を多く使っているということは、一部の人しか分からない様なことを必要としないので良いことだと思います。

トップ画像提供：Shutterstock

Matt Asay
[原文]