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

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

今年は NTTデータに所属する 岩崎正剛（Hadoopコミッタ）⁠，猿田浩輔（Sparkコミッタ）⁠，鯵坂明（Hadoopコミッタ/PMC）の3名でディスカッションした内容を元にお伝えします。

Hadoop 3.0リリース

昨年の新春特別企画では，「⁠2017年はHadoop 3.0がリリースされる年になるはずです。」と書きましたが，Hadoop 3.0.0が2017年12月13日にリリースされました。2017年の間に3.0.0-alpha2，3.0.0-alpha3，3.0.0-alpha4，3.0.0-beta1とリリースを重ね，なんとか2017年内に間に合った格好です。

2016年にリリースされた3.0.0-alpha1では，HDFSのErasure Coding対応，YARNのTimeline Service v.2，マルチスタンバイNameNode，シェルスクリプト（CUI）の改善といった新機能がmergeされていました。

3.0.0（GA）においてはさらに，依存ライブラリのバージョン競合を避けるためのshaded client jar，FileSystem API経由でのS3の操作で一貫性を保つためのS3Guard，ユーザ定義可能なYARNリソースタイプなどが追加されています。

• Apache Hadoop 3.0.0 - Apache Software Foundation

動作環境の変化に着目すると，Hadoop 3.0でJava 7のサポートが廃止され，Java 8が必須になりました。Javaについては2017年9月にJava 9がリリースされましたが，Hadoop側のJava 9対応は現在も作業中の状態です。多くのライブラリを利用し，多くのミドルウェアから利用されるHadoopにとって，動作環境の変更は簡単ではありません。

Java自体もそのリリースサイクルを変更し，6ヵ月ごとに新しいリリースを出すと発表しています。言語処理系の変更にどのように追随し，新機能を活用していくべきかは，コードベースの大きいソフトウェアには悩ましい問題です。

Hadoopに見る大規模OSSプロジェクトの運営

バージョン3のリリースに時間を要したのは，HiveやHBaseに代表される，Hadoopに依存する関連プロダクト側で，移行性の問題等を確認できるようにするために，アルファ版，ベータ版のリリースを複数回行ったためです。エコシステムと呼ばれるほどの多様な関連プロジェクトが存在するため，Hadoopは変更に対してどうしても慎重になります。

開発者側の視点でみると，メジャーバージョンアップは互換性を壊すような変更を行える唯一のチャンスであるため，あれを入れたい，これを入れたいとなって，リリースがずるずる引き伸ばされがちな傾向があります。

規模が大きなソフトウェアにとって，スピード感の低下は避けられない問題ではあるものの，開発コミュニティ内ではオープンに議論が行われ，リリースを行うことができたという点では，健全な状態にあるといえます。

Hadoop 3.0.0と同じタイミングでHadoop 2.9.0もリリースされたため，現在では2.7，2.8，2.9，3.0という4つのブランチが，メンテナンスされている状態になります。パッチのバックポートなどの維持コストが上がるため，あまり多くのブランチをメンテナンスし続けるのは避けるべきですが，開発コミュニティとしていつ止めるかの明確な方針があるわけではありません。あるバージョンの維持が必要なニーズがあって，リリースマネージャ役を務めるコミッターがいれば，メンテナンスが継続されるようになっています。

Sparkの動向

Sparkについては，バージョン2.2が2017年7月にリリースされました。このバージョンの大きなトピックのひとつはStructured Streamingがアルファ版を卒業したことです。これを皮切りに，今後プロダクションでStructured Streamingを活用した事例も次々と登場すると予想されます。またSpark SQLにはコストベースの最適化エンジンが試験的に導入されました。

これまでのルールベースの最適化エンジンでは，複数のテーブルを結合して中間データが膨れ上がるケースの最適化が苦手だったり，I/O量が最小になるように複数のテーブルの結合順序を入れ替えるような最適化ができませんでした。新たに導入されたコストベースの最適化エンジンではそのような"より賢い"最適化が可能になります。現時点ではまだまだ荒削りな実装ですが，2018年中にはプロダクションレディーな完成度に到達するでしょう。

Structured Streamingは先述のとおりアルファ版を卒業してAPIが安定してきましたが，機能追加や実装のブラッシュアップは依然として活発に行われています。Structured Streamingでは現在マイクロバッチベースのストリーム処理エンジンが内包されていますが，一桁ミリ秒オーダーのレイテンシを達成するために新しいストリーム処理エンジンの開発が進められています。

この処理エンジンは，2018年にリリースされるバージョン2.3，もしくは2.4でSpark本体に導入されることが予想されます。Sparkがカバーできるユースケースが更に広がりを見せるでしょう。

Kubernetesの成功とHadoop/Spark

実行基盤としてのDockerが急速に普及し，その管理フレームワークであるKubernetesが大きな注目を集めました。KubernetesはGoogleがオープンソースソフトウェアとして公開した，サードーバーティのツールでしたが，事実上の標準といえるほどユーザに利用されるようになり，2017年10月にはDocker公式のオーケストレーション機能としてサポートされることが発表されました。

昨年の記事でも，Googleがオープンソースソフトウェアに積極的な関与するようになったことに言及しましたが，Kubernetesの成功はそれを象徴する出来事であると感じられます。

アプリケーションを実行する基盤という観点では，HadoopにはYARNと呼ばれるリソース管理フレームワークがあり，タスクをDockerコンテナとして実行する機能も提供しています。Kubernetesに慣れたユーザが増えることで，機能性や使用感で影響を受ける場面があるかもしれません。

Sparkにおいても，従来サポートしていたYARNやMesos，Standaloneなどのクラスタマネージャに加えてKubernetesのサポートが検討され，開発が行われています。