标签：mes   方便   判断   时序   就是   开头   好处   第三方   支持   

Flink CEP

CEP 复杂事件处理：

• 根据事件时间的时序关系和聚合关系定制检测规则,持续的从事件流中查询出符合需求的事件序列,分析后得到更复杂的复合事件。

  说明：

  1.CEP是支持事件乱序的,根据事件时间和WaterMark来判断数据的顺序。
  2.Spark内部没有集成CEP,但是有解决方案,可以集成第三方的类库实现类似CEP的功能。

• CEP的使用: 定义模式->在流上应用模式-> 获取流中匹配到的结果。

• CEP的好处:方便,可以处理乱序问题。

• CEP的缺点:内存,所有等待超时数据存在map中内存等到匹配,数据量大时不好,超时后从map取出放到测输出流中。

CEP对乱序的支持:

1. 事件时间 < Watermark的数据,才能去正常安心的匹配。

   因为基于watermark的机制,认为事件时间小于watermark的数据都到齐了,处理过不会再有人来横插一脚。

2. 实际中可能有迟到的数据 => 如果是迟到数据不参与匹配直接丢弃,实际上是丢到测输出流中。

模式:

1. 单例模式> 单例模式只接受一个事件,默认模式。

2. 循环模式> 循环模式可以接受多个事件,单例模式配合上量词‘times()‘也是循环模式。

   多次的时候一定要配合终止条件使用,否者会占用大量的内存。

3. 条件>

   • 迭代条件:基于前面已经被接受的事件的属性或者它们的一个子集的统计数据来决定是否接受时间序列的条件,通过Context。
   • 简单条件:决定是否接受一个事件只取决于事件自身的属性。继承于IterativeCondition迭代条件,重写了filter方法,返回一个FilterFunction类的filter抽象方法。
   • 组合条件:多个where条件为与的关系,OR为或的关系。
   • 停止条件:满足给定条件后不会再有事件被接受进入模式。用来终止循环模式的oneOrMore和timesOrMore。

4. 组合模式>多个模式组合在一起就是组合模式。

   • 组合模式的连续性:

     1. 严格连续:next("next"); 期望匹配事件中间无间隔。
     2. 松散连续:followedBy("followedBy"); 期望匹配事件中间可以有间隔。
     3. 非确定松散连续:followedByAny("followedBy"); 进一步的松散连续,允许忽略附加条件。

   • 附加条件

     1. 参照标准只能匹配一次。
     2. 事件是流式数据,任务WM之前的数据都已经处理过,只能匹配后面的数据。

   • 两种非:

     1. 不想事件后面直接跟着一个特定事件,使用‘notNext()‘。
     2. 不想某个特定的事件发生在两个事件之间的任何地方,使用‘notFollowBy()‘。
        说明：没有notFollowByAny,因为notFollowBy已经不松散连续了,并且notFollowBy不能 位于事件的最后。

     说明：循环模式也可以使用连续性。
     默认松散连续,量词后+‘.consecutive()‘严格连续, 量词后+‘.allowCombinations()‘非确定松散连续。

   • 循环模式的贪婪性:

     在组合模式下,某个事件同时满足两个模式,优先给贪婪的模式使用,而被贪婪模式使用的事件其他模式不可用。

     注:贪婪比非贪婪的结果要少,模式组不能设置为贪婪的。

   • 模式的可选性:使用‘optional()‘可以指定模式可选,有或没有都可以。

5. 模式组>如果希望量词使用于模式序列整体,需要使用模式组。

   • 超时数据:模式通过‘within‘加上窗口长度后,部分事件序列可能因为超过窗口长度而被认为是超时数据,超时数据并没有直接丢弃,而是放入到测输出流,可以通过获取测输出流来获取超时数据。

匹配后跳过策略:

• NO_SKIP:默认策略,保留所有数据不跳过。

• SKIP_TO_NEXT:丢弃相同开头的数据。

• SKIP_PAST_LAST_EVENT:丢弃除开始之外的结果,多个组之间要求开头不能相同。

• SKIP_TO_FIRST:指定名称的事件,只保留该事件的第一条结果,在它之前的数据丢掉,基准结果一同保留。

• SKIP_TO_LAST:指定名称的事件,只保留该事件的最后一条结果,在它之前的数据丢掉,基准结果一同保留。

  说明:跳过策略都必须满足附加条件,即参照标准只能匹配一次,在此基础上匹配跳过。

Flink SQL:

• Stream -> DynamicTable -> ContinueQuery -> DynamicTable -> Stream

• 动态表:是Flink的支持流数据的Table API 和 SQL的核心概念,与批处理数据的静态表不同,动态表数据是随时间变化的。

• 连续查询:查询动态表将生成连续查询,连续查询永远不会终止,查询的结果会生成一个动态表,以反映动态表的更改。
  说明:连续查询的结果在语义上总是等价于以批处理模式在输入表快照上执行的相同查询的结果。

• TableAPI:依赖于planner解析器,Kafka使用Blibk就行,而ES必须要使用官方的不带Blink的解析器。

  ***说明：Hive使用antlr4来实现SQL查询。

Flink CEP

标签：mes   方便   判断   时序   就是   开头   好处   第三方   支持   

原文地址：https://www.cnblogs.com/yuexiuping/p/14838391.html