2月8日、東京・大井町きゅりあんで開催された6回目となる国内Hadoopユーザの祭典「Hadoop / Spark Conference Japan 2016⁠」⁠。Hadoopの10周年というアニバーサリーイヤー、そして今回はじめてSparkカンファレンスも併催されたということもあり、事前登録者数は1300名を超えるという盛況ぶりでした。

午前中に行われた基調講演に先立ち、開催の挨拶を行った日本Hadoopユーザ会の濱野賢一朗氏（NTTデータ）は「Hadoopはひとつのものではなくなった」と語り、分散処理エンジンもエコシステムもパッケージングも多様になった現在では"これこそがHadoop"といえるものがない現状を説明しています。たとえて言うならば「すこし前のLinuxディストリビューションが乱立していた時期」（⁠濱野氏）に近い状態であり、それは10年前にはおよそ考えられなかった変化だと言えるでしょう。

ではこれからのHadoopはどう変わっていくのでしょうか。濱野氏は「時間が経過するにしたがってLinuxディストロがいくつかの代表的なパッケージに収斂していったように、Hadoopもまたおなじような道をたどるのではないか。もっとも過渡期にあるHadoopがLinuxのように"落ち着き"を見せるのはまだ当分先のこと。世の中にはじめてはびこった分散処理システムとして、Hadoop、そして分散処理はこれからさらに変化/進化/浸透していく」とコメントしています。

つねに変わりゆくHadoop、その未来はいまのHadoopのあり方にかかっています。基調講演では計7名の登壇者が開発者として、あるいはユーザとして見たHadoopのリアルタイムな姿を紹介しました。本稿ではそのうち、2本の講演内容を紹介し、HadoopとSparkの進もうとしている未来の一端を垣間見ていこうと思います。

Hadoopをより良いものに！ 日本人コミッタ2名によるHadoop普及へのチャレンジ

基調講演の最初はNTTソフトウェア イノベーションセンタの小沢健史氏とNTTデータ 基盤システム事業部の鯵坂明氏による「Apache Hadoopの現在と将来⁠」⁠。両名ともに2014年12月から日本人初のApache Hadoopコミッタとして活躍しています。本カンファレンスの直前にあたる2月4日には、そのコミッタの中でも主要開発者となるプロジェクトマネジメント委員（PMC: Project Management Committee）に選出され、名実ともに国内外でHadoop開発を牽引する存在として知られています。

YARNから広がる並列処理実行基盤の多様化

講演ではまず小沢氏からHadoopの構成要素について説明がありました。そもそもHadoopが開発された経緯として並列分散処理の高速化へのニーズが挙げられますが、小沢氏は「1台のハードディスクでは1秒あたり100MBの読み書きが限界で、1TBのデータを読み込むには1万秒（約2時間47分）かかっていた。これを1台のディスクではなく並列分散処理を行い、その読み書きのスピードを上げるためにHadoopが開発された」と説明しています。

そしてそのHadoopを構成する要素として

• Map/Reduce … 並列分散処理を実行するミドルウェア
• YARN … 計算機リソース管理を実行するミドルウェア
• HDFS … 大量のデータを保持するミドルウェア

を挙げていますが、ここで注目したいのはYARNの台頭です。もともとHadoopのリソース管理を汎用化するための手段として開発されたYARNですが、現在ではMap/Reduceよりも抽象化された汎用的な実行処理基盤としての役割がクローズアップされています。ことにHadoop 2系が登場してからは、SparkやTezなどMap/Reduce以外のアプリケーションもHadoopの単一クラスタ上で並列実行できる汎用性が高く評価されています。

小沢氏はYARNが普及した要因を「YARNがマスタを立ち上げ、SparkやTezのjarファイル（アプリケーション）を計算機側にコピーするだけで動作できるようになった。つまり得意なことを得意なものにやらせる実行基盤が揃ってきた」と説明しています。もちろんYARNもMap/Reduceを起点（SparkやTezでの実行に失敗した場合、Map/Reduceに戻すことができる）にしていますが、YARNがより汎用的に実行基盤をサポートすることで、Hadoopそのものの拡張性や柔軟性、効率性も一段と拡がりを増すことにつながりました。

YARNのほかにもこの10年でHadoopの周辺にはさまざまなミドルウェア技術が生まれてきました。小沢氏は前述したTezやSparkのほかに、HBase（NoSQL⁠）⁠、Storm（ストリーム処理⁠）⁠、Pig（大規模データセットに対する手続き型言語⁠）⁠、Oozie（ワークフロースケジューラ⁠）⁠、Sqoop（HDFSとRDB間のデータ転送ツール）などを紹介していますが、その数は今後さらに増えていくことが予想されます。

このほか、Hadoopにおける最近の傾向としてはインタフェースとなる処理言語の多様化も見逃せないところです。小沢氏はその特徴として

• バッチ処理ではSQLに似た言語による記述が主流 … HiveQL、Pig Latin、Spark DataFrameなど
• バッチ処理とストリーミング処理を透過的に扱えるような言語が登場 … Apache Flink、Google DataFlow
• 機械学習に特化した高水準言語の登場 … Apache SystemML、Google TesorFlow

といった点を挙げています。「⁠バッチ処理に関してはMap/Reduce APIを叩くのではなく、SQLライクな言語が主流だが、最近ではFlinkのようにバッチ処理とストリーミングを同時に扱える"攻めている言語"もあらわれてきた。またMap/Reduceが扱うリソースはCPU、メモリ、ディスクが中心でGPUやFPGAのように機械学習用で使われるリソースの扱いに長けておらず、したがって機械学習用の言語を扱うことを苦手としている。こうした中、SystemMLのような機械学習言語を高速に実行するためにGPUに特化したミドルウェアも登場しており、たとえばMicrosoftが展開する機械学習基盤の"Catapult"などはその典型。FPGAを用いてトータルスループットを2倍にし、逆にTCOは削減している」（⁠小沢氏）

Map/Reduce同様、YARNも現在はCPUやメモリ、ハードディスクの処理が中心であるため、「⁠GPUやFPGAのようなさまざまなリソースを扱えるような"データセンターOS"へと進化していくことが今後の課題」と小沢氏。YARNの進化は今後のHadoopの成長と普及に直結するだけに、引き続き期待したいところです。

日本のHadoop開発者も増加、コミュニティをさらに盛り上げたい

YARNなどHadoopの実行処理系の話題が中心だった小沢氏につづいて、鯵坂氏はHadoopのファイルシステムであるHDFSのここ1、2年の動向についての説明から開始しました。性能面ではSSDやメモリを適材適所に活用する機能がいくつか追加されており、さらにセキュリティ/運用性の面では、よりきめ細かいアクセス制御を実現するPOSIX ACLs、データの暗号化、ローリングアップグレードなどが実装され、Hadoop自体の適用範囲を拡げることにつながっています。「⁠YARNと同様、ハードウェアの進化に応じてHDFSもさらなる進化を遂げていく」（⁠鯵坂氏）

鯵坂氏は続けてHadoopコミュニティの活動についても触れています。コミュニティ活動を可視化する手段のひとつとして、鯵坂氏は自身のブログで毎年、コミットログやJIRAのログを集計した結果を発表していますが、その2015年の結果から引用し、変更コード行数が最も多い貢献企業を紹介しています。1位はダントツでHortonworks（23万7619行⁠）⁠、そしてHuaway（8万2381行⁠）⁠、Cloudera（6万2887行）と続き、4位にはNTTおよびNTTデータ（6万2445行）がランクインしているところが目を引きます。また、Hadoopコミッタを3名（小沢氏、鯵坂氏、岩崎正剛氏）輩出しているNTT/NTTデータに加え、Yahoo! Japanが13位（3413行）に入っていることも、日本のHadoopコミュニティが拡がりつつあることのあらわれといえるでしょう。

「Hadoopをより良くしていきたい、というのは我々二人の共通の願い」として、最後に両氏はHadoopを使いやすくするために自分たちができることとして

• メンテナンスリリースの継続
• Java 8および9への対応
• 新しいハードウェアを意識した高速な処理基盤の実現
• Hadoopの開発者をもっと増やしたい、コミュニティを盛り上げたい

といった項目を挙げています。とくにメンテナンスリリースの継続は重要なポイントで、開発コミュニティは新バージョンの機能追加や改善にフォーカスするだけではなく、メンテナンスリースの継続にも力を入れるべき、という指摘は以前からなされています。現在、2.6系と2.7系のメンテナンスはつづいていますが「がんばればもう2バージョンくらいはいけるのではないか」と鯵坂氏。メンテナンスリリースの継続はエンタープライズ企業でのHadoop採用にも大きく関わってくる分野なので、引き続き注目されそうです。

「SparkやTezなど新しい分散処理基盤が登場し、Hadoopは埋もれがちのように見えるが、Hadoopはハードウェアの進化に追従するかたちで着実に進化を続けている。また、日本でもYARNが確実に普及している。日本のHadoop開発者も増えているので、コミュニティをさらに盛り上げていきたい。みなさんもぜひHadoopを使ってコミュニティにフィードバックしてほしい」と講演を結んだ小沢氏と鯵坂氏。日本のHadoopコミュニティの中心人物として、2016年は国内外でのさらなるチャレンジに期待がかかります。

急成長を遂げるSpark、次にめざすのは10倍高速な分散処理エンジン

冒頭でも触れたとおり、今回のカンファレンスでは日本での開催は初めてとなるSpark Conference Japanも併催しています。基調講演では実行委員の取りまとめ役であり、日本人唯一のSparkコミッタとして活躍するNTTデータの猿田浩輔氏が開催の挨拶を行っています。

2015年は世界中で急速にSparkの普及が進んだ年でもありました。日本もその例に漏れず、Spark関連の情報は書籍や雑誌、Webなどでも数多く見かけるようになっています。猿田氏はそうした状況について、「⁠Sparkの日本人コントリビュータも増え、商用運用している例も多数出てきた。一方でいまだに多くの人たちが"手探り"の状態でSparkの活用や開発を行っている。今回のカンファレンスが、Spark活用の取り組みを発信したり、活用のヒントを得たり、または開発に携わるきっかけになればと願っている」と語っています。

なお、本カンファレンスの事前登録者（1347名）を対象に行ったアンケート結果によれば、70％の参加者が実際にSparkを利用中もしくは利用を検討している段階にあり、12％の参加者はすでに本番環境で運用中で、そのうち6％は1年以上に渡って運用しており、中には3年以上運用しているケースもあるとか。国内でのSparkブームは意外と地に足がついているのかもしれません。また、利用中のコンポーネントとしては55％がSpark SQL / DataFrameを利用していると回答、さらに用途のわかりやすいMLibやSpark Streamingも40％近く利用されているという結果が明らかになりました。

Sparkは「ビッグデータ界のテイラー・スウィフト」

このように日本でも高まる一方のSpark熱ですが、現在のSparkはどのようなステージにあるのでしょうか。猿田氏に引き続き登壇したのは米Databricksの創業者のひとりであるレイノルド・シン（Raynold Xin）氏です。現在Sparkコミュニティの3代目リリースマネージャでもあるシン氏は、Sparkの現状、そして5月にリリースが予定されているSpark 2.0のトピックを中心に基調講演を行いました。

シン氏はまずSparkとは何かという定義として「open source data processing engine built around speed, ease of use, and sophisticated analytics（スピード、使いやすさ、洗練された分析を兼ね合わせたオープンソースのデータ処理エンジン⁠）⁠」という表現を用いています。

続けてSparkにとっての2015年を"Great year for Spart"（Sparkにとって大きな年）と振り返っています。その大きな理由として

• 1000人以上のコントリビュータを出した最も活発なオープンソースプロジェクトに成長
• Spark 1.4で新たにR言語のサポート
• 幅広い業界サポートと採用

を挙げています。筆者は昨年、米国で10を超えるIT系カンファレンスに参加しましたが、取材を重ねるごとに、Sparkへの関心が高まっていくのを肌で感じました。とくにIBMのSparkへの傾倒ぶりは強烈で、Sparkプロジェクトに対する度重なる資金の投資と人員の投入を行ってきており、2015年6月にはサンフランシスコにSpark Technology Centerという研究所をオープンしています。

こうした過熱ぎみのSparkブームについて、元Gigaomのジャーナリストで現在はMesosphereのシニアリサーチアナリストを務めるデリック・ハリス（Derrick Harris）氏は「Sparkはビッグデータソフトウェアのテイラー・スウィフト（Taylor Swift）だ」と表現していますが、たしかにデビューして数年は"知る人ぞ知る"的な人気だったテイラーが瞬く間にスターダムをのし上がったさまは、2010年に誕生したSparkが2015年に突如としてNo.1オープンソースの座に就いた状態に近いのかもしれません。潜在的パワーが強力だったところもテイラーによく似ているといえます。

では急激な成長を遂げるSparkは、現在どのような環境で稼働しているのでしょうか。シン氏が示したスライドによれば、48％がスタンドアロンな環境で実行されており、51％がパブリッククラウド（AWS、Azure、GCPなど）上で稼働しているとのこと。また実行基盤としてYARNが40％、Mesosが11％という調査結果が出ていますが、シン氏によれば「Mesosが急激に伸びている」という点が注目されるそうです。

またSparkを利用している企業の内訳として、最も多いのがソフトウェア業界（29.4％）で、つづいてITコンサルティグ（14.0％⁠）⁠、広告/マーケティング/PR（9.6％）と続いています。金融やヘルスケア、キャリア/通信といったエンタープライズ業界での採用は、増えてはきつつあるものの、まだそれほどの比重を占めるには至ってないようです。

さらにSparkアプリケーションとして利用されている上位は1位がビジネスインテリジェンス（68％）で、2位がデータウェアハウジング（52％⁠）⁠、3位にレコメンデーション（44％）と続いています。6位に不正検出/セキュリティが入っているのも、セキュリティに機械学習などのビッグデータ分析技術を取り入れている企業が多い米国のトレンドが反映されています。

Sparkの現状を説明したあと、シン氏は開発中のSpark 2.0について触れています。2016年2月時点での最新バージョンはSpark 1.6ですが、次のバージョンとなるSpark 2.0は5月に正式公開が予定されています。その2.0の特徴についてシン氏は

フロントエンド（RDD、DataFrame、ML Pilelineなどユーザが直接触れるAPI）

フロントエンドAPIの作成。ストリーミングDataFrame/Dataset SQL

バックエンド（スケジューラ、シャッフル、演算子などの実行環境）

10倍のパフォーマンス、全ステージコード生成ベクトル化

と述べています。

SparkプロジェクトではフロントエンドAPIの整備に関しては

1. シンプルだが表現豊かに
2. セマンティクスが十分定義されている
3. 十分に抽象化することでバックエンド処理を最適化

という3つの指針を用意して開発にあたっているそうです。2.0においてとくに大きな変更点となりそうなのがDataFrame APIの拡張で、Java、Scala、Python、SQLといった言語フロントエンドからDataFrame Logical Planに落とし込まれたバイナリをJVM以外の実行環境（Tungstenなど）でも実行できるようにするとのこと。また、2.0でのフロントエンドAPIにおいては

• ストリーミングDataFrame
• DataFrameとDataSetの成熟とマージ
• ANSI SQL（自然結合、サブクエリ、ビューサポート）

といった課題を前提に開発が進められているそうです。

このうちストリーミングDataFrameに関してシン氏は以下のように述べています。「⁠Sparkにおけるストリーミング処理はとてもむずかしい。長期間に渡るアウトプット、遅れてくるデータ、障害、ディストリビューションなどの問題があり、しかもストリーミングはすべての複雑なオペレーションに渡って機能する必要がある。だからこそ指針にもあげたようにセマンティクスの定義が重要だ。十分に定義されたセマンティクスが用意されていれば、ばらばらにくるデータも障害もうまくさばくことが可能になる」

一方、2.0のバックエンド部分でゴールに設定されている"10倍の高速性"については実現可能なのでしょうか。「⁠今でも十分速いとされているSparkを2.0でさらに10倍速くできるのか、その答えをほんの少しだけ見せよう」とシン氏はSQL/DataFrameのパフォーマンスに関するスライドを提示しています。現在のSpark 1.6では1395万行/秒のスループットですが、開発中のSpark 2.0では1億2500万行/秒にまで向上しています。ほぼ10倍近い高速化はおそらくTungstenの成果だと思われます。

現在、GitHub上で活発な開発が行われているSpark 2.0。予定通りいけば、3月から4月にかけてコードがフリーズされ、5月には正式リリースの運びとなります。10倍高速化されたSparkは並列分散処理環境の世界をどのように変えていくのか、今から非常に楽しみです。