LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

Hadoop Conference 2011 参加レポート (2)

こんにちは。ネクストの吉次です。

日本 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
リソース管理-
ジョブ
スケジューリング
--
ジョブ監視--
Resource Manager プロセスは、各マシンで起動する Node Manager というユーザープロセス管理用サーバプロセスと協調して動作します。 Application Master は、 Resource Manager に要求してリソースを調達し、 Node Manager と連携してアプリケーションの実行とタスクの監視を行います。 Resource Manager は、どのノードにどのリソースを割り当てるかという仕事だけに注力すればよいので、旧 JobTracker と比較すると実装がシンプルになったそうです。

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 を補完するフレームワークを作り出す組織も徐々に登場しつつあります。今は「補完」ですが、そのうち「代替」する技術になっていくと私は予想しています。今回のカンファレンスへの参加から、私はむしろこれらの技術に可能性を感じました。

*1:Apache ZooKeeper:クラスタの保守管理サービスを提供する集中型サービスソフトウェア。

*2:実行中だったアプリケーションははじめからやり直しとなる。

*3:新旧アプリケーションの API 互換性と新旧サーバ・クライアント間の通信プロトコル互換性を総称した機能名。

*4:DFD (Data Flow Diagram) : データフロー図。DAG (Directed Acyclic Graph) : 有向非循環グラフ。

*5:DSL (Domain Specific Language) : 特定のタスク向けの仕様記述言語。