為什么要重視項目結(jié)構(gòu)?

說起數(shù)據(jù)分析，我們往往會想到報告結(jié)果、深入見解或可視化。通常這些最終結(jié)果占據(jù)了主要地位，所以人們很容易專注于讓結(jié)果看起來漂亮而忽略了生成它們的代碼質(zhì)量。但是，這些最終結(jié)果都是以編程方式創(chuàng)建的，所以代碼質(zhì)量仍然很重要!此處我們討論的不是代碼縮進或格式標(biāo)準(zhǔn)，數(shù)據(jù)科學(xué)的代碼質(zhì)量的最終標(biāo)準(zhǔn)是正確性和可再現(xiàn)性(reproducibility)。

眾所周知，好的分析通常是隨意和偶然探索的結(jié)果。各種沒得到結(jié)果的探索性實驗和快速測試都是通往好結(jié)果道路上的一部分，并且沒有靈丹妙藥可以將數(shù)據(jù)探索轉(zhuǎn)變?yōu)楹唵蔚木�性過程。

一旦開始一個項目，就很難再去思考代碼結(jié)構(gòu)和項目布局了。所以最好從一個干凈、合乎邏輯的結(jié)構(gòu)開始并一以貫之。我們認(rèn)為使用這樣的標(biāo)準(zhǔn)化設(shè)置是非常有好處的。原因如下：

其他人會感謝你

定義明確的標(biāo)準(zhǔn)項目結(jié)構(gòu)意味著新手無需研究大量文檔就可以理解一項分析。這也意味著他們不一定非得閱讀100%的代碼才知道去哪里找特定的內(nèi)容。

組織良好的代碼往往能做到自我記錄(self-documenting)，組織結(jié)構(gòu)本身可以在無需太多開銷的情況下為你的代碼提供上下文。人們會因此感謝你，因為他們可以：

● 更輕松地與你在此分析中合作

● 從你對流程和領(lǐng)域的分析中學(xué)習(xí)

● 對分析得到的結(jié)論充滿信心

你可以在任何主流的Web開發(fā)框架(如Django或Ruby on Rails)中找到這方面的好例子。在創(chuàng)建一個新的Rails項目之前，沒有人會去思考要在哪個位置放什么，他們只是運行rails new來獲得像其他人一樣的標(biāo)準(zhǔn)項目骨架(skeleton)。由于該默認(rèn)結(jié)構(gòu)在大多數(shù)項目中都是合乎邏輯且合理的，因此從未見過該特定項目的人也可以容易地找到各種部件。

另一個很好的例子是類Unix系統(tǒng)的文件系統(tǒng)層次結(jié)構(gòu)標(biāo)準(zhǔn)(Filesystem Hierarchy Standard)。/ etc目錄有非常特定的目的，就像/ tmp文件夾一樣，每個人(或多或少)都同意遵守該約定。這意味著Red Hat用戶和Ubuntu用戶都知道在哪里查找某些類型的文件，即使他們使用的是對方的系統(tǒng)或者其他任何符合該標(biāo)準(zhǔn)的系統(tǒng)!

理想情況下，當(dāng)同事打開您的數(shù)據(jù)科學(xué)項目時，也應(yīng)該如此。

你會感謝自己

你嘗試過重現(xiàn)幾個月前甚至幾年前做的分析嗎?你可能編寫了代碼，但現(xiàn)在卻不知道是否應(yīng)該使用make_figures.py.old，make_figures_working.py或者new_make_figures01.py來完成工作。以下是我們的一些問題：

● 在開始之前，是否應(yīng)該主動把X列加入到數(shù)據(jù)中?還是說其中某個notebook可以完成這一步?

● 想一想，在運行繪圖代碼之前我們必須首先運行哪個notebook：它是“過程數(shù)據(jù)”還是“干凈數(shù)據(jù)”?

● 地理圖形中所用的shapefiles是從哪下載的?

● 等類似問題

這些問題讓人頭疼，并且是無組織項目的癥狀。良好的項目結(jié)構(gòu)應(yīng)該讓人很容易回到舊時的工作，例如分離關(guān)注點，將分析抽象為DAG，以及版本控制等實踐。

沒有任何約束

不贊同某些默認(rèn)文件夾名稱?正在做一個不標(biāo)準(zhǔn)且與當(dāng)前結(jié)構(gòu)不完全匹配的項目?更愿意使用與(少數(shù))默認(rèn)包不同的包?

去吧!這是一種輕量級結(jié)構(gòu)，旨在成為許多項目的良好起點。正如PEP 8所說：

項目內(nèi)部的一致性更為重要。一個模塊或功能內(nèi)部的一致性是最重要的。...但是，要知道何時不一致，有時風(fēng)格指南建議并不適用。如有疑問，請用你的最佳判斷。查看其他示例并確定最佳效果。并且不要猶豫去提問!

開始

我們?yōu)镻ython項目創(chuàng)建了一個數(shù)據(jù)科學(xué)cookiecutter模板。您的分析不一定要在Python中，但模板確實提供了一些Python樣板，您可能想要刪除它們(例如，在src文件夾中，以及docs中的Sphinx文檔框架)。

需求

● Python 2.7 或 3.5

● cookiecutter Python package >= 1.4.0: pip install cookiecutter

開始一個新項目

啟動新項目只需在命令行中運行如下命令。無需先創(chuàng)建目錄，cookiecutter將為您完成。

cookiecutter

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

示例

 

 

原文中是一段視頻，建議從原文鏈接中觀看。

原文鏈接：

https://www.kdnuggets.com/2018/07/cookiecutter-data-science-organize-data-project.html

目錄結(jié)構(gòu)

├── 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

觀點

項目結(jié)構(gòu)中隱含著一些觀點，這些觀點源于我們在數(shù)據(jù)科學(xué)項目合作時可行的和不可行的工作經(jīng)驗。一些觀點是關(guān)于工作流程的，一些是關(guān)于提高效率的工具的。以下是該項目所依據(jù)的一些信念，如果您有想法，請?zhí)峁┗蚍窒怼?/p>

數(shù)據(jù)是不可變的

不要編輯原始數(shù)據(jù)，尤其不要手動編輯，也不要在Excel中編輯。不要覆蓋原始數(shù)據(jù)。不要保存多個版本的原始數(shù)據(jù)。將數(shù)據(jù)(及其格式)視為不可變的。你編寫的代碼應(yīng)該讓原始數(shù)據(jù)通過分析流程管道并得到最終分析。沒必要每次想要創(chuàng)建一個新計算時都運行所有步驟(請參閱Analysis是DAG)，但是任何人都應(yīng)該能夠僅使用src中的代碼和data /raw中的數(shù)據(jù)來重現(xiàn)分析結(jié)果。

此外，如果數(shù)據(jù)是不可變的，則它不需要像代碼那樣進行源代碼控制。因此，默認(rèn)情況下，data文件夾包含在.gitignore文件中。如果你有少量很少會被更改的數(shù)據(jù)，你可能希望將數(shù)據(jù)包含在repo中。目前Github會警告文件是否超過50MB并且拒絕超過100MB的文件。用于存儲/同步大型數(shù)據(jù)的一些其他方案包括同步工具(例如，s3cmd的AWS S3，Git Large File Storage，Git Annex和dat)。目前默認(rèn)情況下，我們請求一個S3 bucket并使用AWS CLI將data文件夾中的數(shù)據(jù)與服務(wù)器同步。

Notebooks用于探索和交流

Jupyter notebook, Beaker notebook, Zeppelin和其他交互式編程工具對于探索性數(shù)據(jù)分析(EDA)來說是非常高效的。然而，這些工具對重現(xiàn)分析而言效果較差。 當(dāng)我們在工作中使用notebook時，我們經(jīng)常細(xì)分notebook的文件夾。例如，notebook/exploration包括初始探索，而notebook/report包含更漂亮的工作，并可以作為html格式導(dǎo)出到report目錄。

由于notebooks挑戰(zhàn)了源代碼控制的目標(biāo)(例如，json的差異通常不是人類可讀的，并且?guī)缀醪豢赡芎喜?，我們不建議直接在Jupyter notebooks上與其他人合作。為了有效的使用notebooks，這里有兩個建議：

● 遵守一種命名習(xí)慣，可以展現(xiàn)作者以及所做分析的順序。我們使用這種格式: --.ipynb(例如，0.3-bull-visualize-distribution.ipynb)。

● 重構(gòu)某些好的部分。完成相同任務(wù)的代碼不要寫在多個notebook中。如果是一個數(shù)據(jù)預(yù)處理任務(wù)，放入處理管道并把代碼寫在src/data/make_dataset.py中，并且從data/interim中加載數(shù)據(jù)。如果是有用的工具代碼,重構(gòu)到src中。

譯者注：用文本編輯器打開jupyter notebook的文件，可以看到其本質(zhì)上是一個json格式的文件，所以這里作者說很難使用Git去diff或merge不同版本的notebook代碼，不過目前已有工具致力于解決這個問題，例如nbdime。

默認(rèn)情況我們把項目轉(zhuǎn)換成一個python包(見setup.py文件)。你可以導(dǎo)入自己的代碼，并且在notebook中使用，方法如下：

# OPTIONAL: Load the "autoreload" extension so that code can change
%load_ext autoreload
# OPTIONAL: always reload modules so that as you change code in src, it gets loaded
%autoreload 2
from src.data import make_dataset

分析就是DAG

在分析中，你常常會有一些運行時間很長的步驟，比如預(yù)處理數(shù)據(jù)或者訓(xùn)練模型。如果這些步驟已經(jīng)運行過了(并且你已經(jīng)將輸出保存在了某處，例如data/interim目錄)，那你肯定不想每次都等待它們重新運行。我們更喜歡用make來管理彼此依賴的步驟，尤其是運行時間很長的步驟。Make是基于Unix的平臺上的常用工具(可用于Windows)。遵守make官方文檔, Makefile conventions和portability guide將幫助確保你的Makefile在各個系統(tǒng)中有效工作。這是一些入門示例。許多從事數(shù)據(jù)工作的人都使用make作為他們的首選工具，其中就包括Mike Bostock。

還有其他用來管理使用Python而不是DSL(領(lǐng)域特定語言)編寫的DAGs的工具(例如，Paver，Luigi，Airflow，Snakemake，Ruffus或Joblib)。如果它們更適合您的分析，請隨意使用。

從環(huán)境開始構(gòu)建

重現(xiàn)某個分析的第一步通常是重現(xiàn)它運行的計算環(huán)境。你需要相同的工具，相同的庫和相同的版本，以使一切都很好地協(xié)同工作。

一個有效的方法是使用virtualenv(我們建議使用virtualenvwrapper來管理virtualenvs)。通過列舉repo中的所有需求(我們包含一個requirements.txt文件)，你可以輕松跟蹤用于重現(xiàn)分析所需的包。以下是一個不錯的工作流程：

● 運行mkvirtualenv創(chuàng)建新項目

● pip install分析所需的包

● 運行pip freeze > requirements.txt以確定用于重現(xiàn)分析的確切包版本

● 如果你發(fā)現(xiàn)需要安裝其他軟件包，請再次運行pip freeze > requirements.txt并將更改提交到版本控制。

如果你對重新創(chuàng)建環(huán)境有更復(fù)雜的要求，請考慮基于虛擬機的方法，如Docker或Vagrant。這兩個工具都使用基于文本的格式(分別為Dockerfile和Vagrantfile)，你可以輕松添加到源代碼控制中，以描述如何創(chuàng)建滿足需求的虛擬機。

密碼和配置不要加入版本控制

你肯定不想在Github上泄露你的AWS密鑰或Postgres用戶名和密碼。不再贅述，請看關(guān)于這一點的Twelve Factor App。這是一種方法：

將您的機密和配置變量存儲在一個特殊文件中

在項目根目錄中創(chuàng)建一個.env文件。感謝.gitignore，永遠(yuǎn)不要把該文件提交到版本控制repo中。以下是一個例子：

# example .env file
DATABASE_URL=postgres://username:password@localhost:5432/dbname
AWS_ACCESS_KEY=myaccesskey
AWS_SECRET_ACCESS_KEY=mysecretkey
OTHER_VARIABLE=something

使用包自動加載這些變量

如果查看src / data / make_dataset.py中的存根腳本，它使用了一個名為python-dotenv的包將此文件中的所有條目作為環(huán)境變量加載，以便可以使用os.environ.get訪問它們。這是一個改編自python-dotenv文檔的示例片段：

# src/data/dotenv_example.py
import os
from dotenv import load_dotenv, find_dotenv
# find .env automagically by walking up directories until it's found
dotenv_path = find_dotenv()
# load up the entries as environment variables
load_dotenv(dotenv_path)
database_url = os.environ.get("DATABASE_URL")
other_variable = os.environ.get("OTHER_VARIABLE")

AWS CLI配置

當(dāng)使用Amazon S3存儲數(shù)據(jù)時，有一個簡單的方法來管理AWS訪問，即把訪問keys設(shè)置為環(huán)境變量。但是在一臺機器上管理多個keys(例如，同時有多個項目)時，最好還是使用一個憑證文件(credentials file)，通常放在~/.aws/credentials，該文件看起來像這樣：

[default]
aws_access_key_id=myaccesskey
aws_secret_access_key=mysecretkey
[another_project]
aws_access_key_id=myprojectaccesskey
aws_secret_access_key=myprojectsecretkey

你可以在初始化項目時添加名稱。假設(shè)未設(shè)置合適的環(huán)境變量，則使用默認(rèn)的配置。

保守地更改默認(rèn)文件夾結(jié)構(gòu)

為了使這種結(jié)構(gòu)廣泛適用于不同類型的項目，我們認(rèn)為最好的方法是對于你自己的項目而言，你可以自由更改文件夾，但在改變用于所有項目的默認(rèn)結(jié)構(gòu)時要保守。

我們專門為添加，刪減，重命名或移動文件夾的問題創(chuàng)建了一個文件夾布局標(biāo)簽。 更一般地說，我們還創(chuàng)建了一個需求討論標(biāo)簽，用于在實施之前應(yīng)該進行仔細(xì)討論和廣泛支持的問題。

貢獻

Cookiecutter數(shù)據(jù)科學(xué)項目有點武斷，但不怕出錯。最佳實踐總在改變，工具一直在發(fā)展，我們從中吸取了教訓(xùn)。該項目的目標(biāo)是使啟動、構(gòu)建和共享一個分析更加容易。我們鼓勵提出請求和提交問題。我們很想知道什么對你有用，什么沒用。

如果你使用Cookiecutter數(shù)據(jù)科學(xué)項目，請鏈接回此頁面或給我們一個贊，并讓我們知道!

相關(guān)項目和參考鏈接

項目結(jié)構(gòu)和可再現(xiàn)性更多地在R研究社區(qū)中被討論。以下是一些項目和博客文章，如果你使用R工作則可能會幫到你。

● Project Template - An R data analysis template

● "Designing projects" on Nice R Code

● "My research workflow" on Carlboettifer.info

● "A Quick Guide to Organizing Computational Biology Projects" in PLOS Computational Biology

最后，非常感謝Cookiecutter項目(github)，它幫助我們花更少的時間思考和編寫樣板文件，從而花更多的時間去完成工作。

標(biāo)簽： 代碼 服務(wù)器 腳本 數(shù)據(jù)分析

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。