読者です 読者をやめる 読者になる 読者になる

hadoopのバージョン表記について

(2012/01/10 追記)

Cloudera 社から hadoop 1.0 に関する公式ブログ記事が公開されました。そちらの方がより分かりやすく正確に書いています。まずはそちらをご覧ください。

先日 hadoop-1.0 がリリースされたことが巷で話題になっています。
話題になること自体は構わないのですが、この 1.0 が実は 0.20 系の派生だということはあまり理解されていないように見えます。
1.0.0 は従来のバージョンナンバリングポリシーで言えば 0.20.205.1 に相当するものです。
つまり、最新版 0.23 で採用された MapReduce2 を初めとする様々な新機能はこの 1.0 には入っていないということです。

わかりやすく図にしてみました。

よって、新機能を試したいとかいう人には全くおすすめしません。
また、上記の通り既存のバージョンとなんら変わりがないので、たとえば象本や徹底入門(0.20/0.21対応)が役に立たなくなったりする、ということもありません。

この記事では、どういう経緯でこの 1.0 が生まれたかについて、その議論の元となったスレッドをまとめながら説明していきたいと思います。


元になった ML のスレッドは以下にあります。(注:非常に長いです)

http://markmail.org/thread/fy4lpwf3xtkyhnj4
http://markmail.org/thread/oxcqfoicm4ukrnlb

最初に

公平を期するために書いておきますが、私は Cloudera の人間です。
なるべく公平に書くよう努力はしますが、内容にどうしてもバイアスがかかる場合があります。
私の文章が信用出来ない場合は元の文章を読んでください。

登場人物

  • HortonWorks(HW)
    • Arun C Murthy
      • スレ主
    • Owen O'Malley
      • Arun とともに、HW の中心人物
    • Matt Foley
      • HW のエンジニア。
  • Apache Software Foundation(ASF)
    • Doug Cutting
      • ASF チェアマンにして Hadoop 開発者。Cloudera の人間でもある
  • Karmasphere
    • Konstantin Boudnik
      • 通称 cos。元 Cloudera
  • Facebook(FB)
    • Dhruba Borthakur
      • HDFS のすごい人。
  • Cloudera
    • Todd Lipcon
      • HDFS や HBase のエンジニア。Cloudera のエースエンジニア。
    • Eli Colins
      • Cloudera のエンジニアのリーダー格の一人。

スレッドまとめ

11月15日、HW の Arun がこのようなメールを投げました。

Folks,

Apache Hadoop has come a long way since our humble beginnings. As a community we've made significant progress, even in 2011 - we've had 3 releases off the branch-0.20-security (0.20.205 being the latest) and we just released 0.23.0 last week, our first major release off trunk in a while.

With hadoop-0.20.205 we finally have an Apache release with both security and HBase support, both critical for the growing ecosystem.

With that, I think it's time to call it as hadoop-1.0. The 1.0 moniker has something we've wanted for a while and I think it's time for us to just ship it. Linus did something similar with GNU/Linux 3.0.

Yes, we could add more features or better it along many dimensions (ala hadoop-0.23), but right now we have a pretty decent piece of software i.e. the feature set in hadoop-0.20.205 is compelling and widely used. We could call hadoop-0.23 (or 0.22) as 2.0 etc. I do think we, as a community, can support compatibility in the hadoop-1.x series, which is the essential ingredient. This isn't a brand new idea, Doug suggested this a long while ago.

Thoughts?

「0.20-security ブランチとして 0.20 系のリリースを続けた結果、最新 0.20.205 ではセキュリティ及び HBase サポートが入った。そろそろこいつを 1.0 って呼ばない? LinusLinux 3.0 でやったみたいにさ。で、0.22 か 0.23 は 2.0 みたいにしようぜ」

という提案です。
実際に 0.20.x は成熟していて、多くのシステムで採用されていることもあるので 0.20.205 を 1.0 と呼ぼうという方向性はそれなりに支持されました。


しかし、議論はそれでまとまったわけではありませんでした。

0.20.x ブランチをどう処理するか

Cloudera の Todd らは、0.20.x ブランチは残すべきと主張をしました。
これらを 1.0 にリネームすることは多くの混乱を招くというのが理由です。
しかし HW の Arun, Owen らは反対しています。
彼らは逆に、今の 0.20, 0.21 ... というバージョンを説明することの方が多大な苦労を要すると主張していました。

結局この議論はその後うやむやのままになっています。

0.20.205 --> 1.x のマイナーバージョン

Cloudera の Eli らは別の提案をしました。
0.20.20x --> 1.x とした方がいいのではないかという提案です。
つまり、例えば 0.20.205 は 1.5 にした方がいいのではないか、ということです。
これにも HW の Arun, Owen らは反対しています。
0.20.201, 202 がないことをどうやって説明するんだ、といった形での反論です。

最終的には知っての通り、0.20.205.1 が 1.0.0 となりました。

0.22

Karmasphere のエンジニアの Cos は 0.22 の扱いについて強く主張しました。
当初 Doug Cutting は以下のように提案しました。

To be specific, I think one of the possible could be sensible:

A. Rename as follows:

0.20 -> 1.0
0.21 -> 1.1
0.22 -> 1.2
0.23 -> 2.0
0.24 -> 2.1

この案は FB の Dhruba ら多数の人に支持されましたが、Cos は強く反対しました。
0.22 は互換性のない変更が含まれているにも関わらず、これでは前のバージョンからシームレスにアップグレードできるように見えてしまう。
0.22 は 2.0 とし、0.23 は 3.0 とすべきだ、という主張です。
こちらの意見もそれなりに支持がされています。

この件については Cos 案が採用されそうではありますが、現在のところ決着がついていません。

提案の修正

と、けんけんがくがくの議論が行われたところで HW の Matt Foley が提案のまとめを行いました。

  • The next release of 0.20-security (formerly expected as "0.20.205.1") to

be 1.0.0, establishing branch-1.0

  • The next release of 0.22 to be 2.0.0, establishing branch-2.0
  • The recent release of 0.23.0 to be 3.0.0, establishing branch-3.0,

from which the formerly expected "0.23.1" may be released as 3.0.1

  • All three code branches to obey the established major.minor.patch

versioning rules going forward.

  • So the next release from trunk to be 3.1.0 or 4.0.0, at the choice of the

then release manager, and the pleasure of the community.

表にするとこんな感じです。

今までのバージョン 新しいバージョン ブランチ
0.20-security の次期リリース (0.20.205.1) 1.0.0 branch-1.0
0.22 の次期リリース 2.0.0 branch-2.0
0.23 の次期リリース 3.0.0 branch-3.0


この案は比較的広く受け入れられています。
0.22, 0.23 のバージョンについてはまだ議論の余地があるようですが。

その後

1.0 については投票が行われ、可決されました。
後は皆さんご存知の通りです。
リリース準備が行われ、先日無事 1.0 がリリースされたわけです。
0.22, 0.23 についてはなぜかまだ投票すら行われていません。
いずれは行われるのでしょうが、詳細についてはまだわかりません。

海外の反応

http://news.ycombinator.com/item?id=3403924

一応自分の立場もあるのでノーコメントで。

バージョニングポリシーに関する Doug のコメント

Doug Cutting はスレッドの中で、hadoop のバージョニングポリシーを説明しています。

One definition is that a major release includes some fundamental
changes, e.g., new primary APIs or a re-implementation of primary
components. MR2 probably qualifies as both. With a large system with
many APIs and components this becomes a rather subjective measure, but I
don't see an easy way around that.

Another definition is that a major release permits incompatible changes,
either in APIs, wire-formats, on-disk formats, etc. This is more
objective measure. For example, one might in release X+1 deprecate
features of release X but still remain compatible with them, while in
X+2 we'd remove them. So every major release would make incompatible
changes, but only of things that had been deprecated two releases ago.
Often the reason for the incompatible changes is new primary APIs or
re-implementation of primary components, but those more subjective
measures would not be the justification for the major version, rather
any incompatible changes would.

Of course, we should work hard to never make incompatible changes...

  • メジャーリリースは主要 API の変更や互換性のない変更を含む
  • しかし直前のメジャーバージョンとの非互換はあってはいけない (deprecated マークをつけるべき)
  • もちろん、互換性をもたせるよう努力することが一番大事だけど

まとめ

最初に書いた通り、新機能を試したい人にとっては 1.0 は全くおすすめしません。
新機能を試したい人は、0.23 ブランチを試すか trunk を使ってください。

1.0 は、あくまで 0.20 ブランチの安定版を使いたいという人向けです。
でも Cloudera からは hadoopディストリビューション CDH が出ていて、こちらは 0.20 をベースにしつつ 0.21 や 0.22、さらには 0.23 以降の多くの機能も互換性を保ちながらとりいれていますので、安定性を求めるならこちらを使うのがおすすめです。

先ほども書いたとおり私は Cloudera の人間ですので、上記の言葉を信じるかどうかはお任せしますが。