"BigData"では何が問題なのか？
”ビッグデータで奇跡が起こる”
はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。
従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基本的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。
とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある（と思う）。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の２点だ。
1 Webのログ解析
というか「ネットのログ」だ。これは本当は階層になっていて、ローレベルはパケットから始まって、より上位になって、最上位はアプリケーション・セマンティクスレベルになる。今は最上レイヤーでデータ量的にギブアップで、その処理がビッグデータになっている。具体例でいうとレコメンデーション処理等になるかと。
この手のアプリケーションレベルのログというのは「なんか解析すれば、おもしろいデータが出てくるかも・・・」っていう期待は昔からあって、いや昔から分析はしていて、それであんまり役になってないわけです。そういう意味ではレコメンデーション処理は久しぶりのヒットであるとは思う。そもそも、この手の分析系が駄目な理由は大きく二つあって、まずはベストプラクティス的な「決定的利用法」がなかなかないということと、そのプラクティスを実行するのにオーバーヘッドがかかりすぎる、ということ。特に後者はハードルが高い。
「レコメンデーション・エンジン」というのは、プラクティスとして、わかりやすいのと、何より実行しやすい、というのがポイントだったと思う。E/U環境に直結すればいいので、他のフロントの”実行部門”や”関係者”を説得する必要がないわけで。この先は、レコメンデーション・エンジンを越える使い方がでるのか？ということだと思うけど、ここ数年は出てない気がしますし、今後のプラクティスのセマンティクスとしては、レコメンデーションを越えることは難しいかなと思います。
あとは本来的にはデータ階層で、どこまで下位にいけるか、という話になるはずです。アプリケーションレイヤーだけではなくて、もっと下位のミドルレイヤーから下の例えばパケットだとか・・ただし、最下層はもう完全に無理だと思う。なにしろ量が多いので、ちょっと現実的ではない感じもする。Googleような会社は当然トライはしていると思うけど。どうなのかはよくわからない。・・まぁビッグデータがない、とお嘆きの方は、その辺のサーバーのパケットダンプでも延々取っていればあっという間にお手製の”ビッグデータ”ができるので、その辺は心配ご無用です。意味があるかは別ですが。そんな位置付けかと。
2ハードウェアのセンサーデータ
これだ。今後の焦点はこっちですね。これは、ちょっと博打な感じがします。GPS・計量メーター・家電・電気・水道・ガス・車・輸送系・・・枚挙暇がない位に環境はあるし、ネットワークでつながりつつある。ポイントとなる、プラクティスと実行オーバーヘッドで考えてみる。
まず、実行のオーバーヘッドですが、これはやりようによっては下がるとは思います。そもそもセンサーデータが組み込みなところからくるので、これをまた組み込み的に返してやる道ができれば比較的やりやすいかな、と。勿論、内部の政治的なものはあるとは思いますが、結果のフィードバックに人を動かす必要がない、というのは大きい。逆に言うと、適切なプラクティスが見つかるかどうかが鍵になると思う。これは間違いなくドメイン固有のものなので、それぞれの業界で試行錯誤が繰り返されるでしょう。組み込みにしろ、FAにしろ、先読みによる制御や情報のフィードは、ある程度やれてるという話も聞くので、まぁ可能性は高いでしょう。ただし、この辺はCEP的なものも有効ではあるとは思います。
むしろ敵はコストかな、という気もします。この手のマーケットは、ボリュームが出る分だけ単価ベースで見たときには微妙なことが多い。特に、ソフトウェア系は長らくハードのおまけ的な扱いもあり、ちゃんとした付加価値ベースでのビジネスになるか、というとちょっと疑問な感じ。
上記の位置付けは、マスコミや人口に膾炙している感もあり、まぁそうでしょうね、というのは異論も少ない。
さて、問題は1,2以外の話。
というのは、現在のビッグデータのビジネスのラインは、DWHってやつになっています。なぜかというと、現在の一般マーケットでのBIってのは、ほぼすべて、このカテゴリーでビジネスを展開されているからです。フロントエンドで昔のBIパッケージ＋バックエンドにHadoopという、ある意味で黄金の組み合わせ。現状では、まぁこの組み合わせでないものを見つける方が難しい。笑ってしまうのが、日本だけではなく、海外も含めてこういう展開になっていること。上記のWebのログ解析は普通にユーザー企業さんの中でやってしまって、ベンダーはお呼びではない。またセンサーデータは、さすがにR&Dの域を出ていないし、むしろ組み込み系万歳的は話なので、ちょっと遠いという人の方が多い、というベンダー事情もありますね。
・・・本来は、1,2の目的のはずが、手元のビジネスは、既存のDWHの延長で戦っているわけで。
まず、この辺のマーケットはどうか？というと大体以下の相場だ。
まずCRMでBIでも良いが、大体の市場は箱込みで3000万円、これは割と500億〜3000億円程度の企業規模のケース。取引が兆単位の会社になると、億の大台にのることもある。まぁそんな感じだ。かつ、値引き競争でレッドオーシャン状態ですね。30mってのは以前の相場で、今は10mも切っているなんて話も聞きます。うへぇ・・
その上、実はマイニングで問題になっているのは、機械学習のような高度な推論ではない。言ってみれば「只の集計」である。”まともに結合が終わらない”。いや、ビッグデータとかいいから普通に処理を終えてくれ、というのが現実です。たしかに、一時は金とハードで解決って方向で一回倒したけど、気づけばサポート料率の値上げが、まさかのペースで進んでまして、もう無理です。現在のRDBMSは、特にトータルのコストパフォーマンスでは割に合わないことが非常に多い。まずは、ここ解決しないといけない。そこを見ないで、「おお、さすが新型w」とか言って、飛びつくのもどうかなと。処理問題が解決しないのに「いや、Hadoopがですね！機械学習がですね！」といって客先に売りにいくと確実に玉砕するわけです。「その前に、これどうにかしろ」といわれてしまう。
かくしてHadoopは只の集計マシーンになるわけで。まぁ現実的というか、夢がないというか。
んで、実際のなにが問題なのか？ということはこれは実はViewマネージメントがうまくいっていないということに他ならない。
結合のパフォーマンスを見るのであれば、まずもって事前結合が基本になるので、こうなると、組み合わせ爆発をどう処理しきるか、という勝負になる。DWH回りでは、スター・スキーマみたいな”デザイン・パターン”が主流ですけど、これはDWHというビジネスドメインでの、結合処理を最低数にするための方策に過ぎない。結合しないで集計結果を提示する方が圧倒的にパフォーマンスは良いわけで、その辺のバランスをどう見るかに、ほぼすべてが依存するというが実体でしょう。提示すべきviewが、級数的に増えるケースはこれはもう論理的にどうしようもない。例えば、１万倍になりました。これ到底無理ですね。ただし、100倍〜1000 倍のオーダーだとどうか？現行だとやればなんとかなるんじゃね？的な話はある。この辺は、完全にRDBMSの領域もかぶってくるので、あれやこれやで結構話題にはなる。
HadoopBIで真面目に商売しようとベンダーの方が思ったら、まずこの辺を片付けないと駄目ですね。ところがここは結構、真面目にやってないことろが多い。単純につなぎましたとか、Sqoopで行けますとか、入っていくのはOKですけど、帰りはHiveでいんじゃね？とか・・・ちょ それアドホック前提じゃないすか？DWHの集計とか、これ大抵はパターン処理です。まぁ、つながればいいですよ。という感じでいくと、・・・そうです。例のアレですね。これはいつか来た道、デジャブな感じ。個別の作り込みSIでこんなはずじゃなかったプロジェクト、挙げ句の果てがメンテ不能。
この場合は実は、皮肉なことですが結果がビッグデータ（というほどではないですが、RDBMSではハンドルできない程度には大きなデータ）になります。今時の”ビッグデータ”はPバイトクラスから、抽出処理をして、絞っていく形になるので出口はビッグデータではないですが、定型マイニングの方は入り口はスモールデータで、組み合わせ計算を全部やりきって、気づいたら出口がビッグデータでした、なんてことになりかねない。というか、なってるし。
つまりですね。言われているビッグデータでのソリューションは、たしかにあるにはあるのですが、主戦場はそこではなくて、足下の203高地で突撃戦やっとるわけですよ。ビジネスでも、技術でも。これが現在の”ビッグデータ”。
さて、どーするという話になるわけですが、個人的には、逆にこの辺に次の「鍵」があるような気がしてならない。すなわち、Viewマネージメントのアーキテクチャ。クラウドの非同期処理のViewというのをどうするのか？というのは存外おもしろいと思う。
「課題があって、解決案が必要とされる」というのはイノベーションの発生の前提条件ですからね。amazonさんの例のアレもありますし。
