Notes for CEP & Esper Learning(1)——初识复杂事件处理

– 关于这次学习 –

实习狗要开始熟悉业务啦～

当前的任务是初步了解Complex Event Processing(CEP)和Esper。作为一个门外汉，入门的计划就是先了解复杂事件处理，再熟悉其中的Esper开源框架。

小弟水平有限，目前也在不断学习中。这系列博客文章纯当做是自己的学习笔记。如果有什么地方存在错误或纰漏，请用力纠正，以免误人子弟啊哈哈哈 =_=

---

---

初识CEP

1. MapReduce与流式计算系统

大数据时代，为了处理呈爆炸增长的数据量，谷歌的工程师Jeff Dean和Sanjay Ghemawat开创性地发布了系统：谷歌文件系统（GFS）和谷歌MapReduce（GMR）。前者提供了一个大规模数据管理的解决方案，而后者则提供了相应的分布式并行处理的计算框架。而Apache Hadoop的分布式HDFS和并行计算框架MapReduce则可以视作是这二者的开源实现。

然而MapReduce却不是万金油。由于MapReduce框架最初主要是针对批处理进行设计、优化的，所以在实时性上表现并不佳。尽管后人在MapReduce框架下做了更进一步的开发，使之适应实时性的要求（如Facebook在Sigmod 11上发表的利用HBase/Hadoop进行实时数据处理的论文），但这种天生的批处理计算能手不见得一定能够适应流处理的计算任务。总结百度分布式高级研发工程师杨栋的文章观点，其局限性主要有三处：
- 输入数据只能被分割成固定大小的分段再交由MapReduce平台处理。处理延迟与数据片段的长度、初始化处理任务的开销成正比，但分段长度与额外开销又是此消彼长的关系。
- MapReduce需要被改造成Pipeline模式，中间结果只能存储到内存中，增加了系统的复杂度。
- 只能使用MapReduce接口定义流式作业，用户程序可伸缩性大大降低。

目前业界主流的流式处理系统有Yahoo! S4、StreamBase和Borealis三种。

2. 流式计算系统与CEP

复杂事件处理（又译作复合事件处理，Complex Event Processing）的核心系统架构就是基于流式的处理系统。CEP的三大核心关键字：Stream、Base、Insight，流式(Stream)即为其一。

3. 简单事件处理和复杂事件处理

简单事件处理(Simple Event Processing)和复杂事件处理(Complex Event Processing)均从属于事件驱动架构(Event-Driven Architecture, EDA)。EDA以面向服务架构(Service-Oriented Architecture, SOA)为基础，将“服务”转化成“事件”来处理。
简单是件处理可以理解为消息导向的处理架构，主要服务于单一事件。当某一事件被触发后，将会被过滤(filtering)和路由(routing)，凭此决定是否转发该消息、该向谁转发消息。这也是一个实时的过程。
相比起简单事件处理，复杂事件处理（复合事件处理）不仅能处理单一事件，更重要的是能处理多个事件，并且能够根据设定好的事件关联规则进行决策控制。通俗地来讲，单一事件可以认为是某种状态的改变。比如说，图书馆旁边的饭堂人很多，这是一个事件；法学馆的人流量较平时大增，这也是一个事件；还有图书馆很多位置上都摆放着司法类相关的书籍，等……把这些事件组合起来，我们就很容易就能得到一个判断：司法考试马上就要来了。我们也可以据此做出决策：图书馆最近座位紧俏，如果要泡馆就要提前来找位子或者选择其它自习的地方。基于CEP这样的特性，它常被应用于商业活动监控、金融犯罪预防等。