トップ > ログ解析

解析者として僕が大事にしていること

ログ解析

あけましておめでとうございます。@です。今回は技術的な内容ではなく、フロントの解析者・アナリストとして僕が大事にしていること・日々感じていることを書きたいと思います。
このエントリーのきっかけは、最近多くの方から以前の10月に書いたエントリー「解析者の立ち位置」について僕が思うこと。に対して多くの共感のコメントを頂いた事です。この事で僕は今年も解析者として変わらぬ信念を持って、今いっそうの努力を続けていけばよいのだ、やるしかないという決意をもつことができました。コメントを寄せて頂いた皆さん、どうもありがとうございました。

解析者として僕が大事にしていること

ここ数年においては、データが大量に蓄積されてきており、それを解析・マイニングするデータ解析者の重要性が理解されるようになってきているように感じています。それは解析者にとって非常に喜ばしいことでもあると同時に、大きなプレッシャーにもなっているような気がします。

そのプレッシャーの1つに、企画者や経営者・あるいは顧客といった結果を活用する人々（=意志決定者）の「これだけ材料（データ）が揃っているのだから多くの課題が解決できるはずだ」という期待に応えないといけないというプレッシャーがあると思います。しかし正直なところ、いくら大量のデータが揃っていたとしても経営が一気に改善できるようなエクセレントな結果をすぐにもたらすのは非常に難しいと思っています。逆にデータ量が増えて様々な要因が複雑に絡みあって何も見えてこない状況に陥ることもあります。

もちろん僕たち解析者の使命は「データから経営クリティカルな結果をもたらし続けること」であるのでこの困難さから目を背けるわけにはいきません。今日はそんな状況の中で解析者は日々どういう立ち位置で、どういう結果を出していけば良いのかについて僕が大切にしている事を4つお話したいと思います。

  1. 「当たり前の結果」をたくさん出す事の大切さ
  2. 誰のために・何のために解析をやるのかを意識する大切さ
  3. 1人で全部背負わない事の大切さ
  4. 自分の存在価値を高めるための活動の大切さ

1. 「当たり前の結果」をたくさん出す事の大切さ

僕は解析において「当たり前の事をきっちりやる・当たり前の結果をたくさん出す」事は非常に重要な事だと感じています。ただし解析者という専門的な立場である以上、「何も有意な結果が出てこなかった」「当たり前の結果しか出てこなかった」というわけにはいきません。中には常に「何か新しい発見をしないといけない」という焦燥感にとらわれながら仕事をしている人もいるかもしれません。

しかし僕は「意味のある・新しい発見」をもたらすためには「当たり前の結果」を積み重ねることが大前提で、その事をもっと意識して解析をすることがとても重要だと考えています。

その当たり前は本当に当たり前なのか

そもそも「当たり前の結果」というのは誰にとって当たり前なのでしょうか？僕たち解析者の考える当たり前と、意志決定者の考える当たり前は本当に同じなのでしょうか？僕の経験から思うことは「解析者の考える当たり前の半分は意志決定者にとって当たり前ではなく、またその逆もしかり」という事です。

当たり前と思っていた結果を渋々見せると「へぇ、意外に××なんだ、面白い」という反応が返ってきたり、逆に新しい結果が出たと思って見せると「やっぱり」「そりゃそうだよ」といった反応が返ってくることは実は良くあります。つまり解析者がたいした事の無いと思っている結果が実は意志決定者にはとても貴重な情報となる事が多数あるということです。しかし実際は解析者はそういった結果を出す事に注目を置いていないために、多くの意志決定者にとって重要な結果があまりもたされないといった現状に陥ってしまいがちです。

だから僕は「当たり前の結果をたくさん出していこう」という意識を強く持つことはとても重要なことだと思っています。具体的にどうするかというと、できるだけたくさんのデータを出してあげること、しかもわかりやすい表やグラフの形でたくさん出してあげることだと思います。そして何度もその共有を意志決定者と繰り返す。その共有を繰り返すことで相手が何を求めているのか、どういう結果に意味のあるのかがだんだん見えてくると思います。それこそが意味のある有意な結果をもたらす第一歩になると思います。

本当に当たり前の結果を与えることも実は大切

しかし、本当に当たり前の結果、意志決定者が「やっぱりそうか」という結果には意味が無いといえば、決してそんな事はありません。意志決定者が頭の中で感じている事を数値やグラフで裏付けてやるという事はとてもとても意味のあることです。自分の考えている事の正しさがきっちりと検証される事によって得られる安心感と自信は想像以上に大きなものです、そしてそれが次の意志決定の確信度をどんどん高めていきます。相手に安心感を与えてあげるのも僕たちの大きな仕事だと感じています。

「当たり前の繰り返し」が新しい発見を生み出す

「意味のある結果を出さないといけない」という事に執着しすぎに、もっと当たり前の事： " たくさんデータを提示してたくさん表作ってグラフ描く、そしてそれを何度も相手と共有する " 、そういったことをきっちりとこなすことは解析者にとって非常に重要な仕事だと思います。難しいことをやろうとして頭を悩まし、手を止めるよりは、どんどんデータをわかりやすい形で提示して行く方が有意義だと思いませんか？そして結局のところ、新しい発見や経営クリティカルな結果というのはそういった事の繰り返しの上に生まれてくるものでは無いでしょうか？

2. 誰のために・何のために解析をやるのかを意識する大切さ

これは以前のエントリーの中心部分になるのでかぶるのですが、そもそも誰の・何のために解析をするのかという意識を常に明確にしておくことはとても重要だと思っています。

人間の意志決定を支援するために解析をすること・解析結果自身が意志決定を行うのではないこと

解析者は「人間の意志決定を支援するための結果をもたらすことに注力する」という意識を持つ、そのために「難しい事はしない、いかにわかりやすく・簡単に結果を人に提示できるかを意識する」事はとても重要だと思っています。

逆に解析結果自身が意志決定を行う場合というのは、例えば「リコメンドエンジン」や「需要予測システム」を作る場合でしょうか。機械学習や統計モデルといった高度な手法を駆使して、データから機械的に最適な解をもたらし、それを元に自動的にサービスに適用していく。その人の過去の行動から自動的に趣向を理解して適切な商品を推薦する、過去の大量の販売履歴からどれくらいの需要があるのかを数値で提示するといったものです。こういった瞬時に結果を出さないといけない状況や人間の手に負えない状況においては非常に重要です。

しかしそういった目的では無い場合、単にデータを解析する場合においては、解析を「人間の意志決定を支援する」ために注力して行う事が重要だと思います。

そのためには難しい解析手法を用いる必要はありません。例え複雑なモデル式を作ったり、 " 課金額687.3円〜3456.7円・プレイ期間3.4日〜8.9日のユーザークラスタの分布 " といった微妙な境界をもったクラスタリングをしても、それを知った所で人間がどういう意志決定ができるでしょうか？逆に多少誤差があっても、クラスタに偏りがあっても、できるだけ線型モデルや " 課金額1000円〜5000円・プレイ期間1日〜7日のユーザーの分布・傾向 " といったわかりやすい結果で提示してあげることの方が相手にとって意味のあることのように思います。そしてそれをちゃんと可視化してあげて、どれくらい誤差があるのか分布に偏りがあるのかも含めて伝えることも重要です。

解析手法に対するこだわりを捨てること

今まで大学の研究などで非常に高度で複雑な解析手法を用いてすごい事をやってきたという人も多いと思います。機械学習によって自動的に意志決定が行われるということに非常に喜びと価値を感じている人も多いと思います。あるいはそういう高度な知識をアピールする事で周囲に自分の業務の理解や専門性を訴えたくなるとも思います。

そういった人達はどうしてもそういった高度な手法を使いたくなると思いますし、その気持ちはとてもとても理解できます。しかし新しい事をしてジャーナルに掲載されるための研究や、リコメンドや予測といったデータ解析とは違った目的で使用される機械学習、自分の評価のために無駄に複雑なことに時間とお金を費やす行動は、データ解析における目的とは全く異なるものです。

こだわりを捨て明確な目的意識をもって、人間の意志決定を支援するための結果を出す・そのためにどうしたら良いか・どう分かりやすく伝えたらよいか、を必死で考えていくことの方が非常に重要な事のように感じます。

※（追記）もちろん、会社の規模やフェーズなどによっては高度な解析手法や基盤技術を生み出す事もとても重要な解析者の仕事だと思います。

3. 1人で全部背負わない事の大切さ

解析者がデータを集めてきて解析して結果を出す、その事を全て1人で背負う事は非常にしんどいことであり、あまり良くないことだと感じています。初めは僕も「全てを自分でやってどんどん良い結果を提示していかないといけない」と意気込んでいましたが、その困難さに気付くようになりました。

日々増え続け・変わり続けるサービスの全てを把握するのは困難

解析者は自社・あるいは顧客先のたくさんのサービスの解析を一手に引き受けなくてはなりません。そしてWebサービスにおいては非常に早いペースでサービスがリリースされ・絶えず変更されていきます。サービスの全ての内容・特徴・構造、またはログ周りに関するプログラム・データベースのテーブル構造を全てのサービスで把握して解析を行うことは実質不可能です。それにも関わらず全部1人で背負うのは心身共にしんどい事です。

最も優秀な解析者になり得るのは実はサービスを作った人である

これも経験から感じている事ですが、いくら解析の専門技術を持っていたとしても、実際にサービスを作った人の持つ仮説検証能力やデータの読み取り能力には敵わないことが多々あります。そこで「サービスを作った人にも解析に協力してもらう」、「彼らにはない、より科学的な見地で解析を行う」ことが負担を減らす意味でも、良い解析をする意味でも非常に重要なことだと思います。

エンジニアにももっと協力してもらう

一方で解析の元となるログを出してくれるのはインフラエンジニア・アプリケーションエンジニアの人達です。ログのレコードの意味がわからない事や、取得して欲しい項目がある事は日常良くあることです。また、データベースのどのテーブルにどういう形でデータが記録されているのかも全て把握するのは困難です。そしてこれらを自分で頑張って追っていくのは時間の無駄です。そいういう部分は割り切ってどんどんエンジニアに聞く方がよいと思っています。

相手の手をわずらわせないために、どういうデータが見たいのか、あるいはどういう目的で新たな項目を記録して欲しいのかをわかりやすく伝える努力はとても重要です。

4. 自分の存在価値を高めるための活動の大切さ

解析者という業種は環境に依存するところが大きいです。大きなサービスがあるからそこに大きなデータがあり・解析需要が生まれてきます。また、IT産業が拡大し続けているからこそ「データ解析してみよう」という余裕が生まれ、開発者や企画者(=サービスを生む人)以外に解析する人を雇用しようとします。それは現実として会社が傾けばまず解析者の存在が危うくなり、IT産業自身が傾けば市場価値は下がっていく傾向をもたしています。

しかし本当にそれで良いのでしょうか？逆に経営がピンチな時ほど、産業が衰退していく時こそきっちりとデータに基づいた戦略・下支えが必要では無いのでしょうか？悪い原因を一つ一つ地道に突き止めて行き改善していく、そういった事こそが何より重要だと解析者の皆さん自身が一番感じているのでは無いでしょうか？

勉強会など、社外に向けて発信していくことの重要性

だからこそ自分の存在価値を認めてもらうための活動はとても重要だと思います。それを通じて良き理解者や同業種の仲間を増やして行きます。

社内においては結果を出すことに併せて、エンジニアや企画者・経営者と積極的にコミュニケーションをとって解析の良き理解者になってもらうことでしょうか。そして社外では勉強会などで積極的に発表し、解析ノウハウを共有し技術向上に努め、社外の多くの同業種の人と交流を深め、また自身のスキルを広く理解してもらうことではないでしょうか。

特に社外に向けての情報発信はとても重要だと思います。それは業界やコミュニティ発展に大きく寄与することになりますし、今後より良い環境で仕事をしていくための重要な足場作りになります。

2011年は解析者にとって良くも悪くもチャンスの年

2011年はそういった意味で良くも悪くも解析者という存在を認めてもらうためのチャンスの年であると感じています。良いことはHadoop等の大規模分散処理技術やNoSQLの普及によってそれまでお手挙げだった、大規模のデータでも解析することが可能になってきて、それと共にデータ解析の重要性が一般に認知されるようになったことです。そこでデータに基づく戦略を数々打ち出す事ができれば、よりいっそう僕たちの存在価値は高まってくるはずです。

一方で悪いことは今のようなIT好景気がそれ程長く続かない事です。特にソーシャルゲームプロバイダのベンチャーにおいては去年以上の収益をもたらす事は難しく、かつ携帯電話上でのゲームからスマートフォン上でのアプリやその他のサービスへの転換という、大きな舵取りを迫られるはずです。そしてその向かう先は意志決定者にとっては不安だらけです。そういった時に僕たち解析者が彼らの意志決定に自身を持たせ、次にヒットするサービスの大きな下支えになれるかどうかで存在価値は変わってくると思います。

最後に

データ解析というとBtoB向けのアクセスログ解析という印象が強いと思いますが、WebサービスのようなBtoCでもソーシャルデータ特有の解析によって自社サービスを改善していく事での解析者の役割が非常に重要になってきています。GREEには当初からあらゆるデータをきちんとって、それを活かして行こうという気概を持った人とそれを認める文化があったからこそ今のような大規模なサービスを展開できており（えらそうな事をいってごめんなさい）、DeNAも同じく最近では @ さんが解析専門部隊を立ち上げて精力的に活動しています。BtoBで解析をやって来られた方々、解析に興味のある学生の方々、機会があれば是非ともこちらの業界に飛び込んできてみてはどうでしょうか？きっととても楽しいはずです。

参考リンク：
会社の成長を支えるデータ解析/GREE
2100万会員モバゲータウンはデータマイニングの宝の山
楽天技術研究所におけるウェブマイニング

今年も解析者として、普段の仕事もコミュニティ活動も、そして解析者の存在価値を高めていけるような活動も積極的に行っていきたいと思います。そしてたくさんの人に出会あい、刺激をもらうことをとても楽しみにしています。改めて本年も宜しくお願いします。

第8回データマイニング+WEB勉強会＠東京で発表してきました。「MongoDBとAjaxで作る解析フロントエンド＆GraphDBを用いたソーシャルデータ解析」

勉強会 MongoDB GraphDB ログ解析

お久しぶりです。@です。11/14(日)に行われました、第８回 データマイニング+WEB 勉強会＠東京−大規模解析・ウェブ・クオンツ 祭り−で発表してきました。Togetterも参考にして下さい。

発表者・参加者双方の議論を重視するこの勉強会、今回もアツイ議論が絶えず巻起こって、とてもエキサイティングで有意義な勉強会でした。僕は前回に引き続き、今回も発表側として参加させていただきました。その時の資料は以下になります。

前回のログ解析バックエンドの続編として、散在する各種ログを集計してMongoDBに入っているデータを表・グラフとして可視化するためのフロントエンドのお話と、ソーシャルデータの解析をGraphDBであるNeo4jを用いて解析した事例を紹介させていただきました。解析方法の詳細はスライドの方に盛り込ませて頂いたので、今回は今までの解析の総括として以下のアジェンダでお話させていただきます：

  1. 解析用DBとしてのMongoDBの役割とそのメリット
  2. 3ヶ月の仕事を通して感じたこと

GraphDBに関しては次のエントリーでがっつりと書ける程のネタがありますので今回はスルーさせていただきます。

解析用DBとしてのMongoDBの役割とそのメリット

発表や懇親会で「なぜ解析用のDBにMongoDBを選んだのか？」という質問をいつも頂きます。今までのエントリーなどでもその理由をちょくちょく書いてきましたが、今回改めて書こうと思います。まず結論として、MongoDBを採用して間違いなかったことを確信しています。もしこれで無ければもっと基盤構築に時間がかかっていたでしょうし、もっとごちゃごちゃした構成になっていたと思います。といってもそれは作業者のスキル・サービス規模・社内環境／風土・リソース…といった様々な制約条件によって変わってくるものであると思います。なので僕はどのような制約条件の元で仕事をしているか、そこからお話をさせていただきます。
ここでは「データ」を様々なログの1つのレコード、あるいはそれを軽く集計した形でMongoDBに格納されたものと定義します。対して「指標」とはその（複数の）データから計算された最終出力としての数値と定義しておきます。

解析環境・ノウハウ、何も無いところからスタートした（ただ、ログはきちんと残しておいてくれていた）

もともと解析環境やノウハウが無いところからスタートしました。ソーシャルアプリの「おみせやさん」が大ヒットして、弊社が「お客さんにもっとこのゲームを楽しんでもらいたい」→「そのためにログ解析をきちんとやって科学的に仮説検証・実行していこう」というフェーズにあったところに僕が運良くジョインさせてもらったというのがそもそもの流れです。ちょうど8月のことです。ですのでこの課題のゴールとしては、

「とにかく色んなデータを採って検証してみたい」


という、なかなかふわっとしたものになります。例えば他のゴールとしては「PV、UU、ARPU…といった決められた基本指標を出して欲しい」といった場合もあると思います。数TBの手に負えない規模のログデータを持っていたり、そこまで解析を重視しない（そんな余裕がない）といった状況では、基本的な指標算出のみにとどまるでしょう。そういった取るべき指標が明確に決まっている場合はまた違った、もっと効率的な解析手法があったと思います。僕の場合はとにかく色んなデータを採取して見る必要がありましたので、まずログの情報がほとんど”生”の状態で保管しておく必要がありました。まずはどんなデータがあって、どんな数値・特性を持っているのか、そしてそれが今後の意思決定に必要なものになりうるか取捨選択、ということを解析者である僕自身が細かく確認していく作業をしていかないといけません。ですので、

「解析者が必要な時に必要なデータを簡単に眺められて、その特性を見れる」


環境が必要でした。これは、

  • 常にデータが手元にある（社内から簡単にアクセスできる）
  • 散在するログから抽出したデータは一つの場所に集約しておく
  • データの特質を簡単に確認できるデータ保存方法である

ようにしなければならないという事です。今採れているおみせやさんのログは4種類、

  1. MySQLに入っているユーザーの登録情報、課金情報
  2. Cassandraに入っているユーザーのゲームステータス
  3. AmazonS3にバックアップされているゲームのアクセスログ
  4. AmazonS3にバックアップされているユーザーの行動ログ

で、これらを社内から解析者が簡単にアクセスできる1つの場所に集約しておく必要がありました。MySQLのデータは解析専用のレプリケーションを作って頂いて社内からアクセスできる状況にしてもらいました。Cassandraのデータは可動サーバー上にデータを取得するPHPスクリプトを書いて置いておき、社内からそのPHPを叩いてデータを引っ張ってくるAPIの形で取得するようにしました。（実はここはThrift＋PHPの形から、Pigを用いてより効率よく取得していく形を考えて実装しようとしています。ですので資料内のバックエンドの構成図では「Cassandra」→「Hadoop」→「MongoDB」の流れになっています…）残りの行動ログ、アクセスログはS3とデータ同期する社内データストレージを構成して、社内から簡単にアクセスできるようになっています。

これは今から考えるとなかなか難しい要請であったと思います。MySQLやCassandraに関しては、そもそもアクセスする権限を解析者に与えてくれること・整備されたネットワーク環境・それなりの規模であったからそれができたのであり、ファイル形式のログも、今まで全てをきちんとS3にバックアップしてくれていたこと・それを社内で同期できる程のデータ量・ネットワーク環境・リソースがあったからこそです。そして何よりもインフラエンジニアの快い協力があったからです。今回は社内にデータ解析サーバーを構成していますが、例えばサービスを全てAmazonEC2上で構成していれば、解析サーバーも手法も全てAmazonEC2・S3上に集約して解析していたと思います。そうなればもっとAmazonクラウド上でのメリット・デメリットを考慮した構成になっていたと思います。MongoDBも使っていなかったかもしれません。

次は集約してきた各種ログをどのような形で保管していくかの問題になります。それぞれファイルの形で管理しておくことも考えましたし、MySQLで管理、Hadoopを活用して（HIVE、Pig、HBase）HDFS上で管理することも考えました。その中でなぜNoSQLのMongoDBで管理するようになったのかというと、

（管理上の理由）

  • スキーマレスであったこと
  • 他のサービスのログに対しても1つの解析基盤で管理する
  • もっともわかりやすくシンプルで管理しやすい方法であったこと

（後の処理を考慮しての理由）

  • 他の解析者が裏側の構成を把握しなくてもデータをとってくることができる
  • 色んな検索条件でデータを引っ張ってこれること
  • データ増大に備えてスケールしやすいものであること

などが挙げられます。まず初めの2項目、

  • スキーマレスであること
  • 他のサービスのログに対しても1つの解析基盤で管理する

ですが、これはログの情報をできるだけ落とさずに保管しておきかったのと、そもそも1つの行動ログの中でも項目全てが統一された形式で記録されていなかったことが原因になります。さらに今後のイベントや解析手法確立、新サービスリリースなどによってログの項目、とり方が増えたり変わったりする可能性が大きくあることを考慮しての事です。全てのデータにスキーマを定義するのはそもそもデータの種類や性質を把握することから始める時点で困難でありましたし、何かあるたびにスキーマに頭を悩ますのを避けたかったというのもあります。

  • もっともわかりやすくシンプルで管理しやすい方法であったこと

これは結構大きな理由です。なにせ僕ひとりで全ての解析をバックからフロントまでを管理しないといけない、そして僕は駆け出しのへっぽこエンジニアかつアルバイトの身ですのでできるだけシンプルでわかりやすく、かつ特にバックエンドの構成に関しては一度構築したあとはできるだけ手を加えることのない、また僕がいなくても他のエンジニアが構成を容易に把握できて、何かあったときには対策を替わりにしてもらえるようなものにしたかったからです。

  • 他の解析者が裏側の構成を把握しなくてもデータをとってくることができる
  • 色んな検索条件でデータを引っ張ってこれること

これは実際に様々な軸で解析を行うときにどれだけそれがやりやすいか、という次のステップでの処理を考慮した話です。もし今後、解析者が入ってこられるとしたならば、いつでも欲しいデータにアクセスできるという前提のもとで解析自身に専念して欲しいという想いがありました。そもそも純粋な解析者でバックエンドの作業が好きな人はいませんでしょうし、もっとも経営クリティカルなのはデータから何を導き出すかですので、今後増員を考えるならフロントよりの方を集めて欲しいという考えもありました。そういうところではファイルとしての管理方法よりも、DBの一つの大きなストレージの中で管理しておき、かつHadoopなどの特別な知識がなくても、簡単な検索クエリーで好きにデータをとってこれるものが望ましかったです。最後に

  • データ増大に備えてスケールしやすいものであること

これも重要ですね。サービスは今後絶対に増えていきますし、それに伴ってデータは増えていきます。データ量が10倍になることもありうると考えると、今から簡単にスケールする仕組みを考えておかなければなりません。

MongoDBの何が嬉しいのか

上のような環境や想定を踏まえて選択したのがMongoDBでした。ではなぜMongoDBかというとその性質が

  • スキーマレスであったこと
  • ドキュメント志向であったこと
  • クエリの種類が非常に豊富であったこと
  • 更新性能より検索性能が優れていること
  • （Replication、Shardingの2つの観点で）スケールしやすいこと
  • コンソール上で簡単にデータ操作ができ、かつユーザー定義関数が作れること
  • Pythonなどの各種言語のドライバが整備されていたこと
  • ORM、REST Interface、node.jsに対応するドライバも整備されていたこと

であったからです。

  • ドキュメント志向であったこと

は人に読みやすい形式JSONでレコードを眺められるからです。なにせ格納されているデータの種類や特性を把握しないといけないので、その度に何らか人が読める形に整形して出力するのは効率が悪かったからです。また、フロント側のWebUIにはjQueryを使ってテーブル作成やグラフ描画を考えていました。そこにはJSONの形式で投げるので、もともとJSON（内部的にはBSON）の形式でデータを持っていれば、データを取り出して可視化するまでの処理が非常にシームレスです。

  • クエリの種類が非常に豊富であったこと
  • 更新性能より検索性能が優れていること

これは非常に重要な要素でした。解析は様々な角度から多角的に行う必要があります。そういった用途では時間による範囲検索や、特定の項目での絞り込み、や複数条件での検索、集約関数の充実などの機能が備わっていないといけません。かつ、高速に検索できるよう、インデックス機能を備えているかも重要になります。たいていのNoSQLではSQLでは当然だったクエリの種類が少なかったり、そもそも各所にインデックスを貼れることもできないものが多いです。逆にその部分を犠牲にして更新機能などの他の機能を充実させています。MongoDBは更新機能はそこそこですが、検索クエリがずば抜けて豊富で全ての項目にインデックスを作成することができます。これは解析用のDBとしては非常にありがたいことです。

  • （Replication、Shardingの2つの観点で）スケールしやすいこと

MongoDBの一つの大きなウリはスケールアウトが容易なことにあります。Replicationに関してはReplica setを構成すれば3台以上ののサーバーでデータを同期でき、かつMasterに障害があった場合でも自動的に次のMasterを昇格してくれるフェイルオーバー機能を備えています。Shardingに関してはオートSharding機能があり、指定したキーに対して分散したサーバーに自動的にデータを振り分けてくれます。しかもこれらの機能を非常は簡単に扱うことができます。

  • コンソール上で簡単にデータ操作ができ、かつユーザー定義関数が作れること

MongoDBはコンソール上でデータの操作が簡単にできます。かつコマンドはJavaScriptで書かれていて、独自の定義関数をJavaScriptで書けばそれが使えるようになります。例えば毎回実行するけれども、長くなってしまうようなコマンドはこのユーザー定義関数にしておけば非常に楽です。また、コンソールで色んな操作ができることは作業効率の大幅なアップにつながります。

  • ORM、REST Interface、node.jsに対応するドライバも整備されていたこと

これは後のフロント側の処理に関連するところです。WebUIではMongoDBに入っているデータを取得→可視化しないといけませんので、そのための何らかのドライバが必要です。MongoDBはそのための豊富なドライバが各種言語で用意されています。

以上を見ると、MongoDBは今回の僕の解析に求められる条件をほとんど満たしていることがわかります。他の方法ではここまで条件を満たしてはいません。HBaseやCassandraはそこまで検索クエリが備わっていませんし、HiveやPigはデータの可視性や操作性などで面倒な部分があります。CouchDBやRiakなどの他のドキュメント志向DBと比べましても検索クエリが一番豊富でありますし、各種ドライバも豊富です。かつ大容量のレコードを扱えるGridFSやパフォーマンスの非常に高いCappedCollectionといった独自の便利な機能は後に使用することになりそうだとも考えていました。それでは逆にMongoDBの弱点を挙げてみますと、

  • Replicationが遅い
  • メモリ・HDDを大量に消費する
  • インデックスがメモリに乗らなくなった時点でパフォーマンスが著しく低下する
  • 管理者向け機能がプアである
  • map/reduceがシングルスレッドで行われるため、その間DBがロックされる

ことが挙げられますが、これらは解析用として使うにはそれ程クリティカルな要素ではありません。瞬時に大量の書き込みを絶対に裁かないといけないワケでもありませんし、社内向けDBなのでオープンにする必要もありませんし、基本的に毎日1回のバッチ処理ですので速度が多少遅くても問題ありません。メモリやHDDも急激に消耗することも少ないですので、ある程度事前に対策ができます。Shardingも簡単にできますからね。

技術は適材適所、その場に応じたものを選択することが重要

MongoDBを採用した理由はだいたいこんなところです。今回の自分の制約条件を満足する最も最適な解がMongoDBだったのです。前述しましたように条件が変われば解はいくらでも変わってきます。大事なことはその条件に応じて常に最適な技術を選んでこれる能力だと思っています。ただ、プロバイダー側のソーシャルアプリのログ解析においてはだいたい同じようなことが当てはまるような気がします。もし似た環境におられる方は、一度MongoDBを検討してみては良いかと思います。あと、一つの技術だけで全ての要請を満たすことはできないとも感じています。今回の資料にもありますが、ソーシャルデータの解析にはGraphDBを用いた方が便利なような気がします。GraphDBの中でNeo4jはその中で最も発達したDBで、かつ今まで使用してきたPythonのドライバがあって、REST Interfaceも備えています。そういったMongoDBと共通に扱える要素が多いという意味でMongoDBとGraphDBを現在は共存させています。

3ヶ月の仕事を通して感じたこと

芸者東京エンターテインメントにアルバイトに入って、ゼロからログ解析を初めて早くも3ヶ月が経ちました。今少し感じていることを書いてみます。

解析という仕事にはバックエンドとフロントエンドの2種類があって、求められる技術が全く異なる

今までのおはなしの中でもわかって頂けると思いますが、解析という仕事は大きく2つに分類できます。1つは散在するログを集積し、何らかの形式で保管・管理するための仕組み（基盤）を作るバックエンドの部分と、もう1つは欲しいデータが常に手に入るという前提の下でRやEXCELなどのツールを駆使して実際の解析を行ない、経営や企画の意思決定に貢献する部分です。前者で重要なのは、インフラやDBの知識、あるいはHadoopやNoSQLなどの大規模データ処理技術を使いこなせる能力や各種制約の下で適切なアーキテクチャを構築できる能力で、逆に前者はユーザー支点や多角的に物事を観察できる能力、各種ツールを使いこなせる能力です。ですので解析者がいない企業では、前者はインフラエンジニアが兼任し、後者はマーケティング担当や企画側が兼任することになると思います。もちろんどちらの知識も併せ持つことが重要ですが、もし解析者としてエキスパートになるのならば、どちらの方でそれを目指すのかということを考えていかないといけないかもしれません。解析者というと後者の方をイメージされる方、目指している方が多いかもしれません。僕は前者のバックエンドのほうでエキスパートを目指していきたいなと思っています。そこら辺の話はまた別の機会にしたいなと思っています。

とにかく今回の勉強会もとても有意義な素晴らしいものでした。運営者のみなさん、会場を貸していただいたニフティのみなさん、参加されたみなさん、本当にありがとうございました。今後とも宜しくお願いします。

「解析者の立ち位置」について僕が思うこと。

ログ解析

こんにちは、 @ です。週に2、3回は更新しようと思いつつ、今週はこの1エントリーのみです…頑張ります。

本日のエントリーは僕の考える「解析者の立ち位置」について書いています。僕は自分の立ち位置（=役割）を明確にすることが、仕事で成果を出すための重要な要素かなと思っています。ところで、僕のこれから話す「解析者」というのは一般に認知されているような、いわゆる大企業の研究機関、「**研究所」と名のつく機関で解析に関する新しく高度な「手法」を生み出し、大規模解析基盤を構築し、論文もばりばり書き、手法や基盤それ自身が価値を持ち売上げになるようなエクセレントな人々の事を指すわけではありません。100人にも満たないwebベンチャーで、より現場に近い所でログ解析に携わる仕事をする人を指します。

本日の内容

  • 新しいタイプの解析者が求められる時代に
  • 解析者の仕事って何だろう
  • 解析者の立ち位置とは

新しいタイプの解析者が求められる時代に

色々な場所で解析が必要になってきた

最近のWeb業界の勢いは本当にスゴイですよね。僕のバイト先の芸者東京エンターテインメント GTEが現在身を置いている業界、ソーシャルアプリ業界で特に顕著な話ですが、ベンチャー企業の10〜30人程の規模でありながら数百万人、時には数千万人のユーザー会員を抱えることができ、年間売上も10億円を超える企業も多数あったりします。そういった所では日々集積されるデータ（ログ）は1日に圧縮ファイルでも10GB以上、月に数百GB、時にはTB近くになったりします。また、完全なBtoCのサービスであり、従来のWebアクセス解析のようにクリックや遷移をウォッチするのではなく、ユーザーの行動や興味・関心といった所をウォッチして次の戦略に反映していかないといけません。そうした状況もあり、この業界でもデータに基づく様々な指標の重要性が再認識され、連日行われるソーシャルアプリのイベント等ではプロバイダーが「課金率はy％以上」とか「ARPUはxxxx円」とか、様々な指標とその目標数値を述べながら議論されるようになりました。そういった状況もあり、「解析者」や「データマイニングエンジニア」がこの業界でも求められるようになり、またその仕事の価値も少なくとも以前よりは上がったような気がします。

なぜweb業界の解析者は新しいタイプなのか

ではそういった解析者は前述したような研究所で働く解析者と同じような価値観で見られ、同じような結果が求められるのでしょうか？僕は全く異なっていると思っていて、全く新しいタイプの仕事だと思うんです。一番違うことは、求められるものが、手法の開発や高度な基盤構築自身ではなくて、それらをツールとして駆使し、何とかして自社のサービス向上のために施策を打ち出していくことにあると思っています。そのために「作る」側にも「使う」側にも回り、しかもエンジニアだけではなく経営者や企画者とも深く関わって行くコミュニケーションやフットワークの軽さが重要になってきます。ただあくまで理系専門家として、理論的に意見を出していく所ではマーケッターよりはもう少し専門的な仕事だと思っています。

解析者の仕事って何だろうか

それではより具体的にどのような仕事をするのか、ソーシャルアプリ業界で働く僕の日々の経験から考えてみたいと思います。

1. データを以前より多様な指標で集計
2. CMやイベントの効果の効果測定
3. UIやパラメータの複数のパターンから最適な設定を決定する
4. パーソナライズ：ユーザー個々に最適な設定を施す
5. 機械学習や強化学習を用いたサービス最適化

1. データを以前より多様な指標で集計する

もっとも基本的な仕事は、デイリーの集計を行うことです。先日の売上げやアクティブユーザー数・全体課金額などの基本的で大枠の部分は自動で出してくれるツールがあったり、プラットフォーム側で提供してもらえたりします。それではアイテムごとの課金額内訳はどうだったのか、のべでどれくらい友人と交流があったのか、などのより具体的な内訳を見れるようにし、かつ時間軸やユーザー属性の軸、課金の軸などの様々な切り口で眺められるようにします。これをレポートやWebから閲覧できる形にして関係者に提供します。

2. CMやイベントの効果の効果測定

ソーシャルアプリではミニイベントや機能追加、アイテム追加といった機能変更・追加がかなりの頻度で行われています。時にはCMを展開したりもします。なにせ競争がとても激しい業界ですので、逆に何もしないとすぐにユーザーを失ってしまいます。打ち出したイベントやCMの効果の大きさによって月の売上げは大きく変動します。なのでそういった各種イベントの効果を測定するのはとても重要な仕事になります。様々な指標の中のどの部分に効果が見られるのか、あるいは相乗効果はあったのかといった相関を見つけ出すといった所を調べていきます。

3. UIやパラメータの複数のパターンから最適な設定を決定する

前に述べた2つはいわば「過去」に対しての解析であるのに対し、ここでは「未来」に対して意志決定の支援を行います。例えば複数用意されたUIやパラメーターから最適なものを決定するといったことが挙げられます。ユーザーごとや時間毎に数パターンのUIやパラメーターを適用し、どの設定が最適であったかを統計的に決定します。しかし、誰の、何に対して最適を定義するのか、本当に最適なのか、といった判定は難しく、また全ての条件を同じにして比較することもできませんので、導き出された決定に何も考えずに従うのは危険かもしれません。

4. パーソナライズ：ユーザー個々に最適な設定を施す

解析ノウハウも蓄積され、データも蓄積されてパターンがわかってくると、ユーザーをゲーム継続期間や課金額といった属性でカテゴリ分けしたしていたところをより細かく、ユーザー個々に対して最適なアクション（パラメータ設定）を半自動で決定するといったことができるようになってきます。簡単なところでは1週間ログインしていないユーザーにはログインを促す通知を行う、といったものから細かいパラメーター調整、ユーザー個々のステータスに応じて例えば当たりの確率やレアアイテムの出現率を変更させて、テンションを維持させるための施策といったものが挙げられます。

5. 機械学習や強化学習を用いたサービス最適化

さらにもっと高度な技術である機械学習や人工知能といった技術を用いてサービス自身が学習し意志決定するようになれば、サービスの最適化を自動で行ってくれるようになれば、企画者や経営者の負担をだいぶ軽減させられる事ができます。例えばソーシャルリコメンドや自動イベント発生機能といった、パーソナライズよりもより目に見える形の施策を自動で打ち出していきます。

どこまでやるのか？

今述べたことが下に行けば行くほどより高度になっていき、現実味を失っていくのがわかると思います。そして、初めは企画者や経営者の意志決定を支援するような役割であったものが、彼らに代わって自動で意志決定を行うといった役割を持ったものに変わっていきます。そして僕たち解析屋としては、「機械学習やってます！」と言った技術アピールをしたいところです。しかしながら現実問題として、本当に5.のような所までやるべきなのかというと、僕は必要ないと（今のところ）感じています。できれば4.までやりたいところですが、実際は3.までできれば十分なのでしょうか？その理由としましては、

(a) 深い解析をやる時間も資金もない
(b) 企画者の打ち出すイベントに売上げが大きく依存している
(c) それがサービスや売上げの解析に（高確率で）結びつかない
(d) 解析結果を専門家以外理解できない
(e) 解析者個人の趣向がどんどん入り込んでしまう

などがあると思います。

(a) 深い解析をやる時間も資金もない

僕たちの打ち出すサービスは1年も持たないかもしれません、かつ次々に新サービスを同時並行にどんどん打ち出していきます。次のサービスにもきっちり対応していく事の方が重要ですし、短命のサービス1つ1つに時間もお金もそんなにかけられません。現実的に考えて、そこまで深い解析をじっくりやるのは難しいと思っています。

(b) 企画者の打ち出すイベントに売上げが大きく依存している
(c) それがサービスや売上げの解析に（高確率で）結びつかない

では、そもそもそんなに深い解析が必要なのかという問題ですが、たぶん必要ないと思います。それは売上げに関してもっとも重要な事は、企画者の打ち出すイベントの質や数、つまり人間の勘に大きく依存するからです。デイリーの課金額の推移を可視化してみると顕著になるのですが、平坦な部分なんて無いんです。あるのは山か谷のみ。そして山となるのはイベントを打ち出した時で、その後すぐに減少の一途をたどります。そして何もイベントをしないとどんどん課金額は落ちていきます。やはり機械的にはユーザーの心に刺さる施策を自動で見いだすのは困難ですし、それがタイムリーに行われなければいけないので高度な解析や機械学習の結果が人間以上の結果をもたらすのは難しいでしょう。

(d) 解析結果を専門家以外理解できない
(e) 解析者個人の趣向がどんどん入り込んでしまう

いくら高度な技術を元に結果を導いても、それが周囲に理解されなければ全くもって意味がありません。僕たちエンジニアで怖いことは、無駄に技術を駆使した自己満足の結果をもたらしてしまいがちな事ですし。データは人を説得させるものであっても、それ自身が誰にも理解されずに勝手に一人歩きしてもどうしようもありません。前述したとおり、人間の勘が重要なサービスにおいては人が理解できない事は意味がありません。それによる効果がどれほどなのかも後に判断しにくいですし。

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

それでは僕たちはどのような立ち位置で（役割意識を持って）仕事をしていけば良いのでしょうか？僕の思うところを書きますと、

(A) 解析者は企画者や経営者の意志決定を支援する役割に徹するべき
(B) データに基づいた論理的な理論や根拠を明確に相手に伝える能力が必要
(C) 高度な事をやるよりも素早く、わかりやすい結果を出すことに注力する
(D) 時には解析以外の仕事をするを得ないことを受け入れる
(E) 自社のサービスに対して、誰よりもファンであるべき

(A) 解析者は企画者や経営者の意志決定を支援する役割に徹するべき

僕が解析者としての一番の役割は「企画者・経営者の意志決定を（データの立場から）支援する」ことだと思っています。そしてそれは解析者でしかできない唯一の役割でもあると思います。人間の勘に置き換わる結果や仕組みをもたらすのではなく、人間の勘が最大限に活かせるような情報や結果を提供するのです。そのためにどのような集計や解析をするのかを考え、また企画側と常に距離を近くして、どのような要望があるのかをきちんと理解しておくといったコミュニケーションが重要になると思っています。もちろんエンジニアにも解析の結果をきちんと伝えないといけないですし、どのような記録を、どのような形式で残して欲しいのかを伝えることも重要です。

(B) データに基づいた論理的な理論や根拠を明確に相手に伝える能力が必要
(C) 高度な事をやるよりも素早く、わかりやすい結果を出すことに注力する

そうすると相手にいかにわかりやすく伝えるのかをちゃんと考える必要があります。どのように表にまとめるのか、どのようなグラフを出すのか、それをEXCELで出力するのかWebアプリとして出力するのか…こだわりすぎても問題ですが、社内向けだからと言って手を抜きすぎても問題のように思います。また、出力としてはわかりやすいものにしないといけないですが、結果自身は専門家にしかできない、かつ明確な論理に基づいたものでないといけなません。

(D) 時には解析以外の仕事をするを得ないことを受け入れる

話が少しそれますが、ベンチャーで働く以上、自分の仕事だけに固執するのも良くないと思います。解析という仕事はとても重要ですが、経営が厳しい時には真っ先に切られる仕事でもあると思っています。何より企画し、それを実装してお金にしていく事が最優先で、結果の解析などはどうしても後回しです。実際、多くのベンチャーでまだきちんとログ解析ができていないのもそいういった優先度があるからで、これは仕方の無いことだと思っています。そういった意味では、エンジニアとして開発実装やインフラ回りを兼任できる最低限の能力は必要だと思っていますし、それを受け入れる覚悟も必要だと思っています。そして、そういう仕事であるからこそ、自らの市場価値を高めるための日々の努力はとても重要だと思います。

(F) 「自社のサービスに対して、誰よりもファンであるべき」

この言葉は当時GREEの採用面接に行った時に、データマイニングエンジニア、森さんから聞いた言葉で、今でも非常に心に残っています。企業におけるデータマイニングにおいては、選択（どういうデータや手法を用いるのか）と意志決定（結果から的適切なアクションを起こす）が非常に重要です。そしてそれを適切に見分けるためには、何より解析者自身がサービスに精通していないといけないということです。誰よりもサービスについて知っていなければ良い解析はできません。

最後に

今回もだらだらと長くなってしまいました。おそらく、解析者の立ち位置なんて個々のスキルや会社の規模によって全然変わってくると思います。ただ、その時その時に自分の立ち位置を明確にしておいて仕事をこなしていくのはとても重要なことに感じています。とりわけ、解析者なんて社内では希少種ですし、周囲がせわしなく開発のリリースやバグ処理に追われている中でじっくりログを眺めているなんて時にはうとまれたりしますし、自分の存在価値が問われたりすることは多いと思います。だからこそ、自分はこの会社で解析者として何をもたらすことができるのかを明確に持って、それに向かって全力で取り組む姿勢が重要になってくると個人的には思っています。

まあ、何より僕にとっては今の仕事が楽しくて仕方ありません。また、企画の人からも「こんな数字が見たい」とか、「今日こんなイベントしたけど、どんな感じやった？」みたいに僕に色々意見や要望を言ってくれますし、少なからずデータを重視しようという文化に変わってきましたし、まだまだ自分のやれていることなんて微々たるものですが、しっかりと地に足をつけて取り組めているなと感じています。面白い結果がでればまたブログや勉強会で発信していきたいと思っています。

※データマイニング、特に機械学習については概要を http://labs.gree.jp/blog/2010/09/1310/ にも書かせていただきました。参考になればと思います。

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

勉強会 ログ解析

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

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

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

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

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

発表の目的

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

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

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

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

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

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

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

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

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

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

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

Hadoopを選んだ理由

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

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

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

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

勉強会を振り返って

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

勉強会での発表の大切さ ー僕が勉強会で発表した理由ー

勉強会 ログ解析

こんにちは、@です。Twitterの方にべったりの僕ですが、今更ながらブログも始めました。

もともと勉強会で何か発表したらブログを始めようと思っていましたので僕の中では自然な流れではありました。本日は初エントリーなので、なぜ勉強会で発表しようと思ったか、そしてそれと同時になぜブログを始めたかをつらつらと書いていきたいと思います。その前に今の自分の背景を説明します。こういう環境で働いているからこそ、勉強会で発表することが重要だと考えるようになったんです。

ベンチャーでの働き方について

僕は今、アルバイトで芸者東京エンターテインメント GTE というwebベンチャーでログ解析チーム（といっても僕1人ですが）として、ソーシャルアプリ「おみせやさん」を初めとしたサービスのログ解析を行っています。ちょうど今2ヶ月経ったくらいでしょうか。GTEでは今までログ解析を行っていなかったので、ログ解析に関するノウハウなど無く、僕が解析ノウハウを生み出し、蓄積していく立場にあります。なので環境構築からプログラム実装、そして解析手法確立のところまで、解析に関わる全ての部分を自分で考え、作り出していかないといけません。

あっ、僕はこの環境を嘆いているわけではなく、むしろとても幸せに感じています。自分がパイオニアとしてやりたいようにできますし（責任もその分大きいですが）、社内の優秀なエンジニアの先輩方が技術面では全力でサポートしてくれますし、とても恵まれたPC環境を与えてもらっていますし、人の2倍くらいの成長できる内容でありますし、会社のメンバーも大好きですし、むしろ仕事が楽しくて仕方ありません。

どうやって作業を進めていくか

話は戻りますが、そういった環境の中できちんとした技術やノウハウを確立して、会社に蓄積し経営に貢献していくためには外にいる先人の知恵に頼るしかありません。そのための最も便利で手軽な方法はGoogle先生で、様々なブログや技術サイトからノウハウを頂いてきて自分のところに移植していきます。以前「ググるな危険（元ソースはこれ？）」とかいって話題になりましたが、少なくとも僕はググらないと死にます。何もできません。もちろん、「1つのサイトだけを信用しない」「本家サイト（英語）を嫌わない」など僕なりに色々注意しているところはありますが…

  • コミュニティに聞く

あとはそれでもわからないことは、コミュニティに聞いてみることも重要だと考えています。人に伝えるための文章にして質問を投げかけることは、改めて自分の抱えている問題を整理するきっかけにもなりますし、もしそれが海外コミュニティであれば英作文の練習にもなります。例えば僕は社内でKNIMEという解析ツールの使用を検討しているところです。それほど有名なツール（特に日本では）では無いので検索から得られる情報は皆無で、もしコミュニティを利用しなければ、エラーでつまづいた時はソースコードを読んでなんとかするしかありませんし、「KNIMEのバッチ処理で画像の出力先って指定できるの？」「MongoDBのKNIME用jdbcアダプタってまだ無いの？使えるの？」みたいな疑問にはなす術がなかったりします。しかしKNIMEでは本家サイトのコミュニティKNIMEtechがとても手厚くて、Forumに質問トピックを立てると中の人や海外エンジニアの方々がすぐに適切な答えを返してくれます。もちろん、ギブ＆テイクの精神は重要で、自分もわかる範囲で質問に対する答えを書き込ませてもらっています。

「おれおれ仕様」に満足しないために

そうやってGoogleやコミュニティの恩恵を受けて、自力でもある程度のプロトタイプは作れます。しかし本当に重要なのはここからで、それが目指すゴールに対して、本当にベストなのか？ボトルネックは無いのか？安定運用できるのか？よりよい代替え技術は無いのか？…そういった部分を再確認しないといけません。そしてここは自分自身ではなかなか知り得る事ができず、それなりに動く「おれおれ仕様」に満足して本格運用を始めたりしがちです。そいういった過ちを防ぐのが「勉強会で発表してフィードバックをもらうこと」だと考えています。

勉強会での発表の大切さ ー僕が勉強会で発表した理由ー

勉強会発表で得られること

勉強会で発表すると、出席者の方やustを見た人からたくさんのフィードバックを頂くことができ
ます。自分自身や所属する企業の技術アピールにもなります。もちろん批判も多数あると思いますが、それも含めて発表者側にとってはとてもとても貴重な情報になります。そしてフィードバックを通じて

  • 自分の使用した方法の妥当性が確認できる
  • 気付かなかった新手法や新技術の発見できる
  • 他社の事例や参考サイトを知ることができる
  • 社外に技術相談役ができる

など、様々なメリットを得ることができます。僕たちベンチャーのエンジニアはこういったフィードバックを最大限に活かして、自社のサービスやノウハウを向上させていくことが不可欠だと考えています。しかし、発表がただ自己アピールしたいだけの内容であったり、聞く人に何のメリットにもならないようなものですと、こういったものは得られません。

発表者の伝えるということへのこだわりと、自分の情報やノウハウをどれだけ公開するかで、フィードバックの大きさは変わってくる

多くの人から有用なフィードバックを得るためには発表者側の努力は不可欠で、当たり前ですが

  • 相手に伝えるための努力

はとても重要です。発表の構成をどうするか、どういう資料にするか、うまくしゃべるにはどうしたらいいかといった所に気を配らないと、そもそも相手に自分が何をやっているのかが伝わりません。でもそこは時間的にもスキル的にも難しいところですよね。恥ずかしながら僕もまだ全然できていません。

そして、これと同じくらい重要なことに、

  • 自分の持っている情報・ノウハウをどれだけ公開するか

という部分が挙げられると思います。これはあくまで僕の立場での話なのですが、自分が持っている情報やノウハウを開示するリスクの大きさよりも、それによって得られるフィードバックの方が大きいと思っています。この辺の話は次エントリーで実際に公開した資料とともに述べさせていただきたいと思います。

どの勉強会で発表するか

これも重要かもしれません。せっかく準備してノウハウ開示して発表しても、会の趣旨と異なっていたり周囲の求める内容と違っていたり、懇親会目当てで発表を誰も聞いていない、といった状況では残念ながら得られるものはそれほど多くありません。僕のような「技術的なアドバイスを頂きたい」という目的で発表する場合は、発表者だけがしゃべるのではなく、参加者と多くの議論ができる・質問が絶えず飛び交うといった双方向の勉強会の方が合っています。今回僕が発表させてもらったデータマイニング+WEB 勉強会＠東京 （ハッシュタグ：#TokyoWebmining）はまさに僕の求めていた勉強会で、発表と議論の時間が半分半分に設定されていて、熱い議論が絶えず、双方共に大変有意義な時間を過ごすことができます。この勉強会に対する主催者hamadakoichiさんの創設の思い・目的・進行方針はこちらから感じていただけたらと思います。

勉強会は家に帰っても勉強会 ーブログでその後の進捗を報告したいー

さて、ではなぜ勉強会での発表と同時にブログを始めたのかというと、僕は「勉強会はうちに帰っても勉強会」だと考えていて、多くの人から頂いたフィードバックをきちんと業務に反映したり、さらに技術を深めていくということを可能な限りやるべきだと思っています。そしてそれをフィードバックしてくれた人に見てもらう、あるいは自分がそれをサボらないために、ブログのエントリーとしてその後の進捗を公開していくという方法がベストだと考えました。ですので勉強会で発表すればすぐにその資料はここでも公開し、そしてその後フィードバッグからどう改善していったかをエントリーとして公開していきたいと思っています。ですのでブログの話題が途切れないためにも勉強会で発表し続けますし、そのために日々の努力をします。後は技術に関する調査結果やインストールメモ、使用した感想などのエントリーもちょくちょく残していきたいと思います。

ということでこれからも宜しくお願いします。次のエントリーはこちらです。