データ解析の管理にまつわる処問題

ということで前回の続きで，今回はデータ解析周りの環境等をどう管理していくか，という話になります．ていうか，こちらが本題．というか問題って何なのか，というのをまずはまとめたいと思います．

個別の問題のリストアップとその対応策

データサイズ

問題

そもそもデータ解析って，ソフトウェア開発とわりかしごっちゃに語られがちな気がしますが，実際にはかなり性質の違うプロダクトではないでしょうか．ソフトウェア開発とデータ解析の一番の違いって，まさに「データ」の一にあると思います．小規模なデータならだしも，いわゆるビッグデータの領域に入ってくると，データを保存するだけでも一苦労です．

その中である時点での結果を解析して出しましたとしても，そのデータ自体をきちんと保管し続けないと，後から解析のやり直しをしたり，パラメタの変更をしたりできないわけです．

対応策

まずサイズが小さいなら，普通にgit/svnを使えという話なのかなとは思います．1度に扱うデータが数MB〜数十MBとかのサイズなら，十分に対応できるんじゃないでしょうか．もう少しサイズが大きくなって，数GB程度のデータを毎日処理し続けたり，後から加工したりというのであれば，普通に管理/命名規則作って，どっかのファイルサーバでまとめて管理とかが現実的なのかなとは思います．

そしてもっと怖いのは，それ以上のサイズのデータだった場合ですよね．現実問題として，数十GB以上のMySQLテーブルでしかも頻繁に値の書き換えが発生するような場合って，スナップショットをとって分析するにしても，せいぜいHadoopをファイルサーバ代わりにする以外の解決案が，私自身には思いつかないです（Hadoopをファイルサーバとして使うのが邪道だ，というのはふまえた上でも）．そうでなければ，データのスナップショット頻度を間引いて，解析はデイリーでやってるけど，スナップショットはマンスリーでだけおいておくみたいな対応をするか，そもそも同一のデータを保持することをあきらめるか，でしょうか．コストとメリットを考えたら，そもそも再現性を捨てるという対応だってアリだといえるえしょう．

アドホックな処理方法

問題

そしてデータについても，様々な前処理を行う訳ですが，データによって処理手順が違うことはままあって，ダンプしてきたデータをシェルスクリプトとかスクリプト言語でごにょごにょするのが，後から管理はしやすそうですが，逆にそうするとExcelであつかった方が遥かに早いサイズと複雑さのデータに対しては，処理のコストが逆に増大するという話にもなります．会社によっては，自部署だけでは解析用データを生成できないので他部署が間にかむ形だったり，場合によっては外注先に投げると行ったことだってあると思います．さらにいうなら，Hadoopで処理したログを切り出す場合に至っては，PigやらHiveやらですめばいいですが，アドホックなMapReduceとかどう共有するのよ，という話になってしまいます．途中にSQLとかかませて中間処理を入れるのまで入ってくると，もううんざりですね．

対応策

これについては，基本的には手順をある程度共通化するしかないんだろうな，とは思っています．Excel使うなら，マクロでも組んで，かならず全部Excelで完結するようにするとか．またそこそこ大きなデータの前処理については，基本的にコードベースで管理するのが妥当でしょうね．結局そうなると，全体の処理の中に一部だけGUIツールを挟むみたいなのはえらく生産性を下げるので，結局全部コードでやれやという感じになりますね．ローカルの前処理としたら，GUIツールオンリーか，コードオンリーかですね．

問題は前処理のさらに前処理で，でっかいデータベースからデータを切り出してくる場合ですね．単純にMySQLから取り出すだけなら何の問題もない訳ですが，ここにHadoopがかんでくると問題がややこしくなります．それでもPigやHiveで処理できるんであれば，コードベースでの管理に持ち込めるので，たいしたことはない訳です．問題はMapReduceでないと処理できない面倒くさい処理の場合です．アドホックなMapReduceを書くのもそうですが，毎回git/svnにおくんですか？　というのを考えると，そもそもどういうリポジトリ管理が望ましいのか，これはこれで1つのテーマのような気がします．

解析環境の共有

問題

ユーザごとに解析環境が違っていると行った問題ですね．これは通常のソフトウェア開発でもありがちな話なので，たいしたことはないかもしれません．

対応策

解析環境なんかは，解析用サーバを整備するなり，環境構築を終えたVMをあらかじめ作って共有するなりすれば，ある程度は対応できます．まぁ細かいことを言えば，VMだとCPU/メモリ的になかなかシビアなことも多いし，とくにでっかいデータの場合スペック的に厳しいことも多々あるように思います．またRなんかだと必要に応じて新しいパッケージ入れることも多いんで，普通のソフトウェア開発よりもさらに問題がややこしいです．そんなわけで，解析用サーバ作ってみんなそこにアクセスするのが正しい気がします．もちろん，それでもアドホックな別の解析ツールを入れる，みたいなことをしたときに対応しづらいですが…

解析内容の共有

問題

データ解析って，そもそもトライアンドエラーの度合いが非常に多くて，すぐにコードやら解析処理がゴチャゴチャしがちです．個人でやる分にはGUI系のツールですませるのでもいいんでしょうけど，チームでやる場合それだとすぐに破綻します．個人ごとのタスクであっても，再利用性が低くなるのは大問題だと思います．部署移動なり退職なりで他の人が担当することになった場合に，ミスなく解析結果を共有するのは至難の業です．

対応策

そんなわけで，基本はすべてコードベースでの管理に統一するのがベターでしょうね．また似たような解析を数値を変えて何度も行う場合，その手順自体を全部スクリプトにまとめて自動化しておくのが暫定的な対応策になりそうです．このあたり，Hadoop使うと絶望的に手順化するのが面倒くさいことになります．

総論としての対応策

上記の事柄をまとめて，じゃあどうやって知識や手順を共有するかと行った場合に，結局はWikiやらConfluenceに，面倒くさくても上記の情報をすべてまとめる形が，現状でのベターなやり方なんでしょう．その際に，コードはできるだけWiki / Confluenceに貼付けてしまう．基本的にそのページをみれば上にまとめたような手順がすべて順番に記述されている，ということになります．これって個別の解析にはすっごく時間がかかってしまうため，正直言って面倒くさいです．でもこうしないと，意味不明なデータと解析結果の山が後に量産されて，3ヶ月後に途方に暮れるはめになると思います．

特にデータ解析の場合，最後にまとめたレポートが一人歩きして，数ヶ月後に結果を見た人がもとをたどりたくなるとか，別の部署の人がみて詳細を知りたくなるとか，そういうことが普通にあると思うので，上記のドキュメント化の重要性って馬鹿にできないです．そんなときに，Rの分析を簡単にドキュメント化できるRStudio + knitrはすばらしいですね，という話でした。