あけまして、おめでとうございます。

例年、Apache Hadoopを中心に並列分散処理ミドルウェアの動向や展望についてご紹介しています。

今年は、NTTデータに所属する

• 鯵坂 明（Apache Hadoopコミッタ）
• 岩崎 正剛（Apache Hadoop開発者、HTraceコミッタ）
• 関 堅吾（Apache Yetusコミッタ）
• 猿田 浩輔（Apache Sparkコミッタ）

の4名による対談からまとめた、HadoopとSparkを中心に2015年の振り返りと2016年の展望をご紹介します。

2015年を振り返る

2015年の新春特別企画では「TezやSparkなどの新しい処理基盤の活用が進むことになる」と紹介しました。実際に振り返ってみると、Apache Sparkはかなり盛り上がりました。

Apache Sparkは、年初にバージョン1.3、6月には1.4、9月には1.5がリリースされ、その度に新機能や大きな変更が盛り込まれました。特に、DataFrameは大きな影響を持ち、データ分析系のアプリケーション開発者はさらに気軽に並列分散処理を利用できるようになりました。ビジネス面では、我々NTTデータがSparkのサービスを正式発表したり、IBMが3500名規模をSparkに投入すると発表したりと賑わっていました。

Apache Tezも少しずつ利用されていますが、Sparkほど目立ちませんでした。従来からのHive（SQLライクな記述でHaoopを利用するためのミドルウェア）やPig（データ加工の流れを独自の記法で記述できるミドルウェア）の利用者は、スムーズにMapReduceからTezに移行でき、性能を大きく改善できるため、実際に使ったユーザには実利が大きいようです。盛り上がりに欠けていますが、地味に利用が進んでいるというのが実態でしょう。NTTデータの「Twitterデータ提供サービス」の一部サービスでも、Tezに移行して性能上の大きな恩恵に与っています。

Hadoop本体に目を向けてみると、2.7がリリースされた年でした。2.7.0は実質的にアルファ版でしたが、まもなく2.7.2が出る予定です。いくつか新機能が入りましたが、どちらかというとJDK6のサポート打ち切りの方がインパクトは大きいかもしれません（Sparkも1.6でJDK6サポートは打ち切りです⁠）⁠。また、2.6.1～2.6.3等のメンテナンスリリースが出ました。Hadoop開発コミュニティは新バージョン開発に重きを置きすぎていたせいか、これまで過去バージョンの（致命的なバグやセキュリティ課題を解決した）メンテナンスリリースはほとんど出してこなかったのですが、2.6系からはメンテナンスリリースの取り組みが進められています。これは、日本人Hadoopコミッタの鯵坂 明氏らが主導する活動だったりします。

ほかにも、HBase 1.0リリース、Cloudera社によるKuduリリース、PivotalとHortonworks主導でのOpen Data Platform initiative（ODPi）設立、などのトピックもあり、話題に欠かない1年であったことは確かです。

2016年のHadoopとSpark開発のゆくえ

2016年のHadoop開発がどうなりそうかというと、比較的落ち着いた1年になりそうです。Hadoopは2.7や2.8の開発が進められていますが、目玉となる誰もが欲しい新機能の実現というよりは、改善や細かい機能追加が中心になりそうです。

一方で、3系に向けた準備を進める話も出てきています。3系はユーザ視点での新機能は多くないものの（Elasure Codingも3系に向けて開発されていますが、2.x系に入れようという流れもあります⁠）⁠、API整理などのリファクタリングを一気に進めようという動きです。しかし2016年中に本格的に進むかは不透明で、もう少し先になるかもしれません。

Sparkの開発は活発に進みそうです。バージョン1.6の次は2.0となる見込みで、現在、開発者の中で2.0に向けたロードマップの整理が進められています。Project Tungstenによる最適化やハードウェア機能の活用はさらに進みそうです。GPUやLLVMだけでなく、3D XPoint、不揮発メモリ対応の取り組みも登場しそうです。

YARN本格導入の年になるか

複数の並列分散処理エンジンを併用できるようにYARNの実装が進められてきていますが、本当にYARNを使い倒すユーザは多くないはずです。しかし、SparkやTezはYARN上の「キラーアプリケーション」となってきており、いよいよYARNに真剣に取り組まないといけない状況になってきています。その意味で、2016年はYARNが、さまざまな業態・処理にチャレンジしていく年になるかもしれません。

大規模なクラスタを持つユーザにはYARNの恩恵はわかりやすいものとなっていますが、一方で2ラック程度／数十テラバイト程度のユーザには、逆に性能や運用性においてオーバーヘッドが大きく感じられるのが実状です。その課題をどう受け止めつつ、解消していけるかが正念場の1年になるかもしれません。

Sparkは、MLlibなどを使った機械学習によるデータマイニングに注目が集まりがちですが、ストリーム処理（マイクロバッチ処理）を手頃に実現できるSpark Streamingもかなり期待が集まりそうです。現在のところSpark StreamingはDataFrameに対応していませんが、近いうちに対応される見込みです。

やはり、共通インターフェースはHiveに収斂されるのか

今でもHadoopを説明する上でMapReduceは欠かせないアルゴリズム・フレームワークですが、JavaでMapReduceのアプリケーションを記述する機会は確実に少なくなってきたした。理由のひとつはSQL on Hadoopが現実のものになってきている影響といえるでしょう。処理を細かく制御したり、性能を引き出そうとするとMapReduceアプリケーションをコーディングする機会は少なくありませんでしたが、（⁠並列分散処理にSQLが向いているかどうかの議論は残されているものの）SQLライクなHiveQLで記述する機会が確実に増えています。

HiveQLで書いておけばMapReduceはもちろん、TezやSparkでも動いてくれるという、分散処理エンジン間のポータビリティもうれしいですし、Hiveの最適化処理がかなり向上し、ヘタなMapReduceアプリケーションを書くよりHiveの最適化に任せてしまった方が効率よく実行されるという状況になりつつあります。まだまだ並列分散処理エンジンの進化は進み、数年の間で栄枯盛衰が起こるでしょうから、長く利用する処理はHiveQLで整備しておくのが無難というのは間違いなさそうです。HiveユーザはLLAP（Live Long and Process）などの開発動向にも注目しておくとよいでしょう。

ユーザにとっては悩みが増えてくるかもしれない

2015年もそうでしたが、HadoopやSparkのエコシステムは確実に拡大しており、技術的な成長はめまぐるしい状況です。一方で、利用者の立場に立つと、迷いや悩みの多いソフトウェアになってきているな、という印象を受けています。同じHadoopといっても、利用するディストリビューションによって、構成するソフトウェアや特徴が大きく異なっており、その乖離は年々大きくなっている認識です。それぞれに受けられる恩恵はあるものの、Hadoopというひとつの文脈では説明できないほどの違いが生じてきています。これは、我々がHadoopを安心して使い続けるという観点で「悩み」になりかねない気がしています。2016年は、このような状況に、我々自身が一石を投じることができる取り組みを進めて、皆さんに提案していきたいな、と考えています。

課題がありつつも、並列分散処理エンジンの進化は速く、その影響力もますます大きくなってきています。ぜひ、皆さんには2016年もHadoopやSparkに活用して、役立つ、面白い取り組みを進めてもらえばと考えています。よい1年になりますように！