MLOps主要是数据工程

MLOps 主要是数据工程简而言之，MLOps 是一种新出现的工具类别，用于管理数据基础设施，主要面向 ML 用例，按照设想，这类用例会有独特的需求。

几年过去了，随着热度消退，MLOps 与数据工程的重叠显然比大多数人想象的要多。让我们看看这是为什么以及这对 MLOps 生态系统意味着什么。

MLOps 是一个相对比较新的术语。在谷歌趋势上快速地搜索一下就可以发现，其搜索量大约在 2019 年底开始增加。

通过观察上面的趋势线可以看出，2021 年底出现了一个显著的峰值。自那以后，人们对 MLOps 的兴趣一直很高。

不过，机器学习（ML）并不是什么新鲜事物，如果我们看一下谷歌趋势，就会发现这个术语自 2004 年以来就存在了，并且自 2015 年以来搜索量呈指数级增长。

谷歌上“机器学习”一词的趋势图

在过去的 10 年中，机器学习取得了惊人的进展，科技领域一些最重要的成就都与之相关。

机器学习的快速发展是 MLOps 作为一种类别诞生的原因。随着围绕 ML 的创新步伐加快，团队和公司开始遇到难题。

构建和运营 ML 产品开始给数据和 ML 工程团队带来很大的压力，而痛苦就意味着机会！

越来越多的人开始看到将新产品引入市场的机会，希望将每个拥有任何数据的公司都变成 AI 驱动的组织。

就这样，行业发展到了如下图所示的状况。

请记住，上面这个生态圈仅包括标记为“MLOps”的公司，并且与 MAD 2023 ML 类别中的其他类别存在重叠。

这个领域共吸引了 43 家供应商、约 10 亿美元的投资，这还没有计算像谷歌和 AWS 这样的上市公司。

让我们看看这些公司都提供了什么！

MLOps 供应商的产品可以划分为多个类别：

• 模型部署和服务，如 OctoML。

• 模型质量和监控，如 Weights & Biases。

• 模型训练，如 AWS Sagemaker。

• 特征库，如 Tecton。

需要指出的是，在许多情况下，各个类别是互补的。例如，你使用了特征库，还需要一个模型训练服务。

如果你关注过上述产品类别，就会注意到，整体上，它们没有什么特别之处。

为什么这么说呢？

模型部署和服务 → 这在数据工程和软件工程中都是很常见的操作。在 ML 出现之前，人们已经部署了管道，甚至以各种复杂的方式部署应用程序。

模型质量和监控 → 这是 ML 特有的问题。监控模型质量的方式与监控软件项目或数据管道的方式不同。但这只是质量问题的一部分，后面我们会看到更多内容。

模型训练 → 这是 ML 特有的，但构建模型并不新鲜。问题是，过去五年中发生的什么变化需要完全不同的范式来做这件事？

特征库 → 这是 MLOps 中最有趣的产品之一。对于初学者，首先想到的是某种专门的数据库，但特征库并不限于此。它们是作为一个完整的数据基础设施架构被提出并产品化。下文我们将看到，它们与传统的数据基础设施架构有多大的不同？

让我们看看上述每个类别与数据工程重叠（或不重叠）的情况以及这意味着什么。

在我看来，这是 MLOps 中最有趣的方面之一。这主要是因为这一部分是 ML 工程师所做工作的成果，可以产生具体的价值。

推荐系统可以向用户提供推荐服务，欺诈检测可以实时应用。

但有趣的是，这个过程与 ML 并没有太多关系，工程问题更多地与产品工程相关。

我们可以将模型视为一个需要输入和生成输出的函数。为了通过这个函数提供价值，我们需要一种方式将其添加到我们正在提供的产品体验中。

从工程角度来看，这意味着我们必须将模型封装为一个提供清晰 API 的服务，并将其暴露给产品工程师。

然后，我们需要以可扩展和可预测的方式部署这个服务，就像我们为产品中其他服务所做的那样。

之后，我们需要运行服务，并确保可以按需提供资源。

我们还需要监控服务是否出现了问题，并尽快修复它们。

最后，我们希望有某种持续部署 - 集成流程来部署服务更新，就像我们为产品中其他服务所做的那样。

可以看出，以上过程与管理任何其他软件组件的发布周期几乎完全相同，主要是产品工程部门作为利益相关者参与其中。

毕竟，他们必须确保模型提供的新功能以正确的方式集成到产品中，而不会破坏其操作。

由于要使用 ML 模型，所以就对工程和运维团队提出了一个特定的需求，就是要监控模型本身的性能。关于这个问题，我们稍后再讨论。

问题在于，如果在发布、平台工程和运营方面，将模型集成到产品与发布产品的任何其他特性相比都没有多大区别，那么为什么我们还需要一个全新的产品类别呢？

我的看法是，行业正试图通过构建完整的新平台来解决将模型转化为服务的独特挑战，但这不是最佳选择。

真正的需求是开发工具，它将丰富当前已经过验证的平台和方法论，用于以 ML 模型作为基础软件工件进行大规模发布和运营。

我们不需要 MLOps 工程师，我们需要工具，让 ML 工程师可以把他们的工作打包，然后平台和发布工程师利用打好的包生成产品工程师所需的工件，让他们集成到自己的产品中。

我经常看到的一个模式是，供应商会设法创建新的类别，定义新的工程师类型。

在大多数情况下，这是现有角色之间的一个复合，例如分析工程师，他们主要是分析师，但也会做一些数据工程方面的工作，例如创建管道。

这可能是一个聪明的营销策略，但世界不是这样运转的。新的角色会出现，但不能由供应商强推。

为什么我们希望机器学习工程师承担发布或平台工程师的职责？为什么我们希望面向前者推出一种他们在实践中完全不熟悉的全新工具类别？

在软件架构和组织设计中，关注点分离都是一件好事。

这是一个非常有趣的方面。质量保证、控制和监测是软件工程中一个非常重要的话题。稍微夸张点讲，是这些元素将软件工程变成了…工程。

对于软件质量相关的任务，有许多最佳实践和成熟的平台。问题是，机器学习模型很容易对这些最佳实践形成挑战。

你可能听说过，数据基础设施的质量很难保证，这是真的。我们不仅要监控软件的质量，还要监控数据的质量。但是运用质量的概念时，数据有很大的不同。

在机器学习中，情况甚至更糟。基本上，你生成的是一个黑盒系统，你只能通过在生产中观察其输入、输出来监控其性能。

因此，模型质量和监控通常与“模型漂移”等术语一并提起。我们会监控模型随着时间推移的“预测”效果，如果它低于一个阈值，我们就可以知道，需要用新数据重新训练它了。

这是有道理的，对吧？产品会变化，客户行为也会变化，模型需要重新训练以适应这些变化。

我这里主要有两个观点。

第一个是，模型质量监控的可观察性与产品相关的监控有何不同？在产品中，我们不断监控功能的性能，用户是否按我们预期的方式使用它们？如果有什么变化，参与度下降，我们应该解决这个问题，对吧？

这些通常都会被视为是产品实验基础设施的一部分，而其中很大一部分需要正确的数据基础设施和数据工程才能存在。

无论 ML 模型有多独特，最终我们都是观察一个服务在与用户交互时的表现，并根据我们收集到的数据确定是否需要采取行动。

我的感觉是，ML 的可观察性与数据基础设施（组织为产品实验构建的工程基础）之间存在很大的重叠。

我的另一个观点是关于数据质量的。ML 模型建立在数据之上，它们的质量直接反映了用于构建它们的数据的质量。

这是一个数据工程一直在努力解决的严重问题，我看不出复制下这个过程在什么方面有助于解决这个问题。

从收集数据到 ML 工程师可以使用这些数据，数据工程师可以监控整个过程。他们可以访问整个数据供应链，可以监控和控制链上的每一个点。

再增加一个与数据工程和产品工程质量控制都有重叠的平台解决不了问题，而且可能会使情况更糟。

再强调一遍，可以丰富现有架构和解决方案的工程工具才是解决方案。明确数据质量的含义，在负责数据和产品质量保证的人员中间形成共识，并将他们的关注范围扩展到 ML 模型。

说实话，模型训练更多的与云计算有关，而且在我看来，这是大型云服务提供商目前主要提供价值的领域。这主要是因为实际的训练需要硬件。

但一般情况下，模型训练只是一个数据管道。数据从多个来源读取，并通过训练算法进行转换。而这个过程是在 CPU 上进行，还是在 GPU 上进行，则并不重要。

这是数据工程的基础，而且已有工具，在我看来，主要的区别在于云计算抽象，无论如何，我们这里谈论的是类型完全不同的基础设施。

大规模的模型训练应该是数据工程学科的一部分，因为他们已经有工具，对所需的数据负有 SLA 责任，并且可以更好地控制发布生命周期。

ML 的人们会关心这些操作吗？我实在看不出来有什么理由。我认为，他们更愿意把时间花在构建新模型上，而不是处理大规模数据处理的运维。

说了这么多，总结起来还是我们不需要新平台。我们只需要为数据工程师提供合适的工具，让他们有效地与 ML 及产品工程师沟通，并将模型训练添加到 ETL 管道中作为一个步骤。

我特意把特征库留到最后，因为它们是与数据工程重叠的一个很好的例子，而它们的普及也表明当前的数据基础设施存在问题。、

上面是 Tecton 提出的特征库架构，它是最早和最受欢迎的特征库供应商之一。

从上面我们可以看到：

• 流式数据源

• 批处理数据源

• 转换

• 存储

• 服务

• 模型服务和训练

有些公司需要同时具备流处理和批处理能力。特征库与他们所使用的典型数据基础设施架构相似。但是，它们专门支持机器学习特征，并且只为一个类型的数据使用者——ML 模型——服务。

供应商已经将特征库架构打包成产品，这引起了一些困惑。有人可能会质疑，为什么需要另外的 Spark 或 Flink 集群实时进行特征生成，特别是如果他们已经在使用这些工具进行 ETL 作业。无论如何，特征库很有用，因为它们描述了为了有效地将机器学习产品化而需要往现有数据基础设施中添加的内容。

作为产品，特征库应该专注于构建工具和实践，使数据工程师、ML 工程师和产品工程师能够更有效地协同工作。任何额外的开销和复杂性都应该经过仔细评估，以确保使用特征库的好处超过成本。

供应商应该专注于提供有用的工具来支持这一点，而不是复制现有的数据基础设施。

希望读完这篇文章后，你不会觉得我试图否定 MLOps，因为我并没有。

我认为，ML 及其产品化非常重要，将来会变得更加重要，因此需要合适的工具。

但是，MLOps 行业需要成熟起来，并理解谁才是合适的受众，存在什么问题，并在市场上推出下一代解决方案。

金钱和时间已经投入了，教训应该也已经吸取了。我迫不及待地想看看下一代产品将是什么样子。

前方有很多机会！

原文链接：

https://www.cpard.xyz/posts/mlops_is_mostly_data_engineering/

声明：本文为 InfoQ 翻译，未经许可禁止转载。