St_Hakky’s blog

Data Science / Human Resources / Web Applicationについて書きます

データ分析をするときのフォルダ構成をどうするのか問題について

こんにちは。

今回は、データ分析をするときのフォルダ構成をどうするのか問題について、ちょっと調べてみたので、自分のこれまでやってきたことを振り返りつつ、まとめます。

調べた動機

某データサイエンス系のインターンシップでの反省点でもあり、これは普段研究などでコードを書くときに悩みながら作っているのですが、どうしたものかと思って悩んでいました。

  • データの保存どこでどういうフォーマットでするんだよ!
  • くっ、このモデルも試したい、、、でもファイルとフォルダの構成ガァァァァ
  • Aさん、基礎分析とモデルのファイルをごっちゃにするんでない!(ウワァァァァァ!!誰かしっかり共有しておけヨォォォ!!!)

とまぁこんな感じで、複数人でやるとより露骨になってきたのと、いつもだいたいやるフローとしては同じなので、共通化や一般化がある程度できるはずと思っていました。

私がこれまでやっていたこと

├── README.md
├── analysis # データの基礎分析
├── config # 環境設定など
├── data  # データの保管場所。loadingのところで行った整形データもここに入る
├── loading # データのクレンジングや、ロード、整形処理を行う
├── model # モデルの処理
│   ├── predict # 予測を行う処理
│   └── train # 学習を行う処理
├── report  # 報告用の綺麗な画像などを保存したり、そのための処理を書くところ
├── result   # ログとか、解析の結果を保存する場所
│   ├── analysis  # analysisで行った結果を保存する場所
│   ├── loading  # loadingで行ったログを保存する場所
│   ├── model  # モデルの結果を保存する場所
│   │   ├── predict   # 予測結果の保存する場所
│   │   └── train   # 学習結果の保存する場所
│   └── validation  # 検証の結果を保存する場所
└── validation  # 検証を行うための場所

この構成にしてからは、あんまり不満もなく、これで一旦みたいな感じで書いていたんですが、もう少しなんとかできるよなーとか考えていました。

機械学習では色々試行錯誤していると死んだとならないために

モデルを試行錯誤したりしていると、いつの間にか「なんなんだこのクソみたいなコードは、、、」となりますし、モデルの精度が向上しない時に、「おい、どこ直せば良いんだ、、、そして治すとこっちが、、、あぁ、、、」ってなります。

その気持ちをもってTwitterを見ていたら以下のスライドを見つけました。

www.slideshare.net


全人類が悩んでいるんじゃないかという気持ちを凄い綺麗に表現されている上に解決方法も具体的に載っているという笑。

画像認識系の話は以下でみれます。

www.slideshare.net


調べてみた結果

ということで、調べてみました。その結果は以下。

  • もう、悩まなくていい
  • pipで一発インストール。
  • テンプレートをコマンド一発でジェネレートできる

最高ですね。

調べて行き着いたところ

見つけました。もう少しなんとかしたいと思った点を克服しているサイトが!!

qiita.com

このサイトに書いてある、

あなたは機械学習のプロジェクトを毎回違う構成で作っていませんか?
何をどこに配置するかで悩んで時間がかかっていませんか?

すげー共感した。そして、「コマンド一発」で書けるなんて、、、以下のサイトがデータ分析で使用するテンプレートとして用意されているもの。

github.com

フォルダの構成はご覧の通り。

├── LICENSE
├── Makefile           <- Makefile with commands like `make data` or `make train`
├── README.md          <- The top-level README for developers using this project.
├── data
│   ├── external       <- Data from third party sources.
│   ├── interim        <- Intermediate data that has been transformed.
│   ├── processed      <- The final, canonical data sets for modeling.
│   └── raw            <- The original, immutable data dump.
│
├── docs               <- A default Sphinx project; see sphinx-doc.org for details
│
├── models             <- Trained and serialized models, model predictions, or model summaries
│
├── notebooks          <- Jupyter notebooks. Naming convention is a number (for ordering),
│                         the creator's initials, and a short `-` delimited description, e.g.
│                         `1.0-jqp-initial-data-exploration`.
│
├── references         <- Data dictionaries, manuals, and all other explanatory materials.
│
├── reports            <- Generated analysis as HTML, PDF, LaTeX, etc.
│   └── figures        <- Generated graphics and figures to be used in reporting
│
├── requirements.txt   <- The requirements file for reproducing the analysis environment, e.g.
│                         generated with `pip freeze > requirements.txt`
│
├── src                <- Source code for use in this project.
│   ├── __init__.py    <- Makes src a Python module
│   │
│   ├── data           <- Scripts to download or generate data
│   │   └── make_dataset.py
│   │
│   ├── features       <- Scripts to turn raw data into features for modeling
│   │   └── build_features.py
│   │
│   ├── models         <- Scripts to train models and then use trained models to make
│   │   │                 predictions
│   │   ├── predict_model.py
│   │   └── train_model.py
│   │
│   └── visualization  <- Scripts to create exploratory and results oriented visualizations
│       └── visualize.py
│
└── tox.ini            <- tox file with settings for running tox; see tox.testrun.org

私のよりも見通しが良くて、どこに何を書けばいいかわかりやすい、、、


しかも使用者が気をつければ、上で紹介した機械学習のコードで泣くポイントをほとんど回避できる気がしている。。。


というか、このプロジェクトの大本のサイトにあるこの記事で書かれている通り、フォルダ構成がほぼすべてを表現できるように設計されている。。。



このテンプレートを使用する方法も、コマンド一発、、、しかもパッケージもpipでインストールできるし最強かよ、、、

pip install cookiecutter 

わーい!

後は、自分の使いたいテンプレート(上で紹介したテンプレート)を指定して、使用するだけという。

cookiecutter https://github.com/drivendata/cookiecutter-data-science

後は指示に従って頑張るだけ。


わーい!

この記事のテーマからは外れるかもだけど

基本的にはフォルダ構成を決めて、どこに何を書くかさえモデルを書く際に決めれば、基本的に機械学習系のコードでは泣かなくて済むことが増えるんじゃないかなという印象です。

実際のアプリレベルでの運用とかまでは私はまだやったことがないですが、個人でKaggleとか出たり、研究とかで開発する分には上のレベル感で十分かなと思いました。

実際のビジネス運用まで考えると、テストとかのことも考えないといけないですし、そうなるとちょっと話はまた変わってくるのかなと。

それでは。