文化公司网站源码,做风险投资网站,搜外友链平台,门户网站建设运行环境要求背景 美团点评酒旅运营需求在离线场景下#xff0c;已经得到了较为系统化的支持#xff0c;通过对离线数据收集、挖掘#xff0c;可对目标用户进行T1触达#xff0c;通过向目标用户发送Push等多种方式#xff0c;在一定程度上提高转化率。但T1本身的延迟性会导致用户在产生… 背景 美团点评酒旅运营需求在离线场景下已经得到了较为系统化的支持通过对离线数据收集、挖掘可对目标用户进行T1触达通过向目标用户发送Push等多种方式在一定程度上提高转化率。但T1本身的延迟性会导致用户在产生特定行为时不能被实时触达无法充分发挥数据的价值取得更优的运营效果。 在此背景下运营业务需要着手挖掘用户行为实时数据如实时浏览、下单、退款、搜索等对满足运营需求用户进行实时触达最大化运营活动效果。 业务场景 在运营实时触达需求中存在如下具有代表性的业务场景 用户在30分钟内发生A行为次数大于等于3次用户为美团酒店老客即用户曾购买过美团酒店产品用户在A行为前24小时内未发生B行为用户在A行为后30分钟内未发生B行为排除30分钟内用户自发产生B行为的影响降低对结果造成的偏差 本文以该典型实时运营场景为例围绕如何设计出可支撑业务需求高效、稳定运行的系统进行展开。 早期方案 运营实时触达需求早期活动数量较少我们通过为每个需求开发一套Storm拓扑相关代码、将运营活动规则硬编码这一“短平快”的方式对运营实时触达需求进行快速支持如图1所示 早期方案的问题 早期方案是一种Case By Case的解决方式不能形成一个完整的系统。随着实时运营业务开展相关运营活动数量激增线上维护着多套相似代码一方面破坏了DRYDon’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所示 总体来看系统组成模块及功能如下 规则引擎集成于Storm拓扑中执行运营活动条件转换成为的具体规则作出对应响应。时间窗模块具有可选时间跨度的滑动时间窗功能为规则判定提供时间窗因子。定时触达模块设定规则判定的执行时间达到设定时间后执行后续规则。自定义函数在Aviator表达式引擎基础函数之上扩展规则引擎功能。报警模块定时检查系统处理的消息量出现异常时为负责人发送报警信息。规则配置控制台提供配置页面通过控制台新增场景及规则配置。配置加载模块定时加载活动规则等配置信息供规则引擎使用。其中规则引擎由核心组件构成的最小功能集及扩展组件提供的扩展功能组成。由于规则引擎解耦了业务规则和系统代码使得实时数据在处理时变的抽象对数据监控、报警提出了更高的要求。下面我们将从规则引擎核心组件、规则引擎扩展组件、监控与报警三个方面分别进行介绍。 规则引擎核心组件 规则引擎核心组件为构成规则引擎的最小集合用以支持完成基础规则判断。 规则引擎核心流程 引入规则引擎后业务需求被转换为具体场景和规则进行执行如图3所示 规则引擎在执行规则过程中涉及以下数据模型 场景业务需求的抽象一个业务需求对应一个场景一个场景由若干规则组成。用不同的规则组成时序和依赖关系以实现完整的业务需求。规则规则由规则条件及因子组成由路由至所属场景的事件触发规则由规则条件、因子及规则响应组成。规则条件规则条件由因子构成为一个布尔表达式。规则条件的执行结果直接决定是否执行规则响应。因子因子是规则条件的基础组成部分按不同来源划分为基础因子、时间窗因子和第三方因子。基础因子来源于事件时间窗因子来源于时间窗模块获取的时间窗数据第三方因子来源于第三方服务如用户画像服务等。规则响应规则执行成功后的动作如将复合事件下发给运营业务系统或发送异步事件进行后续规则判断等。事件事件为系统的基础数据单元划分为同步事件和异步事件两种类型。同步事件按规则路由后不调用定时触达模块顺序执行异步事件调用定时触达模块延后执行。时间窗模块 时间窗模块是酒旅运营实时触达系统规则引擎中的重要构成部分为规则引擎提供时间窗因子。时间窗因子可用于统计时间窗口内浏览行为发生的次数、查询首次下单时间等表1中列举了在运营实时触达活动中需要支持的时间窗因子类型表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))根据时间窗因子类型可以看出时间窗因子有以下特点 时间窗存储中需要以List形式保存时间窗详情数据以分别支持聚合及详情需求。时间窗因子需要天粒度持久化并支持EXPIRE。时间窗因子应用场景多是许多规则的重要组成因子服务承受的压力较大响应时间需要在ms级别。对于以上特点在评估使用场景和接入数据量级的基础上我们选择公司基于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自定义函数示例所示 名称示例含义equalsequals(message.orderType, 0)判断订单类型是否为0filterfilter(browseList, ‘source’, ‘dp’)过滤点评侧浏览列表数据poiPortraitpoiPortrait(message.poiId)根据poiId获取商户画像数据如商户星级属性userPortraituserPortrait(message.userId)根据userId获取用户画像数据如用户常住地城市、用户新老客属性userBlackListuserBlackList(message.userId)根据userId判断用户是否为黑名单用户文章最前面背景中提到的业务场景在2. 用户为美团酒店老客即用户曾购买过美团酒店产品中判断用户是否为美团酒店老客就用到了自定义函数调用用户画像服务通过用户画像标签进行判定。 定时触达模块 定时触达模块支持为规则设定定时执行时间延后某些规则的执行以满足运营活动规则。文章最前面背景中提到的业务场景在4. 用户在A行为后30分钟内未发生B行为排除30分钟内用户自发产生B行为的影响降低对结果造成的偏差条件中需要在A行为发生30分钟后对用户是否发生B行为进行判定以排除用户自发产生B行为对活动效果造成的影响。 定时触达模块涉及的数据流图如图5所示 早期的业务需求对延迟时间要求较短且活动总数量较小通过维护纯内存DelayQueue的方式支持定时触达需求。随着相关运营活动数量增多及定时触达时间的延长纯内存方式对内存的占用量越来越大且在系统重启后定时数据会全部丢失。在对解决方案进行优化时了解到公司消息中间件组在Mafka消息队列中支持消息粒度延迟非常贴合我们的使用场景因此采用此特性代替纯内存方式实现定时触达模块。 监控与报警 对比离线数据实时数据在使用过程中出现问题不易感知。由于系统针对的运营活动直接面向C端在出现系统异常或数据质量异常时如果没有及时发现将会直接造成运营成本浪费严重影响活动转化率等活动效果评估指标。针对系统稳定性问题我们从监控与报警两个角度入手解决。 监控 利用公司数据平台现有产品对系统处理的实时事件按其事件ID上报以时间粒度聚合数据上报后可实时查看各类事件量通过消息量评估活动规则和活动效果是否正常上报数据展示效果如图6所示 报警 监控只能作为Dashboard供展示及查看无法实现自动化报警。由于用于监控所上报的聚合数据存储于时序数据库OpenTSDB中我们基于OpenTSDB开放的HTTP API定制报警模块定时调度、拉取数据对不同事件按事件量级、活动重要性等指标应用环比、绝对值等不同报警规则及阈值。超出设定阈值后通过公司IM及时发送报警信息。如图7所示该事件环比出现数据量级下降收到报警后相关负责人可及时跟踪问题 总结与展望 酒旅运营实时触达系统已上线稳定运行一年多时间是运营业务中十分重要的环节起到承上启下的作用在系统处理能力及对业务贡献方面取得了较好的效果 平均日处理实时消息量近10亿。峰值事件QPS 1.4万。帮助酒店、旅游、大交通等业务线开展了丰富的运营活动。对转化率、GMV、拉新等指标促进显著。当前系统虽然已解决了业务需求但仍存在一些实际痛点 实时数据接入非自动化。规则引擎能力需要推广、泛化。场景及规则注册未对运营PM开放只能由RD完成。展望未来在解决痛点方面我们还有很多路要走未来会继续从技术及业务两方面入手将系统建设的更加易用、高效。 作者简介 晓星美团平台技术部数据中心数据智能组系统工程师2014年毕业于北京理工大学从事Java后台系统及数据服务建设。2017年加入美团点评从事大数据处理相关工作。伟彬美团平台技术部数据中心数据智能组系统工程师2015年毕业于大连理工大学同年加入美团点评专注于大数据处理技术与高并发服务。招聘 最后发个广告美团平台技术部数据中心数据智能组长期招聘数据挖掘算法、大数据系统开发、Java后台开发方面的人才有兴趣的同学可以发送简历到lishangqiang#meituan.com。
