flink 复杂事件
这篇博客文章试图总结CEP领域中的技术，并介绍它们的主要功能和不足。
有时似乎过度使用了CEP一词（就像'ESB'一样），下面的内容反映了我们对它的理解和理解。
ESPER（ http://esper.codehaus.org/ ）是流行的开源组件，可用于Java的复杂事件处理（CEP）。 它包括对基于滑动时间或长度窗口的模式匹配和流处理的丰富支持。 尽管对“ CEP”一词进行了激烈的讨论（ http://www.dbms2.com/2011/08/25/renaming-cep-or-not /），但ESPER似乎非常适合CEP术语，因为借助ESPER的EPL（事件处理语言），它似乎能够从一系列简单事件中真正识别出“复杂事件”。
最近，在寻找用于实时CEP的开源解决方案时，我们的小组偶然发现了Twitter的Storm项目（ https://github.com/nathanmarz/storm ）。
它声称与Yahoo的S4最具有可比性，并且与Esper和Streambase等“复杂事件处理”系统处于同一空间。
我不确定Streambase，但是更深入地研究Storm项目使它看起来与CEP和ESPER解决方案大不相同。
与S4同上（ http://incubator.apache.org/s4/ ）。
尽管S4和Storm似乎擅长于分布式模式下的实时流处理，并且它们看上去（如他们声称的那样）是“实时Hadoop”，但它们似乎没有提供匹配模式的规定（因此表示复杂事件）。
搜索（我们的研究可能与之相关的）CEP定义导致以下项目符号（ http://colinclark.sys-con.com/node/1985400 ），其中包括以下四个作为系统/解决方案的先决条件被称为CEP组件/项目/解决方案：
- 领域特定语言
- 连续查询
- 时间或长度窗口
- 时间模式匹配
在当前版本的S4和Storm项目中，似乎缺少完全支持时间/长度窗口和时间模式匹配的连续查询。
可能是由于它们的婴儿期，他们将来会逐渐成熟以包含这些功能。
到目前为止，它们似乎只适合预处理事件流，然后再将其传递给ESPER等CEP引擎。
他们的分布式处理能力（la map-reduce模式）可以帮助加快预处理速度，在此情况下，可以过滤事件，或者通过一些查找/计算等来丰富事件。还进行了一些尝试，将Storm与Esper集成（ http://tomdzk.wordpress.com/2011/09/28/storm-esper/ ）。
虽然像S4和Storm这样的处理系统缺少CEP的重要功能，但基于ESPER的系统具有受内存限制的缺点。 事件太多或时间窗口过长可能会导致ESPER内存不足。 如果使用ESPER处理实时流（例如来自社交媒体的实时流），则ESPER内存中将积累大量数据。 总体而言，问题陈述是为大数据发明CEP解决方案。 在更好的层面上，问题陈述包括设计CEP解决方案，以处理机载（批处理）和飞行中（实时）数据。
用DarkStar的术语（ http://www.eventprocessing-communityofpractice.org/EPS-presentations/Clark_EP.pdf ），要求是“实时匹配注册的模式，在数据库中发现类似的模式”。 由于受内存限制是一个限制，因此，如果可以找到某种凝聚内存事件的机制，可能会很有用。 但是，压缩后的数据仍然应该有意义，并保留原始流的上下文。
DarkStar使用符号聚合近似值（ http://www.cs.ucr.edu/~eamonn/SAX.htm ）进行此操作，他们声称通过将SAX与AsterData的nCluster一起使用来满足上述要求，nCluster是mpp（大规模并行）使用基于SQL / MapReduce（ http://www.asterdata.com/resources/mapreduce.php ）的嵌入式分析引擎处理数据库）。
待续（随着我们的进一步研究）…
翻译自: https://www.javacodegeeks.com/2012/03/complex-event-world.html
flink 复杂事件
已为社区贡献60条内容
所有评论(0)