导读
3天前10月7日,美团对外发布《2026国庆消费洞察报告》,对刚刚过去的国庆假期消费情况进行了梳理。报告中最受关注的一项数据是,假期期间酒店连住订单量较去年同期增长31%,反映出游客在目的地停留时间延长的趋势。与此同时,800公里以上长线游订单量同比增长25%,说明长距离出行...
详情
美团 · 技术团队首页历史文章技术沙龙关于我们美团酒旅实时数据规则引擎应用实践 晓星 伟彬 2018-04-19系统数据背景美团点评酒旅运营需求在离线场景下，已经得到了较为系统化的支持，通过对离线数据收集、挖掘，可对目标用户进行T+1触达，通过向目标用户发送Push等多种方式，在一定程度上提高转化率。但T+1本身的延迟性会导致用户在产生特定行为时不能被实时触达，无法充分发挥数据的价值，取得更优的运营效果。
在此背景下，运营业务需要着手挖掘用户行为实时数据，如实时浏览、下单、退款、搜索等，对满足运营需求用户进行实时触达，最大化运营活动效果。
本文以该典型实时运营场景为例，围绕如何设计出可支撑业务需求高效、稳定运行的系统进行展开。
运营实时触达需求早期活动数量较少，我们通过为每个需求开发一套Storm拓扑相关代码、将运营活动规则硬编码这一“短平快”的方式，对运营实时触达需求进行快速支持，如图1所示：
早期方案是一种Case By Case的解决方式，不能形成一个完整的系统。随着实时运营业务开展，相关运营活动数量激增，线上维护着多套相似代码，一方面破坏了DRY（Don't Repeat Yourself）原则，另一方面线上维护成本也呈线性增长，系统逐渐无法支撑当前的需求。
针对以上挑战，结合业务规则特点，美团点评数据智能团队调研并设计了酒旅运营实时触达系统。
提高灵活度需要从业务规则和系统代码解耦和入手，规则和代码耦合直接导致了重复代码增多、业务规则修改困难等问题。那如何将业务规则和系统代码解耦和呢？我们想到使用规则引擎解决这一问题。
规则引擎是处理复杂规则集合的引擎。通过输入一些基础事件，以推演或者归纳等方式，得到最终的执行结果。规则引擎的核心作用在于将复杂、易变的规则从系统中抽离出来，由灵活可变的规则来描述业务需求。由于很多业务场景，包括酒旅运营实时触达场景，规则处理的输入或触发条件是事件，且事件间有依赖或时序的关系，所以规则引擎经常和CEP（复合事件处理）结合起来使用。
CEP通过对多个简单事件进行组合分析、处理，利用事件的相互关系，找出有意义的事件，从而得出结论。文章最前面背景中提到的业务场景，通过多次规则处理，将单一事件组合成具有业务含义的复合事件，进而提高该类仅浏览未下单的用户的下单概率。可以看出，规则引擎及CEP可以满足业务场景的具体需求，将其引入可以提高系统面对需求变化的灵活度。
在设计规则引擎前，我们对业界已有的规则引擎，主要包括Esper和Drools，进行了调研。
Esper设计目标为CEP的轻量级解决方案，可以方便的嵌入服务中，提供CEP功能。
Drools开始于规则引擎，后引入Drools Fusion模块提供CEP的功能。
由于业务规则对时间窗功能及定时触达功能有较强的依赖，综合以上两种规则引擎的优劣势，我们选用了相对SpEL更为轻量的表达式引擎Aviator，将流式数据处理及规则引擎集成至Storm中，由Storm保证系统在数据处理时的吞吐量，在系统处理资源出现瓶颈时，可在公司托管平台上调整Worker及Executor数量，降低系统水平扩展所需成本。
确定引入规则引擎后，围绕规则引擎的设计开发成为了系统建设的主要着力点。通过使用实时数据仓库中的用户实时行为数据，按业务运营活动规则，组合成有意义的复合事件，交由下游运营业务系统对事件的主体，也就是用户进行触达。将系统抽象为以下功能模块，如图2所示：
其中，规则引擎由核心组件构成的最小功能集及扩展组件提供的扩展功能组成。由于规则引擎解耦了业务规则和系统代码，使得实时数据在处理时变的抽象，对数据监控、报警提出了更高的要求。下面我们将从规则引擎核心组件、规则引擎扩展组件、监控与报警三个方面分别进行介绍。
规则引擎核心组件为构成规则引擎的最小集合，用以支持完成基础规则判断。
引入规则引擎后，业务需求被转换为具体场景和规则进行执行，如图3所示：
时间窗模块是酒旅运营实时触达系统规则引擎中的重要构成部分，为规则引擎提供时间窗因子。时间窗因子可用于统计时间窗口内浏览行为发生的次数、查询首次下单时间等，表1中列举了在运营实时触达活动中需要支持的时间窗因子类型（表1 时间窗因子类型）：
对于以上特点，在评估使用场景和接入数据量级的基础上，我们选择公司基于Tair研发的KV的存储服务Cellar存储时间窗数据，经测试其在20K QPS请求下，TP99能保证在2ms左右，且存储方面性价比较高，可以满足系统需求。
在实际运营活动中，对时间窗内用户某种行为次数的判断往往在5次以内，结合此业务场景，同时为避免Value过大影响读写响应时间，在更新时间窗数据时设置阈值，对超出阈值部分进行截断。时间窗数据更新及截断流程如图4所示：
文章最前面背景中提到的业务场景，在1. 用户在30分钟内发生A行为次数大于等于3次、3. 用户在A行为前24小时内未发生B行为、4. 用户在A行为后30分钟内未发生B行为（排除30分钟内用户自发产生B行为的影响，降低对结果造成的偏差）中，均使用了时间窗模块对滑动时间窗内的用户行为进行了统计，以时间窗因子作为规则执行判断的依据。
自定义函数可以扩充Aviator功能，规则引擎可通过自定义函数执行因子及规则条件，如调用用户画像等第三方服务。系统内为支持运营需求扩展的部分自定义函数如表2（自定义函数示例）所示：
文章最前面背景中提到的业务场景，在2. 用户为美团酒店老客，即用户曾购买过美团酒店产品中，判断用户是否为美团酒店老客，就用到了自定义函数，调用用户画像服务，通过用户画像标签进行判定。
定时触达模块支持为规则设定定时执行时间，延后某些规则的执行以满足运营活动规则。文章最前面背景中提到的业务场景，在4. 用户在A行为后30分钟内未发生B行为（排除30分钟内用户自发产生B行为的影响，降低对结果造成的偏差）条件中，需要在A行为发生30分钟后，对用户是否发生B行为进行判定，以排除用户自发产生B行为对活动效果造成的影响。
早期的业务需求对延迟时间要求较短，且活动总数量较小，通过维护纯内存DelayQueue的方式，支持定时触达需求。随着相关运营活动数量增多及定时触达时间的延长，纯内存方式对内存的占用量越来越大，且在系统重启后定时数据会全部丢失。在对解决方案进行优化时，了解到公司消息中间件组在Mafka消息队列中支持消息粒度延迟，非常贴合我们的使用场景，因此采用此特性，代替纯内存方式，实现定时触达模块。
对比离线数据，实时数据在使用过程中出现问题不易感知。由于系统针对的运营活动直接面向C端，在出现系统异常或数据质量异常时，如果没有及时发现，将会直接造成运营成本浪费，严重影响活动转化率等活动效果评估指标。针对系统稳定性问题，我们从监控与报警两个角度入手解决。
利用公司数据平台现有产品，对系统处理的实时事件按其事件ID上报，以时间粒度聚合，数据上报后可实时查看各类事件量，通过消息量评估活动规则和活动效果是否正常，上报数据展示效果如图6所示：
监控只能作为Dashboard供展示及查看，无法实现自动化报警。由于用于监控所上报的聚合数据存储于时序数据库OpenTSDB中，我们基
版权说明：本文系毕昇酒店经编辑部根据公开信息整理转载，内容来源：美团酒店（阅读原文）。本文版权归原作者及原发布平台所有，转载仅为酒店行业信息交流之用，不用于任何商业目的；转载时已注明来源，如有疏漏请联系补充。
异议处理：如您认为本文涉及侵犯著作权、名誉权或其他合法权益，请通过邮箱 6589776@qq.com 联系我们（请附文章链接及权属证明），我们承诺核实后 24 小时内删除或更正。本文内容仅供参考，不构成任何投资建议。