不要再让数据科学家管理 Kubernetes 集群了

阅读数:4 2020 年 2 月 21 日 08:00

不要再让数据科学家管理Kubernetes集群了

本文内容基于我对机器学习团队的观察,而不是对该行业的学术调查。我是 Cortex 的贡献者,这是一个用于在生产环境中部署模型的开源平台。生产级机器学习有一个组织性的问题,这是因为它相对还比较新。虽然更成熟的领域(例如 Web 开发)经过几十年的发展已经有了最佳实践,但是生产级机器学习还没有。如果我们希望未来以 ML 为基础的软件真正普及开来,那么消除基础设施瓶颈就至关重要——要做到这一点,我们需要将其真正的专门化,让数据科学家专注于数据科学。

本文最初发布于 ****Towards Data Science**** 博客,经原作者授权由 InfoQ 中文站翻译并分享。

声明:以下内容基于我对机器学习团队的观察,而不是对该行业的学术调查。我的背景:我是 Cortex 的贡献者,这是一个用于在生产环境中部署模型的开源平台。

生产级机器学习有一个组织性的问题,这是因为它相对还比较新。虽然更成熟的领域(例如 Web 开发)经过几十年的发展已经有了最佳实践,但是生产级机器学习还没有。

举个例子,假设你的任务是为你所在的初创公司组建一个产品工程组织,而这家公司是一个开发 Web 应用程序的公司。即使你没有组建团队的经验,你也可以找到成千上万的文章和书籍,它们会告诉你这个工程组织应该采用什么结构以及如何发展。

现在想象一下,你在一家刚刚开始涉足机器学习的公司。你已经聘请了一名数据科学家来领导最初的工作,结果也不错。随着机器学习在产品中的应用越来越深入,随着数据科学家的职责迅速增加,机器学习团队显然需要发展壮大。

在这种情况下,并没有那么多关于如何构建一个生产级机器学习团队的文章和书籍。

这不是一个不常见的场景,经常出现的情况是,机器学习组织的新职责—特别是基础设施—被分配给了数据科学家。

这是个错误。

机器学习和机器学习基础设施的区别

在这一点上,平台和产品工程师的区别已经很好理解了。类似地,数据分析师和数据工程师显然是不同的角色。

许多公司的机器学习仍然缺乏这种专业化。

了解机器学习和机器学习基础设施之间的区别很重要,这有助于了解它们所需的工作和工具。

为了设计和训练新模型,数据科学家需要:

  • 把时间花在 Notebook、分析数据、做实验上。
  • 考虑类似数据保健和为数据集选择正确的模型架构这样的问题。
  • 使用 Python、R、Swift 或 Julia 等编程语言。
  • 对像 PyTorch 或 TensorFlow 这样的机器学习框架有自己的见解。

换句话说,他们的职责、技能和工具将围绕着操纵数据开发模型,他们的最终输出将是可以提供最准确预测的模型。

基础设施方面则完全不同。

将模型投入生产应用的一种常见方法是将其作为微服务部署到云中。要将模型部署为生产用 API,工程师需要:

  • 在配置文件、终端和云提供商的控制台之间分配他们的时间,设法优化稳定性、延迟和成本。
  • 考虑实例的自动扩展、在 API 不崩溃的情况下更新模型以及在 GPU 上提供推断服务等问题。
  • 使用 Docker、Kubernetes、Istio、Flask 等工具,以及他们的云提供商提供的任何服务 /API。

关于机器学习和机器学习基础设施方面的工作,下面是一个简单的可视化:

不要再让数据科学家管理Kubernetes集群了

机器学习 vs 机器学习基础设施

直观地说,数据科学家应该处理左边的圆,而不是右边的圆,这是有道理的。

让非专业人员管理基础设施有什么问题吗?

我们不妨做个假设。假设你必须指派某人来管理你的机器学习基础设施,但是你又不想让某人全职参与其中。你只有两个选择:

  • 一个是数据科学家,因为他们熟悉机器学习。
  • 一个是 DevOps 工程师,因为他们熟悉一般的基础设施。

这两种选择都有问题。

首先,数据科学家应该尽可能多的把时间花在他们最擅长的数据科学上。当然,这并不是说学习基础设施超出了他们的工作范围,只是基础设施和数据科学都是全职工作,将数据科学家的时间分配到这两项工作中会降低产出的质量。

其次,你的组织需要专门负责机器学习基础设施的人员。在生产环境中提供模型服务不同于托管 Web 应用程序。你需要一个专门的人来担任此角色,他可以在组织中倡导机器学习基础设施。

这种倡导是至关重要的。我了解了很多机器学习组织,你会惊讶地发现,他们的瓶颈往往不是来自技术性挑战,而是来自组织性挑战。

例如,我曾见过需要使用 GPU 进行推理的机器学习团队——像 GPT-2 这样的大型模型基本上都要求合理的延迟时间——但他们却无法获得 GPU,因为他们的基础设施是由更广泛的 DevOps 团队管理的,而这些团队不想让自己承担成本。

有专人致力于你的机器学习基础设施,意味着你不仅有一个不断改进基础设施的团队成员,还意味着你有一个能够满足你的团队需求的倡导者。

那么谁应该管理基础设施?

机器学习基础设施工程师。

现在,不要对这种官方的头衔有异议,要知道,机器学习还处于初级阶段,在头衔问题上,它还属于“狂野的西部”。不同的公司可能会有不同的叫法:

  • 机器学习基础设施工程师
  • 数据科学平台工程师
  • ML 生产工程师

我们已经可以看到成熟的机器学习组织招聘这个职位,包括 Spotify:

不要再让数据科学家管理Kubernetes集群了

还有 Netflix:

不要再让数据科学家管理Kubernetes集群了

随着诸如 Gmail 的 Smart Compose、Uber 的 ETA 预测和 Netflix 的内容推荐等基于 ML 的功能在软件中的应用越来越普遍,机器学习基础设施变得越来越重要。

如果我们希望未来以 ML 为基础的软件真正普及开来,那么消除基础设施瓶颈就至关重要——要做到这一点,我们需要将其真正的专门化,让数据科学家专注于数据科学。

英文原文: Stop making data scientists manage Kubernetes clusters

评论

发布