この記事をtweetする このエントリーをはてなブックマークに追加

掲載日: 2012/06/20

アーリーアダプタと識者が語った!機は熟した?Hadoopによるビッグデータ活用の実際

今後、一般的な企業への広がりも見込まれるビッグデータ。今回は、ビッグデータの主要技術であるHadoopにスポットを当て、早期から活用を実践してきた株式会社リクルート MIT United システム基盤推進室の石川信行氏、そして、Hadoopの技術的側面、市場動向などに詳しいオープン・スタンダード・クラウド・アソシエーションのメンバーであるCloudera株式会社 代表取締役のジュゼッペ小林氏に、導入・活用の実際、具体的な効果、これまで浮上した問題やその解決、今後の展望などを語っていただいた。



――  まず、リクルートではどういうきっかけでHadoopの導入や、ビッグデータ活用に取り組むようになったのでしょうか?

【石川氏】  もともとHadoopを導入した理由は、扱うデータ量が大きくなりすぎて、従来のRDBベースの処理では間に合わなくなってきたということです。大なり小なり、どの企業でもありがちなことでしょうが、例えば、これまでは一晩かければ完了していたものが、翌朝まで回しても終わらないケースが出てきてしまう。そこで、大きなデータをいかに高速にさばけるかという点にフォーカスして、新たなシステムを構築すべく、主にデータウェアハウス製品の比較検討、あるいはHadoopの導入検証などを行ったという流れです。

――  オープンで標準化されたクラウド環境の普及促進を目指す「オープン・スタンダード・クラウド・アソシエーション(OSCA)」では、Hadoopに関しても、情報公開などの様々な活動を行っていますが、導入を検討する企業では、やはりそういうことが契機となるケースが多いのでしょうか?

【小林氏】  結果的には、ビッグデータ活用の目的はほぼ同じと言えます。やはり、データの量が多い、あるいは、データの集約が難しいという課題に対する適用になるでしょう。日本の場合、現在は「何に使うか」「どう使うか」という用途をイメージしていく段階にありますが、これは欧米、特に米国などに当てはめれば、2年ほど前の状況に相当します。当時の考え方としては、あくまでもDWH(データウェアハウス)が中核で、Hadoopの役割としては、従来の手法では不可能なこと、より高速な処理が求められる対象を、専門的に処理するというものでした。

しかし、現在までの2年間でその状況は大きく変わっています。Hadoopは用途目的からインフラ的な存在になり、データから見たITアーキテクチャとしては、データソースに最も近い個所に置くという中心的な存在になっています。これは欧米的な考え方に即した流れですが、極端に言えば、おおざっぱでいいから、とにかく何でも入れてしまおう、と。こうして、まず蓄積という部分にウエイトを置いた上で、それを専門的に活用するために、“周辺”のDWHや高速なNoSQLデータベースなどに必要なデータを入れていく。つまり、Hadoop自体をデータの集約性を実現する“ハブ”にしようというわけです。

――  データソースに近い場所に置くという位置づけに変わってきている理由は何でしょうか?

【小林氏】  まずは、Hadoopが“入れ物”として優れており、しかも、それだけではなく、その入れ物の中で“コンピュテーション”、つまり演算も行えること。“蓄積・集約”しつつ“分析”も可能という、2つが1つになっているかたちだからです。そして、それに加えて、分析した内容を一定の情報の固まりとして見分けつつ、相手側のフォーマットに整えて、DWHなどへデータ移行できるということ。特定用途でのデータ活用というものを意識しながら、それだけではもったいないので、様々な用途で使うことを考えながら“集約”する。日本でもこういう流れが今後出てくると思います。

【石川氏】  弊社でも、最初は高速化という観点でHadoopを導入しましたが、その後は小林さんがおっしゃったのと同じような道をたどっています。Webサイトへのアクセスログなどはもちろんのこと、そのほかの事業データ、外部データなども含めて、すべてをHadoopに持ってきて、そこで演算しようということを進めており、いくつか実装して、実際に事業でも活用しています。

――  そうしたビッグデータ活用は、今後、多くの企業に広まっていくことは間違いないと言えますか?

【石川氏】  弊社の場合は、主にそうした分析により、顧客ごとに最適なコンテンツを提供するといった活用を行っていますが、同様に、行動履歴などを最適な顧客対応に活かすというのは、どの企業でも必要な流れになっているのではないでしょうか。そして、企業がビジネスに生かせるデータというものは、社内はもちろん、外部にもかなりの量が存在しているはずです。いわゆる個人最適のようなことを積極的に取り入れることで、「顧客が離れにくい」「顧客に利用されやすい」状況を作り出せば、売り上げも上がる。そうしたよいスパイラルを回していかないと、競合企業に遅れをとってしまう、差が広がってしまうということですね。

【小林氏】  ビッグデータが「普及するか、しないか」「使えるか、使えないか」という心配はあまり必要はないかと思います。単に今まで以上に低コストで大量のデータが扱えるようになったというだけです。逆に、企業が扱うべきデータ量という観点から見ても、従来は手に負えなかった領域に入ってしまったという事実があります。昔から人間が何かをすれば、情報は生まれていたわけですが、そのすべてをデータ化したり、記録することは到底無理でした。しかし、現在では様々な面でその制限が取り払われ、量的な問題で一定の境界線を越えてしまったので、カバレッジを広げるための新しいやり方が登場した。それがビッグデータと呼ばれるようになっただけだと思います。


このページの先頭へ

――  具体的にはどのような用途に適用していくことになるのでしょうか?

【石川氏】  最終的な出口としては、個人最適のレコメンドを出させるという役割がやはり主体になっています。Hadoopの強みは、先ほど小林さんがお話された「データを蓄積する」ということもありますが、私たちの事業から見ると、ほかのRDBに比べて「非構造データの蓄積に強い」という点が、やはり大きな力となりえます。リクルートの事業はもともと紙媒体を中心に展開してきたこともあり、フォーマットに沿ったデータだけではなく、文章のかたちのままのテキスト、すなわち非構造データも大量に存在します。

これらを解析して、カテゴリ分けしたり、特徴を抽出したり、関係性分析などを行う必要があるのですが、当然、もともとは人がやっていました。ただ、現在のデータ件数は以前とは桁違いで、もはや人の手ではどれほどの期間がかかってしまうかすら分からないレベルです。こうした、人がやっていた作業をコンピュータ処理にリプレースしていく、経験則を分析アルゴリズムへと代替していくというのは、現在最も進めている分野ですし、これからも主体になると思います。

【小林氏】  Hadoopの場合は、従来のDBと異なりデータを取り入れる時には、あえて構造(スキーマ)に落とさなくていい、つまりスキーマ・オン・ライト(Schema on Write)が不要なのです。入れる場所を構造化しなくて済み、データの蓄積時にスキーマ設定やコンバージョンが不要なため、速いし、使い勝手がいいというメリットがある。その特性を生かせる用途には最適だと言えるでしょう。

ただ、前述のように用途別ではなく、インフラ系の集約型といった本来の構造になってくると、もっと別の次元の新たな価値が生まれてきます。つまり、データを1ヵ所にまとめることで、別々の種類のデータの掛け合わせができる。今まで一緒に扱われることのなかったデータがまとまることで、利用する側の想像力次第で、様々な可能性が生まれてくる。分析後、価値と目的が特定できた部分のHadoopデータをDWHやNoSQLなどのスキーマに入れ込んで(Schema on Read)移行し、より詳細な分析をしていくこともできます。それこそがビッグデータの本来の使い方になるもので、インフラになればそれが可能になるというわけです。

――  拡大しつつあるクラウドサービスとの関連性についてはいかがでしょう?

【石川氏】  弊社ではクラウドも使っていますが、Hadoopとは別の環境で動いています。例えば、個人情報の類を扱う場合には、やはり外に出しにくいですし、それ以外の点でも、そもそもクラウドにはメリットもありますが、当然、デメリットもあります。Hadoopで言えば、ロジック的な部分が完全にブラックボックス化してしまうという弊害もあるかと思います。企業によって優先事項が違うと思いますから、ただサービスとして利用できればいいのならクラウドでもいいでしょうし、継続的に分析をしていく中で、システムの最適化を行ったり、使う側のスキルを高めていくのであればオンプレミスのほうがいいかもしれないという話ですね。

【小林氏】  それとクラウド以前に、仮想化ということを考えないといけないと思うのですが、仮想化は資源を効率よく使う、1つのコンピュータを皆で複数のリソースとして使おうという効率化をソフトウェア的に行うことですよね。それはそれでいいんですけど、分散並列処理も似たような目的で動いています。共通の理解を持ちつつ、共同で分散しようという取り決めのもとで動いているわけですが、データとCPUがそれぞれどこにあるのか、できるなら互いに近い場所にあることが保証されなければ、効率的な分散処理は成り立ちません。一般的なクラウド、一般的な仮想化という視点で見れば、そのあたりが保証されていないという不安がともないます。

そして、最も気にしなければいけないのは、もともとのデータがどこにあるかということです。ソースになるデータがクラウドに集まっているのであれば、Hadoopもそこへ行くのが望ましいでしょうし、自社内にデータを蓄積しているなら、クラウドにHadoopを置いて、そこへ巨大なデータを届けるのは効率的ではないかもしれない。まずはデータソースがどこにあるかが重要で、クラウドにするか否かは単純なソーシングの問題でしょう。

――  Hadoop=大規模というのは、やはり前提になるのでしょうか?

【石川氏】  データ量はたしかに大きいほうがいいんですが、米国などで例に挙げられるようなペタバイト単位の情報を持っている企業は、日本ではほとんどないでしょう。数百ギガからテラバイト、せいぜい数百テラくらいまでの範囲の企業が多いと思います。ただ、もとのデータが数百ギガくらいだったとしても、本格的に扱うとしたら結構大変ですし、例えば、そこから回す処理で中間データが大量に出たりとか、ワーク的に使うデータがきわめて多いといった可能性もあります。そういう点を考慮すれば、もとのデータがペタバイト、テラバイト単位でなくても、Hadoopの使い道は大いにあると思います。

【小林氏】  少なくとも、サイズだけの問題ではないですね。データの種類が膨大な場合でも、ビッグデータという概念は当てはまると思いますから。あるいは、分散処理に向いているか、向いていないかという考え方のほうが適しているかもしれません。つまり、シンプルなシーケンシャル処理には適しているし、分散しにくい複雑なトランザクションであれば、高密度の速いCPUが単体で処理したほうがいい。巨大なデータを総なめして、その中である程度の情報を引っ張ってくるというもの、具体的に言えば、統計分析、検索などにはやはり効果的です。

【石川氏】  私がよく例に挙げるのは、中古車情報サイト「カーセンサー」ですね。車種やメーカーごとに区切ったり、あるいは車体カラー、地域などで分けた計算を走らせることが多いのですが、今までは分散処理ができないがゆえに、例えば、特定の地域における軽自動車の販売分析をほかの地域にも当てはめたりするしかなかったわけです。

ただ、そういった分析のやり方、あるいはサンプリング、特に間違ったサンプリングでは気づかない事実もあります。分散処理を活用して全データを対象とすることによって、初めて見出せる統計分析の意味や価値もあり、そこから新たなビジネスが生まれたり、顧客に利便性などのメリットを提供できる。事業としてHadoopを導入したことで、社内から様々な意見をいただきましたが、まさにそうした内容の積み重ねでした。

【小林氏】  そうですね。今まではすべてのデータを扱えなかったので、サンプリングで生じる誤差をアルゴリズムで縮めるといった工夫が必要でした。しかし、データが増えれば「事実に近づく」、または「事実になる」とよく言われます。サンプリングはあくまでもサマリなので、似通ったものを対象として、平均値から何かを想定する場合には有効です。一方で、Hadoopのように全データを扱う際の目的は逆でしょう。平均値を基準とした分析を行いたいのではなく、異常な部分とか、ほかと比べて違う部分だけど、それを見つけたり、意味を見出すことが重要といった場合には、ほかに方法がないのですから。


このページの先頭へ

――  Hadoopを扱う際には、それなりのスキルや知識が必要になるかと思いますが、導入はやはり難しいと言えますでしょうか?

【石川氏】  まず、インフラの構築と、それを用いたアプリ開発という主に2つのフェーズに分けて考えたほうがいいかと思います。インフラに関しては、振り返れば難しかったなという印象はありますが、機器の面では、Hadoopは「コモディティサーバの上で動く」ということが売りになっていますし、実際のところ、移行などで余ったサーバを利用できましたから、特にハードルになるようなことはありませんでした。ただ、弊社が導入を進めた際には、オープンソースという形態ゆえのドキュメント数の少なさや、実際にやってみて気づいた不具合/バグ、あるいは構築して初めて分かったことなども多々ありました。例えば、障害が発生した時に「誰かを呼べばすぐに直してくれる」みたいな考え方は当然ながら通用しなかったわけですが、こうしたサポート周りに関しては、以前と比べれば様々な面で充実しつつあると思います。

一方のアプリ開発については、やはり、ここが最も大きな難関となるのは確かでしょう。要するに、誰もが扱えるのかというと、おそらく「ノー」だと思います。Hadoop特有の分散アルゴリズムであるMapReduceを、Javaなどで直にハンドリングしながら開発を行うのは簡単ではないですから。ただ最近は、Hadoopをより簡単・便利に使うための道具として、エコシステムも発達しています。それらをうまく活用することで、SQLは書けます、シェルを少し使えますといった方であれば、Hadoopを扱えるようになってきている状況だと言えるでしょう。Hadoopが登場してから、時が経つにつれて様々な課題解決も進んでいますから、これから導入する際のハードルは以前に比べれば高くないことは確かです。

【小林氏】  Hadoopは急速に進化し続けていますから、1〜2年前と比べても非常に使いやすくなっていますし、機能も充実してきています。ただ、どんな技術でもそれなりのハードルはありますし、Hadoopが特に難しいとも言えないでしょう。むしろ、問題になりうるのはオープンソースというものに対する姿勢ではないでしょうか。

オープンソースだから費用がかからない。じゃあ、とりあえず、自分たちで導入検証や研究開発の意味合いで使ってみよう。そこまではいいんですが、“そのままのかたち”で商用利用という段階まで行ってしまうのは問題があります。日本の場合は、特にITコンプライアンス上の課題が生じがちではないでしょうか。オープンソースは身近に利用できるものですし、インフラ系に適用すれば大きなメリットが得られますが、事業として利用する場合には、もし何か問題が生じたら、どう対応するのかということを、しっかりと考えて、担保しておく必要もあります。

欧米ではIT監査基準から見た時に、オープンソースを使うこと自体はウェルカムだけど、事業に著しく影響を出さないような手立ても同時に必要となります。その技術を熟知した専門家を確保していなかったり、対応の仕組みを用意していなければ、CIOの責任が問われたり、株主訴訟へと発展してしまう。日本ではそうした意識までは及んでいないのではないでしょうか。

【石川氏】  リクルートは、実験段階では余剰サーバなどを活用して検討、開発を進めてきました。実際の商用化においてはセキュリティ等の非機能面が完備されているオンプレミス環境に設置して利用しています。

――  ハードウェア構成としては、最低限これくらいは必要、これくらい揃えれば最適という要件などはあるのでしょうか?

【石川氏】  リクルートの場合は、最初はスモールスタートで、サーバ5台の構成で始めました。先ほどお話したとおり、データセンタの移行で生じた余剰のサーバを活用しましたから、初めから高性能なCPUをガンガン積んでメモリやストレージも潤沢なサーバなどを用意する必要はないと思います。個人情報の扱いやブラックボックス化の点も特に問題ないようだったら、スタートアップとしてクラウドサービスなどを活用してもいいでしょうね。スペックにあまりこだわる必要はないと思います。

【小林氏】  Hadoopはいわゆる質素な環境でもなんとか走ってくれるので、非常に経済性はいいんですね。ただ、考えるべきは、どう拡張していくかということでしょう。石川さんもおっしゃったように、トライアルの時期はどうにでもなるかと思います。ただ、本格稼働にあたっては、やはり拡張性を計算に入れなければいけませんよね。サーバの占有スペース、ネットワークなどは拡張していかなければならないという前提で、トポグラフィ、区画をきちんと考えておく必要があります。それなりの環境で動いていたとしても、軌道に乗り始めた時に急に止まってしまったり、パワーやリソースが足りないといった事態になるかもしれません。

――  ビッグデータというのは、最初だけではなく、導入後も加速度的に扱うデータが増えていく、分析対象も広がっていくため、それに備えなければいけないということでしょうか?

【小林氏】  相乗効果的に、使えば使うほど規模は大きくなるのは確かです。もちろん、拡大のスピードとしては最初のうちが最も速く、どこかの限界点を過ぎれば、そこからは緩むのでしょうが、雪だるまと同じで転べば転ぶほど、大きくなっていくので、それは頭に入れておかないとまずいでしょう。

【石川氏】  その一方で、CPU、ストレージ、あるいはネットワークなど、ハードウェアのほうもどんどん進化していくわけですから、そういうものにも常に目を配りつつ、うまくバランスをとっていくことが重要でしょうね。

【小林氏】  そうした柔軟性を持つことは大事です。ハードウェアにしても、ソフトウェアにしても、日本の企業では一度導入するとそのまま使い続けたいという意識が強い。それはある程度理解できるのですが、機能面はもちろん、コスト面でも、必ずしも使い続けることが有効と言えないですから。

【石川氏】  まさにリクルートも今、システムの移し替えを始めているんですが、結局、台数が増えていくことでかさんでしまうのが、例えば電気代といったデータセンタのコストなんです。だから、より省エネ仕様の新しいサーバに置き換えるとか、1Uを重ねるよりも高性能な2Uサーバを重ねて台数を減らすほうがよかったりとか、いろいろと勘案する必要があります。そうした、より大きな視点でのコスト意識なども含めて、インフラを扱う際のセンスというか、将来的な読みというのは、今後大事になってきそうですよね。

【小林氏】  高密度とか、省エネというのは、サーバ選定において本当に有効な要素になりつつあるので、やはり最新の動向を追っておかないと、入れたまま何年も使い続けるだけでは、結果的に相当な差が出てしまいかねないですから。


オープンで標準化されたクラウド環境の普及促進を目的に設立された団体。参加メンバーは、デル、インテル、ヴイエムウェア、NTTデータ、エンタープライズDB、オープンソース・ソリューション・テクノロジ、Cloudera、新日鉄ソリューションズ、日本マイクロソフト、日立ソリューションズ、Rackspace、レッドハット、WIDEプロジェクト。ITベンダ、ソリューションプロバイダ、オープンソース関連グループなど各パートナーとの協業関係を構築しつつ、検証作業、技術支援、マーケティング活動などに取り組んでいる。


このページの先頭へ




◆関連記事を探す

ビッグデータ/Hadoopによるビッグデータ活用の実際」関連の情報を、チョイスしてお届けします

※キーマンズネット内の「ビッグデータ」関連情報をランダムに表示しています。

ビッグデータ」関連の特集


フラッシュストレージがこれからのビジネスを支える基盤となる!?ただ処理を高速化するだけじゃない…経営…



 ここ数年、“ビッグデータ”という言葉を多く聞きます。「ビッグデータ!」と盛り上がる前に、「自社のデ…



病気で出すことが難しい「本人の声」を取り戻す音声合成技術研究プロジェクト「ボイスバンク」が始動!音声…


ビッグデータ」関連のセミナー

FinTech時代に求められるDB開発とセキュリティセミナー 【Delphix Software/インサイトテクノロジー】 締切間近 

開催日 12月13日(火)   開催地 東京都   参加費 無料

FinTechサービスを展開するためには、高度なセキュリティを保ちながら、開発速度・生産性を高めることが必須になります。また、サービス提供者にとっては、「差別化…

人工知能(AI)活用実践セミナー 【日本電気】  

開催日 12月13日(火)   開催地 東京都   参加費 無料

近年ディープラーニングをはじめとするAI技術が発達し、実社会での適用が進みつつあります。その中で膨大な画像・業務データの学習・推論・判断をより的確に行うための実…

ビッグデータソリューションセミナー 【NTTデータ数理システム】  

開催日 1月18日(水),3月14日(火)   開催地 東京都   参加費 無料

このようなお悩みを抱えている方、是非ともご参加下さい!・自社のデータでビッグデータ分析ができるのか?とお悩みの方・既にExcelやデータベースでは、集計や簡単な…

「データ分析」関連 製品レポート一覧

このページの先頭へ

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この記事に掲載している情報は、掲載日時点のものです。変更となる場合がございますのでご了承下さい。


30004964


IT・IT製品TOP > ビッグデータ > データ分析 > ビッグデータ > ビッグデータのIT特集 > 特集詳細

このページの先頭へ

キーマンズネットとは

ページトップへ

Hadoopはどのようなメリットをビジネスにもたらすのか。 Hadoopに適している処理。適さない処理。 Hadoop導入はやはり難しい?成功させるには何が必要か。