Uber的机器学习平台：从打车到外卖，一个平台如何服务数十个团队？
作者 | JEREMY HERMANN & MIKE DEL BALSO
编辑｜陈思
优步工程技术团队致力于为客户创造无缝化且极具影响力的体验性技术成果。我们正逐步加大对人工智能（简称 AI）与机器学习（简称 ML）的投入，希望借此实现这一发展愿景。在优步，我们在机器学习领域的一大贡献正是 Michelangelo（米开朗基罗）项目——这是一套内部机器学习即服务平台，旨在实现机器学习技术民主化，并调整 AI 规模以保证商务人员能够像使用优步叫车服务一样轻松地助机器学习之力满足自身需求。
米开朗基罗项目使得优步公司的各内部团队能够以规模化方式无缝构建、部署及运行各类机器学习解决方案。该项目涵盖各项端到端机器学习工作流程，包括数据管理，模型的训练、评估与部署，作出预测并监控预测结果等等。这套系统亦能够支持多种传统机器学习模型、时间序列预测以及深度学习等方案类别。
米开朗基罗项目已经在优步公司的生产环境中运行了约一年时间，并已经成为我们的工程师与数据科学家们的首选机器学习实现系统——目前有数十个团队利用其构建并部署各类模型。事实上，米开朗基罗被部署在多座优步数据中心当中，配合专用硬件并成为我们目前负载强度最高的各项在线服务提供支持。在今天的文章中，我们将介绍米开朗基罗项目、探讨其相关产品用例，同时深入了解这套强大的机器学习即服务系统的整个工作流程。
在米开朗基罗项目诞生之前，我们面临着一系列实际挑战——包括立足优步公司庞大的运营规模与强度构建并部署各类机器学习模型。尽管数据科学家们一直利用多种工具以建立预测模型（包括 R、scikit-learn 以及各类定制化算法等等），但各工程技术团队仍然需要频繁构建一次性定制化系统以适应这些模型的具体需要。因此，优步公司的机器学习在影响力方面始终受到限制，导致仅有部分数据科学家及工程师能够在短时间内利用多种开源工具完成任务。
具体来讲，当时的优步公司还不具备能够构建可靠、统一且可重复的管道系统来打造并管理规模化数据训练与预测任务的系统方案。在米开朗基罗项目出现之前，数据科学家们根本无法对超出台式计算机承载能力的模型进行训练，不具备标准化结果存储平台，也无法利用简单方式将不同实验的具体分析结果进行比较。最重要的是，生产部署模型当中不存在确定的路径——在大多数情况下，相关工程技术团队需要制定仅适用于特定项目的定制化服务容器。另外，Scully 等研究人员还发现并记录下一系列机器学习的反模式场景（即不适用机器学习的模式）。
米开朗基罗项目的设计初衷在于对各团队所使用的工作流程及工具进行标准化调整，从而解决上述差距。通过这套端到端系统，全球用户将能够轻松构建并扩展机器学习系统。我们的目标是在解决这些直接问题的同时，打造出一套能够与业务规模同步发展的系统。
在 2016 年年初着手建立米开朗基罗项目时，我们首先需要解决将可扩展模型训练及部署任务引入生产性服务容器的挑战。在此之后，我们专注于构建更出色的系统与特征共享管道。最近，我们又将关注重点进一步转向提升开发人员生产力水平——即如何加快设计思路的第一生产模式以及随后的快速迭代工作。
在接下来的章节内，我们将着眼于一基示例应用，了解米开朗基罗项目如何构建并部署机器学习模型。虽然我们需要强调这里的 UberEATS 仅属于一项具体用例，但米开朗基罗平台同样可以管理其它企业在实际预测场景当中所使用的类似模型方案。
UberEATS 当中包含多套运行在米开朗基罗平台之上的模型，其功能涵盖外卖交付时间预测、搜索排名、搜索结果自动填充以及餐厅排名等等。交付时间模型预测需要在订单发布之前完成，从而告知用户食物需要多长时间准备、又需要多长时间能够送到您的手中。
图一：UberEATS 应用凭借着由米开朗基罗平台承载的多套机器学习模型提供交付时间预测功能。
估算交付时间（简称 ETD）绝非易事。当 UberEATS 客户下达订单时，餐厅首先需要接受订单并着手准备餐点，而这项任务在订单情况复杂且忙碌饭点期间往往需要更长时间才能办理就绪。接下来，优步公司的派送人员会前往餐厅收取饭菜——具体包括抵达餐厅、找到停车位、走进餐厅拿取食物、回到车里、开车前往客户位置（具体时间取决于路线及交通情况等因素）、找到停车位，而后将食物交至用户手中。对整个流程的时长作出预测需要将多个复杂的执行阶段纳入考量，而期间每一个阶段的变化都会给最终交付时长造成影响——意味着系统必须重新进行计算。
在米开朗基罗平台上，UberEATS 的数据科学家们利用渐变增强型决策树递归模型来预测这种端到端交付时间。该模型的特征包括请求信息（例如当前时间段、交付位置等）、历史特征（例如过去七天中的平均食物筹备时长等）以及近实时特征计算（例如过去一小时内的平均食物筹备时长）。各模型被部署在不同的优步数据中心之内，而米开朗基罗则负责为模型提供支持容器并经由网络请求对 UberEATS 内的各项微服务加以调用。这些预测结果会在餐厅接到订单之前被首先显示给用户，并在得到其认可后方允许餐厅进行食物的筹备与交付。
米开朗基罗当中包含有多种开源系统及内部开发组件。其中的主要开源组件包括 HDFS、Spark、Samza、Cassandra、MLLib、XGBoost 以及 TensorFlow。总体而言，我们更倾向于尽可能使用成熟的开源选项，同时根据需求进行 fork、定制以及贡献——具体包括在开源解决方案不符合用例实际需求时自行构建系统方案。
米开朗基罗平台建立于优步的数据与计算基础设施之上，后者提供一套数据湖以存储优步公司的全部交易与记录数据 ; Kafka 中间人负责汇总来自全部优步服务的记录信息 ; 此外其中还囊括有 Samza 流计算引擎、受控 Cassandra 集群以及优步自主开发的各类服务配置与部署工具。
在下一章节中，我们将以 UberEATS ETD 模型为例，通过深入探讨米开朗基罗系统内的各层以勾勒出其详尽技术面貌。
在优步公司，无论具体负责解决哪些挑战——包括分类、回归以及时间序列预测——所有机器学习用例皆采用同样的一般性工作流程。由于这一工作流不受具体实现方式的影响，因此能够轻松进行扩展以支持新的算法类型与框架——例如新型深度学习框架。另外，其同时适用于不同的部署模式，例如在线与离线（特别是车载与手机内用例）预测用例。
在米开朗基罗平台的设计当中，我们希望能够借此提供可扩展、可靠、可重现、易使用且自动化工具选项，最终解决以下这套六步式工作流程：
数据管理
模型训练
模型评估
模型部署
预测制定
预测监控
接下来，我们将详细介绍米开朗基罗架构如何一步步实现上述工作流。
发现正确特征往往是机器学习工作当中最具难度的部分。我们同时发现，数据管道的构建与管理则通常是机器学习解决方案之内成本最高的部分。
一套平台应该能够提供标准化工具以构建数据管道，并借此生成特征以及标签数据集，进而利用这些成果实现预测所必需的训练（与重新训练）及纯特征数据集。这些工具应当深入集成至企业的数据湖或者数据仓库当中，同时全面与企业的在线数据服务系统相对接。这类管道必须具备可扩展性与良好的成效表现，拥有数据流与数据质量综合监控能力，同时支持在线与离线两种训练与预测模式。在理想情况下，其应以跨团队共享的方式生成特征，同时减少重复工作量并提高数据质量。另外，这些工具还应提供强有力的保护性约束与控制措施，旨在鼓励并批准用户采用各项最佳实践（例如保证在训练周期与预测周期内使用相同的数据生成 / 筹备流程）。
米开朗基罗平台中的数据管理组件按照在线与离线两类管道进行划分。目前，离线管道主要用于批量模型训练与批量预测任务的馈送 ; 而在线管道则负责在线低延迟预测任务的馈送（不久之后，我们还将引入在线学习系统）。
另外，我们还向其中添加了一个数据管理层，其作为特征存储机制以帮助各团队对解决机器学习问题所必需的高准确度特征集进行共享、发现与使用。我们发现，优步目前面临的大多数建模难题都存在着共通性或者说相似性，因此确保各团队能够在不同部门间分享各自项目心得以及特征成果无疑具有重大的实际价值。
图二：数据筹备管道将数据推送至特征存储表与训练数据库当中。
优步公司的交易与记录数据流被引入一套数据湖内，并可通过 Spark 以及 Hive SQL 计算任务轻松进行访问。我们提供各类容器与调度方案以定期运行特征计算任务，而这些特征将可根据项目实际进行内部保留或者被发布至特征库（Feature Store，详见下文）中进行跨团队共享。而批量处理任务则按计划或者配合触发机制运行，结果将被整合至数据质量监控工具处以快速根据本地或上游代码或数据问题对该管道中的问题进行回溯。
以在线方式部署的模型无法访问存储在 HDFS 当中的数据，而且其通常也很难直接面向用于支持优步生产服务的在线数据库进行高成效特征计算（举例来说，我们无法直接查询 UberEATS 订单服务以计算某家餐厅在特定时段之内的平均食物筹备时长）。相反，我们允许对各在线模型所需要的特征进行预计算，并将结果存储在 Cassandra 当中——如此一来，这些结果即可在预测阶段以低延迟方式接受读取。
我们支持两种面向在线特征的计算选项，分别为批量预计算与近实时计算，具体说明如下：
批量预计算。第一种计算选项为定期进行批量预计算并从 HDFS 中将历史特征加载至 Cassandra 内。这是一种简单且有效的方法，通常适用于处理历史特征。该系统保证始终利用同样的数据与批量管道进行训练与服务。UberEATS 在计算“餐厅在过去七天内的平均食物筹备时长”等指标时使用的就是这类系统。
近实时计算。第二种选项是将相关指标发布至 Kafka 处，而后运行基于 Samza 的流计算任务。接下来，这些特征将被直接写入 Cassandra 并随后交付及记录至 HDFS 当中，以供后续训练任务使用。与批量系统类似，近实时计算能够确保在训练与服务过程中使用同样的数据集。为了避免冷启动，我们专门利用一款工具面向历史记录运行批量任务，从而实现数据“回填”并生成训练数据。UberEATS 在计算“餐厅过去一小时内的平均食物筹备时长”指标时，使用的就是近实时特征管道。
我们发现建立一套集中式特征库非常重要，这意味着优步公司的各内部团队将能够创建并管理其实际使用的各类特征，并将其与其他团队进行共享。从宏观角度来看，这种作法能够带来以下两种助益：
其允许用户轻松向共享特征库内添加特征，且仅需要为各特征添加少量额外元数据（例如拥有者、描述以及 SLA 等）即可实现内部及特定项目使用需求。
一旦特征被添加至特征库当中，各团队将能够轻松以在线及离线方式对其进行消费——包括引用特征在模型配置当中的简单规范名称。配合这部分信息，该系统将能够协同正确的 HDFS 数据集以实现模型训练或批量预测，并在在线预测场景下从 Cassandra 处获取正确数值。
就目前来讲，我们的特征库中包含约 1000 项适用于机器学习项目加速的特征，而公司内的各个团队仍在不断向其中添加更多新特征。特征库中的各项特征会得到自动计算，且每天进行一次更新。
着眼于未来，我们希望能够进一步探讨构建一套自动化系统的可能性——我们希望利用它对特征库进行完整搜索，从而发现能够解决某一特定预测问题的重要实用特征。
一般来讲，由数据管道所生成或者来自客户端服务的特征并不具备正确的格式，且其中部分数值可能未得到有效填充。另外，模型本身可能只需要所提供特征中的一个子集。在某些情况下，模型可能更适合将具体时间戳转换为当天内时段或者当周内某天的表达方式。再有，我们也可能需要对各特征值进行归一化（例如减去平均值并除以标准差）。
为了解决这些问题，我们创造了一种 DSL（即域特定语言）以供建模人员在模型训练及预测阶段对发出的特征进行选择、转换以及组合。该 DSL 作为 Scala 的一个子集实现，且拥有完整的常用功能选项。利用该 DSL，各团队还能够向其中添加自己的用户定义功能。具体包括从当前情景（例如离线模式下的数据管道或者在线模式下的客户端当前请求）或者特征库当中提取特征值的能力。
值得强调的是，DSL 表达式亦属于模型配置中的组成部分，且会在训练阶段及预测阶段被用于帮助确保生成同样的最终发出特征集。
我们目前能够支持超大规模离线分布式决策树训练、线性与逻辑模型、无监督模型（k-means）、时间序列模型以及深层神经网络。我们会定期添加新的算法以应对客户的实际需求，而这些算法皆由优步公司 AI 实验室以及其他内部研究人员负责开发。另外，我们还允许客户团队通过提交定制化训练、评估及交付代码的方式添加自己的模型类型。这套分布式模型训练系统可向上扩展至支持数十亿项示例，亦可向下收缩至处理小型数据集的快速迭代。
所谓模型配置，是指模型类型、超参数、数据源引用、特征 DSL 表达式以及计算资源要求（包括机器数量、内存容量以及是否使用 GPU 等）等指标。我们利用模型配置对训练任务进行配置，并将其运行在 YARN 或者 Mesos 集群之上。
在模型训练完成之后，我们会计算其成效指标（例如 ROC 曲线以及 PR 曲线）并将结果合并至模型评估报告当中。在训练末尾，我们会将初始配置、学习到的参数以及评估报告保存至模型库当中以供分析与部署。
除了训练个别模型之外，米开朗基罗还支持面向全部模型类型以及分区模型的超参数搜索。利用分区模型，我们能够自动根据来自用户的配置进行训练数据划分，而后立足各个分区训练对应的单一模型，并在必要时将其回滚至母模型状态（例如为每座城市训练一套模型，并在城市级模型的准确度无法达标时将其回滚至国家级模型版本）。
训练任务可通过一套 Web UI 或者 API 进行配置与管理，我们一般选择使用 Jupyter notebook。也有不少团队利用 API 与工作流工具按计划对其模型进行定期重新训练。
图三：利用特征库与训练数据库内的数据集执行模型训练任务，而后将其推送至模型库当中。
作为方法探索流程中的组成部分，我们通过模型训练以发现特征集、算法以及超参数等能够为特定问题建立最佳模型的因素。在为特定用例找到最佳模型之前，我们往往需要对数百套模型进行训练。尽管其中绝大多数模型不会被应用于最终生产环境，但这些模型的实际表现会给工程师们带来启发，帮助他们借此找到能够实现最佳模型成效的配置方案。追踪这些已训练模型（例如谁在何时对其进行训练、配合怎样的数据集、使用怎样的超参数等等）、对其进行评估并将结果作出相互比较往往难度极大，特别是考虑到模型自身的庞大数量及其给米开朗基罗平台带来的可观数值规模。
对于每一套在米开朗基罗平台上进行训练的模型，我们都会在 Cassandra 中的模型库内为其保存一个版本控制对象，其主要负责记录：
谁训练了该模型
训练任务的开始与结束时间
完整模型配置（所使用特征与超参数值等）
引用的训练与测试数据集
每项特征的发布与相对重要性
模型准确度指标
每种模型类型的标准图表与图形（例如 ROC 曲线、PR 曲线以及二进制分类器的混淆矩阵）
该模型的完整学习参数
模型可视化摘要统计
用户可以通过 Web UI 以及编程化 API 轻松访问这些信息，并利用其检查单一模型中的细节并将其与一套或者多套模型加以比较。
回归模型的模型准确度报告将显示出标准准确度指标与相关图表。分类模型则将显示不同的信息集合，具体如图四与图五所示：
图四：回归模型报告中显示出与回归相关的成效指标。
图五：二进制分类成效报告显示出与分类相关的成效指标。
对于重要的模型类型，我们亦提供更为复杂的可视化工具以帮助建模者了解模型的行为原理，并在必要时对其加以调试。在决策树模型用例当中，我们允许用户浏览其中的每一单独树状结构，查看其对于整体模型的相对重要性、各分割点、每项特征对于特定树状结构的相对重要性，以及各分割点的数据分布情况等。用户还可以指定特征值，并以可视化方式查看决策树因此形成的触发结果、各树状结构的预测结论以及模型的整体预测结果，具体如图六所示：
图六：树状模型可配合强大的树图可视化机制进行探索。
米开朗基罗平台提供的特征报告功能可根据对整体模型的重要性、部分依赖关系散点以及分布直方图按序显示每一项特征。如果选定两项特征，用户则可了解二者间的双向交互依赖关系，具体如下图所示：
图七：通过特征报告查看两种特征、其对模型的影响以及二者间的交互关系。
米开朗基罗平台以端到端方式通过 UI 或 API 支持受控模型部署流程，且模型可通过三种模式进行部署：
模型被部署至一套离线容器当中，同时立足 Spark 任务运行以按需或者根据重复计划生成批量预测结果。
模型被部署至一套在线预测服务集群当中（一般处于负载均衡器之后且包含数百台设备），其中各客户端能够以网络 RPC 调用的方式发送单一或者批量预测请求。
我们计划提供新的选项，允许模型以服务容器的方式进行部署，并将其作为库嵌入至其它服务内且通过 Java API 进行调用。（图八并未包含这种情况，但其工作原理类似于在线部署。）
图八：来自模型库的模型被部署至在线及离线容器当中。
无论如何，一切必要模型组件（包括元数据文件、模型参数文件以及已编译 DSL 表达式）皆被封闭在 ZIP 归档文件内，并被复制至我们的标准代码部署基础设施当中。预测容器会自动从磁盘处加载这些新模型，而后利用其处理对应预测请求。
目前大多数团队都拥有自动化脚本，可用于通过米开朗基罗的 API 定期执行计划内模型重新训练以及部署。在 UberEATS 的交付时间西东发中，数据科学家及工程师们可以通过其 Web UI 手动触发训练与部署操作。
一旦模型由服务容器部署并加载完成，其即可用于根据加载自数据管道或者直接提取自客户端服务的特征数据作出预测。各原始特征通过已编译 DSL 表达式进行传递，其负责修改这些原始特征并 / 或从特征库处提取其它特征。最终特征向量会被建立并传递给模型以进行评分。在使用在线模型的情况下，预测结果会被返回至客户端处。而在离线模型场景下，预测结果将被写回至 Hive 并供下游批量任务进行消费，或直接通过基于 SQL 的查询工具供用户访问，具体如下图所示：
图九：在线与离线预测服务使用特征向量集以生成预测结果。
我们可以在同一给定容器当中同时部署多套模型。通过这种方式，我们将能够以安全方式实现旧版本到新版本的过度，并实现模型的并行 A/B 测试。在交付期间，模型根据其 UUID 进行身份识别，同时配合在部署阶段所指定的可选标签（或者昵称）。在使用在线模型的情况下，客户端服务会发出特征微量以及对应的模型 UUID 或者希望使用的模型标签 ; 如果使用标签方式，则该容器会利用最近以该标签进行部署的模型生成预测结果。而在批量模型的情况下，所有已部署模型都将被用于对各批量数据集进行评分，而预测记录当中则包含对应的模型 UUID 及可选标签，消费方可据此对结果进行筛选。
如果在部署新模型以替换旧模型时，发现两套模型拥有同样的签名（即指向同样的特征集），用户则可继续在新模型中沿用旧模型的标签，而容器则会立即开始使用新模型。如此一来，客户即可在无需变更其客户端代码的前提下对模型进行轻松更新。另外，用户还可以单纯利用 UUID 实现新模型部署，而后在客户端内或者通过中间服务修改配置以将指向旧模型 UUID 的流量切换至新模型处。
至于模型 A/B 测试，用户可以直接通过 UUID 或者标签部署竞争模型，而后立足客户端服务之内利用优步的实验模型向各模型发送流量区段，同时追踪其实际成效表现。
由于机器学习模型具有无状态且不共享属性，因此其能够在在线与离线两种交付模式下轻松实现向外扩展。在在线模型情况下，我们能够直接向预测服务集群中添加更多主机，并允许负载均衡器对负载进行分发。而在离线预测情况下，我们则可添加更多 Spark 执行器并允许 Spark 管理相关并发性任务。
在线交付模式的延迟取决于模型类型、整体复杂度以及该模型是否需要从 Cassandra 特征库内提取特征。如果不需要从 Cassandra 特征库处提取特征，那么 P95 常规延迟通常低于 5 毫秒（5 ms）。但如果需要从 Cassandra 特征库处提取特征，那么 P95 延迟通常低于 10 毫秒。目前我们流量最高的模型能够每秒处理超过 25 万条预测请求。
在对模型进行训练与评估时，我们全程皆使用历史数据。因此，为了确保模型能够在未来继续发挥预期作用，我们必须随时考量生产环境的变化，并根据一切可能影响模型准确度的指标作出调整。
为了解决这个问题，米开朗基罗将自动记录并有选择地保留特定比例的预测结果，而后将这些预测结果与数据管道生成的观察结果（或标签）相整合。利用这些信息，我们将能够对模型的持续性实时准确度进行衡量。在回归模型情况下，我们会将 R 平方 / 确定系数、均方根对数误差（简称 RMSLE）、均方根误差（简称 RMSE）以及平均绝对误差发送至优步的时间序列监测系统当中，以便用户可以随时间推移分析图表并设置阈值警报，具体如下图所示：
图十：对预测结果进行采样，并将其与观察结果进行比较。
这套系统中最后一个重要部分为 API 层，其亦堪称这套系统的大脑所在。API 层由一款管理应用构成，其负责提供 Web UI 与网络 API，同时与优步的系统监控与警报基础设施进行集成。该层还用于协调负责批量数据管道、训练任务、批量预测任务以及批量与在线容器模型部署的工作流系统。
米开朗基罗平台的用户可以直接通过该 Web UI、REST API 以及其它监控与警报工具同这些组件进行交互。
在未来几个月中，我们计划进一步对现有系统进行规模化扩展与增强，旨在支持我们的团队以及优步整体业务的规模增长。随着该平台的不断成熟，我们还计划投入更多高水平工具及服务以推动机器学习技术的民主化进程，从而更好地支持自身业务：
这是一套用于自动搜索及发现模型配置（包括算法、特征集以及超参数值等）的系统，旨在针对特定建模问题提供成效最佳的模型选项。这套系统还将自动 建立生产数据管道，用以生成模型运作所必需的特征与标签。我们已经利用特征库、归一化离线与在线数据管道以及超参数搜索功能解决了其中大部分问题。这套系统将帮助数据科学家们指定一组标签与目标函数，而后立足隐私与安全感知要求选择最佳模型。其设计目标在于提供更易于使用的智能化工具以提升数据科学家们的生产力水平。
对于模型的理解与调试能力正变得愈发重要，特别是在深度学习领域。尽管我们已经通过可视化工具为树状模型提供了良好的理解起点，但未来还需要推出更多相关解决方案以帮助数据科学家理解、调试及调整模型。
优步的大部分机器学习模型都会以实时方式直接影响到优步产品。这意味着其必须运行在复杂的动态物理世界当中并面临不断变化的周遭环境。为了保证环境变化不会对模型的准确度造成影响，我们必须对模型进行及时更新。目前，各团队会立足米开朗基罗平台定期对模型作出调整。未来，我们需要建立一套完善的平台解决方案，旨在轻松更新模型类型、加快训练速度、评估其架构与管道、自动进行模型验证与部署，同时支持更为复杂的监控与警报系统。这无疑是一项庞大的计划，但目前我们已经获得了可喜的初步成果，这也证明我们的思路值得继续坚持下去。
越来越多的优步机器学习系统开始采用深度学习技术。由于需要特殊的平台支持能力，因此深度学习模型上的定义与迭代工作流与标准工作流存在显著差别。深度学习用例通常会处理规模更为庞大的数据，且对硬件的要求也相对更高（例如 GPU），这意味着我们必须对分布式学习方案作出进一步投资，并将其同一整套灵活的资源管理方案作出更为紧密的集成。
相关内容
微信扫码咨询专知VIP会员