数据科学家干嘛做 DevOps？
假如你打算绘制机器学习产品的管线图，一开始你就要设计和训练模型等，显然这属于数据科学职能。
按照正常的流程，通常在将模型投入生产的时候，将由数据科学过渡到基础架构任务。直观地讲，在此时数据科学团队会将事情交接给其他人，比如DevOps团队。
但并非总是如此。在更多的情况下，数据科学家们还要把模型部署到生产环境中。
据Algorithmia称，调查中大多数数据科学家，在模型部署这一任务上就花费了超过25%的时间。有趣的是，你可以看一下在数据科学家的招聘信息中，有多少要求应聘者具有Kubernetes，Dockers和EC2等的“必要经验”的，这足以验证上面的调查结果。
为什么数据科学家不必处理模型服务呢？
最简单的回答就是，模型服务是基础设施问题，而不是数据科学问题。你可以通过比较每个任务所使用的堆栈看出来：
模型开发 vs. 模型部署
当然，有些数据科学家喜欢DevOps，也能跨功能工作，但这样的人毕竟是少数。事实上我想说，人们经常高估数据科学和DevOps之间的重叠程度。
反过来想，你会期望一个DevOps工程师能设计新的模型架构，或者拥有
丰富的超参数调整的经验吗？可能会有一些DevOps工程师掌握了这些数据科学技巧，也能学习这些知识。但将这些视为你的DevOps团队的工作职责，是很奇怪的。
十有八九，数据科学家们不会担心弹性收缩，或编写Kubernetes清单。那为什么公司还要让他们这样做呢？
公司忽略了他们的基础设施
在很多组织中，人们根本不明白模型服务的复杂程度。他们的态度通常是，“现在只要在Flask中打包模型就够好了”。
实际上，任何规模的模型服务都涉及一些基础架构的挑战。例如：
- 如何在不停机的情况下，自动更新生产中的模型呢？
- 一个运行在GPU上的５GB的模型，该如何有效地实现弹性收缩呢？
- 如何监视和调试生产部署呢？
- 如何在不消耗大量云费用的情况下，完成所有这些工作呢？
现在，机器学习基础设施是一个很新的概念。两年前，Uber才透露了他们最先进的内部机器学习基础设施，Michelangelo。机器学习基础设施的很多方面还在发展之中。
然而，也有很多例子说明了，即使没有Uber的工程资源，一个组织该如何区分数据科学和DevOps的关注点。
如何区分数据科学和DevOps
我对这些主题的看法，主要来自我在Cortex上的工作。Cortex是我们的开源模型服务平台，我们通过它把数据科学和DevOps区分开来，并且使我们正在编写的所有基础设施代码自动化。开源以后，我们一直与采用该平台的数据科学团队合作，他们的经验也为我们提供了参考。
我们构建了一个简单抽象的架构，“模型-应用程序接口-客户
”（Model-API-Client），来实现数据科学、DevOps和产品工程之间壁垒的概念化：
- 模型。一个经过训练的模型，它包含一些predict()函数。即使不具备必需数据科学专业知识的工程师，也能使用这个模型。
- API。采用经过训练的模型，并将其部署为Web服务的基础结构层。我们构建Cortex来实现这一层自动化。
- 客户。与部署在API层中的Web交互的实际应用程序。
在模型阶段，数据科学家训练并导出模型。他们还可能编写用于模型生成和过滤预测结果的predict()函数。
然后他们将此模型交给API阶段，这时完全由DevOps功能负责。对于DevOps功能，该模型只是一个Python函数，需要把模型转化为微服务，集群化后完成部署。
一旦启用了模型-微服务，产品工程师就会像对其他API一样，对其进行查询。对他们来说，这个模型只是另一个Web服务罢了。
模型-应用程序接口-客户体系结构，并非唯一区分数据科学和工程的重点的方法。但是它表明了，不用花费过多的开销或者构建昂贵的端到端平台，你也能够划清数据科学和DevOps之间的界限。
仅通过在机器学习管线的不同的功能之间，建立清晰的切换点，你就能解放数据科学家，让他们去做自己最擅长的工作——数据科学。
原文链接，选题由雷锋字幕组提供
