《复杂事件处理技术的研究与应用硕士毕业论文.docx》由会员分享，可在线阅读，更多相关《复杂事件处理技术的研究与应用硕士毕业论文.docx（83页珍藏版）》请在三一文库上搜索。
1、浙江大学硕士学位论文 Error! No text of specified style in document. 复杂事件处理技术的研究与应用 摘要复杂事件处理(CEP)是一种数据分析的技术，它可以实时的对每天在企业系统中产生的大量事件进行分析，从而快速给出决策。对于一家商业网站来说，CEP系统可以提升决策速度，在业务监控，风险预警等方面发挥重要作用，具有很高的业务价值。作者通过对CEP相关技术和系统的研究，结合所在企业的业务现状，开发出一套切合业务需求，能够快速处理复杂业务，具备较高性能，成本适合的CEP系统，并在本文中详细介绍了其中三大关键部分的设计和实现，包括CEP处理框架，CEP中实
2、时事件流统计算法，CEP的规则引擎。CEP处理框架部分，首先分析了复杂事件处理系统的需求，相关的受众，基于此，给出了复杂事件处理系统的设计目标。首先，阐述了复杂事件处理系统的消息通道和事件传输，事件定义方面的设计。其次，阐述了复杂事件处理系统各组件的设计，包括处理引擎，事件处理器，事件流等。最后阐述了复杂事件处理系统基于HBase的存储系统。CEP中实时事件流统计算法，给出了一种基于非等宽直方图的流数据统计算法，并描述了负责实时统计的事件处理器的设计。CEP的规则引擎，首先介绍了规则引擎的概念和业界的产品，之后给出了规则引擎的设计目标，并详细描述了一种可扩展的规则引擎的实现。关键词：复杂事件处
3、理，CEP，规则引擎，实时统计i浙江大学硕士学位论文 AbstractAbstractComplex Event Processing (CEP) is a data analysis technique, it can be real-time analysis of the large number of events generated daily in the enterprise system, to quickly give decision-making. For a commercial website, CEP system can improve the speed of
4、decision-making, play an important role in the business controls, risk warning, with high business value. By study the companys business and related CEP technology , the author of paper lecture developed a CEP system which meet the business needs and be able to quickly handle complex business, with
5、high performance, low cost , The paper described in detail the three key part of the design and implementation, including the CEP processing framework, CEP in real-time event stream statistical algorithms, the CEP rules engine.CEP processing frame part, the first analysis of the requirement for CEP
6、system, relevant actors based on this and design goals, message channels and event transmission of CEP system, the design of the event definition. Also describe each component of a CEP system design, including processing engine, event handler, event stream. Finally, describe the HBase-based storage
7、systems for CEP.CEP in real-time event stream statistical algorithms given a wide histogram stream data statistical algorithms, responsible for real-time statistics and describes the design of the event handler.The CEP rules engine, first introduced the concept of the rule engine and the industrys p
8、roducts, is given after the rules engine design objectives, and describes in detail the implementation of a scalable rule engine.Key Words：Complex Event Processing, CEP, rule engine, real-time statistics ii浙江大学硕士学位论文 目录目录摘要iAbstractii图目录III表目录IV第1章 绪论11.1 课题背景11.1.1 基于商业智能(BI)的决策分析11.1.2 复杂事件处理技术的概念
9、21.1.3 复杂事件处理系统和传统BI的关系31.2 复杂事件处理技术的现状41.2.1 国内外复杂事件处理产品的现状41.2.2 事件流实时分析算法介绍51.3 本章小结6第2章 复杂事件处理系统设计82.1 需求分析82.2 总体架构设计102.2.1 架构设计目标102.2.2 CEP系统部署架构112.3 系统概念模型112.3.1 静态概念模型122.3.2 核心组件的交互132.4 事件的收集132.4.1 事件基本规范142.4.2 事件传输技术选型162.4.3 事件源设计182.5 事件处理引擎及事件路由192.6 事件流设计212.6.1 事件处理的网络拓扑212.6.2
10、 事件处理器222.6.3 并发及性能282.7 事件存储技术选型292.7.1 HBase存储系统简介302.7.2 HBase的数据模型设计322.8 本章小结33第3章 CEP中的实时统计算法343.1 实时统计简介343.2 窗口(Windows)343.3 基于直方图的统计算法353.4 算法改进363.4.1 窗口定义363.4.2 算法实现383.5 实时统计在CEP系统中的应用433.5.1 统计事件处理器的配置433.5.2 HBase存储结构453.6 本章小结46第4章 CEP中的规则引擎实现474.1 规则引擎简介474.2 规则引擎的设计决策474.3 规则语言设计4
11、84.3.1 规则引擎的概要设计484.3.2 ANTLR简介494.4 语法规范494.4.1 语言要素504.4.2 抽象语法树(AST)514.5 规则引擎实现524.5.1 Antlr解析过程524.5.2 规则执行器设计544.5.3 基于Drools的规则实现604.6 规则管理614.7 规则引擎在CEP系统中的应用624.8 本章小结62第5章 CEP系统的效果分析635.1 系统应用场景635.2 系统性能指标635.2.1 系统部署环境635.2.2 系统性能报告645.3 本章小结65第6章 总结和展望676.1 主要完成的工作676.2 本文主要贡献及创新点676.3
12、进一步的研究工作676.4 本章小结68参考文献69作者简历71致谢72III浙江大学硕士学位论文 表目录图目录图 1.1复杂事件处理与BI3图 2.1使用者用例视图8图 2.2业务开发者用例9图 2.3系统开发者用例9图 2.4系统总体架构10图 2.5系统部署环境11图 2.6CEP概念模型图12图 2.7事件类图15图 2.8ActiveMQ架构图17图 2.9EventSource类图18图 2.10事件和事件流的关系20图 2.11事件处理网络拓扑21图 2.12事件处理器的结构22图 2.14事件处理器线程模型29图 2.15Hadoop体系30图 2.16HBase架构31图 2
13、.17HBase数据模型32图 2.18反规范化模型33图 3.1直方图35图 3.2时间窗口的直方图36图 4.1Drools的内部结构47图 4.2规则引擎概要设计图49图 4.3抽象语法树52图 4.4抽象访问者结构55图 4.5表达式实现类图56图 4.6操作数实现类图56图 4.7运算符实现类图57图 4.8基于Drools的改进方案61图 5.1指标计算及保存响应时间64图 5.2读取统计信息时间65图 5.3规则引擎性能65表目录表 2.1架构的质量属性10表 2.2CEP核心概念12表 2.3事件属性的类型14表 2.4事件属性的分组14表 2.5Header部分的内容15表
14、2.6ActiveMQ性能测试结果17表 2.7事件处理器列表24表 3.1未经处理的事件44表 3.2增加了统计字段的事件45表 3.3支持统计的HBase表结构46表 4.1运算符支持列表50表 5.1CEP应用集群63表 5.2HBase集群64VI浙江大学硕士学位论文第1章 Error! No text of specified style in document.第1章 绪论1.1 课题背景在企业或者网站系统中，每天都会收到大量的事件，例如一次订单的产生，一次用户的访问。 在一些企业系统中，这些事件被简单的忽略掉了，显然，在这些持续不断的事件流中，蕴藏着许多有用的信息，包括可能的商机
15、和潜在的风、险。企业系统和网站如果能够快速的对这些事件进行响应，分析，从而发现有用的信息，进而做出快速的决策，对业务的发展具有非常大的价值。 为了解决分析决策的时效性问题，事件流处理系统和相应的复杂事件处理技术(CEP)近年来发展比较迅速，逐渐成为一种用于实时分析决策的有效方法。基于上述的背景，本文研究了复杂事件处理的基本理念，调查国内外的研究状况及相关的产品，并设计了一套可用于生产环境的复杂事件处理系统，经过实际的测试，在网站的风险监测和应用监控方面产生了非常好的效果。1.1.1 基于商业智能(BI)的决策分析对于决策的分析，商业智能（BI）技术已经有了多年的发展，并且在各互联网企业中大量应
16、用。但是，传统的BI分析的时效性通常较差，对于一些需要快速响应的场景（如反欺诈，实时业务及系统监控等），无法满足实时的需求，技术上主要原因在于，数据仓库1是BI分析的基础，传统的数据仓库的工作模式，主要用来进行全局的，复杂的，长时间的分析，并不适用于实时快速的处理，技术上的原因包括：1）数据仓库查询的性能：数据仓库通常基于关系型数据库，并且会建立复杂的关系模型，在高并发，高访问量的场景下，无法满足性能要求。虽然目前已经有基于HADOOP的数据仓库技术，提高的数据仓库的运算速度，但对于数据量较大的互联网公司来说，分析执行时间往往也要数小时，甚至超过一天。2）数据仓库数据的时效性：将数据从线上环境
17、同步到数据仓库的分析环境的（ETL），是一个较长的过程，通常这个过程都是在每天线上环境访问量较小的时段进行（如夜里），数据仓库对数据失效性的保证一般都是T+1，即延迟一天的据。技1.1.2 复杂事件处理技术的概念1.1.2.1 复杂事件（Complex Event）的概念要清晰的描述复杂事件处理技术，首先需要给出复杂事件的概念：1）基本事件：指直接来源于事件源，没有被处理过的事件，如一次会员登录，一次下单，或者某服务的一次处理请求，都可以认为是基本事件，每天在企业系统中，都会产生大量的基本事件，不过，在很多情况下，这些事件都被简单的忽略了，没有产生价值。2）复杂事件(Complex Event
18、)：多个基本事件，经过CEP系统的处理和分析，相互关联形成的事件。一些复杂事件的例子：、从时间的维度：如服务器10分钟内的平均响应时间，某客户1小时内的交易金额。从业务的维度：如用户登陆和下单时两个不同的基本事件，但对于一个商户来说，假设要对来自不同广告商的用户给予一定的折扣，则需要把这两个事件组合成一个复杂事件，即（用户从X入口登陆，并购买A商品） 。1.1.2.2 复杂事件处理(Complex Event Processing)的概念复杂事件处理最早在The power of events2一书中提到，复杂事件处理是把简单事件通过一系列的事件处理模式，形成复杂事件，从而提供决策的过程。更具
19、体来说，它是一种跟踪和分析以事件流形式产生的数据并给出决策的方法3，复杂事件处理系统接收来自多个不同的事件源的事件4，应用一组事件处理模式，在多种复杂的情况下分析出结论5。复杂事件处理的目的是发现事件背后的意义，并及时作出反应。一个典型CEP系统，一般会具有如下的要素：1）事件处理模式:CEP系统通过在事件流上注册一系列事件处理模式来实现事件处理。这些处理模式包括：聚合，多事件的关联，过滤，事件增强，事件修改，规则匹配等。2）事件处理语言，描述事件处理的过程和模式，如Stanford Stream Data Manager中提出持续查询语言(CQL)，采用类SQL的语法形式；很多商业和开源产品
20、中都对CQL进行了扩展。3）规则引擎，规则引擎是根据复杂事件的关键组件，通过在复杂事件之上匹配一系列的规则，给出最终决策。4）支撑系统：如分布式存储，缓存，线程池，消息队列等。1.1.3 复杂事件处理系统和传统BI的关系互联网企业应用复杂事件处理的主要目的是分析和发现模式，为有效的决策提供支持，这一点上，和通常意义上的商业智能(BI)是类似的。复杂事件处理技术的和BI的区别主要在于复杂事件处理的实时性上，传统的BI的分析过程是先将数据存储下来，之后，再对这些数据上一系列的规则，模型进行分析，在实际的网站业务中，一般决策会有一定的滞后性。而CEP的模式正好相反，通常CEP系统不存储任何的数据，而
21、是在事件流上注册一系列的事件处理模式，当事件经过CEP系统，会触发一系列的处理模式，对事件进行分析，得到决策。两者的区别如图1.1所示：图 1.1复杂事件处理与BI两者之间是相互补充的，不存在替代的关系，BI的优势在于可以在整个数据集上进行全面的，复杂的分析；而CEP只能关注局部的数据集(比如一个时间段)，从有限的数据中实时快速的进行分析。两者也可以结合起来，BI可以为实时的规则上线前提供一些试运行的依据，BI通过数据挖掘发现的一些规则，也可以应用在CEP系统中，实现实时化由于实时的特点，CEP近年来被广泛应用在商业活动监控（BAM），金融，证劵行业的风监测；电子商务网站的反欺诈，网站状况的监
22、控，实时的决策分析；最近也有在工业领域的使用案例，如建筑，桥梁情况的监控等。这些领域通常对实时性要求很高，短暂的延时就可能造成严重的损失或者错失可能的商业机会。1.2 复杂事件处理技术的现状1.2.1 国内外复杂事件处理产品的现状事件流处理和复杂事件处理在国外较受关注，国外很多的大学和机构在这个领域进行了大量的研究工作。从CEP产品上看，许多业界知名的公司也涉足了这个领域，推出了一些商业产品，如Microsoft, Oracle, Tibco, IBM, StreamBase等公司。在开源领域，较为成熟的有ESPER，主要在金融领域。1）斯坦福大学Stream Data Manager6 ：从
23、2001年开始，斯坦福大学就开始进行流事件处理的研究，Stream Data Manager是斯坦福大学基于流数据的研究成果开发的事件处理系统，它用类SQL的持续查询语言（CQL）7，使流数据的处理模型与关系型数据库做了对接。在这个系统中，提出了很多重要的理论，如近似统计、CQL查询优化 、内存管理等。积累了很多理论和实践经验。 2）美国加州大学伯克莱分校的数据流管理系统 TelegraphCQ ： 它是一个连续查询处理系统，主要是面向电信领域。3）Borealis是一个分布式的事件处理引擎8. 它接受一系列的事件，经过对事件的统计，连接，修改，过滤，合并等操作，输出处理结果，供感兴趣的系统引
24、用。在Borealis中，Operator(事件处理的单元)可以分布到多台物理机器上9，这些物理机器被成为处理节点(Processing Node) ，并且使用一个分布式的目录系统保持集群的配置信息。事件源发出的事件经过一系列的Processing Node，每个Processing Node对事件进行一次变换，最终形成某个复杂事件，供客户端App使用。4）ESPER10：是一个在业界有较多应用的开源复杂事件处理系统，通常用于业务流程管理，金融行业的实时分析，风险监测等领域。它提供强大的EPL(事件处理语言)，以描述典型的事件处理模式，支持基于滑动窗口，长度等的统计，排序，事件视图的创建，子查
25、询及事件的关联查询等。系统用Java编写，可以较方便的嵌入到其他应用中。一些高级特性如HA，持久化存储，水平扩展等需要购买商业的License才能实现。但其开源版本对研究复杂事件处理系统的实现具有很大的价值。另外，近年来大型互联网公司推出了一些分布式流计算产品，如Yahoo推出的S4，Twitter的Storm，但严格来说，这些产品只是数据流计算的基础框架产品，并不具备完整的CEP产品特征（如不具备事件描述语言，规则引擎等）目前应用还比较少，下面对这些产品做一个简单的介绍：Yahoo S411：是一个分布式，可扩展的流计算系统。它最初的开发目的是为了弥补Hadoop在连续事件流处理方面的不足，
26、已经在Yahoo的广告推荐系统有了成功的应用。S4把事件处理过程抽象成一组PE(Processing Element)，以特定的Key进行分组的事件会被特定的PE消费，每个PE在处理事件后，会发出可被其他事件处理的新事件，或者发布事件处理结果。每个PE都可以是分布式的，由Zookeeper提供分布式支持。S4提供了简单的编程模型和API，可以方便的在其基础上开发实时事件流处理应用。Twitter Storm12：是Twitter公司推出的流计算系统，其定位与Yahoo S4类似，但提供了更灵活的路由规则，同时保证消息传输的可靠性。它的流程处理单元叫做Topology，描述了一个事件处理流程。T
27、opology是由Spout(事件生产者)，Bolt(事件处理单元)组成的事件处理网络。从部署结构上看，Storm集群由控制节点(Nimbus)和多个工作节点(Supervisor)组成，Nimbus负责分配任务，并监控状态。Supervisor负责实际的处理工作。综上所述，目前事件处理产品，大部分都是价格较昂贵的商业产品，且源代码并不公开，后期支持和维护所需花费也比较大。因此，有必要自行开发一套适合自身业务需求，成本合适的CEP产品。1.2.2 事件流实时分析算法介绍事件的实时统计，通常是CEP系统中的的重要功能，不同于传统的数据库统计，由于事件流持续不断的，所以一般会限定一个区间的数据进行
28、统计，常见的包括滑动时间窗口（统计从当前时间起倒退N个时间单位的区间），数量窗口（对最新N条事件进行统计）。流事件统计面临的经典问题包括，滑动窗口上的聚集（COUNT, SUM ,AVG, MAX, MIN）等，滑动窗口内不同值的个数统计（DISTINCT COUNT）等。对数据流进行管理的诸多挑战中的第一个是，由于数据流的长度是无界的，绝不可能将数据流里所有的数据存储下来。我们必须使用有限的存储，和一些合适的算法来存储数据流的摘要信息。一般来说，需要在存储空间的大小和统计结果的精确度之间取得一个平衡。 在数据留上进行统计计算的方法主要有：随机抽样技术、滑动窗口技术、直方图技术、小波技术和哈希
29、方法等。随机抽样(Random Samples)抽样方法是从数据集中抽取小部分能代表数据集基本特征的样本,并根据该样本集合获得近似查询结果。但这种方法对于精度较高的场景并不是很合适。直方图(Histogram)直方图技术是将一个大数据集划分为多个连续的桶(Bucket) ,即小数据集,且每个桶都有一个特征值。主要的直方图有等宽直方图( Equi-width Histogram) 、V-优化直方图(V-optimal Histogram)、端偏倚直方图( End-biased Histogram)等。Jagadish 等人着重于计算离线数据的直方图13，而 Guha 和 Koudas 提出了一种
30、在在线数据流上维护接近最优的、基于时间的直方图的技术14。支持包括在时间属性上对范围值或者点值的查询。Gilbert 等人考虑怎样在数据流中维护随时间衰减的总计值(aged aggregates)的问题15。Mayur Datar16等人给出了一种基于直方图的基本统计方法，基本场景是统计目前为止最近 N位中值为 1 的总位数。算法能够在规定的误差内,使用最小的存储空间，统计出结果，并扩展到了基于时间窗口的count, sum等操作。哈希方法(Hashing) 处理大数据的一种方式是定义一组哈希函数，把较大范围的数据映射到较小的范围。类似的方法可以使用在数据流的Distinct Count计算中
31、，其中 Bloom Filter 方法是可以用一小块远小于数据集数据范围的内存空间表示数据集。例如申请的内存大小为m 比特位,创建h个相互独立的哈希函数,能将数据集映射到 1. . m 中去。对任何元素,经过哈希函数的计算,得到 h个 1. . m 之间的数,并将内存空间中这 h 个对应比特位都置为 1。这样,就可以通过检查一个元素经过 h 次哈希操作后,是否所有对应的比特位都被置 1 来判断该元素是否存在。这种判断方法可能会产生错误虽然某元素并不存在,但是它所对应的h 个比特位都已经被其它元素所设置了。FM(Flajolet and Martins Algorithm)算法17，就是一个基于
32、HASH值的Distinct Value问题解决方法 本文所搭建的复杂事件处理系统，主要会采用一种非等宽的直方图法，作为实时数据流上的滑动窗口统计算法。1.3 本章小结绪论部分，首先介绍了复杂事件处理技术出现的背景，在企业中的应用场景之后，阐述了复杂事件处理和传统BI分析的区别和联系。同时介绍了国内外的复杂事件处理相关产品和算法，技术的现状，以及本课题的研究意义。正文部分详细介绍了自行设计的CEP系统的总体架构设计，事件处理引擎的实现，事件的结构，基于滑动时间窗口的实时统计算法实现，规则引擎的实现，事件处理语言，大数据量支撑，性能，可靠性方面的设计思路，系统的部署环境和性能指标。总结部分，对整
33、个工作进行了总结，并阐述了进一步的工作方向。第2章 复杂事件处理系统设计2.1 需求分析 复杂事件处理系统主要的工作是，接入事件并定义一组事件处理的模式和规则，通过这些模式和规则给出决策，对于决策的处理，应该留给具体的业务系统负责，不在复杂事件处理系统范围内，经过分析，我们发现系统应该有如下三个使用角色：系统涉及到3个角色，使用者，系统开发者，业务开发者。1）使用者：是实际使用系统的人，使用者应该精通业务，对技术能力没有要求，负责根据业务配置具体的业务事件该如何处理，如何给出决策。图2.1给出了使用者的用例视图。2）业务开发者：主要是负责接入事件，并在特殊情况下，通用的事件处理器处理不了，可以
34、定义自己的事件处理器。图2.2给出了业务开发者的用例视图。3）系统开发者：负责维护CEP系统的核心框架，提供接入规范和指导，不涉及具体业务开发。图2.3给出了系统开发者的用例视图。图 2.1使用者用例视图9浙江大学硕士学位论文第2章Error! No text of specified style in document.图 2.2业务开发者用例图 2.3系统开发者用例2.2 总体架构设计图2.4列出了CEP系统的总体架构，业务系统产生的事件经过消息通道，到达CEP系统。CEP系统的事件源组件接收事件后，分发到处理这个事件的处理流上（EventStream），事件处理流应用一系列的事件处理器来
35、分析事件，最终产生分析决策，发布给负责处理决策的业务系统。图 2.4系统总体架构2.2.1 架构设计目标架构设计过程中，架构的质量属性18的考虑是至关重要的，架构的质量属性通常包括，性能，可维护性，可扩展性，可用性，安全性，可测试性等多个方面，架构的设计过程也是对质量属性进行权衡取舍的过程。结合实际情况，综合考虑，表2.1列出了最重要的质量属性如下：表 2.1架构的质量属性质量属性设计决策可维护性采用分层设计，核心概念保持简洁，同时可基于框架代码进行业务扩展。性能根据业务现状判断，系统响应时间应在毫秒级，满足每日1000W事件量的处理需求。 续表2.1质量属性设计决策可扩展性由于业务不断发展，
36、系统可扩展性也至关重要。为方便今后扩展，我们会保持单机部署的系统无状态，同时采用一种高性能的NOSQL数据库作为集中存储2.2.2 CEP系统部署架构图2.5描述了CEP系统的部署环境：图 2.5系统部署环境CEP系统机器本身是无状态的，状态数据都集中存储在HBASE集群中，因此，随着业务的增加，可以通过增加机器的方式实现系统扩展。存储方面，HBase也是可以通过水平扩展方式，实现业务扩容。ActiveMQ，事件量增多时，可以通过Cluster方式扩展。2.3 系统概念模型设计一个大型系统时，首先应该建立概念模型。概念模型是与系统和数据库无关的模型，用来对现实世界进行描述，有了概念模型之后，后
37、面进一步推导出系统设计模型就会比较简单。下面将使用UML来对CEP系统进行概念模型的建模。2.3.1 静态概念模型对于大型系统来说，保持一个简单的核心概念至关重要，需要尽量限制系统核心概念的数量，对于CEP系统来说，主要有7个核心概念，图2.6的类图列出CEP系统的核心概念之间的关系，表2.2对这些核心概念作了详细的介绍。图 2.6CEP概念模型图 表 2.2CEP核心概念名称功能BasicEventBasicEvent是从外部系统发来的，未经处理的的事件，这些事件一般以XML形式，但系统也预留了接口，以便支持更多的格式。InternalEvent是系统内部的事件格式，BasicEvent都会
38、统一转换成InternalEvent，以便后续处理续表2.2名称功能InternalEvent是系统内部的事件格式，BasicEvent都会统一转换成InternalEvent，以便后续处理EventSourceEventSource用来处理不同的事件来源和不同的事件格式，把BasicEvent转换成InternalEventEventProcessingEngine事件处理引擎，是整个CEP的核心组件，负责服务的启动关闭，各组件的初始化，事件的路由等等EventStream是用来定义一个事件处理业务，里面包含了一系列的EventProcessor，对事件进行处理EventProcessor事
39、件处理器，执行具体对事件处理的逻辑，事件处理器有很多种，我们希望能用一组标准的事件处理器的重用解决80%以上的业务问题，同时也预留了给用户自定义事件处理器的接口。CEP Service系统的入口，主要是负责加载配置，启动其他服务2.3.2 核心组件的交互从事件发生开始，系统交互过程如下：1）外部系统发送事件到消息队列，基于JMS的消息中间件（我们这里选用ActiveMQ），维护了一个消息队列和响应的订阅者关系，EventSource作为队列的订阅者，会接收到生产者发送的事件。2）EventSource接收到事件后，首先要对事件格式进行转换，然后对事件进行校验，如果校验通过，提交给EventPr
40、ocessingEngine的路由引擎进行事件路由，如果失败，则记录失败日志，后续可以在日志上加监控，当出现日志失败时进行报警。3）EventProcessingEngine根据路由规则，把事件路由到不同的EventStream中。4）EventStream负责把消息交给EventProcessor.5）事件会经过一系列的EventProcessor，对事件进行各种处理，如统计，Join，变换，规则匹配，存储等等。最终形成决策过程。2.4 事件的收集在设计具体的事件处理过程之前，我们需要首先考虑事件是什么结构，这个结构至关重要，因为这会是和客户端的一种API契约，如果后续对事件格式进行改动，影
41、响面会相当大，并且会引起API使用者的不满，因此需要仔细考虑。2.4.1 事件基本规范在一个较大型的企业或网站中，通常会遇到很多的事件对象，这些事件对象所代表的业务实体，内容，各不相同，格式也比较随意，我们需要对事件进行一定的规范，经过对企业内部事件的调查，确定事件需要具有如下要素：事件类型(Event Type)：事件类型可以理解为代表一组语义和结构相同的事件，我们给这些事件一个标识符，就是事件类型。事件类型是必填的属性，不带事件类型的事件是不被CEP系统所接受的，典型的事件类型例如：loginEvent：用户登陆事件，payEvent：付款事件等事件的属性(Event Attribute)
42、：事件属性是一个事件的结构的主要组成部分。每个属性包括如下3个要素：1）属性名称 2）属性的类型 3）是否是必须的属性对于属性的类型，我们的CEP系统支持的事件属性类型列在表2.3中：表 2.3事件属性的类型属性类型描述对应Java类型INT整数IntegerLONG长整数LongNUMBER浮点数BigDecimal, Double,FloatSTRING字符串StringDATE日期DateBOOLEAN布尔型Boolean这些事件属性的值描述了这样的一些信息：发生了什么？它是什么时候发生的？它是在哪里发生的？有其他的事件与它关联吗？根据属性的不同含义，我们将属性分为如下两组，见表2.4表
43、 2.4事件属性的分组属性组语义headerHeader是事件的元信息，本身不带有业务含义，包括了对于所有事件来说都一致的属性。续表2.4 事件属性的分组属性组语义payloadPayload是某个业务的事件主体，由一系列结构化的Attribute（如前所述的格式）组成，例如，如果一个登陆事件，会记录登陆的IP，通过什么方式登陆的，登陆用户名等信息对于Header包含的内容，在表2.5做了详细的介绍： 表 2.5Header部分的内容属性名说明eventType事件类型occurTime事件发生时间，是事件在业务系统发生的实际时间arriveTime事件到达CEP系统的时间eventID系统产
44、生的唯一标示事件的序列号source事件来源，表示事件是从哪个系统发来的下面是一个用户登陆事件的例子： LoginEvent 2012-01-09 11:17:04.517 CST 2012-01-09 11:17:04.517 CST loginApp 222.191.155.214 wxzztzhm Y webLogin相应的，事件主要由如下结构实现，事件主体主要是一系列键值对的属性，图2.7是事件的类图：图 2.7事件类图EventDefinition可以理解为事件的原型，它的属性包括事件类型，事件的简要描述，payload字段各属性的定义。每个InternalEvent都是EventDefinition的一个实例。2.4.2 事件传输技术选型我们的CEP系统采用的是基于事件驱动的架构19（EDA），在EDA架构下，事件在松散耦合的事件接收者之间路由。事件驱动的系统由事件生产者和事件接收者组成。事件生产者可以将事件发布到事件通道，后者可以将事件分发到订阅事件的接收者。 与生产者发布事件一样，事件通道将事件转发给接收者。如果没有可用的接收者，事件通道会将事件存储起来，然后将其转发到稍后可用的接收者。采用事件驱动架构能够带来很多好处，包括：松耦合：事件发