国立情報学研究所 佐藤教授が語る「クラウドコンピューティングの将来動向」(ビッグデータ編)

2011年9月7日

8月31日から2日間、都内で行われたイベント「Cloud Computing World Tokyo 2011」。そのイベントへの申し込み段階で最初に満員となったのが、国立情報学研究所 佐藤一郎教授のセッション「クラウドコンピューティングの将来動向」でした。

技術的な背景に基づき、ビッグデータ活用に必要な条件とは何か、クラウドのビジネスモデルはどうなるのか、データセンターの進化の方向性、などについて具体的な解説が行われています。

この記事では、そのセッションの内容を紹介しましょう。

ビッグデータ流行の背景となったMapReduce/Hadoop

国立情報学研究所 アーキテクチャ科学 研究系 教授 佐藤 一郎氏。

分散システムの研究者から見た、クラウドのインフラの話、10年先の話をしようと思います。

fig

1つ目はビッグデータの話題。

ビッグデータの処理技術「MapReduce/Hadoop」は、グーグルが検索の前処理をするために開発したもの。ただ分散システムの研究者から見て、いまのビッグデータの盛り上がりにはちょっと疑問をもっています。

たしかに大規模データを分析する技術は必要。でも、実際にビッグデータを持っている組織や企業は少なく、Web系で大成功した企業など。だからみんなが大騒ぎするものでもない。

また、現在の小規模データを活かせない組織が大規模データを生かすのは難しいと思います。

fig

いまビッグデータが流行しているひとつの背景がMapReduce/Hadoop。MapReduce/Hadoopがなぜブレイクしたかというと、コンピュータの台数が増えると、サーバやネットワークで発生する障害に対応しなければならなくなり、どんどん例外処理が増え、それをプログラマが考えなければならないのだけれど、MapReduce/Hadoopではそれをやってくれる。だからデータ処理の難しいところを考えなくて済むようになりました。

研究者としてMapReduce/Hadoopをみたときに「あ、こんな簡易なのでいいのか」と。MapReduce/Hadoopは、データの依存関係がそれほどでない処理に向いているが、その範囲ならこれで十分といえます。

ビッグデータに必要なのはデータを読む能力

ビッグデータといままでのデータ処理を考えると、いくつかの違いがあります。

いままでのデータ解析は、特定のデータに対して精度を高く解析することが目的でしたが、ビッグデータの特徴は、データを深く分析するのではなく、種類の違うデータを組み合わせて意味を抽出することにあります。

ビッグデータで必要なのは、ビッグデータの中から自分が調べたい性質に合わせてデータを取り出して、それにあった解析をする能力です。これまでのデータマイニングなどと何が違うかと言えば、いままでのデータ解析は網羅的に調べるものだったのに対し、ビッグデータは興味あるデータをつまみ食い的に選んで使うことです。

そのときに必要なのは、データを読む能力。売り上げデータでも顧客データでも、データをながめて特徴を発見したら、それに合った解析手法を選ぶ、ということ。ところがそうした能力のある人はそんなにいないと思います。

しかしそういう人を集めないとビッグデータの処理はできません。

fig

余談ですが、昔MIT(マサチューセッツ工科大学)で人気があったのはデータベース系の研究室でした。そこからYahoo!などに就職できたからです。しかし2年前にはデータベースは不人気になっていて、統計などが人気になっていました。これはつまり、グーグルやYahoo!やマイクロソフトといった企業は、2年前からシステム構築ではなくデータ解析の方に興味を寄せている、ということです。

データにはステークホルダーがいる

もうひとつビッグデータにはマルチステークホルダーの問題があります。

例えばITS(高度道路交通システム)のデータはいまの522万倍になると予想されています。しかしデータのステークホルダーである自動車メーカーが、ITSのデータを自由に公開するかというと、おそらくノーでしょう。

東北の震災のときには、複数の研究機関のセンサーから津波が発生しているという情報が気象庁に伝わっていましたがそれが活かせませんでした。気象庁としては、外部組織のデータの信頼度はどれくらいか、センサーの誤差はどれくらいか、といった情報がないと使えないためです。

データにはステークホルダーがいて、実際にはそのネゴシエーションをしないと使えないのです。

本命は処理時間の短縮

それでもビッグデータの処理は重要です。これは特にデータ処理時間を短縮する意味においてで、ビッグデータ技術の利用法としてはこっちが本命かもしれません。

例えば、バッチ処理に時間がかかり予定時間内に終わらないと、いわゆる「バッチの突き抜け」が起きます。この突き抜けを起こさないように、あらかじめ処理量を超えたデータは捨てているのが現状です。

でも分散処理で処理時間が短くなればたくさんのデータを対象とできます。例えば、売り上げ分析の対象が過去1年から数年分になるなど。1年前のデータだけだと、1年前の天気が雨だったら今日の晴れの日の売り上げ予想には使えませんが、数年分あればそうしたことは起こらないでしょう。

また、数時間かかっていた分析処理が数十分、数分にまで短くなれば、売り上げ予測をすぐに売り場に反映できるようになります。多くの企業ではこのことの方が重要でしょう。

ただし、こういうデータ分析ほど現場で使うものとなります。そのため現場に裁量権のある組織でないとせっかくのビッグデータの分析が活かせなません。(ビッグデータの分析能力以上に)組織にとってはこのことが大事です。

fig

続きは次の記事「国立情報学研究所 佐藤教授が語る「クラウドコンピューティングの将来動向」(クラウドサービス編)」へ。

あわせて読みたい

クラウド Hadoop MapReduce




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本