第７回データマイニング+WEB勉強会＠東京で発表してきました。「明日から始めるソーシャルアプリのログ解析」

発表者・参加者双方に有意義な勉強会：データマイニング+WEB勉強会＠東京

@doryokujinです。9/26(日)に行われました、第７回データマイニング+WEB勉強会＠東京で発表してきました。@hamadakoichiさんによるまとめ（発表資料一覧）とTogetterも参考にして下さい。

僕は第6回から参加させていただいていますが、前回に負けじと今回も本当に素晴らしい勉強会でした。
主催者@hamadakoichiさんの創設の思い・目的・進行方針からもわかっていただけますように、発表者と参加者双方が熱い議論を交わしながら進んでいく勉強会です。そんな勉強会に幸運にも発表枠を頂けましたので発表してきました。勉強会の発表はこれが初めてでした。

明日から始めるログ解析1 〜HadoopとMongoDB を活用したソーシャルアプリ解析〜

このエントリーでは、たくさんの方から頂いたフィードバックを元に、発表内容の振り返りを行いたいと思います。

発表の目的

ソーシャルアプリの裏側(ログ解析)の面白さを伝えたい

僕の個人的な気持ちですが、ソーシャルアプリのログ解析は本当におもしろい、そこを伝えたいという気持ちがありました。それはtomiyoichiさんのコメントにありますように、一般のWebのアクセスログ解析の様に「どこのリンクが何回見られた」、「どのリンクからどのリンクに遷移した」といった"ページやセッション"を軸にした解析ではなく、ユーザー1人1人の行動を解析し、「（そのユーザーは）今日誰と何回交流した？」、「今日どんな商品を買った？」、「今日何日ぶりにログインした？」などといった"人の行動"を元に集計・解析を行って、それを元によりユーザーがゲームを楽しんでくれるような戦略を導いていくからです。

ユーザーの行動を解析すること、そして改善の結果がゲームの売り上げやユーザーの満足度にダイレクトに反映されるといったダイナミックさは、ソーシャルアプリならではのものです。今回は具体的な行動ログと解析方法を具体的に提示することで、その面白さを感じて頂ければと思いました。

ノウハウを得るためには外に出て発表して行くしかない

前回のエントリーにも書きましたが、社内1人でログ解析をやっている僕にとっては、外に出て行ってノウハウを発表して、情報やフィードバックを得てこないと、どうしても独りよがりのダメな解析しかできないと考えているからです。そしてそれが自社への貢献につながっていくと思っています。

情報・ノウハウを公開することのリスクの大きさ、その結果得られるメリットの大きさ

今回はかなりの情報を開示しましたが、それは会社自身にとってリスク・メリット双方を天秤にかけた結果の判断でした。そして発表を終えた今でも、たくさんの方からフィードバックを頂き、そこから得たメリットの方が明らかに大きかったと感じています。情報・ノウハウの公開によるリスクとしては

(1) 社員や顧客の個人情報が漏れる、(2) 会社の経営状況が推測される、(3) 社内のノウハウが流出する、(4) 競合他社に真似される、(5) 低レベルな事や誤った情報を公開して会社のイメージを下げる、

のようなものがあって、確かに(1)や(2)はまずいですが、(3)や(4)、(5)に関しては今の解析フェーズではそこまで気にすることないのかなと感じています。そもそも独自のノウハウもあまり蓄積されていませんし、発表した手法もフェーズが変われば変わるでしょうし、真似されるだけの技術があったことに対しては自信が持てますし。

よく「データは宝」と言われ、社外秘としてとても大事に保管されていますが、結局そのまま放置されることの方が多かったりします。「宝の持ち腐れ」とも言いますように何もしないで放置しておくのは非常にもったいないと思っていまして、それならばむしろ外に少し持ち出してさらすことによって、先人から金鉱を探り当てる方法を学んでくる方が僕は重要だと考えています。まあ、この会社自身がベンチャーでしかもとてもオープンな会社で、かつ真似されてもそこに負けないだけの技術力があるという所であったからそれができたのですが。僕はこの会社のそういうところが好きです。

後は、ベンチャー企業が多いこの業界では、ログ解析自身にほとんど着手できないところも多いと思っています。そういった会社が、この発表を聞いて資料を見て、題名の通り明日からログ解析を始めてもらえるきっかけになってもらえれば非常に嬉しい限りです。これが業界の貢献に関するところかな、と。

Hadoopを選んだ理由

今回は行動ログの集計を行うところでHadoopを使用しています。しかしHadoop側でいきなりデイリー指標を集計するといった、すぐにレポートできるくらいのたくさんの処理をやらせるのではなく、レコードの一部分を後で集計しやすい様に整形することと、せいぜいユーザーごとに行動タイプで集計する（頻度やポイントの変化を数える）といった軽い集計しか行わず、しかもHDFS上のファイルとして出力するのではなく、MongoDBに格納して行きます。その時に頂いた意見としましては、

なぜHadoopでもっと細かい処理をやらせないのか
本当にHadoopを使用する意味があるのか。MongoDBに直接集計値を挿入すれば良い

といった、Hadoopの使い方に疑問を持った意見が多かったです。うーん、確かに言われてみればそうかもしれませんねー。少しここは検討してみます。ただ、このようなHadoopの使い方をした理由としましては、元々の設計思想に、

集計作業と解析作業の明確な切り分け

を行いたいというのがあったからです。

解析作業というのは日時単位やユーザー単位である程度集計されて扱いやすくなったデータセットを切り出してきてRやEXCELやKNIMEやRapidMinerなどのツールで解析し、レポートを作る工程で、集計作業というのは散在するログやDBのデータを集約・集計する工程です。そして今後入ってこられる解析者やマーケッターの方々には、集計作業の面倒くさい部分を意識することなく、解析作業に専念して欲しいという想いがありました。

そういった思想を踏まえて考えると、Hadoopでの処理はもちろん集計作業の方ですから、解析専門の人にはここのソースコードをいじったり、大容量のログを何度も読み直すような事はして欲しくありません。今まで見ていなかった指標値が欲しいといった状況があった時は、データバンクからその指標の名前を指定して簡単に取り出せるような仕組みでないといけません。そしてそのデータバンク的存在がMongoDBなんです。なので行動ログだけでなく、MySQLに入っている課金情報やCassandraに入っているユーザーのセーブデータもこのMongoDBに集約しておかないといけなくて、かつ同じ粒度でデータを保存しておかないといけません。それが初めの意見、なぜHadoopに細かい処理をやらせないのか？に対する現状の答えになります。

データクリーニング機能としてのHadoop

ただ、1日4GBの行動ログをそのままMongoDBに入れていくといずれパンクしますし、ログの中には不要な情報もありますし、解析ノウハウが貯まってくるにつれて必要のない指標がどんどんわかってくると思います。そういったものを事前に排除して1/10位にサイズダウンさせるためのFilterとしてのHadoop活用も見込んでいます。また、今後より大きくなっていくログを想定してもHadoopで何らかの処理を行うという仕組みは初めから作って残しておきたかったというのもあります。それが2番目の意見に対する理由です。

MongoDBを選んだ理由

ではなぜデータバンクとしてMongoDBを選んだのかという話をしたいと思います。データを一元管理したいという設計思想や、行動ログ解析の性質や社内に解析のノウハウがたまっていないという現状を加味すると、

スキーマは定義できない：取得する項目がイベントや解析手法変更によって常に増減するので
様々な条件で検索できる柔軟さが必要：日時やユーザー、行動タイプ…さまざまな条件で検索できないとダメ
更新性能は二の次：柔軟な検索ができる事の方が重要です
日常の扱いやすさ：シェル上で簡単な操作ができると嬉しい

といったところの要請を満たして欲しいことになります。そういった要請を満たすデータの管理方法が何か、と考えたときに

（集計済の）各データをHDFS上のファイルとして管理しておき、HiveやPigでデータを取得する
MySQLできちんと管理する
HBaseやCassandraなどの列指向データベースを用いる（NoSQL）
MongoDBやCouchDBのようなドキュメント指向データベースを用いる（NoSQL）

といった候補の中でMongoDBの採用に行き着きました。選んだ理由ですが、スキーマレスでありながら柔軟な検索機能があること、全てのキーにインデックスが貼れること、出力も検索クエリーにもJSONライクな形式をとっていて直感的に扱えるといったことが挙げられます。MongoDBに至った経緯は様々な資料を参考にし、また色々な試行錯誤があってのものでして、そこのところはまたお話しできたらと思います。

また、MongoDBの性能がどれほどのものか、今回の目的に合致するものとして本当に最適なのか、といったところはきちんとこれから検討しないといけません。また、レプリケーションやシャーディングについても実用性をきちんと検討していかないといけません。そういった所は今後調査・検討してブログのエントリーとして報告していくつもりです。

解析者の立ち位置について

スライド最後に書いた部分ですが、ここで多くの方に共感のコメントを頂けたのは嬉しい限りです。ここの部分も改めてしっかり書きたいと思っていますので、次回以降のエントリーということで宜しくお願いします。

勉強会を振り返って

今回の勉強会も様々な分野からの発表者や参加者が来てくれてとても刺激的な勉強会でした。また同じ業界の@satullyさんや @buhiiさんと深いお話しができたり、苦労を共有できたりして僕にとってはとても貴重な場所になってきました。運営者の@hamadakoichiさんと@yanaokiさん、そして毎回会場を提供していただいているニフティさんには大変感謝しております。本当にありがとうございます。今後ともより良い会を目指して協力していきたいと思います。