最新 ‖ 详解UBER的机器学习平台：米开朗基罗

本文作者：Jeremy Hermann Uber工程经理，Mike Del Balso是Uber机器学习平台团队的产品经理。

Uber Engineering致力于开发，为客户创造无缝体验的技术。我们正在越来越多地投入人工智能（AI）和机器学习（ML）来实现这一愿景。

在Uber，我们对这个领域的贡献是米开朗基罗（michelangelo），这是一个内部的ML-as-a-service服务平台，使机器学习民主化，并且AI可以满足商务需求，就像打车一样简单。

米开朗基罗平台使内部团队能够以Uber的规模无缝地构建，部署和运行机器学习解决方案。它旨在涵盖端到端ML工作流程：管理数据、训练、评估和部署模型，进行预测和监控预测。

该系统还支持传统ML模型，时间序列预测和深度学习。

米开朗基罗已在Uber应用了大概一年，已成为我们的工程师和数据科学家的机器学习的常用系统，有数十个团队建立和部署模型。事实上，它被部署在几个Uber数据中心，利用专门的硬件，并为公司最高负载的在线服务提供预测。

在本文中，我们介绍了Michelangelo以及产品用例，并且深入了解了这个强大的新的ML-as-a-service系统的工作流程。

▍米开朗基罗的初衷

在米开朗基罗之前，我们面临着：建立和部署Uber的大规模数据机器学习模型的一些挑战。

虽然数据科学家，正在使用各种各样的工具来创建预测模型（R，scikit-learning，自定义算法等），但是单独的工程团队，也在构建定制的一次性系统，以在生产中使用这些模型。

因此，Uber希望建立ML平台，数据科学家和工程师可以在短时间内建立大多数开源工具。

具体来说，目前还没有建立可靠、统一、可重复的管道系统，用于大规模创建、管理训练和预测数据。在米开朗基罗之前，不可能训练比数据科学家台式机更适合的模型，而且没有一个标准的地方来存储训练实验的结果，也不是一个比较一个实验与另一个实验的简单方法。

最重要的是，没有确定将模型部署到生产中的途径- 在大多数情况下，相关工程团队必须创建专门针对项目的定制服务库。同时，我们也开始看到Scully等人记录的许多ML反模式的迹象。

米开朗基罗旨在通过将整个团队的工作流程和工具标准化，通过端到端的系统来解决这些差距，使整个公司的用户能够轻松构建和运行大规模的机器学习系统。

我们的目标不仅仅是解决这些直接的问题，而且还要建立一个能够与企业发展相关的体系。

当我们在2015年中期开始建立米开朗基罗时，我们开始将可扩展模型训练和部署的挑战应用于生产服务器。然后，我们专注于建立更好的管理和共享特征管道的系统。

最近，重点转移到开发人员的生产力- 如何加快从想法到第一生产模式的路径以及随后的快速迭代。

在下一节中，我们将看一个示例应用程序，以了解米开朗基罗如何用于构建和部署模型以解决Uber的特定问题。虽然我们强调了UberEATS的具体用例，但该平台可以管理各种类似的模型，用于各种预测用例。

▍用例：UberEATS预计交货时间模型

UberEATS有几种型号运行在米开朗基罗，涵盖外卖交付时间预测，搜索排名，搜索自动填充和餐厅排名。交付时间模型预测，在订单发出之前准备和交付外卖需要多少时间，然后在交货过程的每个阶段再次预测。

图1：UberEATS应用程序承载了，由米开朗基罗建立的机器学习模型提供的预测交付时间功能。

预计外卖送货时间（ETD）并不简单。

当UberEATS客户下订单时，它被发送到餐厅进行处理。餐馆然后需要确认订单，并准备餐，这将需要时间，这取决于订单的复杂性和餐厅的繁忙程度。

当餐点接近准备时，一个Uber派送伙伴被派去拿起饭菜。然后，送餐员需要到达餐厅，找到停车场，走进去拿食物，然后回到车里，开车到客户的位置（这取决于路线，交通等因素），找到停车位，并走到客户的门口完成交货。

目标是预测这个复杂多阶段过程的总持续时间，

在米开朗基罗平台上，UberEATS数据科学家使用梯度推进决策树回归模型，来预测这种端到端交付时间。该模型的特征包括来自请求的信息（例如，时间，交货地点），历史特征（例如过去七天的平均外卖准备时间）和近实时计算的特征（例如，平均外卖准备时间最后一个小时）。

模型部署在Uber数据中心，提供给服务器的米开朗基罗模型，并通过UberEATS微服务器的网络请求进行调用。这些预测，将在从餐厅订购之前，向UberEATS客户展示，并且展示正在准备和交付餐点。

▍系统架构

米开朗基罗由一系列的开源系统和内置的组件组成。使用的主要开源组件是HDFS，Spark，Samza，Cassandra，MLLib，XGBoost和TensorFlow。

我们通常更愿意，在可能的情况下使用成熟的开放源代码选项，并根据需要进行分支、定制和贡献，尽管我们有时，会在开源解决方案不适合我们的用例时，自行构建系统。

米开朗基罗建立在Uber数据和计算基础设施之上，提供数据湖，存储所有Uber的事务和记录数据，Kafka经纪人汇总来自所有Uber服务的记录消息，Samza流式计算引擎，管理Cassandra群集和Uber's家庭服务配置和部署工具。

在下一节中，我们将使用UberEATS ETD模型作为案例研究，以体现米开朗基罗的技术细节，从而深入了解系统的各个层次。

▍机器学习工作流程

在Uber几乎所有机器学习用例中，都存在相同的一般工作流程，无论手头的挑战，包括分类和回归，以及时间序列预测。

工作流通常与实现无关，因此很容易扩展，以支持新的算法类型和框架，例如较新的深度学习框架。它也适用于不同的部署模式，如在线和离线（以及车载和手机）预测用例。

我们专门设计了米开朗基罗，以提供可扩展，可靠，可重现，易于使用和自动化的工具来解决以下六步工作流程：  

• 管理数据

• 训练模型

• 评估模型

• 部署模型

• 生成预测

• 监控预测

接下来，我们将详细介绍：米开朗基罗的架构，如何促进这一工作流的每个阶段。

管理数据

找到良好的功能，通常是机器学习中最难的部分，我们发现构建和管理数据管道，通常是完整的机器学习解决方案中，最昂贵的部分之一。

平台应提供建立数据管道的标准工具，以生成用于训练（和重新训练）的功能和标签数据集以及仅用于预测的特征数据集。

这些工具应与公司的数据湖或仓库，以及公司的在线数据服务系统进行深度整合。管道需要具有可扩展性和性能，包括数据流和数据质量的综合监控，并支持在线和离线训练和预测。

理想情况下，他们也应该以可以在团队间共享的方式生成功能，以减少重复的工作并提高数据质量。他们还应提供强有力的护栏和控制措施，以鼓励和授权用户采用最佳做法（例如，使得训练时间和预测时间，都能够保证使用相同的数据生成）

米开朗基罗的数据管理组件，在线和离线管道之间划分。目前，离线管道用于投喂批量模型训练和批量预测作业，在线管道在线提供，低延迟预测（以及在不久的将来，打造在线学习系统）。

此外，我们还添加了一层数据管理功能，可让团队共享，发现和使用高度策划的功能集，用于机器学习解决问题。

我们发现，Uber的许多建模问题，都使用相同或相似的功能，并且在使团队能够分享自己的项目之间的功能，以及不同组织中的团队之间共享功能方面具有重大价值。

图2：数据准备管道将数据推送到Feature Store和训练数据存储库。离线

Uber的事务和日志数据流入HDFS数据湖，并且可以通过Spark和Hive SQL计算作业轻松访问。

我们提供容器和调度，以运行常规作业以计算功能，这些功能可以对项目进行private，或发布到Feature Store（见下文），并在团队之间共享，而批处理作业按计划或触发器运行，并与数据集成质量监控工具合作，可以快速检测流程中的回归- 由于本地或上游代码或数据问题。

在线

在线部署的模型，无法访问存储在HDFS中的数据，并且通常难以从Uber的生产服务（例如，无法直接查询UberEATS订单服务）直接从在线数据库中，计算特定时段内餐馆的平均外卖准备时间）。

相反，我们允许将在线模型所需的功能，预先计算并存储在Cassandra中，在预测时可以以低延迟读取它们。

我们支持两种在线计算服务功能，批量预计算和近实时计算，如下所示：

• 批量预计算：计算的第一个选择是，定期进行批量预先计算，并将历史特征从HDFS加载到Cassandra中。这是简单而有效的，一般适用于历史功能，只要功能只能每隔几小时更新一次即可。

  
  

  该系统保证了相同的数据和批次管道用于训练和服务。UberEATS使用该系统的功能，如“ 餐厅在过去七天的平均外卖准备时间”。
  

• 近实时计算：第二个选择是将相关指标发布到Kafka，然后运行基于Samza的流计算任务，以低延迟生成聚合特征。然后将这些功能直接写入Cassandra，提供服务并登录到HDFS，以便将来进行训练。

像批量系统一样，近实时计算确保了相同的数据用于训练和服务。为了避免冷启动，我们提供了一个工具，通过对历史日志运行批处理作业，来“回填”此数据并生成训练数据。

UberEATS使用这种近乎实时的管道，来实现“餐厅在过去一个小时的平均外卖准备时间”的功能。

Shared feature store

我们发现，建立一个集中的Feature Store非常有价值，其中Uber的团队可以创建和管理他们的团队使用，并与他人共享功能规范。在高层次上，它完成了两件事情：  

它允许用户轻松地将他们内置的功能，添加到共享功能存储中，只需要少量额外的元数据（所有者，描述，SLA等），而不需要private，项目 - 具体用法。

一旦功能部件在Feature Store中，通过在模型配置中引用功能的简单规范名称，它们在线和离线都很容易使用。配备此信息，系统处理加入正确的HDFS数据集进行模型训练或批量预测，并从Cassandra获取正确的值以进行在线预测。

目前，Feature Store中有大约10,000个功能用于加速机器学习项目，而整个公司的团队都在增加新的功能。Feature Store中的功能每天都会自动计算和更新。

将来，我们打算探索构建自动化系统，以搜索Feature Store的可能性，并确定解决给定预测问题的、最有用和最重要的功能。

功能选择和转换的域特定语言

通常，由数据流水线生成，或从客户端服务发送的功能，不是模型的正确格式，并且它们可能缺少需要填充的值。此外，该模型可能只需要提供的一部分功能。

在某些情况下，模型可能会把时间戳转换为一小时或一周的时间，以更好地捕捉季节性模式。在其他情况下，特征值可能需要归一化（例如，减去平均值并除以标准偏差）。

为了解决这些问题，我们创建了一个DSL（域特定语言），建模者用于选择，转换和组合，在训练和预测时间发送到模型的功能。DSL实现为Scala的子集。它是一个纯功能语言，具有一套完整的常用功能。

使用这种DSL，我们还为客户团队，添加自己的用户定义功能的能力。存在从当前上下文（在离线模型的情况下的数据流水线，或来自客户端的在线模型的情况下的当前请求）或从Feature Store获取特征值的访问功能。

重要的是要注意，DSL表达式是模型配置的一部分，并且在训练时间和预测时间应用相同的表达式，以帮助确保在两种情况下，都生成相同的最终特征集，并将其发送到模型。

训练模型

我们目前支持决策树的离线，大规模分布式训练，线性和逻辑模型，无监督模型（k-means），时间序列模型和深度神经网络。

我们定期添加新的算法来应对客户的需求，并且由Uber的AI实验室和其他内部研究人员开发。此外，我们让客户团队通过提供定制训练，评估和服务代码来添加自己的模型类型。

分布式模型训练系统可以扩展到，处理数十亿个样本和低质量数据集，以进行快速迭代。

模型配置指定模型类型，超参数，数据源引用和特征DSL表达式，以及计算资源需求（计算机数量，内存量，是否使用GPU等）。它用于配置在YARN或Mesos群集上运行的训练作业。

在模型训练之后，计算绩效指标（如ROC曲线和PR曲线），并将其合并到模型评估报告中。在训练结束时，将原始配置，学习参数和评估报告，保存回我们的模型库进行分析和部署。

除了训练单一模型之外，米开朗基罗还支持对所有模型类型，以及分区模型的超参数搜索。使用分区模型，我们会根据用户的配置，自动对训练数据进行分区，然后对每个分区训练一个模型，在需要时回到父模型（例如，每个城市训练一个模型，并回到国家级模型，当准确的城市级模式无法实现）。

训练作业可以通过Web UI或API进行配置和管理，通常用 Jupyter notebook（http://jupyter.org/）。许多团队使用API和工作流程工具来安排他们的模型的定期重新培训。

图3：模型训练作业，使用Feature Store和训练数据库数据集来训练模型，然后将其推送到模型库。

评估模型

模型训练，以识别为其问题创建最佳模型的一组特征，算法和超参数。在达到给定用例的理想模式之前，训练数百种不进行切割的机型并不罕见。

虽然这些模型并没有最终用于生产，但是这些模型的性能，可以指导工程师进行模型配置，从而获得最佳的模型性能。跟踪这些受过训练的模型（例如，谁训练他们，什么时候，什么数据集，哪些超参数等等），评估它们，并将它们相互比较通常是处理这么多模型和呈现的大挑战为平台增添了很多价值的机会。

对于在米开朗基罗训练的每个模型，我们在Cassandra的模型库中，存储一个版本化对象，其中包含以下记录：

• 谁训练了模型

• 训练工作的开始和结束时间

• 完整型号配置（使用的功能，超参数值等）

• 参考训练和测试的数据集

• 每个特征的分布和相对重要性

• 模型精度指标

• 每种模型类型的标准图表（例如二进制分类器的ROC曲线，PR曲线和混淆矩阵）

• 模型的完整学习参数

• 模型可视化的摘要统计

• 该信息可通过Web UI轻松获得，并通过API以编程方式提供，用于检查单个模型的细节，以及将一个或多个模型彼此进行比较。

模型精度报告

回归模型的模型精度报告，显示了标准精度指标和图表。分类模型将显示不同的集合，如图4和5所示：

图4：回归模型报告显示与回归相关的绩效指标。

 

图5：二进制分类绩效报告显示与分类有关的绩效指标。

决策树可视化

对于重要的模型类型，我们提供复杂的可视化工具，以帮助建模者了解模型的行为原理，以及如有必要帮助调试。

对于决策树模型，我们让用户浏览每个单独的树，以查看它们对整个模型，它们的分割点，每个特征对特定树的重要性的相对重要性，以及每个树的数据分布分割等变量。

用户可以指定特征值，并且将可视化描绘决策树下的触发路径，每棵树的预测和模型的总体预测，如图6所示： 

图6：可以用强大的树可视化来探索树模型。

功能报告

米开朗基罗提供了一个功能报告，其中显示了每个功能的顺序，对模型的重要性以及部分依赖图和分布直方图。选择两个功能，可让用户将功能交互理解为双向部分依赖关系图，如下所示：

图7：功能，它们对模型的影响及其相互作用可以通过功能报告进行探索。

部署模型

米开朗基罗拥有，通过UI或API管理模型部署的端到端支持，以及可以部署模型的三种模式：

离线部署：该模型部署到离线容器中，并运行在Spark作业中，以按要求或重复计划生成批量预测。

在线部署：该模型部署到在线预测服务集群（通常包含负载平衡器后面的数百台机器），客户端可以将单个或批量预测请求作为网络RPC调用发送。

Library 部署：我们打算推出一个部署到一个服务容器的模型，该容器在另一个服务中，作为库嵌入并通过Java API进行调用。（以下图8中未显示，但与在线部署相似）。

图8：来自模型存储库的模型部署到在线和离线容器进行投喂。

在所有情况下，所需的模型数据（元数据文件，模型参数文件和已编译的DSL表达式）打包在ZIP存档中，并使用我们的标准代码部署基础架构，将其复制到Uber数据中心的相关主机。预测容器自动从磁盘加载新模型，并开始处理预测请求。  

许多团队拥有自动化脚本，可通过米开朗基罗的API，安排定期的模拟再训练和部署。在UberEATS交付时间模型运行时，数据科学家和工程师通过Web UI手动触发训练和部署。

生成预测

一旦模型被服务容器部署和加载，它们将用于根据从数据管道加载的特征数据或直接从客户端服务进行预测。原始功能通过编译的DSL表达式传递，可以修改原始特征和/或从Feature Store获取附加功能。

最终特征向量被构造，并传递给模型进行评分。在线模型运行时，通过网络将预测返回给客户端服务。在离线模型的情况下，预测将被写回Hive，可以通过下游批处理作业进行消费，或直接通过基于SQL的查询工具访问用户，如下所示：

 

图9：在线和离线预测服务使用特征向量集来生成预测。

参考模型

可以同时将多个模型部署到给定的服务容器。这允许从旧型号到新型号的安全过渡以及模型的并行A / B测试。在服务时间，模型由其UUID和部署期间指定的可选标记（或别名）标识。

在线模型的情况下，客户端服务与要使用的模型UUID或模型标签，一起发送特征向量; 在标签的情况下，容器将使用最近部署到该标签的模型，来生成预测。

在批量模型运行时，所有部署的模型，用于对每个批次数据集进行评分，并且预测记录包含模型UUID和可选标记，以便消费者可以适当地过滤。

如果两个模型，在部署新模型以替换旧模型时，具有相同的签名（即期望相同的特征集），则用户可以将新模型部署到，与旧模型相同的标签，并且容器将开始使用新模型立即。

这允许客户更新其模型，而不需要更改其客户端代码。用户还可以使用其UUID部署新模型，然后修改客户端或中间服务中的配置，以逐渐将流量从旧模型UUID切换到新模型。

对于模型的A / B测试，用户可以通过UUID或标签简单地部署竞争模型，然后使用Uber的客户端服务中的实验框架，将部分流量发送到每个模型并跟踪性能指标。

规模和延迟

由于机器学习模型是无状态的，不分享任何东西，因此在线上和离线服务模式下，它们都是微不足道的。在线模型，我们可以简单地为预测服务集群，添加更多的主机，并让负载均衡器扩展负载。在离线预测的情况下，我们可以添加更多的Spark执行程序，并让Spark管理并行性。

在线服务延迟取决于模型类型和复杂性，以及模型是否需要Cassandra功能存储区的功能。在不需要Cassandra功能的模型的情况下，我们通常会看到P95的延迟小于5毫秒（ms）。

在需要Cassandra功能的型号的情况下，我们通常会看到P95的延迟小于10ms。目前最高的交通模式每秒提供超过25万次预测。

监控预测

当对模型进行训练和评估时，始终使用历史数据。为了确保模型在未来运行良好，监控其预测至关重要，以确保数据管道继续发送准确的数据，并且生产环境没有改变，使得模型不再准确。

为了解决这个问题，米开朗基罗可以自动记录，并选择性地阻止其所做的预测的百分比，然后将这些预测，加入到由数据管道生成的观察结果（或标签）中。

有了这些信息，我们可以生成持续的，实时的模型精度测量。在回归模型运行下，我们将U 平方/ 确定系数，均方根对数误差（RMSLE），均方根误差（RMSE）和平均绝对误差度量，发布到Uber的时间序列监测系统，以便用户可以随时间分析图表并设置阈值警报，如下所示：

图10：预测被采样，并与观察到的结果进行比较，以生成模型精度指标。

管理plane，API和Web UI

系统的最后一个重要部分是API层。这是系统的大脑。它包括一个管理应用程序，用于提供Web UI和网络API，并与Uber的系统监控和警报基础架构集成。

该层还包含用于编排批处理数据管道，训练作业，批量预测作业以及批量和在线容器部署模型的工作流系统。

米开朗基罗的用户，通过Web UI，REST API以及监视和警报工具，直接与这些组件进行交互。

▍未来的米开朗基罗平台

在接下来的几个月中，我们计划继续扩展和加强现有系统，以支持我们的客户团队的增长和Uber的整体业务。随着平台层次的逐渐成熟，我们计划投入更高层次的工具和服务，来推动机器学习的民主化，更好地支持我们的业务需求：

AutoML：这将是一个自动搜索和发现模型配置（算法，功能集，超参数值等）的系统，该模型配置可为给定的建模问题提供最佳性能模型。

系统还将自动构建生产数据管道，以生成为模型供电所需的功能和标签。我们已经通过我们的Feature Store，统一的离线和在线数据流水线以及超参数搜索功能来解决了大部分问题。

我们计划通过AutoML加速我们早期的数据科学工作。该系统将允许数据科学家指定一组标签和目标函数，然后使最多的隐私和安全感知使用Uber的数据找到问题的最佳模型。

模型可视化： 理解和调试 模型越来越重要，特别是对于深入学习。虽然我们为基于树型的模型提供了可视化工具的一些重要的第一步，但还需要做更多的工作，以使数据科学家能够理解，调试和调整模型，并让用户信任结果。

在线学习：大部分的Uber机器学习模型直接影响了Uber产品的实时性。这意味着它们在物理世界中移动物体的复杂和不断变化的环境中运作。

为了保持模型的准确性，随着环境的变化，我们的模型需要随之改变。今天，团队定期在米开朗基罗再训练模型。

该用例的完整平台解决方案，涉及易于更新的模型类型，更快的训练和评估架构和管道，自动化模型验证和部署，以及复杂的监控和警报系统。

分布式深度学习：越来越多的Uber机器学习系统正在实施深度学习技术。定义和迭代深度学习模型的用户工作流程，与标准工作流程完全不同，因此需要独特的平台支持。

深度学习用例通常会处理更大量的数据，而不同的硬件要求（即GPU）会激发对分布式学习的进一步投资，并与灵活的资源管理堆栈进行更紧密的集成。