くろたんく雑記帳

日常とか、わんちゃんとか、機械学習とか、競プロとか、

MENU

適当な環境で分析している人が多くてびっくりした件(旧ブログからの再掲)

去年にいろんな機会があり、チームで仕事しているのに環境を整理されてないので、色々問題だと感じてまとめた記事(部分的に修正いれる) 分析再現性については、個人的に普段からかなり強めに言っていることなので、別記事も追加として最後に加えた。renvの解説スライドも載せておいた。



最近、いろんな人の分析環境や、やり方を見る機会があって、ある一部のデータサイエンティストの作業環境や、やり方について色々と問題があるなと感じた。

  • 公式のドキュメントは大抵英語なので、読まずに誰かが書いてくれた日本語の記事を永遠ググって、みつからないとかわからない...
  • コピペマンで応用力0...わざと、rm -rf / と手順書に書いたらそのまま実行しそうで怖い
  • エラーメッセージを読まない(読めない)で手が止まる...
  • ローカルの環境とリモート開発環境のRやPythonのライブラリーやmoduleのバージョンがバラバラ...
  • プロジェクトごとにディレクトリ構造がバラバラの環境で仕事を行なっている...
  • 並列処理せずにforで回してるだけの処理で、計算機のスペックを無駄にあげて全然早くならないと言っている...

このように、最近の一部のデータサイエンティストはエンジニアリングの基本的なところが弱い印象を感じている。おそらく、いわゆる3軸でいうところのデータエンジニア力弱めなパターンと考えている。

まず公式のドキュメントをしっかり読む


ドキュメントに書いてあるサンプルをまず試す

当たり前。ドキュメントに書いてあるように、手元で環境つくって、適当にテストを行う。まずここから始める。当たり前。ドキュメントを読まずにできないというのはやめましょう。

適宜調べる、英語でも調べる

その上で、ググって、対応する。

コピペマンにならない


コピペマンって何だって感じなんだけど、要するに内容よくわからないけど、Qiitaに書いてあるのを何も理解しないままコピペしてエラー吐いてできないとかよくある。 コピペでもいいんだけど、中身理解してるのが前提。コマンドを叩いたらどういう挙動になるのかを理解しつつ、わかってから使うようにする必要がある。 自分で複数回書かないと、大抵身につかないと僕は思っているんだけど。

エラーメッセージ


ちゃんと読みましょう。それこそコピペしてググりましょう。

環境の構築


プロジェクトの環境は固定する

  • 厳し目にやる場合は、Dockerなどを使うことが望ましい
  • せめてrenvやpyenv(最近ではPythonのvenvでやるみたいだけど)
    • Rであるならば、Rのバージョン、ライブラリーのバージョンを固定する
    • Pythonであるならば、Pythonのバージョン、moduleのバージョンを固定する
  • 何も考えずに、ライブラリーやモジュールをインストールし始めない(環境を切り分けているなら戻れるがそうじゃないと戻りづらい)

ディレクトリ構造の統一


作業プロジェクトのディレクトリ構造は基本的に統一しておいた方がいい
  • 構造が常に一緒なので理解が楽
  • 複数のプロジェクトを扱うようになった時に、パイプラインにおけるPATHの設定もプロジェクト名だけ変更するだけで同じように扱えるため

並列処理


並列処理したいならそのようにコードを書く
  • 実行スクリプト内で並列処理できる場合はそのようにコードを書く
  • 1jobに切り出したスクリプトに分けるなどする(ただし、jobの時間がそれなりに長いもの)

参考までに、パラメーターが異なるだけのコマンドを並列に実行する必要がある時には以下のようにやったりする

  • ベースになるコマンドのテンプレートシェルスクリプトを作成する
  • テンプレートシェルスクリプトのパラメーター部分をsedで変更したいパラメーター値に変更する
    • 変更したいパラメーター値は別にリストを作成する
  • 変更と同時に実行するように書いておいても良いが、スパコンでないとジョブスケジューリングしてくれないので一旦大量のシェルスクリプトを作る
  • そのシェルスクリプトをxargsを使って、1cpu 1job扱いになるように実行する (multi threadの時はちょっとやり方を変える)

参考までにGitHubに普段使いしているものをpushしておいた

追記


別記事だったけど、ここに載せちゃう。(ただ書いたの2019年なのでめっちゃバージョンアップしているっぽい。)

Rのパッケージ管理

最近、Rを使う機会があって、だいぶバージョンも古いし、この際だからいい感じ環境作りたいと思っていろいろ探してたら、 RStudioお手製のrenvなるパッケージがあったので使ってみた。

だいぶ使い勝手がよかったので、ついでにスライドにまとめてみた。

詳細はスライドを見た方がいいけど、簡単に説明すると Rはパッケージのインストールが全体に影響するため、分析の再現性を担保するためにパッケージの管理を以下のようなフローで行った方がいい 1. 使用するライブラリを決める 1. 使用するライブラリのパッケージをインストールする 1. コードとライブラリの状態(versionなど)を記録する 1. 環境を再構築する必要がある時に復元する これらを簡単にできるようにしてくれたのがrenv

これまでも、Packratっていうのがあったんだけどちょっとイマイチで、あまり使っている人もいなくてビミョーな感じだった。 RStudioも公式PJページで以下のように言っているし、Packratをよりいい感じにしようとしているんだろうなぁと思う。

The goal is for renv to be a robust, stable replacement for the Packrat package, with fewer surprises and better default behaviors.

スライドではスペースの都合上、うまく書けなかったこととか書き忘れたこととして

  • Rscriptのlibrary(pkg)が書かれていることと保存されていることが重要
  • renv.lockはrenv::init()時にGitで管理してrenv::snapshot()するたびにcommitする
  • まっさらなRscriptで始めなくてもよくて、別のPJからrenv.lockを持ってきて、library(pkg)を書ききってから保存してrenv::init()してもいい(現状のglobal cacheからインストールされる)
  • private libraryから消すならrenv::remove()

PythonはRと比べて環境構築の流れがある程度出来上がっているけれど、Rはまだまだという印象なので、会社でも布教していこうかな