为什么现代人工智能项目离不开数据运维 (DataOps) 与机器学习运维 (MLOps)

我刚开始接触机器学习领域时，认为将模型部署到云环境是最大的挑战。我当时觉得，我只需要把在 Jupyter Notebook 中训练好的机器学习模型部署到云端，就 万事大吉了。

我错了。

起初，一切都按预期进行，大家都对部署的模型感到满意。然而，几个月后，当我尝试发布一个使用更新数据重新训练的新版本时，噩梦开始了。

混乱的数据管道拖慢了整个流程。修复 ETL 流程耗时过长，而且这并非我的职责，因为我是数据科学家。然而，数据团队不再愿意承担责任，因此，我不得不亲自解决这个问题。

我采取的所有 MLOps 措施，如实施实验跟踪、创建模型部署管道等等，都失败了，因为现在的问题是如何将正确的数据传递给我的模型训练管道。

这让我意识到，MLOps 的好坏取决于 DataOps 的好坏，两者缺一不可。

随着时间的推移，在与多个数据科学团队合作的过程中，我观察到一种一致的模式：公司专注于模型生命周期管理，但完全忽视数据生命周期管理。

他们像我一样实现了机器学习的 CI/CD 自动化，但他们仍然依赖手动脚本来移动生产数据并将其存储在开发人员的笔记本电脑上。

数据的重要性常常被忽视，尽管人工智能离不开数据。

但为什么我们对数据本身却如此漠不关心呢？

在本文中，我旨在展示数据运维和机器学习运维必须如何协同工作，才能最大限度地发挥人工智能的优势，并使其真正投入生产使用。

我将详细介绍每个学科的发展历程、它们的重叠之处，以及如何设计一个将它们统一到一个战略下的 AI 平台，以更好地支持机器学习项目的生命周期。

所以，如果你想让人工智能在你的公司取得成功，那就继续往下读吧！

什么是数据运维（DataOps）？

DataOps 受到 DevOps 的影响，DevOps 是软件工程的一种框架和思维方式。

所以，DataOps 之于数据，正如 DevOps 之于软件。

其核心在于将数据管道视为鲜活的、不断发展的系统，需要像软件一样进行严格的规范、测试和自动化。

目标：不再出现 ETL 作业故障、数据模式变更不一致以及无人愿意维护或执行的手动脚本。

DataOps 的核心是将 DevOps 原则（如协作、CI/CD、版本控制和可观测性）应用于数据工作流。

但这不仅仅是这样。它试图建立对数据的信任，因为如果你的数据不可靠，那么下游的一切（例如，机器学习、分析仪表板等）也都会不可靠。

根据我的经验，最佳的数据运维架构遵循以下几个关键原则：

数据质量被视为代码：所有进入系统的数据都会自动 验证。这就像对数据运行单元测试一样。

管道是声明式的，并且具有版本控制：使用Dagster 等编排器将数据流视为代码，从而可以使用 Git 跟踪它们，使用 CI 测试它们，并通过自动化部署它们。

数据溯源至关重要：您应该始终了解数据的来源、转换过程以及最后修改者。Amundsen、OpenMetadata 或 DataHub 等目录工具正是为此而生。

打破信息孤岛：DataOps 迫使从分析师到工程师的团队在单一的共享系统上协同工作，而不是来回传递 CSV 文件。

DataOps 使您对数据更有信心。

您可以获得自动警报、测试和可复现运行。

但是：只有正确操作才能做到。

数据运维最终并非关乎工具，而是关乎能够持续改进的习惯，在这种习惯中，数据像标准代码一样被设计、测试和交付。

什么是MLOps？

所以，DataOps 指的是准备数据，而 MLOps 指的是使用这些数据来训练机器学习模型。

它是训练模型和在现实世界中实际运行模型之间的桥梁。

我最初联系 MLOps 是因为我的模型在生产环境中运行遇到了一些问题。这包括监控模型性能、在不停机的情况下发布新版本模型以及应对流量高峰。其中最具挑战性的部分是：模型的运维部署。

MLOps（机器学习运维）将 DevOps 原则应用于机器学习生命周期，涵盖数据准备和训练、部署以及持续监控和维护。然而，与软件不同，机器学习系统是不断发展的。如果底层数据发生变化，模型的性能可能会下降，这意味着机器学习并非一劳永逸。我不能简单地训练一次模型，然后将其交给 DevOps 团队，就期望它能无限期地运行，或者至少运行到模型所针对的功能结束为止。

那么，一个好的 MLOps 堆栈应该具备哪些要素呢？

我认为以下几个方面最为重要：

实验跟踪：像MLflow或Weights & Biases这样的工具可以记录每次运行、指标和超参数，以便您以后可以重现结果。

模型版本控制和注册表：像管理代码一样管理模型，让您可以准确地知道哪个版本已投入生产以及它使用哪些数据进行训练。

持续训练和部署 (CT/CD)：使用GitLab CI、Tekton或Kubeflow Pipelines自动化重新训练、测试和部署管道。

监控与反馈：观察生产环境中的模型，不仅要关注延迟，还要关注数据漂移、概念漂移和性能衰减。

而最好的MLOP系统对数据科学家来说几乎是隐形的。他们只需一条命令就能推送模型，其余一切都由系统自动处理。

交汇点：数据运维与机器学习运维的交汇处

现在让我们来看看有趣的部分：数据运维和MLOps的交集。

以上是 完整的数据运维（DataOps）—多级运维（MLOps）流程图。在大多数公司里，这两者各自独立运作。一个专注于数据迁移和清洗，另一个专注于模型训练和部署。但这是一种错误的做法！

这两个领域紧密相连。如果其中一个出现问题，另一个也会受到影响。

即使你拥有最好的 MLOps 技术栈，但如果没有足够的数据，你也无法获得好的机器学习模型。

MLOps 确保模型的可靠性，而 DevOps 确保提供给模型的数据值得信赖。

你可以把MLOps想象成引擎，把DataOps想象成燃料系统。两者缺一不可，否则对整个系统的价值提升有限。

两者遵循相同的原则，但侧重点不同：

版本控制和可复现性：DataOps 对数据集进行版本控制，而 MLOps 对模型进行版本控制。它们共同确保每个模型都可以追溯到用于训练它的数据。

测试与验证：DataOps 验证数据质量，MLOps 验证模型性能。二者结合，构建了一道安全网，能够检测出数据缺陷和模型故障。

自动化和持续集成/持续交付 (CI/CD)：DataOps 可自动化 ETL 流程，而 MLOps 可自动化训练和部署流程。将两者结合起来，即可实现从数据到模型训练和部署的完整端到端自动化。

可观测性和溯源性：DataOps 追踪数据的来源，而 MLOps 追踪数据的使用方式。将两者结合起来，您就能知道哪个数据集是由哪个模型训练的，以及更多信息。

总而言之，两者都旨在尽可能实现自动化以减少人为错误，并尽可能进行跟踪以提高可追溯性和信任度。

目标不是将这两个学科合并成一个巨大的流行词，比如“DataMLOps”。而是要在它们之间建立一个反馈循环，使数据变化能够自动触发重新训练，而模型反馈可以为数据改进提供信息。

一旦你建立了这种反馈循环，你就可以放松下来，享受奇迹了！

设计统一的数据运维-机器学习运维工作流程

一旦你发现数据和机器学习经常因为相同的原因而崩溃，你就会开始以不同的方式设计系统。

相信我。

你要停止以孤立的视角思考问题（数据团队与机器学习团队）。

你会开始以封闭的思维模式思考，通过既定的沟通渠道和共同参与的会议来解决问题。

在设计统一的数据运维—MLOps工作流程时，你不仅仅是将两个技术栈粘合在一起。你是在构建一个单一的、连续的系统，在这个系统中，数据质量、模型性能和自动化相互促进。

让我们来看看这在实践中会是什么样子：

1. 数据摄取和验证

一切都始于数据。无论是日志、SharePoint导出数据还是S3导入数据，第一步都是确保数据干净、经过验证并进行版本控制，然后再进行其他任何操作。

Dagster、Airflow或Prefect等数据运维工具负责协调这些管道。它们运行测试（使用Great Expectations或Soda Core），并自动为每个数据集添加元数据标签，例如模式版本、时间戳和来源。

如果验证失败，管道将停止运行。这避免了数据悄无声息地损坏，也避免了“以后再修复”的心态。

相信我，每个人都经历过这种情况，但后来却忘记了解决它，因为桌上已经有了其他问题或任务。

2. 元数据和谱系

下一步需要跟踪元数据。这是数据和机器学习之间的桥梁。

DataHub、OpenMetadata或Amundsen等目录作为中央数据跟踪系统，跟踪数据的来源、变化方式以及哪些模型使用了这些数据。

这并非某些管理者可能会说的“锦上添花”。

必须做出类似“此模型版本是在 1月 14 日从我们的财务 API 获取的数据集 v3.4 上训练的”这样的声明，这样才能创建完整的可追溯性，并建立对机器学习模型和数据聚合的信任。

3. 模型训练与实验

现在MLOps部分开始发挥作用了。

MLflow、Vertex AI或Kubeflow等工具会获取已验证的数据，并处理实验跟踪、模型版本控制和可复现性。

每个实验都会记录元数据（数据集版本、代码提交哈希值、环境、指标等），因此如果出现问题，您可以回滚。

4. 持续部署和监控

模型通过评估后，自动化程序将接管后续工作。

CI/CD 流水线（GitLab、Tekton 或 Argo）将其部署到 Kubernetes 或您的服务平台。

从那里开始，监控工具会观察模型性能（准确率、漂移、延迟）和数据质量（模式偏移、缺失值、异常值）。

当检测到漂移或退化时，管道会触发重新训练作业，从而闭合循环，回到数据摄取。

5. 反馈回路

你想知道真正的奇迹何时发生吗？

这就是系统自我学习的过程！

学习是如何被触发的？

当观察到生产信号，对其进行评估并用于触发受控操作（例如，重新训练模型等）时，就会触发该功能。

那它是如何运作的呢？

来自生产环境的反馈（预测结果、性能指标）会回流到数据湖中。然后，这些数据会用于自动重新训练机器学习模型（如果需要再次审核某些数据，则会以半自动方式进行）。

真实案例

在我的一个项目中，我们使用Dagster进行流程编排，MLflow进行实验跟踪，GitLab CI 进行自动化，构建了这个工作流程。我们使用 DataHub 作为数据目录。

整个工作流程都在 Kubernetes 上运行。

从经验中汲取的现实教训

我对数据运维和多级运维的大部分了解都来自于观察真实系统缓慢崩溃，然后运用我从这两种方法论中学到的原则来修复它们。

首先，我学习了 MLOps，因为我们当时只专注于机器学习方面。实验得到了跟踪，部署实现了自动化，模型也进行了正确的版本控制。我们当时觉得一切都很完美。至少我们自己是这么认为的。

但实际上，这些模型存在很多问题，因为它们的行为难以预测，结果也与预期不符。

在排查故障的过程中，我学到了很多东西，现在我将与大家分享我的主要经验教训。

第一点：大多数“模型问题”都是数据问题。

第一个惨痛的教训是，我意识到许多机器学习事故与算法无关。上游某个列被重命名了。源系统中用于收集数据的硬件发生了变化，导致数据分布也随之改变。

如果没有强有力的数据运维实践，例如模式检查、数据验证和血缘关系，这些变化就不会被注意到。

这类问题的棘手之处在于：模型不会崩溃，而是悄无声息地性能下降，用户对你的应用程序感到不满，并失去信任。

而这正是所有人工智能项目面临的最大风险！悄无声息的性能下降会在人们意识到问题之前很久就摧毁信任。一旦信任丧失，利益相关者就会得出结论：“人工智能行不 通”，然后放弃。

一旦我们添加了明确的数据测试并在流程中强制执行，数量惊人的“机器学习问题”就消失了。

第二点：元数据胜过仪表盘

我们最初尝试用仪表盘监控所有数据，包括准确率图表、漂移图和延迟指标。这些指标都很有用，但并不全面。

我们真正需要的是背景信息。

然后，我们开始收集工作流程中每个步骤的元数据。突然间，我们就能回答诸如“哪个数据集训练了这个模型？”、“生产环境中运行的是哪个特征版本？”、“自上次部署以来发生了哪些变化？”之类的问题了。

现在，我们不仅可以判断出哪里出了问题，还可以通过收集到的元数据知道原因。

当被问及要收集多少元数据时，我的建议是多收集一些，因为在我们的情况下，存储成本几乎为零，所有元数据都存储在廉价的 S3 存储中。

第三点：所有权比工具更重要

我们使用了优秀的工具，例如编排框架、实验跟踪器和 CI/CD 流水线。然而，当所有权不明确时，问题依然存在。数据属于一个团队，模型属于另一个团队，而生产事故的归属却不明确，仿佛所有人都不认识谁。

最显著的改进来自于我们决定所有权需要遵循机器学习项目的生命周期，而不是组织结构图。

团队随后不仅要负责构建模型，还要负责这些模型所依赖的数据。

第四点：简单的系统寿命更长。

我见过的最稳健的流程并不是最复杂的，而是人们真正能够理解的。

尽量保持数据管道的简洁性。就我们而言，我们决定不采用性能最高的批量数据管道，这样可以减少维护工作量。

但这种权衡始终取决于具体情况和您的具体需求。

第五点：没有防护措施的自动化是危险的。

在某个阶段，我们大力推进了再培训的自动化。

数据有变？重新训练。

新标签到了？重新培训。

它看起来很棒，听起来也很精彩，因为不再需要人为干预了。

但是后来收集到的数据集有缺陷，自动化程序生成了一个糟糕的模型。

因此，我们引入了审批门、质量阈值以及关于何时可以进行自动化的明确规则。

例如，某些训练路径需要人工参与，在检查了一些标记的数据后点击批准。

因此，完全端到端的自动化听起来总是很棒，但它并不总是最佳解决方案。

展望未来：人工智能基础设施平台的崛起

现在，MLOps 和 DataOps 发展得非常迅速。

和以往一样，一开始总会掀起一股热潮，想要构建这样一个平台，能够服务于公司内部的各种工作流程。

但各支球队都厌倦了自己包揽一切。这并非因为他们做不到，也不是因为这不好玩（剧透：其实挺好玩的）。

但更重要的是，集成工作永无止境。迟早有一天，你不再是“开发新功能”的团队，而是“维护”团队，这可能并非你当初部署和开发此类平台时的初衷。

这就是人工智能基础设施平台发挥作用的地方。

这些平台为 MLOps 和 DataOps 提供了共同的基础：统一的元数据、一致的治理、集成的编排以及涵盖整个生命周期的工作流。

这种趋势可以从两个方面来看待。

一方面，云原生平台正在不断扩展。数据平台正在增加模型训练、特征管理和部署等功能。与此同时，MLOps平台正在向下延伸至数据沿袭、质量检查和治理等领域。“数据平台”和“机器学习平台”之间的界限变得越来越模糊。

另一方面，许多团队，尤其是在受监管或本地部署的环境中，正在构建自己的内部平台。这些平台不再是工具的简单集合，而是经过精心设计的系统，拥有清晰的契约、共享的元数据和强制执行的策略。

然而，最有趣的变化在于概念层面。整个行业正逐渐从以模型为中心的思维模式转向以数据为中心的AI运维。团队不再问“如何更快地部署模型？”，而是问“如何持续改进模型所依赖的数据？”这种思维模式的转变自然而然地将数据运维（DataOps）和模型运维（MLOps）整合到同一个平台理念之下。

人工智能基础设施平台总体上分为三类：

集成商业平台（有主见、端到端）：Databricks、Palantir、Snowflake。

云原生 AI 平台（托管、可扩展、可控）：Google Vertex AI、AWSSageMaker。

开放的、可组合的技术栈（功能强大但要求较高）：Kubeflow、MLflow、Dagster、Airflow、DataHub等。

最终成果不会是一个“一刀切”的工具，而是一代人工智能基础设施平台，它们将最佳实践直接融入系统之中。

小结

数据运维 (DataOps) 和机器学习运维 (MLOps) 通常被视为两个独立的领域，有时甚至被视为相互竞争的优先事项。但在实践中，这种区分在与生产系统接触后往往难以维系。

模型并非孤立失效。它们失效的原因在于其依赖的数据发生变化、假设悄然失效，以及反馈来得太晚甚至根本没有反馈。同样，即使是最可靠的数据管道，如果模型无法以可控的方式部署、监控和改进，也无法创造价值。

所以你需要把人工智能系统视为连续系统，而不是“我把一个模型扔过围栏，它就总能正常工作”。

那些打造出最优秀、最具价值的人工智能应用的团队，并非那些追逐最新模型架构的团队，而是那些投资于看似枯燥的基本要素的团队：数据质量、元数据、所有权和反馈循环。

随着人工智能深入渗透到业务关键型工作流程中，这种思维方式变得不可避免。问题不再是你需要数据运维还是机器学习运维，而是你是否愿意将它们设计成一个统一的系统。

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。