第3回DBオフライン開催決定！
データレイクって必要ですか？イノベーションを生むためのこれからの情報活用の姿とは？
出演：DBオンラインチーフキュレーター 谷川耕一／日本データベース学会 土田正士
→→ 詳細・お申込みはこちらからどうぞ！
データが増えればノイズも増える
日本でビッグデータに注目が集まり始めたのは、2011年頃からだろう。さまざまな面でデジタル化が進み、大量なデータが発生する。それを集め活用することでビジネスに価値をもたらそうと言うのが、ビッグデータに注目が集まった理由だ。
実際、企業の中のデータも増えているし、オープンデータやソーシャルネットワークのつぶやきなど企業外のデータもどんどん生まれる。IoTでモノから生まれるデータも今後は出てくる。データはたくさんある、とはいえ2011年からすでに4年ほどの時間が経過して、その間に新たにビッグデータを収集、活用し新たな企業価値を生み出せている企業はどれくらいいるだろうか。ビッグデータを活用するために、強力なデータベースと巨大なストレージを導入したけれど、目立った成果が出ていないなんてこともありそうだ。
単に大量のデータを収集し格納して検索できるようにしても、それだけで新たな価値が生み出せるわけではない。新たなIT化で扱えるデータが爆発的に増えても、人が認知し処理できるデータ量は変わらない。データが増えても、それをどう使っていいかが分からないものが増えるのならば、結果的にはノイズのようなデータが増えるだけだ。
たとえばメールも大量にやってくればすべてに目を通すことはできない。どんなにメールクライアントが強力で数千、数万通のメールが軽やかに扱えても、人が1日に読めるメール数はそれほど変わらない。またWebの検索も同様で、検索でヒットする数が多ければすべてに目を通せない。見落とした中に価値ある情報があっても、なかなかそれにはたどり着けないことになる。
つまりは、扱うデータ量が増えれば、それが新たな価値を生み出すチャンスになると同時に、価値あるデータよりもノイズが増え、価値を見つけるのに大きな手間とコストがかかってしまう。データを集めなければ新たな価値が見つからないし、集めると価値を見いだすのに手間がかかる。この矛盾が企業のビッグデータ活用を遅らせている原因でもある。
Web検索では単純なキーワード一致で情報を見つけようとすると、ノイズデータを取り除くことは難しい。Googleはそれをページランク（PageRank）という仕組みで解決して見せた。被リンクの構造を考慮し、それをページの人気投票とみなすことでランキング表示により、ユーザーが望む結果が上位に表示される。この仕組みにより、無秩序で膨大な量のWebのデータが、ある意味できれいに整理される。これでノイズの山が宝の山に変わることになったのだ。
今は使えないけれどあとから使える可能性がある「第3のデータ」
企業が扱う情報は、PageRankのような仕組みで整理するのは難しいだろう。企業内で格納されているシステムも異なれば、データの形式も違うからだ。それらに加え、企業外部のデータも取り込もうとしているのが現状のビッグデータの世界であり、さらに状況を難しくする。
データウェアハウスの時代であれば、ノイズになるようなデータは捨ててしまえば良かった。そう考えると、基幹系システムで利用したり、データウェアハウスに入れたりする企業が日常的に「使える」データと、捨ててしまうかあってもすぐには扱えない「使えない」データという2つだけが企業内には存在したことになる。
ところがビッグデータ活用で新たな価値を見いだそうとすれば、今は用途が見いだないがあとになって役立つかもしれない「第3のデータ」の存在を意識したほうが良さそうだ。この第3のデータを旧来のデータウェアハウスに入れようとすると、データウェアハウスの用途ではノイズが増えることになる。そもそも第3のデータは非構造化データも多いので、簡単にデータウェアハウスに取り込めない。
第3のデータを活用するには、データウェアハウスとは異なる新たな仕組みが必要になる。その仕組みは、有益性がすぐには見いだないのでなるべくコストを下げてデータを蓄積できる必要がある。また溜めずに捨てるデータについても、Stream処理のような方法で発生する段階で価値が出そうなものをより分ける必要もあるだろう。
そうやって集められた第3のデータは、価値がまだはっきりしないので壮大なプロジェクトで対処できない。そこでトライアル的なプロジェクトを起こし、トライ・アンド・エラーで扱うことになる。トライアルの中で何か兆しが見えてくれば、それを本格的なプロジェクトへと昇格させる。
用途が定まらず大規模なITシステム化の決断はできないが、捨ててしまうと将来のイノベーションが失われる「第3のデータ」を溜める仕組みを、最近では「データレイク」と呼ぶようになった。
データレイクの構成と要件
データレイクにはどのような要件があるだろうか。まずは、膨大なデータを蓄積できることが必須だろう。それも継続的にデータが増えるので、拡張性があることも重要だ。さらに、データが増えてもレスポンスが変わらないといった性能も求められる。当然ながら、なるべくコストを抑えてこれらを実現したい。
そうなると分散型のKey-Valueストアーなどが頭に浮かぶ。なので、多くのベンダーのデータレイクのソリューションではHadoopが大きな構成要素となることが多い。とはいえ、Hadoopの仕組みだけがあればいいわけでもない。企業内には基幹系システムで使っている構造化データもたくさんあり、それだって新たにビジネス価値を生み出すには必須だ。
なので、データレイクにはリレーショナルデータベースのOLTP処理の仕組みを取り込むものもあれば、リレーショナルデータベースとデータレイクを透過的に連携させる構成もある。さらにはHadoopとリレーショナルデータベースという組み合わせだけでなく、他のNoSQLデータベースを中核にしてデータレイクを形成する場合もある。どの構成が正解ということではない。それぞれにメリット、デメリットがあるはずだ。
この他にもデータレイクには、捨ててしまうデータから可能性のありそうなものを抽出しておくためのストリーム処理との連携もいる。さらには可視化を行うためには、既存のBIツールへの対応も求められるだろ。容易に必要なデータを取り出すためには、非構造化データにも構造化データにも透過的にアクセスできる仕組みも欲しいところだ。これには使い慣れたSQLを利用したいともなる。また効率よく大量データから知見を見つけるためには、高度な統計処理や機械学習、情報と情報の関係性を明らかにするためのグラフ処理なども欲しい。
要件は多岐に亘るが、データレイクを構成するためにまったく新しいテクノロジーが必要というわけではなさそうだ。NoSQLを含む今ある各種データベースの機能や周辺ツールを組み合わせることで実現できるだろう。今後はこのデータレイクが、企業が新たなイノベーションを起こすために必要な情報活用基盤となるのだろうか。DB Onlineではデータレイクを1つのキーワードにして、次世代の情報活用基盤の姿を改めて探っていきたい。
そんな取り組みの第一弾として、DB Offlineイベントを企画している。データレイクで活用するデータベースとはいったいどんなものなのか、前回のSQL編でも興味深い話をしてくれた日立の「Dr.SQL」こと土田正士さんをゲストに迎え、掘り下げていく。得意のSQL標準化の観点からも、今後の情報活用基盤の姿が垣間見られるはずだ。
