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

作者 Sadek Drobi 译者 郭晓刚 发布于 2008年11月9日 下午7时32分

社区

Architecture

主题

活动,

数据仓库,

企业架构

标签

扩展性,

事件流处理,

数据仓库

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?

• 更早的 >