有些人可能想知道为什么有两种事件处理方式:事件流处理(ESP)和复杂事件处理(CEP)。这篇文章的最初版本是我在13年前写的。当然，ESP工具也随着时间的推移而改变。

2006年的一天，一位罗伯特·米切尔先生打电话给我，要我写一篇有关ESP for ComputerWorld的文章。他想问几个问题作为他主要文章的补充。我们谈了一个小时。一个星期后，我的一个通讯员给我发了两个电脑世界的链接。我读到的并不是我想说的。说句公道话，米切尔先生很难在一篇400字的文章和另一篇200字的文章中捕捉到一小时谈话的真正内容。然而，米切尔先生的问题肯定是相关的，所以我写了一个更完整的版本，我的答案当时。

我在2019年又读了这篇文章，因为它是CEP网站上阅读人数最多的文章之一。在与我的同事罗伊·舒尔特(Roy Schulte)一起重读这本书时，它似乎一点也不过时。ESP在2006年取得了预期的进展。因此，我决定更新这篇文章并重新发布。最后，再次感谢Mitchell先生激发我完成了2006年的文章!

CEP被设计用来解决什么问题?

CEP是1989年至1995年在斯坦福大学开发的，用于分析分布式系统架构的事件驱动模拟。那是25年前的事了!事情是这样发生的。

我们首先设计了一种新的事件驱动建模和仿真语言Rapide，用于在分布式事件驱动系统中建模事件活动。分布式系统中的事件可以彼此独立地发生;它们可以在同一时间或不同时间发生;或者它们可以依次发生，一个导致另一个。因此，Rapide不仅要模拟事件发生的时间，还要模拟它们的因果关系或独立性。不仅如此，我们还需要能够为多层架构建模。因此Rapide必须捕获事件级别，并在不同级别的事件之间建立时间和成员关系。我们的第一个目标是一个新的芯片的硬件设计，包括三个层次，指令集层，寄存器传输层和硬件门级。这种层次结构在硬件设计中是标准的，并且很好地理解了如何定义不同级别的事件之间的关系。

随着新的目标体系结构的出现，我们需要对动态体系结构建模，例如空中交通控制系统，其中组件(例如飞机)可以进入或离开系统，或者组件之间的事件通信可以随时间变化。硬件系统的典型例子是SUN Sparc CPU设计的版本，而软件系统的例子包括军事指挥和控制系统，如宙斯盾巡洋舰雷达控制体系结构，在民用方面，电信协议，自动化机器人制造系统，电子市场，和空中交通管制。

当您模拟一个用Rapide编写的模型时，您得到的输出并不是由事件驱动的模拟器(如Verilog或VHDL)生成的通常的按时间顺序排列的事件流。您得到了一个事件云，在三维空间中按时间和因果关系部分排序，即在每个设计级别(抽象级别)内水平排列，以及在各个级别之间垂直排列。这种部分有序的事件云称为poset(部分有序的事件集)。

此外，我们开发了一套事件处理原则和技术，用于分析posets，以了解在模拟中发生了什么。事件层次结构的构造是比较复杂的CEP分析技术之一。需要捕获的错误可能包括从低级硬件设计中的错误pin连接，到高级分布式通信进程之间的不正确同步，或者违反关键的设计约束。通过事件模式快速定义设计约束。我们将我们的原则和技术集称为复杂事件处理(CEP)。我们建立了一套基于CEP的分析工具来帮助分析posets。这包括posets的图形表示、用于在模拟输出中实时检测事件模式匹配的模式匹配器以及用于定义事件层次结构以支持高级分析的工具。

到1995年，发表了几篇关于Rapide语言、模拟器和CEP分析工具的论文。该系统在斯坦福大学免费提供，并已在全球范围内下载，供研究人员用于分析各种系统，包括制造业和电信行业的标准。我们已经准备好投入商业运作。但是，进入销售一种新的计算机语言的游戏总是很困难的。我已经在斯坦福Ada编译器和1980年Rational软件的创建中经历过了。在我看来，似乎还有另一条路。您可以应用CEP工具来分析在任何类型的事件驱动系统中创建的事件。因此，我们将分析工具从模拟器中分离出来，并开始将它们应用于当时已经成熟的面向消息的商业中间件。在任何基于事件的实时系统中，CEP工具集就是这样开发的，用于分析事件到达时(即它们“处于运动状态”时)的事件。CEP允许您将系统的设计约束定义为事件模式，并实时监视系统的输出是否违反了这些约束。此外，您可以在多层系统的每一层都这样做。

ESP与CEP有何不同?

差异来自于你正在处理的问题。如果你的问题涉及到分析一系列事件，那么你可以使用ESP;另一方面，如果您需要分析事件云，那么您可以使用CEP。这有点简单，让我们更详细地讨论一下。

首先，ESP正在发展。最初，ESP的起源是不同的。在开发CEP的同时，还进行了实时事件数据分析方面的平行研究。这始于20世纪90年代中期，当时数据库社区意识到数据库太慢，无法进行实时数据分析。他们开始研究在传入数据流上运行连续查询的想法。他们使用滑动时间窗口来加快查询速度。查询的答案只对当前时间窗口中的事件有效，但是随着窗口随着时间向前滑动，答案也被更新为包含新事件并排除旧事件。这项研究被称为数据流管理(DSM)，并导致了当今的事件流处理世界。重点是实时处理大量事件中的数据。有趣的是，自20世纪90年代以来，数据库变得更快了，但与此同时，事件的数量也增加了，因此现代数据库仍然不能总是跟上当前的事件流输入。现在有超过40个商业和开源ESP产品，为实时事件流处理提供简单的分析，请参阅ESP趋势。

其次，流和云之间有一个根本的区别。事件流是按时间顺序排列的事件序列，例如股票市场订阅源。事件云是在IT系统的不同位置发生的许多事件生成活动的结果。一朵云可能包含许多溪流。流是云的一种特殊情况。但是假设您正在按照事件到达的顺序处理事件流是有好处的。它允许您设计用于处理事件中的数据的算法，这些事件使用很少的内存，因为它们不需要记住很多事件。ESP算法可以非常快。它们在到达时对流中的事件进行计算，将结果传递给下一个计算并忘记这些事件。然而,最近一些ESP系统现在有能力处理非常简单的情况下的无序事件处理的基础上,事件时间(事件发生时,根据事件的时间戳)而不是处理时间(特别是软件执行时计算,这可能是当事件到达)。这种处理无序事件的能力从2015年开始出现在某些ESP产品中。因此，这种现代ESP系统与最早的CEP研究有一些相似之处。

另一方面，如果您使用CEP处理云，则不能假定事件以良好的顺序到达。您需要处理事件时间，而不是处理时间。你可能会寻找一个模式实例的事件,说,a和B在一起导致C,但是当你运行搜索,实际上事件C之前到达你的观测点的或B,那么你必须记得C同时继续寻找一个a和B,导致它并将完成一个匹配的模式。事件A、B、C可以是管理协议中多个进程的操作和响应，这些进程应该同步并执行事务，但有时会失败。在找到表示已完成事务的事件之前，您可能必须记住许多事件。在这种情况下，关键是要知道哪些事件导致了哪些事件。这需要更多的内存和时间!它需要一个因果参考模型来说明事件是如何在被分析的系统中产生的。在事件到达时引用这个模型来检查A和B导致C的模式需要时间。从好的方面来说，您可以处理更丰富的问题集，不仅可以在传入事件级别处理事件数据，还可以处理业务流程管理中分层结构的流程集的正确或错误行为。

在事件驱动系统的CEP分析中使用事件层次结构是独特的。当模式匹配传入事件时，CEP分析器可能会创建新事件。这些新事件被视为比输入更高的级别。它们的目的通常是抽象表示在目标系统中发生了重要事件的输入事件模式。通过将事件模式分析应用于更高层的事件，CEP分析器可以创建事件层次结构，其中的高层包含的事件比低层输入更易于理解。例如，在分析门级芯片设计的模拟时，会创建数千个门级事件。例如，“一个来自32号门的输出信号被传送到64号门的输入端。”这个事件，以及模拟中的许多其他事件，可能被抽象到寄存器传输层，然后再抽象到指令层，最终导致创建一个更容易理解的事件，比如“添加指令完成”。这将告诉人类用户门级模拟是否按预期运行。

ESP更侧重于对事件流中的数据进行高速查询，并将数学算法应用于事件数据。最初的一些商业应用，如算法交易，与金融市场中的交易系统有关。CEP更关注于从企业IT和业务系统中创建的事件云中提取信息。CEP包括事件数据分析，但强调事件的模式，并对模式中的信息进行抽象和简化。其理念是支持尽可能广泛的企业管理决策领域。CEP的第一个商业应用是在业务活动监视（BAM)中，例如监视服务级别协议的一致性。

总之，ESP和CEP都是处理事件的方法。两者都会产生复杂的事件。乍一看，ESP是CEP的一个子集，两者的区别可以归结为特殊目的的事件处理与通用目的的区别，但这种区别现在不像过去那么明显了，我们将在下面看到这一点。

ESP和CEP产品的应用有何不同?

让我们从现在开始。大多数用ESP产品构建的应用程序似乎都关注于诸如count、sum、average、maximum、minimum、top-k或bottom-k这样的聚合。例如，它们可能被用来计算在一个时间窗口中某个主题的tweet的数量;或者在30秒的时间段内，通过多个传感器读数的平均值来报告机器的温度。这些基于聚合的事件层次结构比使用模式检测(通常与聚合结合)的原始CEP应用程序中的层次结构简单得多。通过适当的编程，ESP产品可以用于关联来自不同流的事件、检测缺席事件(在时间窗口内没有发生的事件)、搜索布尔组合(如a和B、a或B)，甚至检测更复杂的模式。但是它们不使用水平因果关系(同一抽象层上的事件A导致事件B)或独立性(A独立于B而发生)，这可能是因为当前用于ESP的商业应用程序集不用于诊断复杂的场景，通常不需要复杂的事件模式。

在很多问题领域，您需要查看的不仅仅是事件流中的数据。除了事件计时之外，您还需要检测哪些事件导致其他事件，以及哪些事件是独立发生的。在企业运营需要协调工作的任何领域都是如此。例如，当电子商务中的业务流程不同步时，就会发生一些愚蠢的事情。一个过程将一组产品放在降价销售，而另一个过程对相同的产品应用促销折扣，从而导致两次降低价格。要解决这个问题，仅仅发现某一产品的价格被两次下调是不够的。我们需要检测进程何时没有按照它们应该的方式进行通信。另一个例子是电子拍卖中的一组交易过程，它不计时，而不是匹配所需的买卖比例。我们需要找出他们在哪里偏离了预期的行为模式，而这个模式将是复杂的。当您遇到使企业操作保持在正确轨道上的这些问题时，您必须尽可能快地检测出事件不相关的情况，并对操作进行调整。这要求CEP检测表示问题的事件模式。

在未来，流处理工具的角色将如何演变?

ESP工具现在已经涉及到算法交易领域之外的应用程序，顺便说一下，它们的主要竞争对手是内部定制的编码系统。ESP系统的底层工程使其比定制编码系统更容易扩展。因此，对于那些无法提前预测事件处理需求将随时间增长和改变多少的客户来说，它们很有吸引力。此外，ESP产品提供了计算移动时间窗口的基础设施，否则就必须在自定义流处理应用程序中手动开发移动时间窗口。ESP的应用将变得更加复杂。当这种情况发生时，ESP将被扩展到包含越来越多的原始CEP元素。我曾与ESP技术人员讨论过这个问题，他们中的一些人当然知道如何在应用程序需要时将事件因果关系添加到其事件模式中。当然，当他们这样做时，所引用的一些重要事件处理吞吐量数字会减少一些。使用事件时间和处理无序处理的新兴ESP平台必然会产生比那些假定事件是有序的、然后在事件到达时立即从事件生成结果的平台具有更高延迟的结果。ESP(部分地)与CEP合并以使所有人受益。

脚注

在此上下文中，分层体系结构指的是抽象层，其中一个抽象层上的事件与事件层次结构中另一层上的事件相关。例如，网络中的数据包处于较低的抽象层。一组特定的信息包可以一起组成一条消息。消息是一个复杂事件，它的抽象级别高于作为复杂事件成员的包。信息包和消息之间的关系是垂直因果关系，因为信息包是在更高抽象级别上的事件(消息)的因果关系。信息包作为对等点与其他信息包相关联，并以不同于与其他消息相关联的方式进行操作。在这种情况下，垂直因果关系基于一种模式——所有与特定消息相关的包都可以关联，因为它们共享一个公共消息标识符。在计算和其他领域的许多地方都可以找到其他类型的抽象层。下面是一个具有垂直因果关系的事件层次结构的示例，它基于简单的聚合概念，而不是更复杂的模式概念。它以一组5个事件开始，这些事件报告发生在下午2点到3点之间的5个购买，构成报告层次结构中的最低层。五个购买事件被总结为一个复杂的事件，它记录了一个计数(5个购买)和sum(在下午2点到3点的时间窗口内发生的购买的总数)。购买事件是称为小时销售的复杂事件的成员。复杂事件位于更高的抽象层上，与成员事件相比，它将用于不同的目的，例如管理报告或警报，而成员事件可能保留以供后续的深入研究，以防有人需要了解某些业务目的的详细信息。这里的垂直因果关系是基于聚合计算而不是模式检测。在这个应用程序中没有横向因果关系(我们规定没有一个购买事件导致另一个购买事件)。

原文：https://complexevents.com/2019/07/15/whats-the-difference-between-esp-and-cep-2/

本文：jiagoushi.pro/node/983/

讨论：请加入知识星球或者微信圈子【首席架构师圈】