あけましておめでとうございます。
例年、Apache Hadoopを中心に並列分散処理ミドルウェアの動向や展望についてご紹介していますが、今年は特に、Apache Hadoopの開発コミュニティ寄りの視点からお伝えしたいと思います。
2016年のHadoop
2016年9月にHadoop 3.0.0-alpha1がリリースされました。
このリリースは、後方互換性のない変更の影響を、HiveやHBaseのようなHadoopに依存するプロダクトの側で、早期に確認できるようにするためのものです。エンドユーザが利用することはあまり想定されていませんが、新しい機能やインタフェースを確認するために、ちょっと使ってみることはできます。
大きな機能追加としては、HDFSのErasure CodingとYARNのTimeline Service v.2があります。
Erasure Codingは、コールドデータなどを冗長性を下げることなく、効率的に格納するための仕組みです。また、Timeline Serviceは、YARNの基盤上で動作する各種アプリケーションの実行情報、メトリクスを統一的に収集、参照できるようにするための仕組みです。
それ以外の変更点としては、NameNodeがスタンバイを複数ノード持てるようになったり、シェルスクリプトで実装されたコマンド群が整理されたりしています。
いまやHadoopは多くのプロダクトから依存される状態なので、互換性を崩さずに安定性や運用性を向上させることが重要な課題となっています。これは、新機能を追加することに消極的であるというわけではありません。既存のコードパスに影響を与えないように機能を追加することは、既存のコードを変更することよりもむしろ容易だったりします。
ちなみに、Hadoopそれ自体も多くのプロダクトに依存しており、たとえばJSON処理系やロガーなどの汎用的なライブラリのバージョンが、Hadoopに依存する下流のプロダクトやアプリケーションと、バッティングしてしまいがちです。いわゆるdependency hellと言われる状態です。これについても改善の取り組みがありますが、Hadoop 3.0.0-alpha1の時点ではまだ完成していません。Hadoop 3.0.0-alpha2 でかなり改善したようですが、完成と呼べるまでにはもう少し時間がかかりそうです。
さらに広がるプロダクトの選択肢
実際に大規模データの処理を行うためには、利用目的に応じて、分散ファイルシステム、分散処理エンジン、SQLエンジン、キーバリューストア、メッセージブローカー、データフローエンジン、セキュリティモジュールなど、さまざまな機能を提供するプロダクトを組み合わせて利用することになります。
Hadoopを中心とするエコシステムの拡大により前述の機能を実現するための選択肢はどんどん増えていますが、どのプロダクトのどのバージョンをどう組み合わせればまともに使えるのかを把握するのは容易ではありません。ClouderaやHortonworksに代表されるHadoopディストリビュータと呼ばれる企業は、組み合わせて検証したパッケージ一式をディストリビューションとして提供していますが、実はオープンソースのコミュニティにも、「組み合わせて検証」するためのApache Bigtopと呼ばれるプロジェクトが存在します。
Bigtopは元々、ClouderaのディストリビューションであるCDH（Cloudera's Distribution including Apache Hadoop）をビルドするための資材がオープンソース化されたもので、現在ではHadoopエコシステムのプロダクトを広くカバーしています。ビルドしたパッケージをデプロイし、組み合わせての動作を確認するテストもあわせて提供されています。
また、PivotalやHortonworks主導で設立されたOpen Data Platform initiative（ODPi）が発表している仕様の中でも、「Apache Bigtopのテストを通ること」のような形で言及されています。
さらに、Amazon Web Servicesが提供するHadoop環境であるAmazon EMR（Elastic MapReduce）でも、2015年7月にリリースされた4.0.0以降では、Apache Bigtopベースのパッケージが利用されています。
Amazon EMRについては、EMRとしてはサポートしていないHadoopエコシステムのプロダクトを、Bigtopを活用して自分でビルドして、EMR上で使う方法がブログで公開されています。
エコシステムが拡大してプロダクトの選択肢が増えた結果、ディストリビュータやサービス提供者が万人にフィットする環境を提供するのが難しい状況を鑑みると、おもしろい使い方の提案と言えそうです。将来的にEMRや各種ディストリビューションに反映されることを期待して、Bigtopにパッチを投稿してみるのもアリかもしれません。
ちなみに、2016年12月には、日本人の開発者でNTTデータに所属する関堅吾（@sekikn39）がApache Bigtopのコミッタに就任しています。困ったときに日本語で相談できる開発者がいるというのは、日本のユーザにとって助けになるはずです。
Hadoopとクラウドサービス、そしてオープンソース
一時的に大きなデータ処理をする必要がある場合に、Amazon EMRに代表されるクラウドサービスを利用する場面は以前からありましたが、Hadoopディストリビュータ各社も積極的に取り組むようになり、サービスメニューの選択肢と質が拡充しはじめているように見受けられます。
もともとHadoopを使う必要があるほどの大量のデータを持ち、サーバ環境として多数のハードウェアを用意できるユーザは決して多くはなかったため、Hadoopコミュニティの裾野が広がりにくかったという側面がありましたが、クラウドサービスの拡充でHadoopの利用を視野に入れる人が、より一層増えることが期待されます。
特に後発となるクラウドサービスでは、プラットフォームで利用されている技術、仕様がオープンであり、別のサービスから容易に移行できることがアピールされています。
たとえば、Googleはオープンソースソフトウェアにあまり注力していなかった印象がありますが、2015年2月にHBase 1.0がリリースされた際にはAPIの策定に全面協力し、Cloud Bigtableにおいて「open-source, industry-standard HBase API」をサポートしていることをその価値として謳っています。
さらに2016年2月にはCloud DataflowのSDKに相当するプロダクトを、Apache Beamプロジェクトとしてオープンソース化しています。
HivemallがApache Incubatorに
2016年9月、日本発のHadoop関連プロダクトのひとつといえる機械学習ライブラリHivemallがApache Incubatorに採用されたというニュースがありました。2016年を振り返るにあたり、こちらを取り上げておきたいと思います。
ユーザにとって、利用しているソフトウェアが特定の企業やサービスの寿命とは独立に存在し続けることには価値がありますが、この場合、単にソースコードがOSSライセンスに基づき公開されているだけではなく、開発者やユーザを含めたコミュニティが、利用者にとって十分な期間、持続可能な状態になっていることも重要です。
そのような状態を実現するために、Apacheソフトウェア財団（ASF）にはApache Incubatorという取り組みがあります。ここでは、メンターを付けたり、Webサイト、メーリングリスト、ソースコードリポジトリなどのインフラを提供することでソフトウェアプロジェクトの立ち上がりを支援しています。
プロダクトがASFに寄贈され、Incubatorプロジェクトとして活動し、Incubatorを卒業するというのが、Hadoopエコシステムのプロダクトの定番の流れとなっています。
2016年9月には日本人開発者が中心となって、機械学習のライブラリを提供するHivemallがIncubatorに加入しました。今後の発展が期待されます。
2017年のHadoop
2017年はHadoop 3.0がリリースされる年になるはずです。とはいえ、Hadoop 3.0で何かまったく新しいことができるようになるわけではなく、メジャーバージョンアップだからこそできる整理整頓をしてプロダクトとしての成熟度を示すものという位置づけになるでしょう。
不揮発性メモリなど、新しいハードウェアの活用も引き続き期待されます。これはHadoopの既存のコードの延長線上というよりは、新しいプロダクトとして出てくる可能性の方が高いかもしれません。エコシステム全体をみれば多くのユーザが存在し、データ処理基盤をさらに活用したいというニーズがあるという事実が、Hadoopを後押しする力となるのではないでしょうか。
課題がありつつも、並列分散処理エンジンの進化は速く、その影響力も広がり続けています。ぜひ、皆さんには2017年もHadoopとエコシステムを活用して、役立つ、面白い取り組みを進めてもらえばと考えています。
よい1年になりますように！
