Hadoop Summitが閉幕した。筆者はニュースをカバーするために、米サンノゼで開催された今回のイベントに参加し、分科会の1つで発表を行った。筆者の話は業界の分断に関するものだった。ビッグデータのエコシステムにはベンダーも多すぎ、Hadoopディストリビューションも多すぎ、実行エンジンも多すぎ、Apacheプロジェクトも多すぎる。その結果、製品やテクノロジの市場が複雑になりすぎており、顧客が購入の判断を下すのは極めて難しい作業になっている、というのがその内容だった。
この発表に向けて準備する中で、ニュースに対する筆者の見方に偏りが生じた可能性もあるが、興味深いことに、分科会で筆者が示した課題について、同カンファレンスの出展者の一部も同じ考えを抱いていたようだ。
リリースサイクルに生まれつつある秩序
そのよい例が、Hadoopディストリビューションベンダーによるリリースサイクルの扱い方だ。考えてみてほしい。各ベンダーは、自社のリリースに多くのオープンソースのプロジェクトを同梱しているため、各社のディストリビューションは、リリースサイクルの速い多くのプロジェクトの下流に位置していることになる。各ベンダーは、各プロジェクトの新規リリースで新たに利用可能になった機能をできるだけ速く顧客に届けたいが、一方で、新しいディストリビューションへのアップグレードを頻繁に顧客に強いるのは避けたい。
筆者は米国時間6月28日、「MapR」の新しいアプローチについて報じた。これは、新しいオープンソースソフトウェアを同梱した「MapR Ecosystem Pack」（MEP）をオプションとして別に用意し、完全版のMapRよりも頻繁にリリースするというものだ。Hortonworksもまた、同様の試みを行うことを発表した。ディストリビューションのコア（「YARN」、「MapReduce」、「HDFS」）のアップデートはマイナーリリースで頻繁にリリースし、ディストリビューションの残りの部分については、頻度の低いフルバージョンのメジャーリリースでアップデートするという。
ランタイムに関する合意
Hortonworksが選択したディストリビューションのコアは、「Open Data Platform initiative」（ODPi）のRuntime Specification（ランタイム仕様）と足並みを揃えている。HortonworksがODPiの設立メンバー企業であることを考えれば、これは当然だろう。また、ODPiは今回のカンファレンスで、他のメンバー企業も各社のディストリビューションで同様の方式を採用することを発表した。これには、独自のHadoopディストリビューションを使用してHadoop-as-a-Serviceを提供しているAltiscaleや、やや知名度の低いロシアのArenadataが提供しているHadoopディストリビューション、インドの世界的なシステムインテグレーターであるInfoSysのディストリビューションが含まれる。IBMの「BigInsights」も、すでにこれに参加している。
いくつかのディストリビューションが統合の方向に向かっているのはよいニュースだが、MapRとClouderaはまだODPiのメンバーにはなっていない。実際、この2社の考え方はまったく逆の方向を向いている。また、新しいプロジェクトであるODPi Operations Specification（運用仕様）が事態をさらに悪化させる可能性がある。この新しい仕様は、Hortonworksが自社のディストリビューションで使用しているコンポーネントである「Apache Ambari」を前提にしているのだ。一方Clouderaは、独自のコンポーネント「Cloudera Manager」を持っており、MapRも6月28日に独自のソリューションである「Spyglass Initiative」を発表した。
