事件流处理：数据仓库的可伸缩替代品

Dan Pritchett 在博客上提出了一种数据仓库应用的替代方案。虽然厌恶“只能单一位置及单一存储空间上实现的方案”，他也承认有时候必须先聚合数据才能作分析。他所说的正是数据仓库应用的功能——沿着某些变量轴聚合信息并转化数据间的关系。而在 Pritchett 看来，数据仓库应用在使用中有许多缺点。数据仓库应用不仅非常昂贵，“比较小的组织一般难以企及”，而且 ETL（Extract, Transform and Load，提取、转换、装载）软件的工作方式意味着要付出可伸缩性和反应能力的代价：

首先，ETL 给生产数据库增加了明显的负担。如果你的业务有空窗期可以做 ETL，那是最好的；如果没有，管理可伸缩性就是很大的挑战。第二，数据仓库里的数据新鲜度一般滞后 24 小时或更长，随着业务增长，滞后时间会越来越长。

Dan Pritchett 相信有一种方案更便宜，也更可伸缩：用 ESP（ Event Stream Processor ）处理事件流。

ESP 用类似 SQL 的语言处理各种事件流。与数据库和数据仓库通过 SQL 分析数据表类似，ESP 用它们的查询语言分析事件流。要想理解 ESP，可以把事件类比成数据库表中的行，而事件的属性则对应数据库表的列。每一种事件类型就等于是一张表。 […]

[ESP 分析] 数据的变化，而且就在变化发生的当时分析。我们不再进行批量的 ETL，而是把业务事件变成一连串的数据状态变化。这就创造出一种更易于管理的生产系统的伸缩模型。

[…]

ESP 可以做水平伸缩，因此可以达至一种更具成本效益的业务方案。而且由于 ESP 执行分析是实时的，因此得到的业务指标更加应时，并且不受业务增长的影响。

Dan 也特别指出这种方法的弱点，就是不能进行历史性的分析，不能从当前以外的角度去观察业务活动。Pritchett 提出用一种捕捉并重演事务的框架去克服此弱点，不过该方案相当昂贵。Tahir Akhtar 在帖子的留言中提出另一种弥补方法：用 ESP 替代 ETL，但在享用 ESP 的可伸缩性和反应能力优势的同时，继续使用数据仓库应用以保留历史分析能力。

查看英文原文： Event Stream Processing: Scalable Alternative to Data Warehouses?