作者：伴鱼技术团队 陈易生

前言

本文是 「算法工程化实践调研」 系列的第 2 篇，介绍来自 Uber 在 2017 年 9 月发布的技术博客 Meet Michelangelo: Uber’s Machine Learning Platform [1]。它介绍了机器学习平台 Michelangelo（意大利文艺复兴时期伟大的绘画家、雕塑家、建筑师和诗人）的各个组件的职能，第一次细致地向大家描述了机器学习平台应有的全貌。

现状和问题

Uber 有众多业务线，其中包含许多使用 ML 的场景，例如：共享出行 App 需要用算法预测乘客的到达时间、送餐 App 需要用算法为用户按照个人喜好为餐馆排序、客服中心需要用算法减少人工客服的介入，等等。多个业务线为了快速满足使用 ML 的需求，很自然地采了烟囱式的架构，逐渐产生了系统难以维护、模型难以上线等问题，亟需统一的解决方案来涵盖 ML 的全流程。

为了系统地解决问题，Michelangelo 平台（以下简称平台）首先厘清并定义了 ML 的全流程——数据管理、模型训练、模型评估、模型部署、做出预测、预测监控，并给出了各环节的解决方案。下文讨论平台在各个环节的做法。为了便于讨论，下图展示了平台的全景，会在后文被反复引用。

数据管理

数据是 ML 中最难的部分。平台的数据管理组件包括特征生成管道和特征仓库。

特征生成管道（Stream Engine 和 Data Prep Job）经工作流引擎的调度，从 Kafka 流数据源 和 Data Lake 批数据源读取数据，转换成供 ML 模型使用的特征，写入特征仓库（Cassandra Feature Store 和 Hive Feature Store）。一旦特征落库，就可以供在线预测（Realtime Predict Service）、离线训练（Batch Training Job）和离线预测（Batch Predict Job）使用。

值得一提的是，为了简化特征生成管道的实现，平台内置了一套基于 Scala 的 DSL，支持声明式地定义逻辑，而无需编写 Samza（注：平台在 2019 年之前已经把逻辑迁移到 Flink）和 Spark 代码。平台后续开发的 PyML 支持直接调用 Python 库，编写 Python 代码，进一步简化了特征生成管道的实现。

这样的架构有什么好处？

  • 特征生成管道是把数据加工为特征的唯一指定地点，避免因逻辑散落各处（训练、预测）而造成的错误。
  • 特征仓库作为联系数据和模型的桥梁，让不同团队分工明确。
  • 集中的特征仓库使得特征的发现和共享成为可能，避免不同业务线重复开发和维护特征生成管道，这对于 Uber 业务线众多的现状十分重要。

模型训练

模型训练是一个高度交互的过程。平台支持算法工程师在最为熟悉的 Jupyter Notebook 环境中，通过调用 Python SDK 完成模型训练的全过程。

  1. 定义模型。算法工程师需要在模型配置中，声明模型类型（需要在平台的支持列表内）、超参数（平台支持超参数搜索）、数据源、特征生成管道 DSL、计算资源要求（机器数量、内存大小、是否使用 GPU 等）。
  2. 触发训练。触发后，工作流引擎执行训练任务。
  3. 存储训练结果。训练完成后，评估报告（P-R 曲线和 ROC 曲线）、模型配置和模型参数会被上传到模型仓库（Cassandra Model Repo），用于分析和部署。

模型训练注重迭代，因此训练效率十分重要。平台通过 Data Science Workbench 满足算法工程师的不同训练需求：在 GPU 集群上分布式训练深度学习模型、在 CPU 集群上训练树和线性模型、在普通 Python 环境下实验各种不同模型。平台还针对深度学习的训练提供额外支持，见 Horovod。

模型评估

在得到理想模型之前，算法工程师往往需要训练很多个模型，记录、评估、比较这些模型会为算法工程师提供很多有用的信息。平台在基于 Cassandra 的模型仓库中记录详尽的模型元数据，包括：

  • 训练发起人。
  • 训练工作流的起止时间。
  • 模型配置。
  • 使用的训练和验证数据集。
  • 每个特征的分布。
  • 模型准确度指标。
  • 常用图表，如 ROC、P-R、confusion matrix。
  • 习得参数。
  • 模型可视化。

模型部署

平台支持通过 CLI 和 UI 快捷地部署模型。部署所需的模型 artifacts（包括元数据、模型参数文件，和编译过的特征生成 DSL）被打包成 ZIP，传送到指定服务器。预测服务会重载模型，重新开始处理预测请求。

做出预测

平台支持在线和离线预测。

对于在线预测，在模型部署完成后，在线预测服务已经将预测所需的模型从模型仓库中载入到内存中。一旦在线预测服务收到从客户端发来的包含 entity ID 的预测请求，它首先通过 entity ID 从在线特征仓库获取对应的特征向量，然后将特征向量输入模型，计算出预测值，返回给客户端。预测服务使用 Java 开发，以实现高并发和低延迟。

对于离线预测，工作流将模型载入工作流的内存，从离线特征仓库中批量读取特征并作出预测，将预测值写入 Hive 或 Kafka。

预测监控

训练中表现优秀的模型在生产环境中可能会错得离谱，因此平台支持对模型的预测进行细致的监控。最有效的办法是在生产环境中打印出一定比例的预测日志，并在稍后与观测值进行 join 和比较。另一种办法是记录下预测值的分布。

总结

Uber 团队在开发 Michelangelo 的过程中总结出三点重要经验。

  • 从小做起，快速迭代。从范围最小、影响力最大的切入点做起，容易出成果，获得领导层支持，有利于后续的快速迭代。在初期，平台专注于支持大规模的离线训练和离线预测。随后，逐渐支持特征仓库、模型评估、在线预测服务、深度学习、Jupyter Notebook 集成、partitioned models 等。
  • 让工程师使用最趁手的工具。在平台的早期，外部用户还不多，开发的主力是平台工程师，使用 Spark / Spark ML / Scala / Java 这个技术栈有利于快速迭代。但当平台愈发成熟，平台的重点变为快速的模型试错和迭代，该阶段的开发主力是算法工程师，他们可能需要定制化地在不同环节增加对某些模型的支持，例如实现未被内置支持的数据预处理、实现对新的深度学习模型分布式训练的支持等，这时他们希望能使用熟悉的 TensorFlow / PyTorch / Python / Jupyter Notebook 进行开发。PyML 正是这方面的尝试。
  • 数据是 ML 系统最重要，但也是最难的部分。难体现在技术和人两方面。在技术的方面，每个公司都有一套运行多年的数据仓库、数据管道、工作流系统，其中可能存在各种不尽完善之处，导致在接入 ML 平台后难以应对频繁和快速的变化。在人的方面，取数的需求由算法工程师提出，由数据工程师实现，跨部门、跨工作语言（JVM vs. Python）的合作通常不易。特征仓库这个抽象层正是为了解决这个问题而提出的，详情可参见平台的特征仓库 Palette。

Uber 通过丰富的业务实践，沉淀出一个成熟的 ML 平台�