連休中、Hadoop Streamingでアクセス解析やっている記事が少し気になって、またアクセス解析への熱が出てきた。
以前から自作のアクセス解析プログラムの執筆を行っていた。Google Analyticsの結果は申し分ない。特にJavascriptから励起して結果を残すという点において、Javascriptが動作するブラウザの履歴が残るという点が気にいっている。
アクセス解析のプログラムを検討する際にWebサーバの生ログを参照すると、人間が操作したのではないアクセスが無視できないほど記録される。例えば、「Ameba」が月間アクセス数100億PVを突破という記事に対して、それは検索エンジンのボットも含むので大量に水増しされているのではないか、という話もあるほどだ。
こうした問題を解決するには、大きく2つの方法がある。botが実行しないjavascriptを利用しての解析と、生ログからbotのagentを1つずつ削除していく方法だ。前者の方法をGoogle Analyticsでは行っている。またjavascriptによる観測の場合、観測する対象が別のサーバ、他のドメインに移ったとしても、同じjavascriptコードを貼り付けているだけで良いので混乱がない。
しかしながら、前者の方法では得ることのできない情報が生ログにはある。例えばjavascriptを動作させないタイプのブラウザの情報であったり、また、あえてボットの情報やDOS攻撃等の解析を行いたい場合、もしくは1つのアクセスをIPやアクセス時間に着目して詳細に解析したい場合がそれに該当する。
この情報を日付ごとにまとめたい場合、RDBで単純に入れて集計しようとすると、100万件を越えたあたりから、めっさ重くなる。重くなるのでインデックスを作り、週間、月間ごとにまとめるテーブルを作り、などの設計を事前に行う必要がある。このために、簡単なテストコーディングの後にDB設計変更とコーディングを行う必要があった。インデックスを縦横に張り巡らせたDBのためのか、閲覧は早いが、データの入力が遅く、またインデックスでガチガチに固めてあるため、解析の手法を変えようと思っても容易に変更できない問題点が生まれた。
そのため、Hadoopなどの実装を代表とするMapReduceの手法に興味が出てきた。MapReduceとはGoogleが採用する分散エンジンであり、多くのコア、コンピュータを介して作業することに長けている。Hadoop Streamingなる実装によってrubyでも簡単に利用できるようだが、Hadoopの環境が1台では大して効果がなさそうである点、複数用意するにしてもHDFSなるファイルシステムを入れたものを準備する面倒も資金も受け入れられないという点が気に入らなかった。
Tokyo Cabinetの活用
そこで視点を変更し、Hadoopが得意とする全文検索の機能を持つ、Tokyo Cabinetなら、上手くいくのではないかという仮説を立て、利用することにした。Hadoopは全文検索もログ解析も得意であるから、というテキトーな理由からだ。
Tokyo Cabinetにはいくつかのデータベースのモデルが存在し、そのうちRDBと似た感覚で利用できるテーブルデータベースを利用することにした。Tokyo Cabinetは通常key-value形式のDBであるが、テーブルデータベースとしての利用ではvalueにまたnameを持たせることが出来、それに対してインデックスを張ることが可能である。RDBとは違い、スキームを設定することなく利用できる点も手軽だ（例えばCREATE TABLEをしなくて済む）。
この点から、生ログの各項目をnameに設定してインデックスを張り、検索を行ってみたところ、意外と軽快に動作した。この調子であれば、データベースの設計に心を割くことなく、様々な視点での解析が行えるのではないかと心が躍る。
この後に、大量のログを入れてウマウマしようかと思ったが、連休が終わってしまって、なんだかやる気が萎えてしまったので、ここまで行った考察と作業を残して、もう寝る。
「Tokyo Cabinetを使ってみた」というところで終わりにして、Tokyo Cabinetの全文検索ツエーが分かったということで。