1月21日、東京ビッグサイトにおいて日本Hadoopユーザ会主催のユーザイベント「Hadoop Conference Japan 2013 Winter」が開催されました。今年で4回目となるカンファレンスですが、事前登録者数1,000名超、3トラック21講演を終日、東京ビッグサイトで行うという、いちオープンソースのユーザイベントとは思えない規模の開催となりました。
基調講演が行われた東京ビッグサイト 国際会議場の模様
本稿では午前中に行われた基調講演のうち、Hadoop生みの親であるDoug Cutting氏のビデオメッセージの内容を中心にその模様をレポートします。
1000名超えの参加者はHadoop普及の証？
基調講演の冒頭、日本Hadoopユーザ会の会長である濱野賢一朗氏が開催にあたっての挨拶を行いました。2009年から開始された本カンファレンスですが、「 初回、2回めは300名程度の参加者だったが、昨年は1,000名を超えた。そして今年もその勢いのまま1,000名を超え、会場も東京ビッグサイトになった。コミュニティレベルでの開催としてはそろそろ限界に近づいているかもしれない」と、すでにユーザカンファレンスの域を超えた規模になっていることを明らかにしています。
開会挨拶を行う濱野賢一朗氏
本カンファレンスが多くの登録者を集めたということは、Hadoopの普及が日本でも本格的に始まったということのあらわれなのでしょうか。濱野氏はここで登録者を対象に行った事前アンケートの結果を紹介しています。
まずユーザの範囲に関しては「劇的に変化しているということはなく、使っているユーザの経験年数が増えている。とくに（Hadoop使用歴が）6ヵ月未満というユーザの割合が減って、使い続けているユーザが多くなっているという印象。ということは、新規で使いはじめる人はまだ少ないのではないか」と語り、Hadoopが本格的に普及しはじめたとは言いがたい状況にあると指摘しています。
Hadoopの本格的な普及を妨げている要因のひとつとして濱野氏が挙げたのが「謎が多いHadoopのバージョン」です。周知の通り、Hadoopには大きく2つの系統があり、また開発スピードが非常に早いため、ただでさえ複雑なバージョンの存在がよりわかりにくいものになっているとのこと。それを裏付けるように「Hadoopの導入予定があると答えた人も、バージョンとなると決めきれていないケースがほとんど」（ 濱野氏）だったそうです。
なお、Hadoopユーザに最も使われているのはやはり0.20系で、ディストリビューションではCDH 3がトップという結果でした。また、Hadoopエコシステムではどのプロダクトを利用しているかという質問に対しては、HiveやHBaseといった回答が多かったそうです。
ためらうな！Hadoopを使い続けろ
濱野氏は続けて、Hadoop生みの親であるDoug Cutting氏のビデオメッセージを紹介しました。現在はClouderaでチーフアーキテクトを務めるCutting氏ですが、本当ならば今回のイベントのために来日したかったとのこと。残念ながらどうしてもスケジュールの調整がつかず、来日はかないませんでしたが、日本のHadoopユーザのために「Beyond Batch the Evolution of Apache Hadoop」と題したビデオメッセージを送ってくれました。ここではその概要を紹介します。
Cutting氏は“ Hadoop” の名前の元となったゾウのぬいぐるみを手に登場
「Hadoopはとてもポピュラーな存在になった。一方でそのことを不安に思うユーザから"いまはHadoopバブルじゃないのか"という声を聞くこともある」とCutting氏。そんな質問を受けたとき、同氏はきまって「ためらうな! Hadoopを使い続けるんだ。なぜならHadoopには力強い未来があるのだから」と答えるそうです。Hadoopの前途は明るいものだと信じて疑わないと断言するCutting氏。
では"Hadoopの力強い未来"の根拠はどこにあるのでしょうか。まずは歴史から、ということでCutting氏はHadoopがバッチプロセッシングシステムとしてプロジェクトがスタートした経緯を振り返っています。テラバイト級、あるいはペタバイト級の大量のデータをバッチ処理するために誕生したHadoopは、シンプルで、汎用的で、効率的でパワフルな分散処理コンピューティングを可能にしました。とくにバッチエンジンとしてのMapReduceは非常に効率性にすぐれた処理モデルでした。加えてCutting氏は、「 PigやHiveといったコンポーネントがともに成長したことも大きい。開発者に余計な負担をかけずに済んだ」と振り返っています。
データはあればあるほど分析に役立つ
しかしHadoopが急激な普及を見せた背景には、やはりビッグデータというトレンドの到来を切り離して考えることはできません。Cutting氏は「ビッグデータをバンドルするのはバッチだけではない。ビッグデータにおけるより重要なテーマはスケーラビリティだ」と指摘しています。大量のデータを処理するためには当然、バッチ処理も必要ですが、Hadoopがもともと備えているすぐれたスケーラビリティこそが、ビッグデータへの新しいアプローチとして認識されることになったというわけです。
HadoopのスケーラビリティについてCutting氏は
分散と信頼性
コモデティハードウェア、OSSなどのコストパフォーマンス
Schema on Read
アルゴリズムよりもデータ
を特徴として挙げています。とくにテラバイト級、ペタバイト級のデータを処理する必要がある企業にとって、ITコストを抑えることは非常に重要です。「 トラディショナルなエンタープライズストレージに比較して1/10の価格で10倍のデータ量を格納でき、しかもOSSなのでライセンスフリーに加え、プロセッサを追加デプロイしても追加コストがかからない」（ Cutting氏） 、つまり単なる並列分散システムというだけでなく、コスト的にもスケーラブルだったことがHadoopの普及に大きくつながったといえます。
Hadoopのスケーラビリティ
もっとも企業ITにとっては信頼性も欠かせない要素です。「 1台のコンピュータではコアをたくさんもつことはできない。だからHadoopはコモデティを並列分散するシステムになっている。この場合、信頼性を担保することが欠かせない」とCutting氏は強調します。「 1台のマシンがダウンするのは年に一度のことかもしれない。しかし365台運用すれば、毎日どれかのマシンが落ちるということになる。3,600台になれば、2、3時間に1台は動かなくなる計算になる。つまりスケーラブルなシステムとは、どのシングルコンポーネントがいつ落ちたとしてもも、その状況をサバイブできなくてはならない」 。ノードが1台壊れても、すぐさま別のノードが代わりとなることができる点も、Hadoopが高く評価された理由のひとつです。
さらにCutting氏は続けて、データベースとしてのHadoopがもつ"Schema on Read"という特性に触れています。既存のリレーショナルデータベースは"Schema on Write"、つまりスキーマを設計し、テーブルを作成し、それからデータを追加して、クエリをかけます。しかしこれではスキーマのサイズからあふれるデータ、たとえばテラバイト級のデータなどは扱うことはできません。スキーマを変更するには、いったんテーブルをリロードする必要があります。
一方、Hadoopで採用している"Schema on Read"は、最初にデータを「ラフなフォームのままで1ヵ所に」（ Cutting氏）ロードし、クエリをかけます。スキーマを設計する必要がない"スキーマオンザフライ"を可能にしているということは、データサイズの制限に縛られないというスケーラビリティを意味しています。
Hadoopのスケーラビリティを特徴づける最後の要素が"アルゴリズムよりもデータ"を重視するスタイルです。Hadoopは大量の生データを収集することを得意とします。「 大量のデータ処理にはシンプルなアルゴリズムが適しているに決まっている。複雑なアルゴリズムはかえってデータを見えなくし、本質を失わせる」とCutting氏。複雑なアルゴリズムによるデータ解析を試みるよりも、単により多くのデータを集めることこそが、最も効率的な解析につながるというCutting氏の哲学が伝わってきます。「 解像度が高い画像のほうがよりよく見えるように、データがあればあるほど正しい分析につながる」 ─ビッグデータ分析の本質をついている言葉といえるかもしれません。
HBaseはHadoopの欠けた部分を補完する
ビッグデータというトレンドに押されるようにして大きな普及を果たしたHadoopですが、今後はどういう道をたどっていくのでしょうか。その行く末を占う存在がHadoopエコシステムのひとつであるHBaseだとCutting氏は言います。
HBaseは最近話題のカラムナー型（列指向型）のNoSQLデータベースです。HDFS上に構築できるオンラインKVSで、「 Hadoopエコシステムにおいて、はじめてバッチ処理以外のために作られたプロダクト」（ Cutting氏）として、ある意味エポックメイキング的な存在として位置づけられているようです。
Hadoopが苦手とするランダムアクセスもリアルタイムで行えるデータストア環境であるだけでなく、バッチ処理、つまりMapReduceを同時に扱うことも可能です。Cutting氏は「バッチエンジンともインテグレードできるHBaseはHadoopに欠けていた部分を補完する存在。Hadoop本体とのインテグレートが容易であることはHadoopエコシステムのメンバーであるためには非常に重要なことで、HBaseはその好例」とHBaseを高く評価しています。実際、冒頭の濱野氏の紹介にもあったようにHBaseのユーザは国内でも徐々に増え始めており、「 バッチコンピューティングもHBaseから始める」（ Cutting氏）という人もこれからは多くなるのかもしれません。
ビッグデータへのニーズが存在する限りHadoopの未来は明るい
今後も輝かしい未来に向かっていくため、Hadoopはどこをめざすべきなのか。Cutting氏が指標として提示したのがGoogleの技術です。もともとGoogleの開発したMapReduceとGoogle File System（GFS）がHadoopのベースとなっており、同様にSawzallがPigとHiveに、BigTableがHBaseに、とGoogleのそれぞれのプロダクトをベースにHadoopエコシステムがオープンソースで開発されてきました。最近ではGoogleのDremel/F1を下敷きにしたオンラインクエリエンジンのImpalaをClouderaが発表しています。この流れで行けば、次にHadoopプロジェクトがめざすのは"世界初の地球規模のデータベース"といわれるSpannerをモデルにしたプロジェクトになる可能性は高いとCutting氏。
Googleが道しるべ？
もっともCutting氏は「Hadoopはすでに単独のプロダクトではなく、さまざまな技術が複合されたビッグデータのための汎用的なプラットフォーム」と位置づけています。つまりビッグデータとHadoopはすでに切り離せない存在であり、そのニーズにしたがってさまざまなHadoopコンポーネントが派生する可能性を示唆しています。実際、ImpalaもHiveより速いSQLライクなクエリエンジンを求めるニーズから生まれたもので、「 （ Impalaは）まだ最初のステップの段階にあるものの、ビッグデータの未来のために登場した技術。これからさらに前に進んでいく」とCutting氏は評しています。
Hadoopエコシステムのもと、これからもさまざまなプロダクトが生まれ、もしかしたら廃れていくものもあるかもしれません。しかしビッグデータへのニーズが存在する限り、そして世界中から開発者が開発に参加している限り、Hadoopというあらゆるスケーラビリティを備えたオープンソースのプラットフォームが消えてしまうことはない─Apache Software FoundationのチェアマンでもあるCutting氏はこう確信しているようです。
「良くも悪くもHadoopは開発のスピードが速い」と濱野氏は冒頭の挨拶でこう語っていましたが、Hadoopの利用フェーズはMapReduceプログラミングだけでなく、HBaseのような比較的使いやすいフロント部分に拡がっているようにも思えます。新たなプロダクトとともに新たなユーザ層が増え、Hadoop自体も変化していく─単なるバッチ処理システムからビッグデータ時代のメインプラットフォームとして、確実な進化を重ねているのは確かなようです。
