Scala Flink Core和Flink CEP在性能方面有什么不同？

在过去几天研究Flink CEP库时，我一直认为它没有为Flink的标准功能添加任何新的基本功能。Flink CEP的唯一目的似乎是通过清晰的语义和直观的代码结构简化事件处理。作为一个例子，Flink CEP只显示了事件匹配跳过的情况。尽管这些语义对于很多情况来说可能已经足够了，但它可能无法解决特定的问题，这让我们回到了普通的Flink

测试用例是以下模式：

Emmit流中每对非重叠数字的警报（用“a”表示）

由模式表示：

Pattern.begin[EventType]（“pair”，skipStrategy）.where（新的AlwaysTrueFunction（））.times（2）

因此，对于像（从流上从左到右输入的数字）

1

这样的输入，预期输出将是

a

，但5种跳过匹配策略都不会给出正确的结果：

No-skip: a a a a
Skip-to-next: a a a a
Skip-past-last-event: a a a a
Skip-to-first[1]: a a a a
Skip-to-last[1]: a a a a

尽管这些策略无法生成所需的模式，但可以使用带有

ValueState

计数器的

RichFunction

轻松生成该模式，以确定何时应发出新警报，从而在事件流中转换输入流

因此，我希望对这些问题有所了解：

• 如果Flink看起来更完整，为什么要创建CEP库

• 与使用Flink标准数据流操作符制作的模式相比，使用CEP制作的模式更高效（更高的吞吐量/其他指标）（如果可能，提供有关这方面的文章/论文/文档的一些链接）

---

感谢您与Flink CEP合作
Flink CEP是Flink之上的一个库。因此，它不会添加任何不能使用vanilla Flink（ProcessFunctions等）实现的功能。事实上，在引擎盖下，它是作为一个特殊的操作员来实现的，他正在检查与特定模式匹配的元素，它的许多功能甚至可能被实现为一个ProcessFunction（有很多工具）
也就是说，Flink CEP可能不会添加不能用vanilla Flink实现的功能，但它增加了表达能力，这使得一些用例更容易实现。其他API也是如此，例如Flink中的Windowing API，您可以使用ProcessFunctions（使用大量工具）实现它

---

现在说到效率，答案是“视情况而定”。手工制作一个特殊的过程函数，根据您的用例进行定制，并对您的工作负载进行所有可能的优化，这比FlinkCEP更有效，因为后者是一个通用库。如果您有专业知识和时间，那么最佳解决方案将始终是同时使用CEP和vanilla Flink实现POC，并为您的案例选择最有效的方法。
谢谢您的回答，这正是我所想的。今天我终于找到了，这与我对Flink CEP的印象是一致的。