Jubatusについて - 急がば回れ、選ぶなら近道

先週の月曜日にお披露目会的なものがあったので行ってきた。
ちょいと前半戦は見れなかったので、肝心なところを見てない説もあり、その辺は割り引きたいが、まず印象まで。

基本的なラインは、言ってみれば、分散CEP+機械学習というコンセプト。（ある程度の）リアルタイム性を重視して、データの使い捨てをベースにして、スケールアウト戦略を選択している。溜めてから学習するのではなく、ストリーミングしながらの学習というコンセプトに見える。アーキテクチャはN:Nな感じ。耐障害性はどこまで見ているのか？ってのはあるが、まずはスループットを優先したのと、ボトルネックが発生しないように割と気を使っているのはわかる。おそらくもっとも重視したのは「使い勝手」だろう。

まず、現状の日本のITでは機械学習は使いこなすだけ精一杯という中で、アーキテクチャや仕組みまで考えたフレームワークとして、完全に頭1つは抜けている感もあり、素晴らしいと思う。自分たちの力で「違う」アーキテクチャを提案している、という点でエンジニアリングを強く感じる。そこは高く評価したいし、されるべきだ。なんでもそうだが、1を2にするよりも、0を1にする方が難しいわけで、今回はまさに「0を1にする」ことに挑戦したというところだと思う。

ツールや環境という意味でも、個人的には高い評価になる。例えばMahoutとの比較でいうと、ユーザービリティ視点で見れば、Jubatusに軍配があがる。ぶっちゃけHadoopでひーこら言っている段階で、Mahoutを使い来なすまでは相当道のりがあるのは事実なんで、その点サービサーさえ入ればあとは割と簡単に使える、という点と、そもそもデータを溜めなくてもよいという点でJubatusの方が、機械学習を利用するツールとしては断然上だろう。まぁ溜めた方がよいというアルゴリズムもあるとは思うので、Mahoutの方がラインナップとしては上ですよ、という意見もあるとは思うが、まずHadoop入れて、運用のせて、データ溜めて、それからMahoutってのと、どっかのサービサーの開いた口に気軽に突っ込むだけ、というJubatasとでは圧倒的に後者だろう。自分もどっち使いますって言ったら、Jubatasにすると思う。データを溜めるということがMahoutであれば、溜めないメリットを逆手に取っているのがJubatusであると思う。

プレゼンを聞いていて、個人的にもっとも気になったのはビジネスモデル。

電気使用量とパケットの話が、LTで出ていたが、あれはちょっと微妙な感じではある。そもそもリアルタイムである必要がない気がするわけで。単にパケット情報を溜めなくてもよいです、ってところが利点なんだろうな〜とは思った。ネタ的にはいかにもNTTライクな感じではあると同時に、あの延長線で商売を考えるのがNTTライクなんだなぁ〜、とちょっと感じたりして。

まぁユースケースとかいろいろ考えていてみたけど、個人的に大きくは二つの方向性から検討できる気がしている。

1. CEP的モデル
一つは、まぁベースがCEP的な位置付けではあるし、まぁ他にも使い方はあるとは思うけど、CEPとして見てみましょうと見方ですね。フィルタリングに利用して、なんかのwarningの仕組みとして使う。あるシグナルがきた時に、モデル的に次の状況を予測するとか判断する、というユースケースですね。市場はある程度は限られますが、確実に需要はある。金融系かな〜、実際CEPが使われているのは金融がメインなんで。

ベースとしてはSmart CEPという感じになるモデル。既存の置き換えか、既存の追加フィルターというビジネスモデル。特定の業界でのCEPを使った（感じ）のパッケージは一部とんでもない値段になっているのはよく聞く話なので、そのあたりのマーケットを見ていくというのはありだと思う。パッケージをサービスでリプレースする感じで、CEP的なサービスはありかな、と思う。

2. Yet Another Big Data Usecase的モデル
もう一つは「溜めないビックデータ」という提案だろう。まぁ極論すれば、来たデータを全部その場で正規化して集計して、元データは破棄しますってのとあまり変わりません。集計データ（学習的にはモデルになる）だけ欲しいのであれば、それは正解。中途半端Mahoutよりは全然良いソリューションになるでしょう。レコメンデーション・エンジンも、スループットが上がれば、その場で最適なレコメンドもできるわけで、これはなかなかアドバンテージにはなる。

例えば、とりあえずレコメンドだけ欲しいというスタートアップのWeb系には非常に役に立つだろう。今後のWeb系ではMLでのレコメンドはほぼ必須のサービスになるはずで、そのたびに重たい装備がいるというのは問題がある。のでその意味ではサクっと使えるJubatusは役に立つでしょう。AWS上でのサービサー出てくるだろうし。

また、別のセグメントになるけど、組み込み系でのコントローラー的な役割にニーズはある。一般にセンサーデータ系はデータ量が増えるので処理が勢いビックデータになります、というのが現在の論調。その場合、溜めるというのはやはりいろんな意味でコストになる。そこでデータを溜めずに処理しましょう、というのはマッチする話。全体のイメージは、エンジンをクラウド上において、通信させていくという形になる。まぁこの辺狙っているという話も出ていた。ボトルネックをできるだけ発生させないようにしている点も組み込み系にはプラスになる。

3. 自分的モデル
自分のドメインの流通であれば、受発注情報のリアルタイムクレンジングとSemantic Validation だろうな〜と思います。基本的にはエラー検出だと思う。この手の仕組みは閾値の設定という形で現在使われることが多いが、基本的に硬直的なことが多く、実際は役にはたっていない。MLを導入することで、精度があがるのであれば、十分に目はあるだろう。

Asakusa的にいうと、Windgateとの相性が良い。Asakusaの特長の一つがマルチリソース・マルチアウトプットなので、投入データをフックして、分岐してJubatusに流すというのは、簡単にできる。単純Hadoopだとやりようがないが、外側から制御をかけるAsakusa的には、ひとつの有望なアダプターになる。固定的にはHadoopだけどJubatusも、ってなケースが出てくればいいかなと。

まぁ、最後に、全般的な印象としては、ビジネスドライブであれば、NTTの上の人がもっとビジネスサイドにドライブしないと進みませんよ、とは思う。まぁ、個人的に応援しているので、使える部分は積極的に使っていきます。本音ベースで、Mahoutよりもいいと思う。まぁ要するにそういうことです。