ビッグデータの「4V」をテクノロジーはどこまで解決したのか

ブログを書くと決めたものの何から書き始めようか決めかねていたのですが、いきなり細かい話から入るのもアレですし、まずは総論というか、アナリティクス全体についての自分自身の現状認識を書いてみるところから始めてみようかと思います。

あくまで個人的な経験や、そこからくる認識の話ですので、また私とは違った意見をお持ちの方はコメントを頂けると嬉しいです。

The 4 V’s of Big Data

アナリティクスについてある程度ご存じの方は、おそらく「ビッグデータの4つのV」という言葉もご存じだと思います。

「3つのV」の最初の出典はガートナーさんのようですが、それを4つに拡張したバージョンはIBMさんがよく出されていたものです。

• Extracting business value from the 4 V’s of big data http://www.ibmbigdatahub.com/infographic/extracting-business-value-4-vs-big-data

Extracting business value from the 4 V’s of big data | IBM Big Data & Analytics Hub

「4つのV」は以下から構成されています。

• Volume
• Velocity
• Variety
• Veracity

Volumeはデータ量、Velocityはデータの生成される速度、Varietyは扱うデータの多様性、Veracityはデータの正確さを意味しており、ビッグデータではこれらの要素が重要である、またはこれらが特徴である、というものです。

今回は、この4つのVが「テクノロジーによってどの程度解決されてきたのか」、あるいは「そもそもテクノロジーで解決できるのか？」ということを考えてみたいと思います。

（余談ですが、私個人は”ビッグデータ”という言葉は普段はほとんど使いません・・・）

Volumeとテクノロジー

ビッグデータの時代は、まずはこのV、Volume（量）に対応するところから始まったように思います。

Hadoopが世に出てきたのは今から見るとずいぶん前のことになりますが、その時点で、MPPなどのDWHテクノロジーは既に存在していました。

が、コモディティサーバを使ってスケールアウトさせる、ストレージからデータを取り出して処理するのではなく、データのあるところ（ノード）で処理させるというHadoopの思想は、「増え続けるVolumeに如何に対応するか」という問題意識が出発点になっていたように思います。

そのため、Hadoop以降のデータ処理に関連するハードウェアやソフトウェアは、まずはこのVolumeへの対応力を高めるところにフォーカスして開発され、扱えるデータサイズや処理のスループットなどが競われてきました。テクノロジーとしてはMap-Reduce（バッチ）からMPPまで、さまざまなテクノロジーが存在しており、この10年ほどの間にそれぞれのテクノロジーが進歩してきました。

その結果として「Volume」への対応力はテクノロジーの進歩とともに非常に高まってきたと思います。私自身、現在はExadataのユーザですし、周りにはHadoopユーザも多くいますが、数千万、億単位のレコードのテーブルを処理するのは当たり前、というような日々になりつつあります。一昔前と比べると大容量のデータを処理するテクノロジーは大きく発達して、身近に、かつ使いやすくなってきました。

「Volume」への対応力はテクノロジーの進歩が大きく貢献した領域と言えますし、この認識を否定する人はあまりいないでしょう。

Velocityとテクノロジー

2つ目のVはVelocity（速度、頻度）です。

頻繁に、あるいは常にデータが生成され続ける、しかも大量に生成され続けるデータを如何にして処理するか、というのがVelocityの課題です。VelocityもVolumeと同じく、新しいテクノロジーの観点から語られることが多く、多くの人に馴染みのある領域だと思います。

少し前には「CEP（Complex Event Processing）」という名称で有名になりましたし、「ストリームデータ処理」という言葉を聞いたことがある方も多いでしょう。現在もチャットボットやIoTブームの最中でもありますし、そういったコンテクストでは今まさに盛り上がっている領域でもあります。

アクセスログをリアルタイムに収集して集計する、レコメンデーションを行う、あるいはリアルタイムに不正検知のような処理を行う、といった用途もこの領域に属するものになります。

「CEP」というキーワードが流行った頃はテクノロジー先行、イノベーター先行のイメージがありましたが、現在はその頃と比べると現実的なアプリケーションの文脈で語られることが増えてきたかな、という気もしています。

この領域では、最近ではソフトウェアの進歩だけでなくFPGAなどのハードウェアによるアプローチにも期待がかけられており、そういう観点でもテクノロジーの進歩が「Velcoity」への対応力の向上に大きく貢献している領域であると言えます。

Varietyとテクノロジー

3つ目のVは「Variety」、つまり「データの種類」で、ビッグデータの時代になるとさまざまなデータの種類を扱うようになる、という論点です。

「大部分は非構造化データである」という文脈で語られることの多いVarietyですが、必ずしもそれだけでもなく、構造化データであってもさまざまなデータソースからデータを集めてくれば、Varietyのあるデータになります。

例えば、私が以前従事していたヘルスケアの分野では、レセプト（医療報酬明細書）と健康診断のデータを組み合わせてさまざまな分析を行っていました。種類が少ないとは言え、これもやはりデータの Variety を活かす例と言えるでしょう。

そんなデータの「Variety」ですが、実は、この辺りからまだまだ現実的な難題の多い分野であると感じています。言い換えると、「まだテクノロジーが問題を解決してくれていない」と（個人的に）思っている領域であるということです。

一例として、厚労省の「レセプトと検診のデータを突合（結合）できなかった問題」が挙げられます。

何年か前、ちょうど私がヘルスケアの業界でレセプトと検診データの突合処理などを行っていた頃、このようなニュースが出ていました。

• 厚労省の診療データ 約８割が活用できず NHKニュース http://web.archive.org/web/20131103152055/http://www3.nhk.or.jp/news/html/20131103/k10015777731000.html

かなり話題になったので覚えている方も多いのではないでしょうか。私自身も自分の仕事と直結する話題だっただけに背筋に寒いものを感じたのを覚えています。

この事例の場合は、詳細が明らかになるにつれて「そもそもの検討不足なのでは」という指摘も多く聞かれるようになりましたし、このように「複数の個人のデータを結合したい」という際には、今では事前にそれなりに検討がされているのが一般的な状況になってきました。

が、「少し何かを見落としたり間違えるだけでデータがまったく使い物にならなくなる」というリスクは、今もデータ分析の現場に横たわる現実なのではないかと思います。

これもまたヘルスケアの事例ですが、ちょっと前には糖尿病に関連するHbA1cの数値を、それまでの日本標準であった「JDS」から国際標準の「NGSP」に切り替える、という話がありました。

• HbA1cの国際標準化と表記 | 糖尿病情報センター http://dmic.ncgm.go.jp/general/infomation/020/info_07.html

このような単位の切り替えについても、並行運用をするモラトリアムの期間の設定、検診をする組織のポリシー、年度ごとによる違い、過去遡及の考え方、担当者の個人的なポリシーによるクレンジング、アプリケーションの実装やタイミングなどによって、「既存の」データをより多く結合しようとすると、カオス状態に陥る可能性があります。

このように、非構造化データはもちろんのこと、構造化データについても、「そのデータが前提としている状況」はさまざまであり、そのようなデータを集めてきても、思っているほど無条件に簡単に結合・統合することはできません。ここに Variety に対処する現実の困難さがあります。

が、この Variety の扱いの難しさや泥臭さは、現時点ではテクノロジー的解決が困難であり、人間が介在して一生懸命ハンドリングするしかない、というのが実際のところなのではないかと私自身は考えています。

Veracityとテクノロジー

最後のVは「Veracity」、つまり「データの正確さ」で、データをどの程度信頼できているか、という論点です。

最初にご紹介したIBMさんのInfographicによると、ビジネスリーダーの3人のうち1人は自分が意思決定に使っているデータを信用できていない、とのことです。

これはなかなか難しい問題で、しかも variety のところで議論したような問題を抱えていることを踏まえると、「正確性」を担保するための前提においてリスクを抱えている、という現実と対峙せざるを得なくなります。端的に言うと、「veracity以前の問題」ということです。

いろいろ書くと長くなりそうなので詳細は割愛しますが、以下に私の好きな書籍からのフレーズを引用します。（私のプレゼンでよく引用するフレーズです）

「どこから来たのか、どうやって集められたのか、
各フィールドが何を意味しているのか、といったような
情報があまりないデータセットを渡されるというのは、
そう珍しいことではありません」
Kevin Fink 「バッドデータ ハンドブック」（オライリー・ジャパン）

個人的にはこれは本当にその通りだと感じており、

• 自分がよく知らない業界の
• 自分が知らないシステムからの
• 自分が知らない仕様の
• 自分が知らない人たちが作った
• 自分が質問や改善要望すら出せない

そんなデータを渡されて結合して価値を引き出す、というのは並大抵のことではありませんし、その状況で正確性を担保せよというのは無理ゲーに近いのでは、と感じることもあったりします。

これが（特にビッグデータという文脈における） veracity に対する私自身の現時点での認識です。

まとめ

というわけで、今回の話をまとめてみます。

• ビッグデータ、アナリティクスを扱うテクノロジーは確かに進歩してきた
• 特に Volume や Velocity への対応力はテクノロジーの進歩によって格段に良くなった
• 一方で Variety や Veracity については、テクノロジーによって解決されていない部分も多い
• 前提の異なるデータをいろいろ集めたとしても、それらを組み合わせて使うのは簡単ではない
• しかも、これらの課題は既存のソリューションでは解決できない可能性も高い
• データ活用に向けてのボトルネックは、Volume/Velocity から Variety/Veracity に移りつつあるのではないか

データマエショリストの見解としては、どうしても Volume や Velocity へのテクノロジーが注目を浴びがちではあるけれど、次にイノベーションが求められているのは、実は Variety や Veracity にどう対応するのかというところなのではないか、と思ったりする今日この頃です。

これを読んでいる皆さまも、何か感じるところ（賛成の意見でも反対の意見でも）がありましたら、コメント欄なりTwitterなりで聞かせていただけると嬉しく思います。

では、また。

あ、本ブログの新着情報をメールで受け取る仕組みをセットアップしましたので、RSS等を使っていない方はぜひ以下のリンクからどうぞ。

本ブログの新着記事をメールで受け取る