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

阅读数:387 2008 年 11 月 9 日

话题:架构语言 & 开发

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?