内容はJenkinsとHadoopを利用して継続的にデータを解析する環境をつくる方法についてです。やはりデータを解析するために、解析を回しやすい環境を作らなければなりません。データを観察して、なぜそうなっているのかという仮説を立て、実際に計算機を回し、結果を出します。高い成果を上げるには人の頭で考える部分に時間を割かなければなりませんが、Hadoopを利用した解析においては手軽に回す環境をつくるということが実はやや面倒なのではないかと感じています。なので、Jenkinsを利用してそういった作業を効率的にしてみたらどうだろう、と考えたのが発端でした。
今関わっているアプリケーションは全てAWS上で動作しています。発表ではあまりそのへんには触れられなかったのですが、Fabricとbotoを組み合わせてELB以下のEC2インスタンスを取得し、各EC2インスタンスに色々なコマンドを送る、といったことをやっています。そして何より、Elastic MapReduceを如何に気軽に利用できるかという点が肝になってきますが、HiveクエリやMapReduceのJavaアプリケーションの実装後は全てJenkinsに任せることで、実際にHadoop上でジョブが回せるようになっています。Elastic MapReduceでジョブを回すにはS3に配置してelastic-mapreduceコマンドを実行する必要がありますが、やはりそのへんをあまり意識せずに解析ジョブを流すことができるようになったのはとても楽です。各々の細かい資料については参考資料にいろいろ載せてありますので、参照していただけると幸いです。
発表後に「Hiveで解析するときにログの形式とか入ってるデータが変わったらどうするの？」と@katzchangさんから聞かれたのですが、うまく答えられませんでした。今のログの形式は基本的なdelimiterがあれば簡単に解釈できるものと、そうではなくて正規表現マッチが必要なものがあります。後者についてはPythonでmapperを書いて流しこむようにしているのですが、とはいえそもそも何らかのカラムが追加されるなど、ログに入ってくるデータが変更された場合には根本的に何か対応できるかというとそうではなく、やはり運用でカバーする部分が多くなってしまうと思います。僕のところでは異なる形式のログを扱っているところはありますが、そもそもS3のバケットが分かれており、分析対象としても疎だったりするので、あまりそういった場合に直面することがありませんでした。ただカラムを足すような場合にも昔のデータを参照して時系列で一元的に分析したい、という場合は起こると思うので、適切なmapperを実装して、Hiveテーブルのスキーマに流し込めるようにするというのが現実的なところなのかな…と思います。
とはいえ発表できて良かったです。話していて、理解の浅い部分が明確になりました。そもそも発表の発端は@bash0C7さんとの「発表することになったのでよろしくね」「えっ」「えっ」という会話だったりして不思議なものですが、とても良い機会になりました。改めてありがとうございました！
今日もこれからad:tech Tokyoにいってきます。
