为什么数据科学家需要承担开发运维的工作?

2020-06-01 11:25:53
Caleb Kaiser
文章摘要: 据统计,大多数数据科学家都需要花费25%以上的工作时间来部署模型。有趣的是,在数据科学家职位的招聘广告中也经常看见Kubernetes、Docker和EC2之类的技术要求。

作者 | 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

信息化软件服务网 - 助力数字中国建设 | 责编:左右
文明上网,理性发言!请遵守新闻评论服务协议
评论