くろたんくブログ

Practice Makes Permanent

このエントリーをはてなブックマークに追加

2019年 9月 14日 土曜日 17:59:19 JST(modified: 2019年 9月 15日 日曜日 18:06:39 JST)
views: 69, keywords: 日記, tech

適当な環境で分析している人が多くてびっくりした件

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

  • 公式のドキュメントは大抵英語なので、読まずに誰かが書いてくれた日本語の記事を永遠ググって、みつからないとかわからない...
  • コピペマンで応用力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しておいた

prev:意思決定とdefault action next:新しい家族ができた