Flink cep动态模板+cep规则动态修改实践

私信之前请一键三连，请给一点动力！谢谢

目录

Flink CEP 概念以及使用场景

1.什么是CEP？

2.Flink CEP 应用场景

3.Flink CEP 原理（只做简单了解）

规则条件遵循参考

简单规则：

相对复杂规则：

CEP支持的模式

个体模式

模式序列

groovy+aviator的介绍

groovy是什么？

Aviator是什么？

groovy+aviator+cep的整合使用

正常cep代码开发流程

cep动态模板

cep动态模板+动态规则修改

运行演示

集群运行效果

具体代码

flink_cep_groovy_aviator项目

flink_cep_groovy_aviator2项目

相关代码

参考文章

最后

---

Flink CEP 概念以及使用场景

1.什么是CEP？

   CEP的意思是复杂事件处理，例如：起床-->洗漱-->吃饭-->上班等一系列串联起来的事件流形成的模式称为 CEP。如果发现某一次起床后没有刷牙洗脸亦或是吃饭就直接上班，就可以把这种非正常的事件流匹配出来进行分析，看看今天是不是起晚了。

     在真实场景中，起床，洗漱，吃饭，上班就是一个个事件数据。
CEP的特征如下：
      目标：从有序的简单事件流中发现一些高阶特征；
      输入：一个或多个简单事件构成的事件流；
      处理：识别简单事件之间的内在联系，多个符合一定规则的简单事件构成复杂事件；
      输出：满足规则的复杂事件。

下图中列出了几个例子，三个场景：

• 第一个是异常行为检测的例子：假设车辆维修的场景中，当一辆车出现故障时，这辆车会被送往维修点维修，然后被重新投放到市场运行。如果这辆车被投放到市场之后还未被使用就又被报障了，那么就有可能之前的维修是无效的。
• 第二个是策略营销的例子：假设打车的场景中，用户在 APP 上规划了一个行程订单，如果这个行程在下单之后超过一定的时间还没有被司机接单的话，那么就需要将这个订单输出到下游做相关的策略调整。 
• 第三个是运维监控的例子：通常运维会监控服务器的 CPU、网络 IO 等指标超过阈值时产生相应的告警。但是在实际使用中，后台服务的重启、网络抖动等情况都会造成瞬间的流量毛刺，对非关键链路可以忽略这些毛刺而只对频繁发生的异常进行告警以减少误报。

2.Flink CEP 应用场景

• 风险控制：对用户异常行为模式进行实时检测，当一个用户发生了不该发生的行为，判定这个用户是不是有违规操作的嫌疑。
• 策略营销：用预先定义好的规则对用户的行为轨迹进行实时跟踪，对行为轨迹匹配预定义规则的用户实时发送相应策略的推广。
• 运维监控：灵活配置多指标、多依赖来实现更复杂的监控模式。

3.Flink CEP 原理（只做简单了解）

• Flink CEP内部是用NFA（非确定有限自动机）来实现的，由点和边组成的一个状态图，以一个初始状态作为起点，经过一系列的中间状态，达到终态。点分为起始状态、中间状态、最终状态三种，边分为 take、ignore、proceed 三种。 

• take：必须存在一个条件判断，当到来的消息满足 take 边条件判断时，把这个消息放入结果集，将状态转移到下一状态。

• ignore：当消息到来时，可以忽略这个消息，将状态自旋在当前不变，是一个自己到自己的状态转移。 

• proceed：又叫做状态的空转移，当前状态可以不依赖于消息到来而直接转移到下一状态。举个例子，当用户购买商品时，如果购买前有一个咨询客服的行为，需要把咨询客服行为和购买行为两个消息一起放到结果集中向下游输出；如果购买前没有咨询客服的行为，只需把购买行为放到结果集中向下游输出就可以了。 也就是说，如果有咨询客服的行为，就存在咨询客服状态的上的消息保存，如果没有咨询客服的行为，就不存在咨询客服状态的上的消息保存，咨询客服状态是由一条 proceed 边和下游的购买状态相连。

下面以一个打车的例子来展示状态是如何流转的，规则见下图所示。

    以乘客制定行程作为开始，匹配乘客的下单事件，如果这个订单超时还没有被司机接单的话，就把行程事件和下单事件作为结果集往下游输出。

假如消息到来顺序为：行程-->其他-->下单-->其他。

状态流转如下：

1）开始时状态处于行程状态，即等待用户制定行程。 

2）当收到行程事件时，匹配行程状态的条件，把行程事件放到结果集中，通过 take 边将状态往下转移到下单状态。 

3）由于下单状态上有一条 ignore 边，所以可以忽略收到的其他事件，直到收到下单事件时将其匹配，放入结果集中，并且将当前状态往下转移到超时未接单状态。这时候结果集当中有两个事件：制定行程事件和下单事件。