Esper( InfoQ 曾在一年前报道其 1.0 版本的发布消息)是一个事件流处理(Event Stream Processing,ESP)和复杂事件处理(Complex Event Processing,CEP)的系统,它可以监测事件流并当特定事件发生时触发某些行动——可看作是把数据库反过来,语句是固定的,而数据流进进出出。事件处理是软件行业的一个发展趋势,已有数家大厂商以及许多初创企业加入到该市场中。其常有的应用例子包括系统自动交易、BAM、RFID、高级监测系统、欺诈检测,甚至直接集成进 SOA。InfoQ 恰遇 Esper 的创始人,向他了解了项目的近况,以及最近的基准测试问题。
如 Esper 开发小组所说,Esper 现在是仅有的纯 Java 开源 ESP/CEP 引擎,由 EsperTech 公司提供商业支持服务,而这个公司也在维护一个同样的.Net 项目。
BEA 得到了 Esper 授权,将在修改后在加入到六月发布的 WebLogic Event Server 中。根据多方面的反馈,Thomas 跟 InfoQ 谈道:
我相信 Esper 在 BEA 的产品中占一席位的事实,在多个方面都有助于 Esper 的发展。首先,我们所获得的反馈的声音对于 Esper 的改进有很重要的作用。其次,BEA 的产品从总体上提高了 CEP/ESP 技术的知名度,并且因此扩大了市场的共识。第三,这是 Esper 技术的开放性,可扩展性,适应企业级应用的最好的证明。Esper 社区和用户群都真的为此而感到自豪。
随着市场空间的扩大,多种实现之间出现的竞争,标准化能给该行业带来一定的好处。Thomas 对 CEP 语言标准化的潜力和背景作了评价:
CEP 社区显然把 CEP 和 ESP 看作是互补的,并且认为其他手段(如贝叶斯网络或神经网络)也可应用于 CEP 的问题。由于存在各种实现技术,各厂商又各执己见,ANSI SQL 标准化委员会在扩展 SQL 基础上所提供的“行序列的模式匹配”似乎成为最重要的曙光。对于这个初步的课题当然会有进一步的研究,并且标准化很可能会超出 ESP/CEP 语言标准化的范围。
Esper 近期最突出的消息是在八月中旬发布了一个性能基准测试工具及公布了性能测试结果:
Esper 在双 2GHz CPU 的 Intel 系统测试环境下,处理超过 500 000 个事件 / 秒;在 VWAP 基准测试中在有 1000 语句的情况下,引擎延时平均小于 3 微妙(在 10us 时超过 99% 的预测准确率)——最高时有 70 Mbit/s 流量并占用 85% 的 CPU 资源。
虽然这个基准测试是基于一个相当简单的用例,其发表的目的是震动整个行业,因为它提供了完整的工具集来重现测试结果。Esper 事件服务器监听远端客户端通过网络传送过来的股票市场事件信息。Esper 引擎是通过一个滑动的时间窗口或事件窗口,来实时计算输入信息的成交量加权平均价。当被问及该基准测试的必要性时,Esper 回应道:
整个 CEP 市场已被含糊不清的信息所包围,每个厂商都在各自的宣传单上做文章,避开详细地交待实际性能和延时。在这个领域中还没有对它们作比较的基准测试。在这个行业中含糊的性能信息已经受到 Progress Apama 和其他人的批评。以下是来自于 Apama 的博客中的抱怨的声音:
……Skyler 处理速度高达 200,000 条 / 秒……主要特征:Coral8 每秒处理从数千到百万计的事件……StreamBase 性能领先,每秒处理超过 1 百万个事件,反应时间接近零……Aleri Labs 打破了亚毫秒反应时间的障碍……
Apama 自己也说过“一个能处理数千事件每秒的高性能、可伸缩的引擎”这种话。同样的措词在BEA 也能找到, WebLogic Event Server 公告了似乎较差但较为精确的指标“当我们的产品准备好,它将提供 50,000 复杂事件/秒的处理速度”。那些测试结果似乎确定了在这个领域里“数十万”事件每秒是普遍的,毫无例外。同时也正显示了 Esper在特定场景中的性能表现。它同样给了用户群有价值的工具来更好地得知实际性能,而不是听信厂商任意的令人充满疑惑的宣传,对有价值的开源软件普遍怀有的偏见。
Esper 小组已经在其 wiki 上发布了所有运行的详情,并且已更新了网页的性能部分和性能最佳实践部分。另一个基准测试的来源是最近成立的STAC 基准测试委员会,该委员会的目的是为技术的交易而提供由客户推动的基准测试标准。
请点击这里获取InfoQ 之前有关Esper 和CEP 背景的相关报道: http://infoq.com/esper 。
查看英文原文: Catching up with Esper: Event Stream Processing Framework
评论