美团点评-一站式机器学习平台架构的搭建PPT课件.pptVIP

针对以上的挑战，我们主要做了以下三件事，首先我们做的工作就是统一，我们对模型表示格式进行了统一，例如，对于大多数的机器学习模型来说，我们都用PMML格式来表示；我们还统一了模型预测接口，不管是本地预测还是远程预测，我们都是用统一的接口，降低开发成本。 第二项工作是适配，我们适配了不同的机器学习训练平台、异构资源适配上，交互协议我们也进行了适配，例如：TensorFlow默认使用gRPC进行通信，我们根据公司中间件的需要，进行了Thrift协议的适配。 第三项工作是线上模型预测和线下训练的优化，我们针对PMML开源库进行了大量的优化工作，效果也是非常明显的，预测性能提升了5倍。 这个图展示的就是我们模型管理平台的架构，模型的训练和模型预测都可以通过我们的Web Conosole进行统一配置，训练平台训练的模型会存储在HDFS上，模型调度器模块会进行模型的发现，然后维护一个模型状态机，通过指令中枢将模型推送到业务系统本地，或者ModelServer上，对于ModelServer来说，还需要进行模型路由，模型路由也是通过模型调度器统一控制的。 模型的执行有两种方式，一种是在业务服务本地执行，一种是在ModelServer上远程执行。 本地执行和远程执行有什么区别呢？首先本地没有额外的网络开销，单次计算的性能高，但它的缺点也是比较明显的，会占用业务方资源，对于批量预测来说，只能做到单机多线程执行。 分布式计算的优点也比较明显，首先模型计算和业务进行了解耦，不会占用业务方的资源，也能比较方便的支持异构资源的使用（例如GPU），还能做到多机多线程并行，这个对于大批量的预测来说是非常重要的。 分布式计算的缺点也比较明显，有额外的网络开销，不太适合单次小批量的预测。 在模型管理中，我们还遇到另外一个问题，就是超大模型的问题，对于超大模型，单机内存装不下，怎么办？ 我们的解决方案是架构大模型拆分成多个小模型，比如一个城市一个模型，然后对于小模型进行sharding，将多个小模型均匀分布在多个ModelServer上，通过路由模块控制模型预测。整个sharding的过程对于上游调用来说是完全透明的，业务方根本感觉不大它在使用一个大模型。 A/B实验平台 算法深入到配送各个环节 更多 更快 更好 配送AB实验的特点 在线策略平台 传统Ab实验 策略之间相互影响 配送AB实验特点 策略效果滞后 线下因素影响大 面向C端用户进行流量选择 流量之间独立决策、互不干扰 配送AB实验 在线策略平台 独占流量试验区 并行试验区 哈希分桶 UUID 哈希 骑手ID 哈希 地理位置 哈希 调度 提单页ETA 补贴 定价 补贴 定价 列表页 ETA C端 定价 分时间片 哈希分桶 区域 城市 ABABAB BABABA ABABAB AAAAAA 区域 城市 UUID 哈希 骑手ID 哈希 地理位置 哈希 单层实验 必保证流量互斥才可保证实验正交 分层实验 每一层哈希均匀即可保证实验正交 外卖C端 分时间片对照 在线策略平台 策略A 策略B 策略A 策略B 策略A 策略B 策略A 策略B 策略A 策略B 策略A 策略B 第二天 第三天 第四天 第五天 第六天 第一天 策略A/B在两组区域类交替切换，最大限度减少线下因素的影响，确保实验科学、公正 A/B实验平台 算法深入到配送各个环节 流量选择 AA 回朔 指标体系 分流 统一埋点 效果分析 实验报告 配送业务介绍 机器学习在美团配送中的应用 美团配送算法数据平台演进历程 数据闭环和平台化 数据闭环问题 问题在哪里？ 上下文收集 特征收集 模型计算 日志收集 分流实验 业务服务 上层业务 算法支撑 线上数据 线下数据 特征平台 模型管理 版本管理 分流实验 算法Dashboard 业务数据库 MySQL 特征缓存 特征数据 模型文件 离线业务数据 Hive Flume日志Hive 5 4 1 1 2 3 3 1 模型不知道由那些特征数据训练生产 2 Flume日志无法自动追溯到业务 3 缺少算法自动评估 4 算法执行结果没有统一可追溯的日志 5 算法依赖的上下文数据无法追溯 数据缺乏闭环 问题1 平台化问题 问题在哪里？ 问题驱动方式 解决问题 实时特征平台 离线特征平台 模型管理平台 在线策略平台 解决实时特征提取效率问题 解决离线特征行问题 解决模型在线使用问题 解决灰度实验问题 能力之间缺乏协同，不像一个完整平台！ 问题2 数据闭环与平台化 平台建设的方向转变 数据闭环 平台化 数据血缘 特征提取 模型训练 线上预测 AB实验评估 数据图谱 离线特征平台 实时特征平台 模型管理平台 AB实验平台 数据闭环 数据闭环与平台化 分流 实时特征 离线特征 上下文数据 算法全流程日志（Thre