FlinkCEP Flink复杂事件处理
FlinkCEP是在Flink之上实现的复杂事件处理(CEP)库。
它允许您在无穷无尽的事件流中检测事件模式,使您有机会掌握数据中什么是重要的。
它可以用于处理实时数据并在事件流到达时从事件流中提取信息,并根据定义的规则来判断事件是否匹配,如果匹配则会触发新的事件做出响应。
除了支持单个事件的简单无状态的模式匹配(例如基于事件中的某个字段进行筛选过滤),也可以支持基于关联/聚合/时间窗口等多个事件的复杂有状态模式的匹配(例如判断用户下单事件后 30 分钟内是否有支付事件)。
关注博主不迷路,获取更多干货资源
1 FlinkCEP概述
1.1 官网
https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/libs/cep.html
1.2 FlinkCEP是什么
Complex Event Processing(CEP)是 Flink 提供的一个非常亮眼的功能,是Flink提供的复杂事件处理(CEP)库,使用它可以在无界的事件流中检测事件模式,让我们可以掌握数据中重要的事项。并允许指定要在流中检测的模式,然后检测匹配事件序列并对其进行操作。
复杂事件处理实际上就是基于事件流进行数据处理,把要分析的数据抽象成事件,然后将数据发送到CEP引擎,得到事件处理结果。
说到底,Flink 的 CEP 到底解决了什么样的问题呢?
在我们的实际生产中,随着数据的实时性要求越来越高,实时数据的量也在不断膨胀,在某些业务场景中需要根据连续的实时数据,发现其中有价值的那些事件。
比如,我们需要在大量的订单交易中发现那些虚假交易,在网站的访问日志中寻找那些使用脚本或者工具“爆破”登录的用户,或者在快递运输中发现那些滞留很久没有签收的包裹等。
Flink 对 CEP 的支持非常友好,并且支持复杂度非常高的模式匹配,其吞吐和延迟都令人满意。
CEP可以简单理解为:
一个或多个由简单事件构成的事件流通过一定的规则匹配,然后输出用户想得到,满足规则的复杂事件/数据。
1.3 FlinkCEP使用场景
Flink CEP应用于实时数据流的业务场景,可以应用于规则匹配,数据监控,实时预警、异常行为监测、风控等业务范围,具体有如下应用场景:
1 |
|
下面是一些具体详细的例子
1.风险控制:
对用户异常行为模式进行实时检测,当一个用户发生了不该发生的行为,判定这个用户是不是有违规操作的嫌疑。
假设车辆维修的场景中,当一辆车出现故障时,这辆车会被送往维修点维修,然后被重新投放到市场运行。如果这辆车被投放到市场之后还未被使用就又被报障了,那么就有可能之前的维修是无效的。
对于电商来说,羊毛党是必不可少的,国内拼多多曾爆出 100 元的无门槛券随便领,当晚被人褥几百亿,对于这种情况肯定是没有做好及时的风控。另外还有就是商家上架商品时通过频繁修改商品的名称和滥用标题来提高搜索关键字的排名、批量注册一批机器账号快速刷单来提高商品的销售量等作弊行为,各种各样的作弊手法也是需要不断的去制定规则去匹配这种行为。
2.策略营销:
用预先定义好的规则对用户的行为轨迹进行实时跟踪,对行为轨迹匹配预定义规则的用户实时发送相应策略的推广。
假设打车的场景中,用户在 APP 上规划了一个行程订单,如果这个行程在下单之后超过一定的时间还没有被司机接单的话,那么就需要将这个订单输出到下游做相关的策略调整。
分析用户在手机 APP 的实时行为,统计用户的活动周期,通过为用户画像来给用户进行推荐。比如用户在登录 APP 后 1 分钟内只浏览了商品没有下单;用户在浏览一个商品后,3 分钟内又去查看其他同类的商品,进行比价行为;用户商品下单后 1 分钟内是否支付了该订单。如果这些数据都可以很好的利用起来,那么就可以给用户推荐浏览过的类似商品,这样可以大大提高购买率。
3.运维监控:
灵活配置多指标、多依赖来实现更复杂的监控模式。
通常运维会监控服务器的 CPU、网络 IO 等指标超过阈值时产生相应的告警。但是在实际使用中,后台服务的重启、网络抖动等情况都会造成瞬间的流量毛刺,对非关键链路可以忽略这些毛刺而只对频繁发生的异常进行告警以减少误报。
4.实时网络攻击检测
当下互联网安全形势仍然严峻,网络攻击屡见不鲜且花样众多,这里我们以 DDOS(分布式拒绝服务攻击)产生的流入流量来作为遭受攻击的判断依据。对网络遭受的潜在攻击进行实时检测并给出预警,云服务厂商的多个数据中心会定时向监控中心上报其瞬时流量,如果流量在预设的正常范围内则认为是正常现象,不做任何操作;如果某数据中心在 10 秒内连续 5 次上报的流量超过正常范围的阈值,则触发一条警告的事件;如果某数据中心 30 秒内连续出现 30 次上报的流量超过正常范围的阈值,则触发严重的告警。
1.4 FlinkCEP优缺点
Flink的CEP是基于Flink Runtime构建的实时数据规则引擎,擅长解决跨事件的匹配问题, 是一套极具通用性、易于使用的实时流式事件处理方案。
Flink CEP可以用于分析低延迟、频繁产生的不同来源的事件流。 CEP 可以帮助在复杂的、不相关的事件流中找出有意义的模式和复杂的关系,以接近实时或准实时的获得通知并阻止一些行为。
Flink CEP支持在流 上进行模式匹配,根据模式的条件不同,分为连续的条件或不连续的条件;模式的条件允许有时间的限制,当在条件范围内没有达到满足的条件时,会导致模式匹配超时。
优势:
继承了 Flink 高吞吐的特点
查询是静态的,数据是动态的,满足实现和连续查询的需求
擅长解决跨事件的匹配
API友好
劣势:
本身无法做的直接动态更新规则(痛点),需要借助其他技术才可以动态注入或更新规则
2 FlinkCEP原理
2.1 NFA
Apache Flink在实现CEP时借鉴了Efficient Pattern Matching over Event Streams中NFA的模型
在这篇论文中,提到了NFA,也就是Non-determined Finite Automaton,叫做不确定的有限状态机,指的是状态有限,但是每个状态可能被转换成多个状态(不确定)。
2.2 状态和转换
先理解两个概念:
状态
:状态分为三类,起始状态、中间状态和最终状态转换
:take/ignore/proceed都是转换的名称
在这NFA匹配规则里,本质上是一个状态转换的过程。
Flink CEP 内部是用 NFA(非确定有限自动机)来实现的,由点和边组成的一个状态图,以一个初始状态作为起点,经过一系列的中间状态,达到终态。
点分为
起始状态
、中间状态
、最终状态
三种,
边分为
take
、ignore
、proceed
三种。
take
:必须存在一个条件判断,当到来的消息满足 take 边条件判断时,把这个消息放入结果集,将状态转移到下一状态。ignore
:当消息到来时,可以忽略这个消息,将状态自旋在当前不变,是一个自己到自己的状态转移。proceed
:又叫做状态的空转移,当前状态可以不依赖于消息到来而直接转移到下一状态。举个例子,当用户购买商品时,如果购买前有一个咨询客服的行为,需要把咨询客服行为和购买行为两个消息一起放到结果集中向下游输出;如果购买前没有咨询客服的行为,只需把购买行为放到结果集中向下游输出就可以了。 也就是说,如果有咨询客服的行为,就存在咨询客服状态的上的消息保存,如果没有咨询客服的行为,就不存在咨询客服状态的上的消息保存,咨询客服状态是由一条 proceed 边和下游的购买状态相连。
2.3 CEP规则解析
我们以一个简单的CEP规则为例,看看在NFA中,这些事件之间是什么样的关系。
1 |
|
上述代码描述的是start/middle/end之间的关系且每个事件满足的条件,其中,middle要在start之后,end要在middle之后;三者之间并不需要严格邻近,其中middle是可有可无的(optional),用NFA的结构来描述他们就是下面这张图:
现在让我们假设一条只有四个元素的数据流:
1 |
|
收到start,满足条件,进行Take转换,当前状态转为middle。
收到xx,不满足条件,当前状态转为middle:0;因为有Proceed存在,当前状态转为end,但也不满足条件,所以丢弃这条转换。
收到middle,对于middle:0满足条件(Take)转换为end;对于end,不满足条件(Ignore),转换为自身。
收到end,满足条件(Take),转换为$end$,结束匹配。
2.4 状态转换流程
下面以一个打车的例子来展示状态是如何流转的,规则见下图所示。
以乘客制定行程作为开始,匹配乘客的下单事件,如果这个订单超时还没有被司机接单的话,就把行程事件和下单事件作为结果集往下游输出。
假如消息到来顺序为:行程–>其他–>下单–>其他。
状态流转如下:
1.开始时状态处于行程状态,即等待用户制定行程。
2.当收到行程事件时,匹配行程状态的条件,把行程事件放到结果集中,通过 take 边将状态往下转移到下单状态。
3.由于下单状态上有一条 ignore 边,所以可以忽略收到的其他事件,直到收到下单事件时将其匹配,放入结果集中,并且将当前状态往下转移到超时未接单状态。
这时候结果集当中有两个事件:制定行程事件和下单事件。
4.超时未接单状态时,如果来了一些其他事件,同样可以被 ignore 边忽略,直到超时事件的触发,将状态往下转移到最终状态,这时候整个模式匹配成功,最终将结果集中的制定行程事件和下单事件输出到下游。
上面是一个匹配成功的例子,如果是不成功的例子会怎么样?
假如当状态处于超时未接单状态时,收到了一个接单事件,那么就不符合超时未被接单的触发条件,此时整个模式匹配失败,之前放入结果集中的行程事件和下单事件会被清理。
3 FlinkCEP案例
3.1 准备工作
3.1.1 FlinkCEP在流处理中的位置
CEP处于如下位置:
1.目标:从有序的简单事件流中发现一些规则特征
2.输入:一个或多个由简单事件构成的事件流
3.处理:识别简单事件之间的内在联系,多个符合一定规则的简单事件构成复杂事件
4.输出:满足规则的复杂事件
3.1.2 FlinkCEP编码步骤
https://ci.apache.org/projects/flink/flink-docs-release-1.12/dev/libs/cep.html
3.1.3 FlinkCEP代码的完整构成
上图中,蓝色方框代表的是一个个单独的模式;浅黄色的椭圆代表的是这个模式上可以添加的属性,包括模式可以发生的循环次数,或者这个模式是贪婪的还是可选的;橘色的椭圆代表的是模式间的关系,定义了多个模式之间是怎么样串联起来的。
通过定义模式,添加相应的属性,将多个模式串联起来三步,就可以构成了一个完整的 Flink CEP 程序。
总结
3.2 案例1:量词
1 |
|
3.3 案例2:条件
1 |
|
3.4 案例3:组合
1 |
|
3.5 案例4:连续和允许组合
1 |
|
3.6 案例5:恶意搜索用户胡别
1 |
|
3.7 案例6:高频交易风险用户识别
1 |
|
3.8 案例7:订单超时监控
1 |
|
3.9 案例8:监控市场价格
1 |
|
3.10 案例9:运维监控规则引擎
1 |
|
关注博主不迷路
本博客所有文章除特别声明外,均为原创。版权归博主小马所有。任何团体、机构、媒体、网站、公众号及个人不得转载。如需转载,请联系博主(关于页面)。如其他团体、机构、媒体、网站、博客或个人未经博主允许擅自转载使用,请自负版权等法律责任!