Scaling Machine Learning as a Service

http://proceedings.mlr.press/v67/li17a.html

1 概述

Uber使用机器学习的场景有预测供求、餐厅推荐、地图和自动驾驶等。 Uber机器学习的挑战

Uber应用实时产生大数量，需要有可扩展性。
Uber跨多个城市，每个城市分别训练和管理模型难以维护
Uber的模型多样性

解决思路

建立feature store和相关计算引擎，以便于获取特征
训练和管理一个分层次的模型
自动的扩展和部署模型预测服务

2 系统架构总览

2.1 数据准备

Uber使用SQL作为各种数据源的查询接口，查询引擎底层进行优化。数据源都有metadata，不同的用例可以共享数据准备任务。

2.2 Feature Store

Batch和实时机器学习流水线共享特征计算引擎和Feature Store。只需要在数据流水线中指定UUID，就可以通过特征名称获取特征。在线预测可以低延时地从在线存储(Cassandra)中查询特征。批量训练、预测和在线预测使用统一的标准(canonical)名称来访问特征，在线和离线可以使用相同的表达式来获取特征。

2.3 Model Training

传统机器学习：Spark MLlib, XGBoost
深度学习: Caffe, Tensorflow
2.4 模型部署和管理

将模型组织为分层结构，训练一个有层次的模型部署到所有城市。支持将模型一键部署成批量预测或在线服务。

2.5 模型服务和实时监控

为保证批量和在线的模型结果相同，模型服务Core可以给批量预测流水线和在线预测容器使用。在线请求中包括基础特征和Model ID，预测服务再从Feature Store补全特征，进行特征变换，然后调模型服务Core来做预测。批量模型和实时模型，所有的预测结果都写入Kafka用于诊断和监控。

3 特征计算和服务

3.1 需求与挑战

需求

支持多样的特征集合。特征一般与实体（如骑手、司机等）关联，需要支持静态属性（如注册城市）和时间段统计特征（如店铺最近1天下单量）。
需要特征新鲜度和保证serving延时。
- 离线特征最近更新时间不超过12小时，10ms rt。
- 近实时特征最近更新时间不超过5分钟，10ms rt。

特征计算的挑战 统一流批引擎的限制

长时间范围的历史特征计算效果不够高，因为要为延迟到达数据的按需更新维护状态。
流引擎(Spark Streaming)不支持计算特定类型的特征。

特征Serving的挑战 批量训练和在线预测的特征分开存储，原因是

大多数数据仓库只能有效的支持批量访问或者点查询
批量访问会造成点查询抖动
3.2 解决方案

Uber选择流批计算分别选用Samza, Spark作为计算引擎，特征存储分别选用Hive, Cassandra作为离线和在线的特征存储。引擎分开后，需要保证以下三点：
训练和预测使用one code path来计算特征。
用户只需要在训练时选择特征，预测时需要自动使用同一批特征。
离线计算的特征需要上传到在线存储，实时计算的特征需要写入离线存储。
3.2.1 Feature Groups

Feature Group是调度和存储的基本单元，同一group的特征由同一job计算，存储到同一表中。 Feature owner来定义特征组和向已有特征组来添加特征。每个Feature Group都有meta YAML文件，定义语义和一组源码文件。使用git管理，可以做CR和批准。废弃特征需要通知到用户，平台会记录使用信息。活跃特征的语义不允许变更，变更语义时需要产生新特征。

3.2.2 批量计算和存储

Spark ETL任务来生成一组相关特征（Feature Group)，结果写入Hive表中，每列一个特征。每行由唯一ID和分区时间作为Key。 ETL任务完成后，也需要拷贝到在线特征存储中。

3.2.3 近实时特征计算和在线存储

在线存储有两个源：历史特征和从Kafka topic计算得到的实时特征。特征补全之后，使用DSL做特征变换。

4 分区模型

4.1 挑战

之前的方案是每个城市训练一个模型，管理上百个模型既耗时又容易出错。

每个分区（城市）都需要创建两个样本集，导致大量的数据重复、不必要的序列化和大量的文件。
训练上百个模型会影响其他模型的训练。
4.2 解决方案

使用分层次的分区模型，作为一个逻辑模型来训练和管理。如果某一分区的数据不足以训练模型，自动回退到父模型或祖先模型。在持久化全局训练和验证集时带有每个分区的metadata，在创建分区训练和验证集时不需要再序列化和存储数据。持久化数据也可以用于fail over和re-train。使用Spark自顶向下训练，每一层并行训练。一个分层次模型使用一个Spark任务来训练（既非依赖工作流调度器，也非依赖外部的控制器）。

5 实时预测和监控

使用TChannel作为网络协议。在请求Header中指定使用的模型，预测服务检查header路由到指定的模型。预测结果写入Kafka，join实际结果，然后发布监控和报警指标。使用API来上下线模型。上线前会打包必要的文件，验证模型可以正确运行，然后部署到容器。

6 经验教训

ML工作流失败有各种原因，因此Debug能力非常重要，需要展示和记录有意义的错误信息。
容错很重要。
在ML算法层设计系统抽象，以便于接入不同的ML库。
自动化的易于使用的ML工作流非常有必要。用户只需要在Web UI指定特征、算法和模型的超参数，模型就可以自动训练生成标准化的性能指标，用户从中选择最好的模型然后一键部署上线。
ML系统需要有供其他系统集成的API。

egolearner / paper-note

Scaling Machine Learning as a Service #3

1 概述

2 系统架构总览

2.1 数据准备

2.2 Feature Store

2.3 Model Training

2.4 模型部署和管理

2.5 模型服务和实时监控

3 特征计算和服务

3.1 需求与挑战

3.2 解决方案

3.2.1 Feature Groups

3.2.2 批量计算和存储

3.2.3 近实时特征计算和在线存储

4 分区模型

4.1 挑战

4.2 解决方案

5 实时预测和监控

6 经验教训