通过示例理解事件流处理的概念和意义

将数据组织为事件流这种思想在许多领域中都已得到应用，但不幸的是，人们有时会用不同的术语来表达这一思想，例如流处理（Stream Processing）、事件溯源（Event Sourcing）或复杂事件处理（Complex Event Processing - CEP）。 Martin Kleppmann 为读者解释了这一思想中的基本概念。

Kleppmann 是即将出版的《设计数据密集型应用》（Designing Data-Intensive Applications）一书的作者，他表示这些基本的思想概念中有许多是十分简单的，并且值得深入学习。这些思想能够帮助我们设计出具有更高的伸缩性、可靠性和可维护性的应用程序。

Kleppmann 以 Google Analytics 这一工具作为使用事件的一个示例，这个工具能够按照访问者对网站的页面访问次数进行跟踪。在这个工具中，每一次页面访问都会产生一个事件，其中包含的内容有页面的 URL、时间戳，以及客户端 IP 地址等等，这对于用户量庞大的流行网站来说可能会造成数量巨大的事件产生。从这些事件中收集该网站的使用情况有两种选择，这两种选择都具有实用性，但各自适应于不同的场合：

• 将所有的数据保存在某种类型的数据存储系统中，然后使用某种查询语言对 URL、时间段等信息进行分组，并在需要时进行数据的聚合。使用这种技术的一个优点在于，可以对旧的数据采用新的计算方式。
• 在事件到来时，直接对 URL、时间等信息进行聚合，而不是在诸如 OLAP cube 等系统中保存事件本身，这种方式的一个优点在于能够进行实时决策，例如对某个特定客户端限制它的访问次数。

事件溯源也是一种类似的思想，它是由领域驱动设计（DDD）社区所提出的。这方面的一个常见例子就是电子商务网站中的购物车。这种思想是不对当前的购物车状态进行改变和保存，而是将每个改变了购物车状态的事件保存下来。这种事件可以是 _ItemAdded_ 和 _ItemQuantityChanged_。通过对事件进行重演、或是将它们进行聚合，可以重现购物车的当前状态。Kleppmann 表示，这一思想与 Google Analytics 的示例非常相似。

对于 Kleppmann 来说，事件是保存数据的一种理想的方式，所有的信息都作为一个单独的 blog，通过添加的方式进行保存，这就避免了对多个表进行更新的需求。他也认为，对于从数据存储系统中读取数据来说，对数据进行聚合是一种理想的方式，因为用户感兴趣的通常都是当前的状态。以用户界面举例，用户对某个按钮的单击行为对应着一个事件，而对页面的请求则表现为通过某个聚合展现当前的状态。Kleppmann 在他的示例中还衍生出一个模式：原始的输入事件是不可变的事实，它易于保存，并且具有真实性。聚合就是源自于这些原始事件的，并且在新的事件到来后会进行缓存和更新。在必要的时候，可以将所有事件进行重演，以重建所有的聚合。

转而使用类似于事件溯源一类的方式，就意味着要远离传统的由数据库保存当前状态的方式。Kleppmann 仍然坚持采用这种方式的原因包括以下方面：

• 由于将写入与读取的 schema 进行分离，因此可以实现松耦合。
• 分离的 schema 意味着可以对读取与写入操作进行独立的优化，这就能够提升性能，还可以避免规格化（与反规格化）方面的争论。
• 在创建聚合时，如果要尝试新的算法，可以简单地放弃或取代旧的算法，这方面具有高度的灵活性。
• 在对事件进行重演时如果发生异常，易于处理出错的场景，及发现它背后的原因。

各种 Actor 框架，例如 Akka 、 Orleans 和 Erlang OTP 等等都是构建在不可变事件流的基础上的，但 Kleppmann 指出，设计这些框架的主要目的是作为一种处理并行任务的机制，而不是用于数据管理的。

查看英文原文： Making Sense of Event Stream Processing