Yelp 借助 Training Orchestrator 实现机器学习模型训练的统一管理

Yelp 推出了 Training Orchestrator。这一全新的内部框架取代了各团队各自独立编写的 Spark 训练脚本。现在，它采用了一种基于配置、以 DAG 为基础的执行模型。此举解决了大型机器学习平台中常见的问题。此前，每个应用机器学习团队都会创建自己的编排方案，这导致了代码重复、配置不一致以及自定义监控机制不稳定等问题。

在此之前，Yelp 的训练任务是以单体脚本的形式运行的，而且与 Spark 集群和作业启动器执行紧密耦合。这导致了无法在本地运行、可测试性差以及迭代速度缓慢的问题。即使是很微小的代码更改，也需要提交一个 Spark 作业，然后等待容器和集群启动完成后才能知道是否发生了故障。验证逻辑分散在各个脚本中，这使得在不同的环境中重现过去的运行过程变得非常困难。此外，还存在配置不一致和溯源信息缺失等问题。

Training Orchestrator 将“运行什么”与“如何运行”分离开来。管道使用基于 Pydantic 的配置对象，其中包括协调器配置、MLflow 运行配置以及各种步骤配置。所有配置在创建时都会经过验证，因此不会浪费计算资源。协调器利用声明的步骤依赖关系构建出一个有向无环图（DAG），随后，它会按拓扑顺序执行这些步骤。其中还添加了一个共享的 Spark/MLflow 上下文，相同的步骤定义无论是在本地、Jupyter 还是生产环境中，均可以直接运行而无需修改。每个步骤将一个设置类与一个用户定义函数关联了起来。它使用输入/输出模式来展示其接收和返回的内容。例如，PrepareDataStep 接收一个数据集，并输出一个经过预处理的数据集。这种设置使团队能够轻松更改预处理逻辑。他们可以同时运行不同的模型版本。此外，他们还可以在不同管道之间复用函数，而且不需要更改编排代码。

训练编排器架构

模式验证能够快速发现配置不匹配的问题。它能在几秒钟内标记出诸如步骤输入/输出配对错误、参数超出范围等问题。这比在 Spark 作业运行数小时后才发现这些问题要快很多。由于步骤与基础设施是分离的，开发人员可以使用样本数据在本地运行完整的管道。他们还可以为每个步骤编写单元测试。此外，对数据加载步骤的输入进行缓存，可以缩短在较小数据集上进行的集成测试的时间。每一次运行的完整配置都会自动作为 MLflow 工件记录下来，从而可以基于这一记录重现运行过程。此前各团队需要手动实现的 Slack 通知和 MLflow 运行跟踪功能，现在只需设置几个配置参数就可以实现。

训练协调器与 Yelp 的机器学习平台协同工作。它连接了特征存储库、共享神经网络、梯度提升树库以及用于跟踪和部署的 MLflow。核心机器学习团队将训练协调器视为他们所需的关键协调层。这是一个内部框架，并非开源项目。Yelp 计划为模型评估、比较和解释添加明确的步骤，并将在编排层实现血缘追踪。这样一来，该框架就可以无缝地扩展至现有管道，而不需要进行迁移。

其主要模式采用经过 Pydantic 验证的声明式步骤配置，并由此驱动有向无环图（DAG）执行引擎。这种模式实现了训练逻辑与集群运行时的分离，可以同时支持本地运行和单元测试。这种方法不只适用于 Yelp 专有的 Spark 技术栈。需要考虑的问题在于，需要对模式和步骤类型设计进行初期投入，还要将现有脚本迁移到“设置与函数”契约中。Yelp 认为，这是成本集中化的一种方式，可以避免团队重复承担这些成本。

Yelp 的这一举措反映了行业内广泛存在的一种趋势。许多拥有多个机器学习团队的公司都正朝着这个方向发展，试图构建一个清晰规范的集中式训练基础设施。Netflix 也通过 Metaflow 取得了一些进展。最近，他们新增了一个配置对象，使团队能够清晰地管理其所维护的众多机器学习管道中的流程行为。Uber 的 Michelangelo 平台正是为了解决 Yelp 提到的碎片化问题而创建的。它通过提供从原型设计到生产环境部署的清晰路径来帮助使用不同工具的团队。

这些举措表明，各工程团队得出了一个共同的结论：随着模型和训练团队数量的增加，临时性的协调工作已经成为瓶颈。尽管初期成本较高，但集中管理这一流程能够提高可重现性、可测试性以及开发效率。

原文链接：https://www.infoq.com/news/2026/07/yelp-ai-model-training/