一、 什么是Flink SQL CEP
CEP即Complex Event Processing复杂事件处理，它可以让你在无限事件流中检测出特定的事件模型。新版本的SQL标准支持在SQL中的模式识别（Row Pattern Recognition in SQL），它允许Flink使用MATCH_RECOGNIZE子句融合CEP和SQL API，以便在SQL中进行复杂事件处理。
二、应用场景目标：从有序的简单事件流中发现一些高阶特征 输入：一个或多个简单事件构成的事件流 处理：识别简单事件之间的内在联系，多个符合一定规则的简单事件构成复杂事件 输出：满足规则的复杂事件
三、SQL语义CEP处理： 每个 MATCH_RECOGNIZE 查询都包含以下子句：
PARTITION BY - 定义表的逻辑分区；类似于 GROUP BY 操作。 ORDER BY - 指定传入行的排序方式；这是必须的，因为模式依赖于顺序。 MEASURES - 定义子句的输出；类似于 SELECT 子句。 ONE ROW PER MATCH - 输出方式，定义每个匹配项应产生多少行。对于SQL API只支持ONE ROW PER MATCH，对于Stream API还支持ALL ROWS PER MATCH。 AFTER MATCH SKIP - 指定下一个匹配的开始位置；这也是控制单个事件可以属于多少个不同匹配项的方法。 PATTERN - 允许使用类似于 正则表达式 的语法构造搜索的模式。 DEFINE - 本部分定义了模式变量必须满足的条件。注意 目前，MATCH_RECOGNIZE 子句只能应用于追加表。此外，它也总是生成一个追加表。
四、进阶 4.1、贪婪量词和勉强量词每一个量词可以是 贪婪（默认行为）的或者 勉强 的。贪婪的量词尝试匹配尽可能多的行，而勉强的量词则尝试匹配尽可能少的行。
在SQL API里有以下语法规则： 所谓的贪婪就是*和+，所谓的勉强就是? 例如：
PATTERN (A B* C) WITHIN INTERVAL '2' MINUTE DEFINE A AS A.num>10, B AS B.num<15, C AS C.num>12其中事件B的匹配是贪婪的，数据集为： 输出结果为： 贪婪匹配的结果是，B事件会尽力匹配更多的行，因此所有小于15的都被判断为B事件了，即12，13，14均为B事件。那么相应勉强匹配是：
PATTERN (A B*? C) WITHIN INTERVAL '2' MINUTE DEFINE A AS A.num>10, B AS B.num<15, C AS C.num>12对应的输出结果为：
4.2、严格近邻和宽松近邻前面提到，像 (A B) 这样的模式意味着 A 和 B 之间的连接是严格的。因此，在它们之间不能存在没有映射到 A 或 B 的行，也就是说这样的模式是严格近邻的。其实在CEP Stream API里，是支持不连续的，也就是宽松近邻，如图所示： 在SQL里是没有宽松近邻概念的，模式种的事件必须严格按照顺序排布。那么SQL就没有办法处理宽松近邻场景了吗？答案是否定的，我们可以通过中间事件结合贪婪量词实现。事实上在上面的例子种已经涉及，即：
PATTERN (A B* C) WITHIN INTERVAL '2' MINUTE DEFINE A AS A.num>10, B AS B.num<15, C AS C.num>12 4.3 循环匹配假设在宽松近邻场景下，有以下数据集合： 可以结合AFTER MATCH跳转语法实现 使用SKIP TO NEXT ROW，可以在匹配了一个模式后，继续匹配项的第一个成员的下一行开始匹配，也就是循环匹配。
ONE ROW PER MATCH AFTER MATCH SKIP TO NEXT ROW PATTERN (A X* C) WITHIN INTERVAL '2' MINUTE DEFINE A AS A.num<3, C AS C.num>7, X AS NOT X.num>7测试数据集： 输出结果：
五、遗留问题通过SKIP TO NEXT ROW实现了循环匹配，但是却无法对结尾事件做循环匹配，因为语法不支持在结尾事件中使用贪婪或勉强量词。即无法应对这样的场景： 这种场景是否有解决方案呢？当你遇到了这种场景，首先思考应该是否真的存在？也许可以通过合理的规则制订避免，如果实在无法避免，这可能就是CEP无法解决的组合。
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
