こんにちは。ネクストの吉次です。
日本 Hadoop ユーザー会の主催により、2011年9月26日に東京のベルサール汐留で開かれた「 Hadoop Conference Japan 2011 Fall 」カンファレンスの詳細です。
今回の数ある講演の中で、私にとって面白かった「 MapR 」「基幹バッチ処理から見た Hadoop 」と「 Hadoop 0.23 と MapReduce v2 」について報告します。
MapR
「MapR」 (http://www.mapr.com/) は Hadoop をベースとした新しいフレームワーク。 Hadoop との一番大きな違いは、新規に独自の分散ファイルシステムを用いたこと。これにより Hadoop の分散ファイルシステム (HDFS) の持つ欠点 (単一障害点がある、上書きができない、 File Descriptor の浪費など) の解消を狙っています。パフォーマンスは 2～5 倍程度向上したということです。
Hadoop 0.23 の新機能
最新の動向を知ることが私の参加の目的だったので、この講演を今回のメインコンテンツとして紹介したいと思います。
次期安定版であるとされる Hadoop 0.23 では、現行からいくつかの大きな変更点があります。今回の講演ではその中から特に HDFS Federation と MapReduce v2 を取り上げていました。
HDFS Federation は HDFS をいくつかの名前空間に分割することでスケーラビリティを確保するものです。名前空間ごとに存在する Name サーバがダウンしてもデータが失われることはないが、ダウン中はその名前空間内のデータにアクセスできなくなるそうです。
MapReduce v2 による構成変更
MapReduce v2 では、旧バージョンにおける JobTracker (リソース管理およびジョブ スケジューリングとジョブ監視) を、 Resource Manager 、 Application Master という2つのコンポーネントに分割します。 (表1)
表1 JobTracker と Resource Manager の比較
| 旧バージョン | 新バージョン | |||
|---|---|---|---|---|
| Jpb Tracker | Resource Manager | Application Master | Node Manager | |
| リソース管理 | 〇 | 〇 | - | 〇 |
| ジョブ スケジューリング | 〇 | - | 〇 | - |
| ジョブ監視 | 〇 | - | 〇 | - |
MapReduce v2 の耐障害性
MapReduce v2 では、 Hadoop を ZooKeeper*1 と連携させることで耐障害性を確保しています。つまり、 ZooKeeper での監視により、 Resource Manager がダウンしても、すぐに Secondary Resource Manager を起動させます。そして、 ZooKeeper に記録してあるクラスタの状態に復帰します。その時点でキューイングされたすべてのアプリケーションが再起動されます*2。
MapReduce v2 の優位性
MapReduce v2 では、 MapReduce アルゴリズム以外のアルゴリズムを導入可能とするため、ユーザーの選択の余地が広がります。データや MapReduce アプリケーションの互換性といった理由から、アーキテクチャを変えてしまうことには不安がつきまといますが、そこは Wire compatibility*3 を持たせることで過去との互換性を保持させるとのことでした。 Wire compatibility の MapReduce v2 への実装及び統合については、 Owen O'Malley 氏がその必要性をかなり強調していました。データやアプリケーションの互換性が保たれるのであれば、 Hadoop 0.23 にバージョンアップして、可用性とアルゴリズムの柔軟性の向上を見込めるというのはかなり魅力的だと思われます。
なお、現行バージョンの Hadoop はマイナーバージョンアップであってもバージョンアップするとデータの互換性はありません。※アップグレードは可能
基幹バッチ処理から見た Hadoop
そもそも基幹処理と Hadoop の相性はあまりよくないと私は思っていたので、ノーチラス・テクノロジーズ社の OSS (オープンソース) フレームワーク「Asakusa」に関するプレゼンテーション「基幹バッチ処理から見た Hadoop 」は、かなり興味深い内容でした。基幹業務処理に用いる上での、 Hadoop のイケてないところには、
- HDFS 上のファイルの追記や更新ができない
- トランザクション処理ができない
- MapReduce のアルゴリズムしか実行できない
- Namenode の単一故障点問題
などがあります。そこを独自のフレームワーク「 Thunder Gate 」を組み込む事で補い、顧客毎に異なる基幹業務に Hadoop を適用可能とするフレームワークを作り出しています。
私は不可能を可能にしようとするその技術屋魂に感銘を受け、また「これからの SIer かくあるべし」とも思いました。しかし、 OSS 化されているとはいえ、設計技法として DFD-DAG*4 ベースのDSL*5 を用いるなど、一般の企業が導入するには多少の壁 (主に学習コスト) を感じるだろうことも事実です。
しばらく基幹系 Hadoop はノーチラス・テクノロジーズさんの一人勝ちになるのでしょうか?
Hadoop の今後あれこれ
日本における Hadoop は、成熟期に入りつつあるか、その直前だと思います。ノーチラス・テクノロジーズ社やエヌ・ティ・ティ・データ社など一部の先進企業が導入に成功し、それに倣って他の企業が導入を検討し始めた、もしくは導入し始めている時期だと考えられます。
私が想像する日本での Hadoop のこれからは、次のようなシナリオです－－多数の企業が Hadoop にチャレンジし、そして様々な難点 (基幹バッチ処理から見た Hadoop 内でいくつか挙げました) のために、導入し損なって失敗事例が増えていく。バブルがはじけ、結局生き残るのは一部の先進企業のみとなる。もしくは Hadoop を補完もしくは代替するような他の分散処理フレームワークが登場し、多くの企業はそちらへと流れていく－－。
このように私は Hadoop の未来に対してあまり楽観的ではありません。 Hadoop はまだまだ発展途上の技術であり、そのまま発展途上で消えていく可能性も十分にありうると思うのです。一方でノーチラス・テクノロジーズ社や MapR Technologies 社のように、 Hadoop を補完するフレームワークを作り出す組織も徐々に登場しつつあります。今は「補完」ですが、そのうち「代替」する技術になっていくと私は予想しています。今回のカンファレンスへの参加から、私はむしろこれらの技術に可能性を感じました。
