大数据：美团酒旅实时数据规则引擎应用实践

背景

美团点评酒旅运营需求在离线场景下，已经获得了较为系统化的支持，经过对离线数据收集、挖掘，可对目标用户进行T+1触达，经过向目标用户发送Push等多种方式，在必定程度上提升转化率。但T+1自己的延迟性会致使用户在产生特定行为时不能被实时触达，没法充分发挥数据的价值，取得更优的运营效果。

在此背景下，运营业务须要着手挖掘用户行为实时数据，如实时浏览、下单、退款、搜索等，对知足运营需求用户进行实时触达，最大化运营活动效果。

业务场景

在运营实时触达需求中，存在以下具备表明性的业务场景：

1. 用户在30分钟内发生A行为次数大于等于3次
2. 用户为美团酒店老客，即用户曾购买过美团酒店产品
3. 用户在A行为前24小时内未发生B行为
4. 用户在A行为后30分钟内未发生B行为（排除30分钟内用户自发产生B行为的影响，下降对结果形成的误差）

本文以该典型实时运营场景为例，围绕如何设计出可支撑业务需求高效、稳定运行的系统进行展开。

早期方案

运营实时触达需求早期活动数量较少，咱们经过为每一个需求开发一套Storm拓扑相关代码、将运营活动规则硬编码这一“短平快”的方式，对运营实时触达需求进行快速支持，如图1所示：

图1 早期方案示意图

早期方案的问题

早期方案是一种Case By Case的解决方式，不能造成一个完整的系统。随着实时运营业务开展，相关运营活动数量激增，线上维护着多套类似代码，一方面破坏了DRY（Don't Repeat Yourself）原则，另外一方面线上维护成本也呈线性增加，系统逐渐没法支撑当前的需求。

挑战

为解决早期方案中出现的问题，对系统建设提出了如下挑战：

• 硬编码活动规则的方式产生了大量重复代码，开发成本较高，需求响应时间较长。
• 业务规则修改困难，调整运营活动条件须要修改代码并重启线上拓扑。
• 线上Storm拓扑较多，资源利用率、系统吞吐量低，统一维护成本较高。
• 缺少完善的监控报警机制，很难早于业务发现系统及数据中存在的稳定性问题。

针对以上挑战，结合业务规则特色，美团点评数据智能团队调研并设计了酒旅运营实时触达系统。

技术调研

规则引擎的必要性

提升灵活度须要从业务规则和系统代码解耦和入手，规则和代码耦合直接致使了重复代码增多、业务规则修改困难等问题。那如何将业务规则和系统代码解耦和呢？咱们想到使用规则引擎解决这一问题。

规则引擎是处理复杂规则集合的引擎。经过输入一些基础事件，以推演或者概括等方式，获得最终的执行结果。规则引擎的核心做用在于将复杂、易变的规则从系统中抽离出来，由灵活可变的规则来描述业务需求。因为不少业务场景，包括酒旅运营实时触达场景，规则处理的输入或触发条件是事件，且事件间有依赖或时序的关系，因此规则引擎常常和CEP（复合事件处理）结合起来使用。

CEP经过对多个简单事件进行组合分析、处理，利用事件的相互关系，找出有意义的事件，从而得出结论。文章最前面背景中提到的业务场景，经过屡次规则处理，将单一事件组合成具备业务含义的复合事件，进而提升该类仅浏览未下单的用户的下单几率。能够看出，规则引擎及CEP能够知足业务场景的具体需求，将其引入能够提升系统面对需求变化的灵活度。

规则引擎调研

在设计规则引擎前，咱们对业界已有的规则引擎，主要包括Esper和Drools，进行了调研。

Esper

Esper设计目标为CEP的轻量级解决方案，能够方便的嵌入服务中，提供CEP功能。

优点

• 轻量级可嵌入开发，经常使用的CEP功能简单好用。
• EPL语法与SQL相似，学习成本较低。

劣势

• 单机全内存方案，须要整合其余分布式和存储。
• 之内存实现时间窗功能，没法支持较长跨度的时间窗。
• 没法有效支持定时触达（如用户在浏览发生后30分钟触达支付条件判断）。

Drools

Drools开始于规则引擎，后引入Drools Fusion模块提供CEP的功能。

优点

• 功能较为完善，具备如系统监控、操做平台等功能。

劣势

• 学习曲线陡峭，其引入的DRL语言较复杂，独立的系统很难进行二次开发。
• 之内存实现时间窗功能，没法支持较长跨度的时间窗。
• 没法有效支持定时触达（如用户在浏览发生后30分钟触达支付条件判断）。

因为业务规则对时间窗功能及定时触达功能有较强的依赖，综合以上两种规则引擎的优劣势，咱们选用了相对SpEL更为轻量的表达式引擎Aviator，将流式数据处理及规则引擎集成至Storm中，由Storm保证系统在数据处理时的吞吐量，在系统处理资源出现瓶颈时，可在公司托管平台上调整Worker及Executor数量，下降系统水平扩展所需成本。

技术方案

肯定引入规则引擎后，围绕规则引擎的设计开发成为了系统建设的主要着力点。经过使用实时数据仓库中的用户实时行为数据，按业务运营活动规则，组合成有意义的复合事件，交由下游运营业务系统对事件的主体，也就是用户进行触达。将系统抽象为如下功能模块，如图2所示：

图2 系统模块图

整体来看，系统组成模块及功能以下：

• 规则引擎：集成于Storm拓扑中，执行运营活动条件转换成为的具体规则，做出对应响应。
• 时间窗模块：具备可选时间跨度的滑动时间窗功能，为规则断定提供时间窗因子。
• 定时触达模块：设定规则断定的执行时间，达到设定时间后，执行后续规则。
• 自定义函数：在Aviator表达式引擎基础函数之上，扩展规则引擎功能。
• 报警模块：定时检查系统处理的消息量，出现异常时为负责人发送报警信息。
• 规则配置控制台：提供配置页面，经过控制台新增场景及规则配置。
• 配置加载模块：定时加载活动规则等配置信息，供规则引擎使用。

其中，规则引擎由核心组件构成的最小功能集及扩展组件提供的扩展功能组成。因为规则引擎解耦了业务规则和系统代码，使得实时数据在处理时变的抽象，对数据监控、报警提出了更高的要求。下面咱们将从规则引擎核心组件、规则引擎扩展组件、监控与报警三个方面分别进行介绍。

规则引擎核心组件

规则引擎核心组件为构成规则引擎的最小集合，用以支持完成基础规则判断。

规则引擎核心流程

引入规则引擎后，业务需求被转换为具体场景和规则进行执行，如图3所示：

图3 规则引擎处理流程图

规则引擎在执行规则过程当中，涉及如下数据模型：

• 场景：业务需求的抽象，一个业务需求对应一个场景，一个场景由若干规则组成。用不一样的规则组成时序和依赖关系以实现完整的业务需求。
• 规则：规则由规则条件及因子组成，由路由至所属场景的事件触发，规则由规则条件、因子及规则响应组成。
• 规则条件：规则条件由因子构成，为一个布尔表达式。规则条件的执行结果直接决定是否执行规则响应。
• 因子：因子是规则条件的基础组成部分，按不一样来源，划分为基础因子、时间窗因子和第三方因子。基础因子来源于事件，时间窗因子来源于时间窗模块获取的时间窗数据，第三方因子来源于第三方服务，如用户画像服务等。
• 规则响应：规则执行成功后的动做，如将复合事件下发给运营业务系统，或发送异步事件进行后续规则判断等。
• 事件：事件为系统的基础数据单元，划分为同步事件和异步事件两种类型。同步事件按规则路由后，不调用定时触达模块，顺序执行；异步事件调用定时触达模块，延后执行。

时间窗模块

时间窗模块是酒旅运营实时触达系统规则引擎中的重要构成部分，为规则引擎提供时间窗因子。时间窗因子可用于统计时间窗口内浏览行为发生的次数、查询首次下单时间等，表1中列举了在运营实时触达活动中须要支持的时间窗因子类型：

类型	示例	因子构成
count	近X分钟浏览POI大于Y次	count(timeWindow(event.id, event.userId, X * 60))
distinct count	近X分钟浏览不一样POI大于Y次	count(distinct(timeWindow(event.id, event.userId, X * 60)))
first	近X天支付的首单酒店	first(timeWindow(event.id, event.userId, X * 60))
last	近X天最后一次搜索的酒店	last(timeWindow(event.id, event.userId, X * 60))

表1 时间窗因子类型

根据时间窗因子类型能够看出，时间窗因子有如下特色：

1. 时间窗存储中须要以List形式保存时间窗详情数据，以分别支持聚合及详情需求。
2. 时间窗因子须要天粒度持久化，并支持EXPIRE。
3. 时间窗因子应用场景多，是许多规则的重要组成因子，服务承受的压力较大，响应时间须要在ms级别。

对于以上特色，在评估使用场景和接入数据量级的基础上，咱们选择公司基于Tair研发的KV的存储服务Cellar存储时间窗数据，经测试其在20K QPS请求下，TP99能保证在2ms左右，且存储方面性价比较高，能够知足系统需求。

在实际运营活动中，对时间窗内用户某种行为次数的判断每每在5次之内，结合此业务场景，同时为避免Value过大影响读写响应时间，在更新时间窗数据时设置阈值，对超出阈值部分进行截断。时间窗数据更新及截断流程如图4所示：

图4 时间窗数据更新示意图

文章最前面背景中提到的业务场景，在1. 用户在30分钟内发生A行为次数大于等于3次、3. 用户在A行为前24小时内未发生B行为、4. 用户在A行为后30分钟内未发生B行为（排除30分钟内用户自发产生B行为的影响，下降对结果形成的误差）中，均使用了时间窗模块对滑动时间窗内的用户行为进行了统计，以时间窗因子做为规则执行判断的依据。

规则引擎扩展组件

规则引擎扩展组件在核心组件的基础上，加强规则引擎功能。

自定义函数

自定义函数能够扩充Aviator功能，规则引擎可经过自定义函数执行因子及规则条件，如调用用户画像等第三方服务。系统内为支持运营需求扩展的部分自定义函数如表2所示：

名称	示例	含义
equals	equals(message.orderType, 0)	判断订单类型是否为0
filter	filter(browseList, 'source', 'dp')	过滤点评侧浏览列表数据
poiPortrait	poiPortrait(message.poiId)	根据poiId获取商户画像数据，如商户星级属性
userPortrait	userPortrait(message.userId)	根据userId获取用户画像数据，如用户常住地城市、用户新老客属性
userBlackList	userBlackList(message.userId)	根据userId判断用户是否为黑名单用户

表2 自定义函数示例

文章最前面背景中提到的业务场景，在2. 用户为美团酒店老客，即用户曾购买过美团酒店产品中，判断用户是否为美团酒店老客，就用到了自定义函数，调用用户画像服务，经过用户画像标签进行断定。

定时触达模块

定时触达模块支持为规则设定定时执行时间，延后某些规则的执行以知足运营活动规则。文章最前面背景中提到的业务场景，在4. 用户在A行为后30分钟内未发生B行为（排除30分钟内用户自发产生B行为的影响，下降对结果形成的误差）条件中，须要在A行为发生30分钟后，对用户是否发生B行为进行断定，以排除用户自发产生B行为对活动效果形成的影响。

定时触达模块涉及的数据流图如图5所示：

图5 定时触达模块数据流图

早期的业务需求对延迟时间要求较短，且活动总数量较小，经过维护纯内存DelayQueue的方式，支持定时触达需求。随着相关运营活动数量增多及定时触达时间的延长，纯内存方式对内存的占用量愈来愈大，且在系统重启后定时数据会所有丢失。在对解决方案进行优化时，了解到公司消息中间件组在Mafka消息队列中支持消息粒度延迟，很是贴合咱们的使用场景，所以采用此特性，代替纯内存方式，实现定时触达模块。

监控与报警

对比离线数据，实时数据在使用过程当中出现问题不易感知。因为系统针对的运营活动直接面向C端，在出现系统异常或数据质量异常时，若是没有及时发现，将会直接形成运营成本浪费，严重影响活动转化率等活动效果评估指标。针对系统稳定性问题，咱们从监控与报警两个角度入手解决。

监控

利用公司数据平台现有产品，对系统处理的实时事件按其事件ID上报，以时间粒度聚合，数据上报后可实时查看各种事件量，经过消息量评估活动规则和活动效果是否正常，上报数据展现效果如图6所示：

图6 实时事件监控图

报警

监控只能做为Dashboard供展现及查看，没法实现自动化报警。因为用于监控所上报的聚合数据存储于时序数据库OpenTSDB中，咱们基于OpenTSDB开放的HTTP API，定制报警模块，定时调度、拉取数据，对不一样事件，按事件量级、活动重要性等指标，应用环比、绝对值等不一样报警规则及阈值。超出设定阈值后，经过公司IM及时发送报警信息。如图7所示，该事件环比出现数据量级降低，收到报警后相关负责人可及时跟踪问题：

图7 报警信息示意图

总结与展望

酒旅运营实时触达系统已上线稳定运行一年多时间，是运营业务中十分重要的环节，起到承上启下的做用，在系统处理能力及对业务贡献方面取得了较好的效果：

• 平均日处理实时消息量近10亿。
• 峰值事件QPS 1.4万。
• 帮助酒店、旅游、大交通等业务线开展了丰富的运营活动。
• 对转化率、GMV、拉新等指标促进显著。

当前系统虽然已解决了业务需求，但仍存在一些实际痛点：

• 实时数据接入非自动化。
• 规则引擎能力须要推广、泛化。
• 场景及规则注册未对运营PM开放，只能由RD完成。

展望将来，在解决痛点方面咱们还有不少路要走，将来会继续从技术及业务两方面入手，将系统建设的更加易用、高效。

做者简介

晓星，美团平台技术部－数据中心－数据智能组系统工程师，2014年毕业于北京理工大学，从事Java后台系统及数据服务建设。2017年加入美团点评，从事大数据处理相关工做。

伟彬，美团平台技术部－数据中心－数据智能组系统工程师，2015年毕业于大连理工大学，同年加入美团点评，专一于大数据处理技术与高并发服务。

招聘

最后发个广告，美团平台技术部－数据中心－数据智能组长期招聘数据挖掘算法、大数据系统开发、Java后台开发方面的人才，有兴趣的同窗能够发送简历到lishangqiang#meituan.com。

若是对咱们团队感兴趣，能够关注咱们的专栏。