原文：一站式机器学习平台建设实际
1. 业务背景
2019 年 7 月份，美团外卖的日订单量曾经冲破 3000 万单，占有了绝对当先的市场份额。围绕着用户、商户、骑手，美团配送构建了寰球当先的即时配送网络，建设了行业当先的美团智能配送零碎，造成了寰球规模最大的外卖配送平台。
如何让配送网络运行效率更高，用户体验更好，是一项十分有难度的挑战。咱们须要解决大量简单的机器学习和运筹优化等问题，包含 ETA 预测、智能调度、地图优化、动静定价、情景感知、智能经营等多个畛域。同时，咱们还须要在体验、效率和老本之间达到均衡。
2. 美团配送机器学习平台演进过程
2.1. 为什么建设一站式机器学习平台
如果要解决上述的机器学习问题，就须要有一个功能强大且易用的机器学习平台来辅助算法研发人员，帮忙大家脱离繁琐的工程化开发，把无限的精力聚焦于算法策略的迭代下面。
目前业界比拟优良的机器学习平台有很多，既有大公司研发的商用产品，如微软的 Azure、亚马逊的 SageMaker、阿里的 PAI 平台、百度的 PaddlePaddle 以及腾讯的 TI 平台，也有很多开源的产品，如加州大学伯克利分校的 Caffe、Google 的 TensorFlow、Facebook 的 PyTorch 以及 Apache 的 Spark MLlib 等。而开源平台大都是机器学习或者深度学习根底计算框架，聚焦于训练机器学习或深度学习模型；公司的商用产品则是基于根底的机器学习和深度学习计算框架进行二次开发，提供一站式的生态化的服务，为用户提供从数据预处理、模型训练、模型评估、模型在线预测的全流程开发和部署反对，以期升高算法同学的应用门槛。
公司级的一站式机器学习平台的指标和定位，与咱们对机器学习平台的需要不约而同：为用户提供端到端的一站式的服务，帮忙他们脱离繁琐的工程化开发，把无限的精力聚焦于算法策略的迭代下面。鉴于此，美团配送的一站式机器学习平台应运而生。
美团配送机器学习平台的演进过程能够分为两个阶段：
- MVP 阶段 ：灵便，疾速试错，具备疾速迭代能力。
- 平台化阶段 ：业务成指数级增长，须要机器学习算法的场景越来越多，如何既保证业务倒退，又能解决零碎可用性、扩展性、研发效率等问题。
2.2. MVP 阶段
初始阶段，大家对机器学习平台要倒退成什么样子并不明确，很多事件也想不分明。然而为了撑持业务的倒退，必须疾速上线、疾速试错。因而，在此阶段，各个业务线单独建设本人的机器学习工具集，依照各自业务的非凡需要进行各自迭代，疾速反对机器学习算法上线落地利用到具体的业务场景，也就是咱们所熟知的“烟囱模式”。此种模式各自为战，非常灵活，可能疾速反对业务的个性化需要，为业务抢占市场博得了先机。但随着业务规模的逐步扩充，这种“烟囱模式”的毛病就凸显了进去，次要体现在以下两个方面：
- 反复造轮子 ：特色工程、模型训练、模型在线预测都是各自研发，从零做起，算法的迭代效率低下。
- 特色口径凌乱 ：各个业务方反复开发特色，雷同特色的统计口径也不统一，导致算法之间难以协同工作。
2.3. 平台化阶段
为了防止各部门反复造轮子，晋升研发的效率，同时对立业务指标和特色的计算口径，标准化配送侧的数据体系，美团配送的研发团队组建了一个算法工程小组，专门规整各业务线的机器学习工具集，心愿建设一个对立的机器学习平台，其需要次要包含以下几个方面：
- 该平台底层依靠于 Hadoop/Yarn 进行资源调度治理，集成了 Spark ML、XGBoost、TensorFlow 三种机器学习框架，并保留了扩展性，不便接入其它机器学习框架，如美团自研的 MLX（超大规模机器学习平台，专为搜寻、举荐、广告等排序问题定制，反对百亿级特色和流式更新）。
- 通过对 Spark ML、XGBoost、TensorFlow 机器学习框架的封装，咱们实现了可视化离线训练平台，通过利落拽的形式生成 DAG 图，屏蔽多个训练框架的差别，对立模型训练和资源分配，升高了算法 RD 的接入门槛。
- 模型治理平台，提供对立的模型注册、发现、部署、切换、降级等解决方案，并为机器学习和深度学习模型实时计算提供高可用在线预测服务。
- 离线特色平台，收集分拣线下日志，计算提炼成算法所须要的特色，并将线下的特色利用到线上。
- 实时特色平台，实时收集线上数据，计算提炼成算法所须要的特色，并实时推送利用到线上。
- 版本治理平台，治理算法的版本以及算法版本所用的模型、特色和参数。
- AB 试验平台，通过迷信的分流和评估办法，更快更好地验证算法的成果。
3. 图灵平台
平台化阶段，咱们对美团配送机器学习平台的指标定位是：一站式机器学习平台，给算法同学提供一站式服务，笼罩算法同学调研、开发、上线、评估算法成果的全流程，包含：数据处理、特色生产、样本生成、模型训练、模型评估、模型公布、在线预测和成果评估。为了响应这个指标，大家还给平台取了个大胆的名字——Turing，中文名称为图灵平台，尽管有点“胆大包天”，然而也算是对咱们团队的一种鞭策。
1）首先在获取数据阶段，反对在线和离线两个层面的解决，别离通过采样、过滤、归一化、标准化等伎俩生产实时和离线特色，并推送到在线的特色库，供线上服务应用。
2）模型训练阶段，反对分类、回归、聚类、深度学习等多种模型，并反对自定义 Loss 损失函数。
3）模型评估阶段，反对多种评估指标，如 AUC、MSE、MAE、F1 等。
4）模型公布阶段，提供一键部署性能，反对本地和近程两种模式，别离对应将模型部署在业务服务本地和部署在专用的在线预测集群。
5）在线预测阶段，反对 AB 试验，灵便的灰度公布放量，并通过对立埋点日志实现 AB 试验成果评估。
3.1. 离线训练平台
离线训练平台的指标是：搭建可视化训练平台，屏蔽多个训练框架的差别，升高算法 RD 的接入门槛。
为了升高算法 RD 进入机器学习畛域的门槛，咱们开发了带有可视化界面的离线训练平台，通过各种组件的利落拽组合成 DAG 图，从而生成一个残缺的机器学习训练任务。
目前反对的组件大抵分为：输出、输入、特色预处理、数据集加工、机器学习模型、深度学习模型等几大类，每种类别都开发了多个不同的组件，别离反对不同的利用场景。同时为了不失去灵活性，咱们也破费了一番心理，提供了多种诸如自定义参数、主动调参、自定义 Loss 函数等性能，尽量满足各个不同业务方向算法同学各种灵活性的需要。
咱们的离线训练平台在产出模型时，除了产出模型文件之外，还产出了一个 MLDL（Machine Learning Definition Language）文件，将各模型的所有预处理模块信息写入 MLDL 文件中，与模型保留在同一目录中。当模型公布时，模型文件连带 MLDL 文件作为一个整体独特公布到线上。在线计算时，先主动执行 MLDL 中的预处理逻辑，而后再执行模型计算逻辑。通过 MLDL 买通了离线训练和在线预测，贯通整个机器学习平台，使得线下和线上应用同一套特色预处理框架代码，保障了线下和线上解决的一致性。
在公布模型时，咱们还提供了模型绑定特色性能，反对用户把特色和模型的入参关联起来，不便在线预测时模型主动获取特色，极大地简化了算法 RD 结构模型输出时获取特色的工作量。
3.2. 模型治理平台
后面介绍了，咱们的图灵平台集成了 Spark ML、XGBoost、TensorFlow 三种底层训练框架，基于此，咱们的训练平台产出的机器学习模型品种也十分多，简略的有 LR、SVM，树模型有 GBDT、RF、XGB 等，深度学习模型有 RNN、DNN、LSTM、DeepFM 等等。而咱们的模型治理平台的指标就是提供对立的模型注册、发现、部署、切换、降级等解决方案，并为机器学习和深度学习模型提供高可用的线上预测服务。
模型治理平台反对本地和近程两种部署模式：
- 本地：模型和 MLDL 对立推送到业务方服务节点上，同时图灵平台提供一个 Java 的 Lib 包，嵌入到业务方利用中，业务方通过本地接口的形式调用模型计算。
- 近程：图灵平台保护了一个专用的在线计算集群，模型和 MLDL 对立部署到在线计算集群中，业务方利用通过 RPC 接口调用在线计算服务进行模型计算。
对于超大规模模型，单机无奈装载，须要对模型进行 Sharding。鉴于美团配送的业务个性，能够依照配送城市 / 区域进行分区训练，每个城市或区域产出一个小模型，多个分区模型扩散部署到多个节点上，解决单节点无奈装载大模型的问题。分区模型要求咱们必须提供模型的路由性能，以便业务方精准地找到部署相应分区模型的节点。
同时，模型治理平台还收集各个服务节点的心跳上报信息，保护模型的状态和版本切换，确保所有节点上模型版本统一。
3.3. 离线特色平台
配送线上业务每天会记录许多骑手、商家、用户等维度的数据，这些数据通过 ETL 解决失去所谓的离线特色，算法同学利用这些离线特色训练模型，并在线上利用这些特色进行模型在线预测。离线特色平台就是将寄存在 Hive 表中的离线特色数据生产到线上，对外提供在线获取离线特色的服务能力，撑持配送各个业务高并发及算法疾速迭代。
最简略的计划，间接把离线特色存储到 DB 中，线上服务间接读取 DB 获取特色 Value。读取 DB 是个很重的操作，这种计划显著不能满足互联网大并发的场景，间接被 Pass 掉。
第二种计划，把各个离线特色作为 K - V 构造存储到 Redis 中，线上服务间接依据特色 Key 读取 Redis 获取特色 Value。此计划利用了 Redis 内存 K - V 数据库的高性能，乍一看去，如同能够满足业务的需要，但理论应用时，也存在着重大的性能问题。
典型的业务场景：比方咱们要预测 20 个商家的配送时长，假如每个商家须要 100 个特色，则咱们就须要 20*100=2000 个特色进行模型计算，2000 个 KV。如果间接单个获取，满足不了业务方的性能需求；如果应用 Redis 提供的批量接口 Mget，如果每次获取 100 个 KV，则须要 20 次 Mget。缓存 mget 的耗时 TP99 约 5ms，20 次 Mget，TP99 靠近 100ms，也无奈满足业务方的性能需求（上游服务超时工夫约 50ms）。
因而，咱们须要对离线特色从存储和获取进行优化。咱们提出了特色组的概念，同一维度的特色，依照特色组的构造进行聚合成一个 KV，大大减少了 Key 的数目；并且提供了绝对欠缺的治理性能，反对对特色组的动静调整（组装、拆分等）。
3.4. 实时特色平台
相比于传统配送，即时配送无论是在地位信息、骑手负载，还是在以后路网状况，以及商家出餐状况等方面都是瞬息变动的，实时性要求十分高。为了让机器学习算法可能即时的在线上失效，咱们须要实时地收集线上各种业务数据，进行计算，提炼成算法所须要的特色，并实时更新。
3.5. AB 试验平台
AB 试验并不是个新兴的概念，自 2000 年谷歌工程师将这一办法利用在互联网产品以来，AB 试验在国内外越来越遍及，已成为互联网产品经营精密度的重要体现。简略来说，AB 试验在产品优化中的利用办法是：在产品正式迭代发版之前，为同一个指标制订两个（或以上）计划，将用户流量对应分成几组，在保障每组用户特色雷同的前提下，让用户别离看到不同的方案设计，依据几组用户的实在数据反馈，迷信的帮忙产品进行决策。
互联网畛域常见的 AB 试验，大多是面向 C 端用户进行流量抉择，比方基于注册用户的 UID 或者用户的设施标识（移动用户 IMEI 号 /PC 用户 Cookie）进行随机或者哈希计算后分流。此类计划广泛应用于搜寻、举荐、广告等畛域，体现出千人千面个性化的特点。此类计划的特点是实现简略，假如申请独立同散布，流量之间独立决策，互不烦扰。此类 AB 试验之所以可能这样做是因为：C 端流量比拟大，样本足够多，而且不同用户之间没有互相烦扰，只有分流时足够随机，即根本能够保障申请独立同散布。
即时配送畛域的 AB 试验是围绕用户、商户、骑手三者进行，用户 / 商户 / 骑手之间不再是互相独立的，而是相互影响互相制约的。针对此类场景，现有的分流计划会造成不同策略的相互烦扰，无奈无效地评估各个流量各个策略的优劣。
鉴于上述的问题，咱们将配送侧的 AB 试验分为三个阶段：事先的 AA 分组，事中的 AB 分流，预先的成果评估。
- AA 分组：将候选流量依照既定的规定事后分为对照组和实验组，基于数理统计的实践确保对照组和实验组在所关注的业务指标上没有显著差别。
- AB 分流：将线上申请实时分到对照或者试验版本。
- 成果评估：依据对照组和实验组的数据比照评估 AB 试验的成果。
因为即时配送的场景较为非凡，比方依照配送区域或城市进行 AB 试验时，因为样本空间无限，很难找到没有差别的对照组和实验组，因而咱们设计了一种分工夫片 AB 对照的分流办法：反对按天、小时、分钟进行分片，多个工夫片进行轮转切换，在不同区域、不同工夫片之间，对不同的策略进行交替切换进行 AB 分流，最大限度缩小线下因素的影响，确保试验迷信公正。
4. 总结与瞻望
目前图灵平台撑持了美团配送、小象、LBS 平台等 BU 的算法离线训练、在线预测、AB 试验等，使算法 RD 更加关注算法策略自身的迭代优化，显著进步了算法 RD 的效率。将来咱们会在以下方面持续深刻摸索：
1）增强深度学习的建设
- 增强深度学习的建设，全面反对深度学习，实现深度学习相干组件与机器学习组件一样，在可视化界面能够和任意组件组合应用。
- 离线训练反对更多罕用深度学习模型。
- 反对间接写 Python 代码自定义深度学习模型。
2）在线预测平台化，进一步解耦算法和工程
- 简化图灵平台 SDK，剥离主体计算逻辑，建设在线预测平台。
- 在线预测平台动静加载算法包，实现算法、业务工程方、图灵平台的解耦。