作者 | Caleb Kaiser
译者 | 弯月，责编 | 夕颜
头图 | CSDN下载自视觉中国
出品 | CSDN（ID:CSDNnews）
以下为译文：
如果你需要创建一个生产环境下的机器学习流水线，那么开始的部分工作（设计和训练模型等）显然属于数据科学的范畴。
某种意义上，当你需要将模型投入生产环境时，需要将常规的流水线从数据科学领域转移到基础设施领域。直观地讲，这时数据科学团队需要将工作移交给其他人，即开发运维。
然而，现实并非总是如此。越来越多的公司开始要求数据科学家负责将模型部署到生产的工作。
据统计，大多数数据科学家都需要花费25%以上的工作时间来部署模型。有趣的是，在数据科学家职位的招聘广告中也经常看见Kubernetes、Docker和EC2之类的技术要求。
为什么数据科学家不应该处理模型服务？
简单来说，模型服务是基础架构的问题，不属于数据科学范畴。我们可以比较一下这两个领域使用的技术栈：
当然，有些数据科学家喜欢开发运维，他们也可以承担跨部门的工作，但是这种情况比较罕见。事实上，我认为大家都高估了数据科学与开发运维之间的重叠度。
我们反过来看，你是否认为开发运维工程师能够设计新的模型体系结构，或者拥有大量调整超参数的经验？可能那些具备了数据科学知识，而且愿意学习一切的开发运维工程师确实能够胜任这些工作，但是将这些工作视为开发运维团队的职责就很奇怪了。
将心比心，数据科学家也不应该操心自动伸缩或编写Kubernetes清单文件的工作。那么为什么各个公司会这样要求他们呢？
各个公司忽视了基础设施的工作
许多组织对于模型服务的复杂程度存在根本的误解。通常他们的态度是“利用Flask打包一下模型就足够了。”
然而现实情况是，无论规模如何，任何模型服务都涉及一系列基础设施的难题。例如：
如何在保证不停机的情况下，自动更新生产中的模型？
如何有效地自动伸缩一个在GPU上运行的5GB模型？
如何监视和调试生产部署？
如何在控制云消费的情况下，完成所有的工作？
平心而论，现如今的机器学习基础设施是一个非常新的概念。两年前，Uber才透露了他们最先进的内部机器学习基础设施：Michelangelo。机器学习基础设施的编写方式多种多样。
但是，很多组织也很好地示范了如何在没有Uber工程资源的情况下，将数据科学与开发运维的工作重心分开来。
如何分离数据科学与开发运维的工作？
在这个话题上，我的很多看法主要来自我从事的开源模型服务平台Cortex上的工作。
我们通过模型-API-客户端的抽象架构，概念化了数据科学、开发运维与产品工程之间的交接工作：
模型：经过训练的模型，即便是没有数据科学专业知识的工程师也可以使用predict()函数。
API：基础设施层接受训练好的模型，然后部署为Web服务。我们构建了Cortex来自动化这一层的工作。
客户端：实际与部署在API层中的Web服务交互的应用程序。
在模型阶段，数据科学家会训练并导出模型。他们还将负责编写predict()函数，用于根据模型生成和过滤预测。
接下来，他们会将该模型移交给API，这个阶段的工作完全由开发运维部门负责。对于开发运维部门来说，该模型只是一个Python函数，只需将其转换为微服务，然后进行容器化和部署。
在模型-微服务启动后，产品工程师就可以把它们当作API进行查询。对他们来说，该模型只是一个Web服务。
模型-API-客户端体系结构不是分割数据科学与工程问题的唯一方法，但这个例子说明了你完全可以在数据科学和开发运维之间划清界线，同时无需引入过多的开销或构建昂贵的端到端平台。
只需在机器学习的工作流程中建立明确的交接点，就可以将数据科学家解放出来，让他们去做擅长的工作：数据科学。
作者简介
Caleb Kaiser，机器学习基础设施工程师。
原文链接：
https://towardsdatascience.com/why-are-data-scientists-doing-devops-bc36d00584c3
