最近，在寻找用于实时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 ）的嵌入式分析引擎处理数据库）。