最近听了一场微软在 EngineeringDaily 的关于数据科学团队协作和工作流的 Podcast 分享，觉得挺有意思，于是爬上去看了看，发现还是挺不错的。这篇文章主要用来描述在微软，数据科学项目是如何被执行落地和交付的。之后会再想办法挖一下啊其他家大厂的这个方向上的工作流。当然我个人认为工作流最有价值的点不是具体执行什么内容，而是为什么要执行这些内容和什么时候去执行这些内容。

顺便贴一下原文地址：https://docs.microsoft.com/en-us/azure/machine-learning/team-data-science-process/。

概览

大致的工作流流程

首先从大致的工作流程出发，这一点非常直观。下边儿这张图比较简明扼要的概括了一个数据科学项目有哪些流程。主要是：

1. 商业理解

2. 数据获取清理

3. 建模

4. 部署

5. 成果检测与交付

角色介绍

具体这 5 个流程中每个流程应该完成那些事情，以及对应的 Deliverable 会在后面详细介绍一下。然后在这整个 5 大块的工作流程过程当中，又分为一下 4 种角色：

1. Solution Architect 解决方案架构师

2. Project Manager 项目经理

3. Data Scientist 数据科学家

4. Project Lead 项目负责人

具体的这 4 个角色是如何在上边儿几个流程里协同工作的流程以及不同流程的 Deliverable 可以参考下面这个流程图：

标准模版项目结构

对数据科学团队（大概 4 人以上）来说，标准化数据科学项目对于项目执行以及管理是非常重要的。如果团队非常小，只有 2 个人，其实不太需要拘泥于标准化项目结构。但是当团队扩张之后就需要有一个好的标准化的模版来参考。在微软的标准数据科学项目中，一个项目主要由 3 个部分组成：项目文档，数据源，代码。这里对于项目代码文档和项目功能性/商业需求文档是分开的，项目代码文档应当存在代码这个部分里面。因为看这两类的人群不一样，意图也不太一样，所以最好分开。

数据科学项目技术架构与工具

这边微软的官方文档上边儿给了几个推荐，分别是云端存储，数据库，分布式计算框架比如 Hadoop 和 Spark 集群还有一些机器学习服务。他们的 GitHub 上面有专门的一个Repo来介绍工具。我这边个人来讲一般会把工具分为 3 类：存储，引擎，和算法平台。具体每块有哪些工具可以选型之后会再写篇文章总结一下。不过这里实际上去和项目应用的时候应当按照具体环境实施。如果有解决方案架构师的话，他们往往能给出非常不错的参考建议。

详细工作流程介绍

讲完概览，我们这边来详细讲一下工作流程

阶段 1:商业理解

阶段目标

1. 定义问题：明确模型要解决的问题以及相关的评估标准。

2. 定义数据源：明确解决这个问题所需要的数据是否是已有的或者是可能需要额外收集的。

如何达到这些目标

1. 定义问题

2. 在定义问题的过程中，我们需要知道整个项目想要预测分析的目标量是什么。它可以是Regression来带的Forecast，也可以是某个记录为某个特定Class的可能性。这里其实就是需要 Data Science 团队里面能有人去提供行业背景知识和业务背景知识的了（Industrial Expertise）

3. 明确问题的类型。微软把数据科学解决的问题分为了5个大类

4. 回归：预测量

5. 分类：预测类别

6. 分组：就是Clustering，分组

7. 异常检测：也就是常说的Anomaly Detection

8. 推荐

9. 定义团队角色和分工

10. 定义可衡量的项目成功标准。这里微软推荐用SMART标准来制定这一标准：

11. Specific

12. Measurable

13. Achievable

14. Relevant

15. Time-bound

16. 定义数据源

17. 这里边数据主要可以分为两类，一类就是我们的相关数据或者特征, Indpendent Variables。还有一类就是Dependent Variable。前者可以去确保我们能够通过建模来解决我们的问题，后者可以帮助我们评估模型的效果。

阶段性交付内容

1. 项目的计划书
   

2. 数据源以及数据获取方式
   

3. 数据文档
   

阶段 2:数据获取清理

阶段目标

1. 构建一个干净的，质量优秀的，与阶段1中的目标量相关且了解关系是什么样的数据集。并且将这分数据放在即将要建模的环境里面。

2. 构建一个能够方便产生上述数据集的数据清洗管道。比如很多ETL都是做这个的。

如何达到这些目标

这一步主要有 3 步，主要是获取数据，探索数据集，设置数据管道。下面分开讲讲。

1. 获取数据：这一步需要明确如何获取数据，具体内容视架构而定。比如工具选择上Sqoop还是Flume都得视具体环境决定。解决方案架构师应当帮助数据科学团队明确技术选型。

2. 探索数据集：数据探索分析，也就是常说的EDA。这里微软提供了一个样例的数据探索分析的JupyterNotebook,非常具有参考价值。在数据探索完成之后，便可以开始着手对数据的组成以及情况进行了解，之后才是进行建模。对数据分布，组成，以及意义进行了解之后，在模型选择以及构建这一步其实会更加的游刃有余。但是我们不可置否这一步常常会经常的重复进行，因为我们也许会对数据质量不满意或者认为需要更多纬度/特征。

3. 设置数据工作流：这一步我们需要根据我们的数据以及软件架构建造一个相对简便的数据获取自动化的流程。这一步往往有3种数据收集的方式：

4. 批式收集

5. 流式收集

6. 二者混合

阶段性交付内容

1. 数据质量报告 可参考上方提到的样例的数据探索分析JupyterNotebook

2. 解决方案架构：它可以是数据管道的架构图或者是解释。我们会用这个架构来测试新构建的模型。这个结构应该也能够支持我们基于新的数据来刷新之前构建的模型。

3. 决策点： 重新评估项目，评估是否项目是否可行。

阶段 3:建模

阶段目标

1. 找出对于模型来说最适合的特征

2. 构造出一个最精准的可用于解决业务问题的机器学习模型

3. 构造出一个适合部署的机器学习模型

如何达到这些目标

1. 特征工程

这一步会通过对于数据的总结，聚合以及变形来帮助构造新的特征以达到分析的目的。如果我们想要知道模型的背后是怎么构成的，那么我们就得去理解特征构成的规则以及我们使用的机器学习算法是如何利用特征来构造出这些模型的。这一步其实需要算法能力和业务能力结合。特征工程其实是在平衡尽可能找到相关特征并且避免无关特征。相关特征会帮助我们提升模型的效果，但是无关特征则会给数据集带来很多噪音。

2. 模型训练

基于解决的问题类型不同，我们选择的算法往往也不一样。算法选择方向上微软有给一篇参考文章。模型训练大致来说有以下 4 步：

• 切割数据为训练集合和测试集合

• 构建模型

• 评估模型

• 选择最优解决方案

微软这里非常良心的给了一个 Baseline 模型的生成工具 是用 R 语言写的。喜欢 R 的小伙伴们可以关注一下。但是这个文件最近一次更新是 3 年前，所以我估计也没什么人在用或者就是非常稳定导致没有更新哈哈哈。

阶段性交付内容

特征列表：构建模型所用到的特征列表。这里微软也有给出一个参考文档，非常推荐。

模型报告：同样，也有模版，不过个人认为不要太纠结于模版，而是要思考模版里边儿的每一块儿背后都是什么，为什么要有它。

决策点：这里有 2 个主要的决策点：1. 这个模型是否能够解决我们提出的问题 2. 如果不能，我们是否需要去回到阶段 2 重新收集数据，建模。

阶段 4:部署

阶段目标

将模型成功部署到生产环境，为线上业务提供稳定的服务。

如何达到这些目标

尽可能的将模型的部署做到组件化、积木化。具体取决于业务场景。个人认为这块儿主要分为在线预测和离线预测的，这两种场景的部署方式都是大不相同的。

阶段性交付内容

1. 模型性能以及表现的看板

2. 模型部署结果报告

3. 解决方案架构

阶段 5:成果检测与交付

阶段目标

交付项目，确认数据管道工作流以及模型效果和部署都能满足需求方的目标。

如何达到这些目标

1. 确认功能上模型能够解决需求方的问题。

2. 将项目交付给使用模型的组，或者是ML ops团队。

阶段性交付内容

项目结束报告，这里微软也有给出参考的文档 主要还是总结归纳并且探索之后如何优化。其实还是离不开项目复盘的那几大块。引用最近看的一个主播常说的这叫做一通百通。

结语

1. 微软在进行数据科学项目的规范化的时候我们还是能非常直观的感受到大公司的这种流程制定标准的。某种程度上来说，它降低了公司的管理成本，同时也能帮助职员们更好的执行内容。但是这些的前提，我认为还是需要去了解哪些流程是必要的，哪些流程是也许可以省略的。毕竟很多公司可能数据科学团队就3个人，流程搞得太复杂反而会降低效率。

2. 微软也很认可数据科学项目需要和实际的业务应用场景结合，要接地气。我相信对于在做数据科学的同学们来说，如何和行业专家有效交流的这种能力在这类项目里面是非常宝贵的。

3. 一个平台型的工具，微软Azure的ML Service，其实还是有一定的learning curve的。产品设计合理的时候，配合产品的培训往往会给项目团队带来非常不错的return。不过这里也说到了，产品设计是否合理，其实是很难界定的。从我个人的角度出发，我觉得一个好的平台型还是得能灵活多变，配套不同的使用场景。比如Excel，你甚至能在一些游戏发布会上看到这个产品的身影。当然，这里的Trade off就是scale的成本。往往不标准化的产品，用的好的能上天，用不习惯的往往觉得设计反人类。

作者简介：

鱼哲， 阿里云史上最年轻产品经理，有从 0 到 1 构建数据科学团队的经验，知名开源软件 Jupyter Lab 贡献者。

本文转载自公众号：“数据科学老司机”。

原链接：https://mp.weixin.qq.com/s/3Y6aNFXw-NdxaJ3m_8e5sQ