レポート

「Hadoopには力強い未来がある」Doug Cutting氏からのメッセージ─Hadoop Conference Japan 2013 Winterレポート(1)

この記事を読むのに必要な時間:およそ 3 分

データはあればあるほど分析に役立つ

しかしHadoopが急激な普及を見せた背景には,やはりビッグデータというトレンドの到来を切り離して考えることはできません。Cutting氏は「ビッグデータをバンドルするのはバッチだけではない。ビッグデータにおけるより重要なテーマはスケーラビリティだ」と指摘しています。大量のデータを処理するためには当然,バッチ処理も必要ですが,Hadoopがもともと備えているすぐれたスケーラビリティこそが,ビッグデータへの新しいアプローチとして認識されることになったというわけです。

HadoopのスケーラビリティについてCutting氏は

  • 分散と信頼性
  • コモデティハードウェア,OSSなどのコストパフォーマンス
  • Schema on Read
  • アルゴリズムよりもデータ

を特徴として挙げています。とくにテラバイト級,ペタバイト級のデータを処理する必要がある企業にとって,ITコストを抑えることは非常に重要です。⁠トラディショナルなエンタープライズストレージに比較して1/10の価格で10倍のデータ量を格納でき,しかもOSSなのでライセンスフリーに加え,プロセッサを追加デプロイしても追加コストがかからない」⁠Cutting氏)⁠つまり単なる並列分散システムというだけでなく,コスト的にもスケーラブルだったことがHadoopの普及に大きくつながったといえます。

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が道しるべ?

Googleが道しるべ?

もっともCutting氏は「Hadoopはすでに単独のプロダクトではなく,さまざまな技術が複合されたビッグデータのための汎用的なプラットフォーム」と位置づけています。つまりビッグデータとHadoopはすでに切り離せない存在であり,そのニーズにしたがってさまざまなHadoopコンポーネントが派生する可能性を示唆しています。実際,ImpalaもHiveより速いSQLライクなクエリエンジンを求めるニーズから生まれたもので,Impalaは)まだ最初のステップの段階にあるものの,ビッグデータの未来のために登場した技術。これからさらに前に進んでいく」とCutting氏は評しています。

Hadoopエコシステムのもと,これからもさまざまなプロダクトが生まれ,もしかしたら廃れていくものもあるかもしれません。しかしビッグデータへのニーズが存在する限り,そして世界中から開発者が開発に参加している限り,Hadoopというあらゆるスケーラビリティを備えたオープンソースのプラットフォームが消えてしまうことはない─Apache Software FoundationのチェアマンでもあるCutting氏はこう確信しているようです。


「良くも悪くもHadoopは開発のスピードが速い」と濱野氏は冒頭の挨拶でこう語っていましたが,Hadoopの利用フェーズはMapReduceプログラミングだけでなく,HBaseのような比較的使いやすいフロント部分に拡がっているようにも思えます。新たなプロダクトとともに新たなユーザ層が増え,Hadoop自体も変化していく─単なるバッチ処理システムからビッグデータ時代のメインプラットフォームとして,確実な進化を重ねているのは確かなようです。

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Twitter(@g3akk)やFacebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。

バックナンバー

2013年

バックナンバー一覧

コメント

コメントの記入