分享嘉宾：李金康 美团 高级技术专家 编辑整理：Frank 出品平台：DataFunTalk

导读：2019年5月，美团正式推出新品牌「美团配送」，升级配送开放平台。那你知道支撑美团配送大脑的实时特征平台是如何建设的吗？如何实现每分钟生产千万级的实时特征？如何在70w+QPS的场景下实现4个9响应耗时在50毫秒的需求？本文将为大家介绍配送实时特征平台的发展历程，关键技术和实践经验。

01配送业务介绍

1. 商业模型 配送的业务最主要的就是一个履约的行为，将用户、商家和骑手关联起来，促进配送效率提升、用户体验提高、配送成本降低，从而形成一个闭环的商业模型。

即时配送平台核心职责就是调整好用户、商家、骑手三元的关系，用更低的成本为用户带来更好的体验，为商家带来更多的单量，为骑手带来更多的收入。

2. 履约模型 配送就是一个履约的过程，不像电商主要是线上完成，配送主要是线下完成履约。

物理世界中，一个运单的完成过程是从用户下单开始到用户收餐骑手离客为止，需经历一系列室内室外的场景——用户下单，系统派单，骑手室外骑行到目的地然后下车步行到商家，等待取餐驻留室内，商家出餐，骑手取餐离店后步行上车，室外骑行到用户目的地，下车步行上楼送餐，驻留室内等待用户收餐，最后用户收餐骑手离客。

可以看到物理世界是比较复杂的一个过程，那就需要智能决策系统来做一定的调度，派给哪个骑手？何时到店取餐？同时要做一个合理的定价，针对恶劣天气和爬楼梯等特殊情况收的费用肯定是不同的，收多少配送费？付给骑手多少配送费？最后还要给出一个合理的时间预估，配送时长是多少？商家多久可以出餐？

算法要做以上这些智能决策过程中，就需要做履约过程整个链路的数字化，通过实时特征平台来做实时感知的数字化，通过AIoT平台完成如骑手骑行、爬楼等行为精准感知的数字化；本次主要介绍实时感知数字化的实时特征平台。

02实时特征平台建设

1. 背景 2017年开始做实时特征平台建设的背景是为了解决两大问题：

  • 千万订单履约过程智能化：最开始履约过程是由简单的规则构建的，现在要实现从规则配置化向智能化过渡，包含智能调度、ETA时间预估、配送费定价和爆单等场景；算法实时决策需要分钟级数据的时效性。
  • 现有开发模式无法及时响应：当时实时特征开发散落在4个业务团队，进行烟囱式开发，流程长、效率低，存在一些重复建设；实时特征开发耦合在业务系统中，稳定性风险较高。

2. 目标&规划 基于建设背景，设定了建设目标——建设分钟级时效的实时特征平台，多粒度刻画履约过程，提升研发效率，降低研发成本。

基于建设目标，设定了三阶段的演进计划：

第一阶段——系统化：和业务系统划清边界、确定实时平台架构；将系统搭建起来，验证是否可以支撑业务场景；将新增特征进行收口管理。 第二阶段——规模化：建设高可用的系统，支撑更多的实时特征，将旧特征“绞杀”进行统一收口管理。 第三阶段——平台化：将实时计算整合，进行完善的服务治理。

3. 系统化

① 设计思路

② 整体架构

进行系统化整体架构设计时，先制定了左侧的架构标准：

流程标准化：从数据输入，加工计算到数据输出做了一个流程的标准化。

数据分层，将共性沉淀下来。 特征兜底，降低风险。

基于架构标准，最终制定了右侧的架构图，共分为6层： * 数据源层：主要有包裹表、运单表、骑手表以及运单扩展表。 * 数据层：ODS层将数据进行清洗和转换，在DWD进行维表建模和合流，最后形成索引数据和明细数据的宽表。 * 计算层：通过标准化的SQL对宽表数据进行计算。 * 存储层：存储计算层输出的特征数据。 * 服务层：通过实时特征服务将存储层数据统一输出应用层应用。 * 应用层：主要有ETA时间预估策略服务、调度策略服务、保单策略服务以及定价策略服务。 * 管理系统：主要就是一些元数据的管理，比如数据源、特征口径以及存储的管理；还包含兜底策略管理，降级模块，可以对单特征降级，也支持批量降级的核按钮。

③ 数据层关键点

做实时数据系统大都会碰到两个挑战：

  • 流乱序问题
  • 端到端的Exactly-Once语义保障

针对以上挑战，结合配送的实际业务场景给出对应的解决思路：

  • 提前构建“拼图”模板，实时填充：结合物理世界的配送履约过程，构建业务宽表，涵盖下单时间、支付时间、发单时间、调度时间、接单时间、取餐时间、送达时间等，根据实时数据流填充模板宽表，避免各数据流填各自的字段，避免乱序问题。
  • 上游合流保证不丢，下游解决重复问题。

④ 计算层关键点 2017年调研了一些行业解决方案:

Storm开发运维成本较高、SQL化难度高。

Flink没有现在这么火，稳定性无法保障；Spark Streaming不是公司运维的关键点，对于线上场景的稳定性也是无法保障。

耦合在业务系统内部的基于Rpc计算在公司有成熟的监控运维体系和技术框架，但有一个问题是，该场景主要是基于关系型数据库进行计算的，例如MySQL，是存在单点问题的，扩展较难。

因为对基于Rpc的计算是相对有把握的，所以首先升级计算框架，将原有基于关系数据库计算升级为基于内存计算，计算是无状态、可扩展的；为了防止数据倾斜，基于业务特点进行提前按区域分片，采用“能者多劳”模式，计算比较快的节点就多计算一些。

更多内容请点击下方查看原文

内容中包含的图片若涉及版权问题，请及时与我们联系删除