数据科学 - 版本控制

+++翻译自Shuaiw's Blog, 转载请注明原作者出处+++

数据科学是一个相对较新的领域，没有首选的版本控制标准。在这篇文章中，我将讨论数据科学周期，其独特的版本控制策略以及一些可能的解决方案。

数据科学循环

数据科学不同于传统的软件工程, 尤其对于探索性数据分析, 特征工程, 机器学习建模和验证阶段. 但是数据科学和软件开发领域相似之处是都需要进行代码的i安歇, 数据科学倾向于代码的迭代性和循环性, 通常, 该循环开始与最初的数据理解, 然后是数据收集, 探索, 清洗和转换阶段, 并且最终转向数据建模和模型验证和相应机器学习模型的部署过程, 而且该循环将加深最初的数据理解并且成为下一个循环的开始.

Image credit: DataScience.LA

数据科学同时也更具有交互性, 我们经常看到数据科学家更倾向于使用notebook, 例如(Jupyter, Zeppelin, or Beaker), 而不是仅仅使用IDE, 因为notebook相比后者更具有交互性, 能够快速实现code-result的循环.

这要求不同的版本控制范例, 因为简单的复制软件开发领域的VCS(版本控制系统)应用到数据科学是不适合的. 数据科学需要它自身独有的版本系统, 以至于数据科学家和数据工程师能够更好的协作, 测试, 共享和复用.

目前，虽然我们看到了一些进展，, 但是数据科学领域的版本控制系统仍然相对不成熟, 并且拥有大量的优化空间, 在这篇blog剩下的部分, 我将讨论数据科学领域独有的版本策略.

版本策略

重复性

数据科学的指导原则是人们能够轻松地看到和复制彼此的工作。Cookiecutter Data Science有一段很好的评论

A well-defined, standard project structure means that a newcomer can begin to understand an analysis without digging in to extensive documentation. It also means that they don’t necessarily have to read 100% of the code before knowing where to look for very specific things.(定义明确的标准项目结构意味着新手可以理解分析，而无需深入了解大量文档。这也意味着在知道在哪里寻找非常具体的东西之前，他们不一定必须阅读100％的代码。)

重复性要求对于每个结果，跟踪它的生成方式，以及所包含的随机性的分析，记下底层的随机seeds。所有自定义脚本都需要进行版本控制。

需要意识到的一件重要的事情是为了确保数据科学的复用性, 我们不仅仅需要在类似GitHub, Bitbucket, and GibLab等平台上备份相应的代码, 同时需要对相应的数据以及模型进行版本控制.

数据版本化

相比代码, 通常, 数据因为它的大小因素很难进行版本控制. 当数据在GB范畴内, 应该感到为之庆幸, 因为在大数据时代, 通常数据规模都在TB或PB级别.

一个好的办法是, 保留原始数据不变更, 并且至少保留一个版本的原始数据.

有时, 某部分数据, 可能是经过一个耗时且繁重的程序运行的结果, 我们可能想要将某个中间步骤中所处理的数据dump到本地. 确保标记好生成这部分数据的脚本和该脚本的版本. 同时尽量不要变更数据路径, 否则其他脚本所指向的数据路径将发生严重崩溃.(注, 尽量在一开始便进行相应的文件路径规划).

同时, 开源或商业的数据版本控制方案也由很多, 例如, 像Amazon和Google的云供应商, 在他们的S3 and cloud storage服务, 因此数据科学家能够从偶然的错误操作或者软件故障中进行恢复. 同时, Git Large File Storage是一个对于大文件的版本控制扩展, 并且它可以在本地服务器进行部署. 但要记住的一件事是，更改原始文件并保存更新版本可以轻松地在版本控制系统中使用你的磁盘（假设你有一个5GB的文件，更改1个字节也会从硬盘再消耗另外的5GB）。

模型版本化

模型也应该不可变更. 模型因为特征工程, 参数调优, 新数据的增加会导致其版本呈现指数式增加.因此在版本控制中需要更多细节。通常，遵循以下规则将是不错的选择：

指定模型的名称，版本和训练脚本。拥有统一的命名约定, 例如(时间)-(模型名称)-(模型版本)-(训练脚本ID)
确保具有唯一的文件名(避免重写)
拥有一个全局json文件去存储模型名称和分数映射, 例如,
{'model name' : (training score, validation score, test set scores)}
拥有一个脚本根据不同的标准(例如测试集评分)去转换模型, 并且根据标准去清理legacy模型(例如根据标准低于x%或者未服务于某一年中的某一月).

Notebook版本化

Notebook是数据科学工作不可或缺的一部分，我们需要它来分享结果（特别是探索阶段的图表和发现）。

Image credit: Jupyter

虽然Notebook是JSON格式, 但是对于版本控制来说却非常不易. 具体, 有以下方式可以解决这个问题:

除去notebook的输出. 可以很容易手动去除Notebook输出单元格中的内容, 或者使用例如nbstripout库通过编程方式实现.
重构好的部分. 不要使用重复的代码, 数据科学家不应该使用不同notebooks去处理相同的任务. 假设我们需要去读入.csv文件, 并且将所有的非数值列进行编码处理. 在Notebook中, 我们可以看到类似的代码:

import pandas as pd

df = pd.read_csv('path/to/data')

### code block ###
for c in df:
  if df[c].dtype == 'object':
    df[c] = df[c].factorize()[0]
##################

相比粘贴复制代码段到新的Notebook中, 我们应该构建一个utils.py文件, 重构脚本为一个函数, 并且在下次使用时,导入该函数.

# uitls.py
def encode_object_col(df):
  # put code block here

# johndoe-eda-2017-02-30.ipynb
import pandas as pd
from utils import encode_object_col

df = pd.read_csv('path/to/data')
df =  encode_object_col(df)

为了更好, 我们可以增加一些处理步骤, 例如处理缺失值, 分割数据等等, 我们可以使用另一个类似管道的函数来调用所有重构函数，将每个步骤作为二进制或阈值进行参数化并将它们链接在一起：

# utils.py
def make_data_for_ml(*params):
  ... # read in data and process step by step

# johndoe-eda-2017-02-30.ipynb
from utils import make_data_for_ml
X_train, X_test, y_train, y_test = make_data_for_ml(*params)

重构虽好, 但是大部分人包括我自己会经常忽视这个工作(因为重构需要耗费时间和精力). 但是长期不重构, 只会使得数据工程越来越乱, 并且更难管理. 因此, 无论何时, 将重构的想法根植于心, 尽可能的使Notebook文件中的代码尽可能保持高利用度，同时利用VCS在脚本中对相对较低级别的代码进行版本控制。

最后, 我想说的是对于notebook文件的命名习惯问题. 因为他们通常是探索性脚本, 我们可能需要多次打开他们(因此就涉及到一个搜索相应notebook的问题). 常用的命名模式是(日期-作者-主题.ipynb), 因此我们可以通过以下方式搜索:

时间(ls 2017-01-*.ipynb)
作者(ls 2017*-johndoe-*.ipynb)
主题(ls *-*-feature_creation.ipynb)

所有字段当然都需要遵循一个共同的标准（2017-01-30或01-30-2017，JohnDoe，JDoe或jd）。

其他版本控制策略

设置分支借鉴于软件工程，分支可用于多用户和多阶段情况下的数据科学，其中典型的数据科学阶段（采集，EDA，特征工程等）可以跨越多个分支。

设置虚拟环境安装所有的软件或package相当耗时, 并且还需要随着时间对其进行升级, 因此一个好的想法是, 测试或者整合虚拟环境进入你的版本控制系统. 例如使用Data Science Toolbox, Virtualenv, Anaconda, or even Docker container去构建一个统一的环境.

JSON化超参数无论在脚本中放置参数多么诱人，都不要这样做。而是将它们放入全局JSON文件中, 如果创建了种子，也将它们放在此文件中。更好的是，将模型得分JSON文件与此结合起来，这样您的数据项目就会有一个参考来跟踪机器学习模型的性能，不同的参数设置如何影响性能，以及模型如何随着时间的推移而发展。

创建域知识流 经常被忽视或者至少是管理不善的一件事是领域知识的版本化。数据科学的一个关键部分是领域专有技术，它的使用程度如何影响数据结果的质量。而不是使用Excel或Word来跟踪SME的研究结果或笔记，而是在版本控制系统中创建专用流。

数据科学版本化方案

就像用于软件开发的VCS一样，我们面临着两种数据科学版本化的选择：托管方案和本地方案。然而，数据科学版本化有点不同，因为数据和模型隐私和合规性有时会使事情复杂化，因此托管解决方案不是一种选择。

在大多数情况下，Github或Bitbucket等托管服务以及云存储（S3或Google云存储）将为大多数数据科学版本打下基础。如果公司不希望他们的任何数据（甚至加密数据）位于其他人的磁盘中，他们可以在本地服务器上设置Git和Git大文件存储或其他分布式文件系统（如HDFS）来实现相同的目标。

无论我们选哪种方案，都需要集中式版本控制系统。以下是一些不错的方案:

数据版本控制(DVC)DVC是一个新的开源项目，通过自动构建数据依赖图（DAG）使数据科学可重现。它与Git，AWS S3，Google Storage集成，允许从单个DVC环境中单独共享代码和数据。

DVC sharing. Image credit: DVC

Pachyderm另一种选择是Pachyderm，一种用于生产数据管道的工具。在Docker和Kubernetes的基础上，Pachyderm可以在本地安装并部署在AWS, GCP, Azure, and more.等上。

Cookiecutter Data Science第三种选择是Cookiecutter Data Science，它具有逻辑的，合理标准化但灵活的项目结构，用于执行和共享数据科学工作。它将为数据科学项目创建一个目录结构（模板），并为您的数据流构建一个DAG。也可以在本地安装。

Luigi由Spotify构建的Luigi是一个Python模块，可帮助您构建批处理作业的复杂管道。它处理依赖项解析，工作流管理，可视化等。它还内置了Hadoop支持。查看源代码了解更多信息。