2017搜索引擎优化规则(美团点评数据智能团队调研运营实时触达需求早期活动数量较少)

　　2017搜索引擎优化规则(美团点评数据智能团队调研运营实时触达需求早期活动数量较少)

　　背景

　　美团点评酒旅服务的运营需求已经在线下场景得到系统支持。通过线下数据采集和挖掘，T+1触达目标用户，可以通过向目标用户发送Push等多种方式。，一定程度上提高了转化率。但是，T+1本身的延迟会导致用户在产生特定行为时无法实时触达，无法充分发挥数据的价值，取得更好的运营效果。

　　在此背景下，运营业务需要开始挖掘用户行为的实时数据，如实时浏览、下单、退款、搜索等，实时触达满足运营需求的用户，最大限度地发挥用户行为的效果。业务活动。

　　商业场景

　　在实时满足运营需求方面，有以下代表性的业务场景：

　　用户在 30 分钟内有 3 次或以上行为 A 的行为。用户是美团酒店的常客，即用户购买了美团酒店产品。用户在行为A发生前24小时内没有发生行为B。用户在行为A发生后30分钟内没有发生B行为（排除用户在30分钟内B行为的自发影响，减少由行为A引起的偏差）结果）

　　本文以这个典型的实时运行场景为例，扩展了如何设计一个可以支持业务需求的系统，实现高效稳定运行。

　　早期计划

　　满足实时运营需求的早期活动数量很少。我们针对每个需求开发了一套Storm拓扑相关的代码，并对运营活动的规则进行硬编码，这是一种“短、平、快”的方式，快速支持实时的运营需求，如图1：

　　

　　早期计划的问题

　　早期的解决方案是Case By Case的解决方案，不能形成一个完整的系统。随着实时运营业务的发展，相关运营活动的数量急剧增加，在线维护多套相似代码。一方面，DRY（不要重复自己）的原则被打破了。另一方面，在线维护的成本也呈线性增长，系统逐渐增多。无法支持当前的需求。

　　挑战

　　为解决早期方案中存在的问题，对系统建设提出以下挑战：

　　针对上述挑战，结合业务规则特点，美团点评数据智能团队研究设计了酒旅运营实时接入系统。

　　技术研究规则引擎的必要性

　　提高灵活性需要解耦，从业务规则和系统代码入手。规则与代码的耦合直接导致代码重复增加、业务规则修改困难等问题。如何解耦业务规则和系统代码？我们想到了使用规则引擎来解决这个问题。

　　规则引擎是处理复杂规则集的引擎。通过输入一些基本事件，可以通过演绎或归纳得到最终的执行结果。规则引擎的核心功能是从系统中提取复杂多变的规则，用灵活多变的规则来描述业务需求。由于很多业务场景，包括酒旅运营的实时触发场景，规则处理的输入或触发条件为事件，且事件之间存在依赖或时序关系，因此规则引擎常与CEP结合使用（复合事件处理）。

　　CEP对多个简单事件进行分析和处理，利用事件的相互关系寻找有意义的事件并得出结论。文章 在前面背景中提到的业务场景中，通过多条规则处理，将单个事件组合成具有业务意义的复合事件，从而增加用户只浏览未下单的下单概率。可见，规则引擎和CEP可以满足业务场景的特定需求，引入它们可以提高系统响应需求变化的灵活性。

　　规则引擎研究

　　在设计规则引擎之前，我们对业界现有的规则引擎进行了研究，包括 Esper 和 Drools。

　　埃斯珀

　　Esper 的设计目标是 CEP 的轻量级解决方案，可以轻松嵌入到服务中以提供 CEP 功能。

　　优势

　　坏处

　　流口水

　　Drools 最初是一个规则引擎，后来引入了 Drools Fusion 模块来提供 CEP 功能。

　　优势

　　坏处

　　由于业务规则严重依赖时间窗函数和时序访问函数，综合以上两种规则引擎的优缺点，我们选择了Aviator这个比SpEL更轻量级的表达式引擎来集成流数据处理和规则引擎。集成到 Storm 中，Storm 保证了系统在数据处理过程中的吞吐量。当系统处理资源出现瓶颈时，可以在公司托管平台上调整Workers和Executor的数量，降低系统横向扩展的成本。

　　技术解决方案

　　在确定引入规则引擎后，规则引擎的设计开发就成为了系统建设的主要重点。通过使用实时数据仓库中用户的实时行为数据，按照业务运营活动的规律，将其组合成有意义的复合事件，交由下游运营业务系统到达事件的主体，也就是用户。该系统抽象为以下功能模块，如图2所示：

　　

　　总的来说，系统组成和功能如下：

　　其中，规则引擎由核心组件和扩展组件提供的扩展功能组成的最小功能集构成。由于规则引擎将业务规则和系统代码解耦，处理过程中对实时数据进行了抽象，对数据监控和告警提出了更高的要求。下面分别介绍规则引擎的核心组件、规则引擎的扩展组件、监控和告警。

　　规则引擎的核心组件

　　规则引擎的核心组件是构成规则引擎的最小集合，支持完成基本的规则判断。

　　规则引擎的核心流程

　　引入规则引擎后，将业务需求转化为具体的场景和规则来执行，如图3所示：

　　

　　规则引擎在执行规则的过程中涉及到以下数据模型：

　　时间窗口模块

　　时间窗模块是酒旅运营实时接入系统规则引擎的重要组成部分，为规则引擎提供时间窗因子。时间窗因子可用于统计时间窗内浏览行为的次数、查询第一单的时间等。表1列出了运营实时触达活动需要支持的时间窗因子类型（表 1 时间窗因子类型）：

　　类型示例因子组合

　　数数

　　在过去 X 分钟内浏览 POI 超过 Y 次

　　count(timeWindow(event.id, event.userId, X * 60))

　　不同的计数

　　在过去 X 分钟内浏览不同 POI 超过 Y 次

　　计数（不同的（时间窗口（event.id，event.userId，X * 60)））

　　第一的

　　最近X天支付的第一家酒店

　　第一（时间窗口（event.id，event.userId，X * 60)）

　　最后的

　　最近 X 天内搜索的最后一家酒店

　　last(timeWindow(event.id, event.userId, X * 60))

　　根据时间窗因子的类型，可以看出时间窗因子具有以下特点：

　　时间窗存储需要以List的形式保存时间窗明细数据，分别支持聚合和明细需求。时间窗口因子需要日粒度持久化，支持EXPIRE。时间窗口因子有很多应用场景，它是许多规则的重要组成部分。服务压力大，响应时间需要在ms级别。

　　针对以上特性，基于对使用场景和访问数据水平的评估，我们选择了Tair公司开发的基于KV的存储服务Cellar来存储时间窗口数据。经过测试，在20K QPS的要求下，TP99可以保证在2ms左右，而且存储方面性价比高，可以满足系统的需求。

　　在实际运营活动中，对时间窗口内某些用户行为次数的判断往往在5次以内。结合该业务场景，同时为了避免Value过大影响读写响应时间，在时间窗口内更新数据时设置了一个阈值。超过阈值的部分被截断。时间窗数据更新截断流程如图4所示：

　　

　　文章前沿后台提到的业务场景，在1.用户在30分钟内发生3次以上的A行为，3.用户在24分钟内没有发生在A行为B行为之前的小时，4.用户在A行为后30分钟内没有B行为（排除30分钟内用户B行为的自发影响，减少结果造成的偏差），时间窗口模块用于控制滑动计算时间窗口内的用户行为，并以时间窗口因子作为规则执行判断的依据。

　　规则引擎扩展

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

　　自定义功能

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

　　名称示例含义

　　等于

　　等于（message.orderType，0)

　　判断订单类型是否为0

　　筛选

　　过滤器（浏览列表，'源'，'dp'）

　　过滤审查侧浏览列表数据

　　poiPortrait

　　poiPortrait(message.poiId)

　　根据poiId获取商家画像数据，例如商家明星属性

　　用户画像

　　用户画像（message.userId）

　　根据userId获取用户*敏*感*词*数据，如用户常住城市、用户新老客人属性

　　用户黑名单

　　用户黑名单（message.userId）

　　根据userId判断用户是否为黑名单用户

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

　　定时到达模块

　　定时到达模块支持为规则设置定时执行时间，延迟某些规则的执行以满足业务活动的规则。文章在前面背景中提到的业务场景中，4.用户在A行为后30分钟内没有B行为（不包括用户在30分钟内B行为的自发影响，并减少对结果的影响（在偏差的情况下），需要在A行为发生30分钟后判断用户是否进行了B行为，以消除用户自发的B行为对效果的影响活动。

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

　　

　　早期的业务需求需要更短的延迟时间和较少的活动总数。通过维护一个纯内存的DelayQueue，按时满足需求。随着相关操作活动的增多和计时到达时间的延长，纯内存方式占用的内存越来越多，系统重启后所有计时数据都会丢失。在优化方案的时候，了解到公司的消息中间件组支持Mafka消息队列中的消息粒度延迟，非常适合我们的使用场景，所以用这个特性代替纯内存来实现时序到达模块。

　　监控报警

　　与离线数据相比，实时数据在使用过程中出现问题时不易感知。由于系统针对的运营活动直接面向C端，如果不及时发现系统异常或数据质量异常，将直接造成运营成本的浪费，严重影响活动转化等活动效果评价指标速度。关于系统稳定性问题，我们从监控和告警两个角度着手解决。

　　监视器

　　使用公司现有的数据平台产品，系统处理的实时事件根据事件ID上报，并按时间粒度聚合。数据上报后，可以实时查看各种事件的数量，通过消息量评估活动规则和效果，并上报数据。显示效果如图6所示：

　　

　　报警

　　监控只能作为Dashboard进行展示查看，无法实现自动报警。由于监控上报的聚合数据存储在时间序列数据库OpenTSDB中，我们基于OpenTSDB开放的HTTP API定制告警模块，定时调度，拉取数据，针对不同的事件，根据事件的大小、活动的重要性和其他指标，应用不同的报警规则和阈值，如环比和绝对值。超过设定阈值后，会及时通过公司IM发送告警信息。如图7所示，该事件的数据水平较上月有所下降，相关负责人接到报警后可及时跟踪问题：

　　

　　总结与展望

　　酒旅运营实时接入系统上线一年多，稳定运行。它是运营业务中非常重要的组成部分，起到了连接上下游的作用。在系统处理能力和对业务的贡献方面取得了不错的成绩：

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

　　展望未来，我们在解决痛点方面还有很多路要走。未来，我们将继续从技术和业务两方面着手，让系统更易用、更高效。

　　作者介绍

　　最后，贴个广告。美团平台技术部-数据中心-数据智能组长期招聘数据挖掘算法、大数据系统开发、Java后端开发人才。有兴趣的同学可以把简历发到lihangqiang#。