ログ解析飲み会

10/19（水）に都内某所でログ解析飲み会なるものを開催した。

ログ解析飲み会なのにログが無いってどういうこと？と某氏に突っ込まれたので酔っぱらいの記憶をたよりに書いてみる。ここには書けないオフレコ話も多々あったように思うが忘れたので書かない。

またここに書くことは僕の脳みそで理解した部分に限るが、誤解が含まれている可能性はもちろんあるので変なことを書いていたら指摘していただけると幸いである。

で、この飲み会を開いた経緯としてはですね、僕自身がHiveを用いたログ解析をするようになって他の人の現場寄りの話を聞きたいなーと思ってTwitterで絡んでいたら大物がきたので開催した次第である。大物が誰かはマル秘事項である。一人じゃないとだけいっておこう。

世の中的にも主にWeb業界でHadoopでのBI案件が広まるにつれて、Hive, Pig, Hadoopストリーミング, 生MapReduceなどを使ったログ解析が行われるようになってきたという背景がある。

ログを高度な統計手法を用いて解析するという話ももちろん面白いわけだが、奇麗なログじゃないと解析できない。

分析屋さんもログのクレンジングが作業の8,9割だと言うし、前処理超重要だよね。

前処理っていっても生ログをどのようにパースしてHDFSに突っ込むかっていう話もあるし、ログをどう収集するんだって言う話もある。

まあその辺のログ解析にまつわる泥臭い、生々しい、涙無くして語れない、グダグダな？話を飲みながらする会を開催しましたよって感じです。

ちなみに僕の現場ではログ収集はアクセス解析ツールに頼っている。毎日定期的にFTPサーバにログが配信されてくるので、常時起動しているスクリプトがログを取り込んでHDFSに突っ込んでいる次第です。

HDFSという分散ストレージに突っ込んでいるわけだが、マスターは何かというとFTPサーバにある生ログだ。生ログとスクリプトがあればデータは作れるからね。分散ストレージにあるものはマスターじゃないというのが飲み会では統一見解だったように思う。

ログ自体もタブ区切りで比較的奇麗な状態になっている。例えば画像データへのアクセスなどPVに関連しないリクエストはログに含まれない。データ処理はひたすらHiveだ。フォーマットはSequenceFile+gzipだ。

map数が4000とかになるとシャッフルデータも40Gぐらいになるのでmap出力の圧縮とかしたほうがいいのかなあと話題を振ったら某氏曰く、ネットワークがボトルネックになることはまず無いのであんま意味なくねという指摘あり。

圧縮、解凍処理にCPUを使うのがもったいない。他にも処理するmap, reduceあるんだしとのこと。なるほど。

その某氏の現場では毎日数百GBクラスのログがやってきてストリーミング的に処理している。scribeでログを収集してHDFSに突っ込むというFaceBookと同じ方式だ。

scribeはC++で書かれており、JNI経由でHDFSにデータを突っ込む。この辺は使えるHadoopのバージョンにも限りがあるようでセットアップもなかなか大変なようだ。ただ性能はいいらしい。

そのような状況下で最近fluentというイベントログ収集ツールが登場した。fluentはrubyで書かれたソフトウェアでプラグインアーキテクチャを採用している。柔軟性が売りだろう。

しかし柔軟性とプラグインの書きやすさというメリットと引き換えに性能がscribeほど出ないらしい。なんでもrubyのgcが遅いとか。C++で書けば性能は出るだろうが、それだとプラグインが書きにくくなるので悩ましいと別の某氏は語っていた。

ともあれ話題のfluentだが現状ではHDFSに書き出すプラグインが無い。某氏曰くHDFSにデータを突っ込むええ感じのインターフェースがあるわけではないのでHadoopのDFSClient相当をrubyで実装する必要があるがこれは大変。jrubyを使うとオーバーヘッドもあるので却下。いっそHTTPでHDFSを処理するHOOPを使うという手もあるが性能的に難しい。別の某氏曰く、そこはhadoop fs -putすればいいんですよとのこと。

とまあこんな感じで活発な意見が交わされました。とてもためになり面白かったと同時にレベルたけえなーと思った次第です。