分布式复杂事件实时检测及其应用


ADissertationSubmittedtoZhejiangUniversityfortheDegreeofMasterofEngineering一一⑧TITLE:Researchandapplicationofdistributed!兰Q!王呸塑虹.星y曼蛩!!星垒!:!i塑鱼曼亟曼!曼Q±i堕gA玎thor:ShaoChunfeiSupervisor:旦丛亟坠g圣hQ坠g鱼Q坠gSubject:College:SubmittedDate:2014.3.8 浙江大学硕士学位论文摘要复杂事件处理技术以事件为驱动,从实时事件流中检测复杂事件模式,对实时性要求较高,因此本文提出分布式复杂事件实时检测系统,以实现良好的可扩展性、更高的吞吐量,更低的检测延时为目标,适合各种应用场景。首先,综述复杂事件处理相关技术,分析以Esper为代表的面向事件流的复杂事件处理引擎和以DroolsFusion为代表的面向规则的复杂事件处理引擎之间的异同,通过系统延时测试和吞吐量测试实验证实Esper具有更好的处理性能。本文设计一个通用的分布式复杂事件实时检测系统,详细阐述复杂事件处理引擎Esper与分布式实时计算框架Storm的有效结合,提出基于事件流分发和基于规则分发的分布式复杂事件实时检测系统,实现不同拓扑结构的构建,同时,对系统可靠性,实时流与历史数据结合处理等关键技术进行研究。针对金融股票监控较高的实时性需求,实现基于分布式复杂事件实时检测的股票预警系统,提供用户定制股票规则和动态加载规则功能。系统根据股票实时数据和股票规则制定不同的拓扑结构,并进行了实验分析。关键词:复杂事件处理,实时计算,分布式,股票预警 浙江大学硕士学位论文AbstractAbstractDrivenbyevents,complexeventdetectiontechnologiesanalyzethemassdatafrominformationsysteminrealtime,SOthatpatternminingandeventdetectioncanbeachieved.Thisarticlehaspresentedareal-timedetectionmodelonthedistributedcomplexevents,whichwillachievescalability,highthroughput,lowdelayandmulti—scene.First,weintroducesomerelatedtechnologiesaboutcomplexeventprocessing.Thenweanalyzedthedifferenttypesofcomplexeventprocessingengines.Similaritiesanddifferencesbetweenevent··basedandrule--basedcomplexeventprocessingengineshavebeenstudied.Esper,DroolsFusionrepresentsthisresearch.Uponthedelayandthroughputtests,resultshaveshownthatEsperhassuperiorperformance.Areal-timedetectionsystemforgeneraldistributedcomplexeventsisdesignedbythisarticle,elaboratingtheperfectcombinationofEspeLthecomplexeventprocessingengine,andStorm,thedistributedreal-timecalculationstructure.Thisarticlepresentsthereal-timedetectionmodelofdistributedcomplexevents,basedeitheroneventstreamorrules.Meantime,somekeytechnologieshavebeenstudied,suchasthereliabilityofsystem,thecombinationofreal—timestreamandhistorydata.Stockmarkethasalwaysgothighrequirementonreal—timemonitoring.Real—timestockwarningsystemisbasedondistributedcomplexeventreal-timedetection.Itallowsclientstoinstitutestockrules.Thoserulesaffectsdynamically.Whenrulesaretriggered,warningswillbesenttoclientsinrealtime.Intheend,differenttopologiesareprovidedandexperimentedaccordingtostockrulesandreal-timedata.Keywords:ComplexEventProcessing,Real-timeComputing,Distributing,StockTickwarming11 浙江大学硕士学位论文目录目录摘要⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯iAbstract....,.............................⋯⋯.⋯⋯.......⋯.........................⋯.......................⋯.........ii第1章绪论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯11.1课题背景与意义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.11.2论文主要工作⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.21.3论文组织结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.31.4本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.4第2章复杂事件处理技术综述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯52.1事件定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.52.1.1原始事件⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯52.1.2复杂事件⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一62.2复杂事件检测方法⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.72.2.1基于Petri网的事件检测方法⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.72.2.2基于有向图的事件检测方法⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..82.3复杂事件处理发展历程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.92.3.1主动数据库⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一92_312数据流管理系统⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯102.3.3专有的复杂事件处理系统⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.1l2.4复杂事件处理引擎⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯122.4.1复杂事件处理引擎特点⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯122.4.2Esper..⋯⋯⋯..⋯...⋯.......⋯⋯⋯.⋯⋯..⋯...⋯.⋯.......⋯..⋯.⋯.⋯...⋯⋯.⋯⋯.132.4.3DroolsFusion.⋯.⋯....⋯⋯.⋯...⋯⋯.⋯.⋯.⋯...⋯...⋯⋯⋯..⋯...⋯...⋯.⋯....1—4.2.5分布式实时流处理框架⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯152.5.1StormToplogy⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.152.5.2StormCluster⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯162.6本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯17第3章复杂事件处理引擎选型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..183.1Esper⋯⋯...⋯.⋯...⋯....⋯...⋯.⋯⋯.⋯⋯⋯..⋯...⋯....⋯.⋯....⋯...⋯..⋯.⋯⋯⋯..⋯....18 浙江大学硕士学位论文目录3.1.1事件流处理过程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯193.1.2复杂事件模式匹配⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯203.2DroolsFusion⋯⋯⋯⋯⋯⋯⋯.........⋯⋯⋯⋯.⋯⋯..................⋯...........................233.2.1事件处理模式⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯233.2.2复杂事件模式匹配⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯243.3性能测试实验⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯263.3.1延时测试⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯273.3.2吞吐量测试⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯283.4综合比较⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯313.5本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯33第4章分布式复杂事件实时检测系统设计与实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一344.1数据分发策略⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯344.1.1基于事件流或规则分发的拓扑结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯344.1.2构建拓扑结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯374.2架构设计⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯384.2.1功能概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯384.2.2总体架构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯394.3主要模块实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯414.3.1数据流输入⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯4l4.3.2分布式复杂事件实时检测模块⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯444.4关键技术研究⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯484.4.1实时流与历史数据结合处理⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯484.4.2系统可靠性⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯504.5本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一52第5章股票预警应用案例⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一535.1股票预警需求分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯535.2事件和规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯545.2.1股票事件定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯545.2.2股票规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯555.3系统详细设计与实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯595.3.1总体架构设计⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯59U 浙江大学硕士学位论文目录5.3.2拓扑结构实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯595.4股票连续放量上涨和缩量下跌实验与分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯615.4.1实验内容与结果⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6l5.4.2实验结果分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯645.5不同拓扑结构股票预警实验与分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯645.5.1实验内容与结果⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯645.5.2实验结果分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯675.6本章小结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯68第6章研究工作总结和展望⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..696.1研究工作总结⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯696.2未来工作展望⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯69参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯71攻读硕士学位期间主要的研究成果⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯73致{射⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.74III 浙江大学硕士学位论文图目录图目录图2.1事件表达式中使用的函数⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6图2.2基于Petri图的事件检测方法图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯8图2.3基于有向图的事件检测方法图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯8图2.4企业信息系统中的复杂事件处理架构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一12图2.5StormTopology图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯15图2.6StormCluster图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯16图3.1Esper事件流处理架构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯19图3.2Esper动态状态树图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯22图3.3Esper处理事件的流程图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯23图3.4Drools规则匹配模型图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一24图3.5DroolsFusion股票放量上涨规则的Rete图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.26图3.6Esper和DroolsFusion的延时测试结果图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯28图3.7Esper和DroolsFusion的吞吐量测试结果图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯3l图4.1基于事件流分发的拓扑结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.35图4.2基于规则分发的拓扑结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.36图4t3基于规则和事件流分发的拓扑结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.36图4.4EsperBolt、rules、events关系图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯37图4.5EsperBolt、rule、event对应关系图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..37图4.6用户用例图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.39图4.7总体架构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.40图4.8用户启动系统序列图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.4l图4.9通用事件类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.42图4.10StreamId类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯43图4.11事件类型描述类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯43图4.12SpoutBean类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯44图4.13EventSpout类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯45图4.14RuleSpout类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯46图4.15DataSpout类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一46图4.16EsperBolt类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯47图4.17XML配置文件⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一48图4.18EsperBolt接收实时流和历史数据图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯49图4.19EsperBolt结合实时统计结果和历史数据图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯50图5.1股票预警管理员需求用例图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.54图5.2股票预警用户需求用例图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.54图5.3股票实时数据信息StockTick类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯55IV 浙江大学硕士学位论文图目录图5.4股票历史数据信息StockData类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯55图5.5股票预警总体架构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.59图5.6RuleBaseGrouping的chooseTasks方法流程图⋯⋯⋯⋯⋯⋯⋯⋯⋯61图5.7新浪财经2013年5月20日SH600036招商银行的分时图⋯⋯⋯一62图5.8股票预警拓扑结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.65图5.9StormUI监控界面⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..65图5.10股票预警应用延时测试结果图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯66图5.11股票预警应用吞吐量测试结果图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯67V 浙江大学硕士学位论文表目录表目录表3.1EPL事件规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯..20表3.2Esper股票放量上涨规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯21表3.3DroolsFusion股票放量上涨规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一25表3.4延时测试结果(单位ms)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯27表3.5吞吐量测试结果(单位ms)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯29表3.6有干扰事件的吞吐量测试结果(单位ms)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯29表3.7Esper与DroolsFusion比较⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯31表4.1初始化窗口规则语句⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.51表5.1单只股票的监控规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.56表5.2股票历史数据的监控规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.57表5.3多只股票的监控规则定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.58表5.4股票放量上涨程序运行结果⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.63表5.5股票缩量下跌程序运行结果⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯.63VI 浙江大学硕士学位论文第1章绪论第1章绪论1.1课题背景与意义随着计算机信息技术的快速发展,互联网产生大量的数据,并且以每年两倍以上的速度在快速增长【】]。软件应用源源不断的产生大量数据,以至于不能依靠人为检查来从中挖掘小部分人们感兴趣并可以加以利用的信息。在商业智能领域,大量数据隐含着不可预知的潜在力量,实时有效的利用这些数据可能产生更丰富的收入,以及更好的满足客户需求。举个较好的例子,如通过实时检测股票交易数据,可以给客户提供实时预警分析,有利于客户及时采取措施,同时也可以检测金融欺诈现象,避免不必要的损失。处理海量数据的传统方法是将产生的历史数据存储在数据库中,或生成日志文件,间隔一段时间,借用分布式框架如Hadoop[2】进行批量处理,得到分析结果。然而,随着数据的快速增长,传统的系统不能及时有效的将所有数据完整地存储在数据库中,也不能有效地进行实时分析处理,很难满足许多商业应用希望快速获得数据处理结果的需求,此外,商业应用对原始数据并不敢兴趣,而更关注从原始数据中提取推理出高水平的商业智能。因此,系统需要能够通过过滤,聚合,关联这些实时数据,从而把检测分析的结果和异常情况快速地通知给感兴趣的群体,为了满足这些需求,系统的实时处理性能非常重要。目前这类系统的最新发展是引入复杂事件处理技术CEP(ComplexEventProcessing)[31,用于检测连续达到的数据之间存在的特定模式,具有高吞吐量、低延时和复杂计算等特点。复杂事件处理的应用非常广泛,例如金融机构或手机运营商,使用CEP语言定义异常的转账交易或电话欺诈行为,从而对大量的实时数据进行过滤和模式匹配,最终实现欺诈检测【4]。如某一时刻,某账户收到一笔大额转账收入,并在短时间内进行大量的小额转出到多个账户,那么此账户可能有洗钱的嫌疑。又如某手机在短时间内连续打出上百个长途电话,那么此号码可能有电话欺诈的嫌疑。 浙江大学硕士学位论文第1章绪论复杂事件处理系统接收来自不同数据源、不同类型的事件,所需处理的数据流非常大,然而对实时性要求较高,面对海量而关系复杂的数据信息,系统需要快速计算并决策,这对系统的吞吐量提出了更高的要求,单一节点的计算速度往往不能满足需求。然而,某些应用需要极高的吞吐量要求,例如对股票市场监控进行欺诈检测等,纽约期货交易所高达每秒150万的交易数量【5]。近年来,分布式复杂事件检测技术不断发展,研究的主要重点为获得更好的可扩展性、高吞吐量、低延时。如基于事件分发的并行查询条件,将部分查询分发在不同的机器上并行计算,大多数系统满足同时进行大量的查询,因此可以简单地根据查询操作粒度进行分布式事件检测。但这类系统具有一定的局限性,当事件数量极具增加,而查询个数有限时,很难获得较高的事件吞吐量。目前已有的CEP引擎根据事件处理语言可以分为两大类:面向流和面向规则的CEP引擎。面向流的CEP引擎有MicrosoftStreamlnsight、OracleCEP、瑕MSPADE、Esper等,而面向规则的CEP引擎有IBMAmit、TIBCOBusinessEvents、JBossDroolsFusion等。1.2论文主要工作本文针对复杂事件检测的不同类型的引擎进行原理分析,探究面向事件流的复杂事件处理引擎和面向规则的复杂事件处理引擎之间的异同点,分别以Esper【6j,DroolsFusiont7]为代表,进行延时测试实验和吞吐量测试实验,并从多种因素比较两者的异同点。本文的主要目的是设计一个通用的分布式复杂事件实时检测系统,实现复杂事件处理Esper与分布式实时计算框架Storm的结合,探究复杂事件检测并行计算的可能性,以获得更高的吞吐量,更低的检测延时为目标。提出基于事件流分发或基于规则分发的分布式复杂事件实时检测系统,同时对系统可靠性,如何做好实时事件流和历史数据结合等关键技术进行研究。最后,以实时股票预警实验为例验证本文系统的可行性,用户可以通过事件处理语言EPL(EventProcessingLanguage)定义感兴趣的股票事件模式,系统将2 浙江大学硕士学位论文第1章绪论事件规则解析,根据股票代码和规则之间的联系生成Storm的网络拓扑结构,进行分布式实时计算,以达到更高的事件检测性能。1.3论文组织结构论文共分为六章,结构组织如下:第一章为绪论。此章首先对论文的课题背景和意义进行介绍,说明了复杂事件处理技术应用广泛,指出复杂事件处理引擎单一节点的缺陷和不足,以及分布式复杂事件实时检测的重要性,然后对论文的主要工作和内容安排作了描述和介绍。第二章为复杂事件处理技术的研究现状。此章主要对复杂事件处理技术原理进行了介绍,并对基于Petri网和基于有向图的事件检测方法进行详细阐述。依次介绍主动数据库,数据流管理系统的特点与应用,然后分析复杂事件处理技术与主动数据库、数据流管理系统之间的异同点。介绍复杂事件处理引擎特点,并简单介绍Esper和Drools,由于引擎的单节点性能瓶颈,引入Storm分布式实时流处理框架。第三章为不同类型的复杂事件处理引擎的基础原理的分析和比较,主要分为两大类:以Esper为代表的面向事件流的复杂事件处理引擎,以DroolsFusion为代表的面向规则的复杂事件处理引擎,对两个开源引擎进行性能测试实验与分析,探究其适合的应用场景和异同点。第四章为分布式复杂事件实时检测系统的设计与实现,提出复杂事件处理技术Esper与分布式实时计算框架Storm的有效结合,从需求分析到数据设计和系统总体架构,详细介绍了主要模块的实现和关键技术研究,探究复杂事件检测并行计算的可能性,以获得更高的吞吐量,更低的检测延时为目标。第五章为实现基于分布式复杂事件实时检测的股票预警系统,提供用户定制股票规则和动态加载规则功能。系统根据股票实时数据和股票规则制定不同的拓扑结构,并进行了实验分析。第六章为总结和展望。此章首先对本文所有的工作进行了总结,并对本文工 浙江大学硕士学位论文第1章绪论作可进一步研究的几个方面进行了展望。1.4本章小结本章主要对论文的课题背景和意义进行介绍,说明了现今复杂事件处理技术的缺陷和不足,以及分布式复杂事件实时检测的重要性,然后对论文的主要工作和内容安排作了描述和介绍。4 浙江大学硕士学位论文第2章复杂事件处理技术综述第2章复杂事件处理技术综述随着信息化时代的降临,社交网络、实时搜索、算法交易等新应用的出现,实时数据处理技术越来越受到人们的关注。由于大规模的数据流不能快速完整的存储与查询,然而,即时地处理海量数据,挖掘其中潜在的事件模式在商务智能等领域具有极其重要的意义。从海量的连续数据流中推理出深层次的事件信息,检测发现用户定义的事件模式,复杂事件检测技术己成为现今计算机技术领域的一大研究方向。2.1事件定义复杂事件处理技术(CEP,ComplexEventProcessing),最早在20世纪90年代由斯坦福大学的DavidLuckham等人提出,用于接收来自不同数据源的消息,从原始事件中提取出更高层次的知识。一个事件可以理解为发生的一件有意义的事情,可以是一个原始事件或者复杂事件。2.1.1原始事件原始事件是指某个时刻发生的某个行为,可以理解为一个三元组:E《id,attributes,timestamp)其中id表示事件的唯一标识符,attributes表示事件属性,fimestamp表示事件发生的时间[8]。生活中有许多原始事件,例如温度传感器的测量结果、一个股票报价等商业敏感的数据等等。事件可以被定义为一个感兴趣的事情,原始事件发生在某个时刻,而复杂事件可以视为一段时间内发生的一串原始事件。如图2.1所示,使用E表示事件类型,e表示一个事件实例,t_begin(e)表示事件实例e发生的时间,t_end(e)表示结束时间,interval(e)表示事件实例e发生的持续时间interval(e)=t_end(e)一t_begin(e)。dist(e1,e2)为两个事件e1,e2的距离,其值等于t_end(ez)一t_end(e1)。Interval(e1,e2)表示两个事件的持续时间,等于max(tend(e2),tend(e1))一min{t_begin(ez),t_begin(e1)}c t_end(e{》毒t_凝gin(e,)l图2.1事件表达式中使用的函数2.1.2复杂事件复杂事件往往被定义为由一些原始事件或其他复杂事件复合组成。复杂事件含有特定的事件模式,即原子事件相互关联进行事件之间的一系列组合操作构成事件模式[9]。1)基本的无时态复杂事件构造函数·AND(A),如(E1AE2)表示两个事件同时发生。●OR(v),如(E。VEz)表示两个或多个事件至少有一个发生。●NOT(1),如(]E)表示没有发生特定事件,常与AND,OR结合。2)时序的复杂事件构造函数·SEQ(;),意味着两个事件按一定的顺序发生,(El;Ez)表示E2发生前,E1已经发生,即E1结束在E:发生前。●TSEQ(:),表示事件的时序约束,TSEQ(E1jE2,tf,k)表示事件E1和E2发生在时间段[oI,tu],也意味着白≤dist(E1jE2)≤tu)。·Aperiodic,SEQ+(;+),表示在特定的时问间隔内不定期的发生某事件·TSEQ+(:+),非周期时序操作,TSEQ+(E,tf,气)表示在时间段‰tu]不定期、无规律的发生事件E。●WITHIN,事件间隔约束,VVITHIN(E,c)表示发生事件实例e,等同于interval(e)≤t。在现实生活中,这些操作有利于构造复杂事件,一个复杂事件可以是以上一个或几个操作的组合发生。一型嗡堕删;塑囊 浙江大学硕士学位论文第2章复杂事件处理技术综述2.2复杂事件检测方法复杂事件的模式定义形式多样,也有很多检测方法,主要有基于Petri网的事件检测方法、基于有向图的事件检测方法【1叭。另外,基于有限自动机的检测方法和基于匹配树的检测方法将在下文结合复杂事件处理引擎详细介绍。2.2.1基于Petri网的事件检测方法经典的Petri网【11】是简单的过程模型,主要包括四种元素:·Place:库所,用圆形节点表示●Transition:变迁,使用方形节点表示·Arc:有向弧,表示库所和变迁之间的有向连接·Token:令牌,标记库所的动态对象,可以在库所间移动如果一个变迁的每个输入库所都拥有令牌,那么该变迁即为被允许,当一个变迁被允许时,变迁将发生,输入库所的令牌被消耗,同时输出库所产生令牌。基于Petri网的事件检测方法,将每个事件模式可以表示成一个Petri网,当给定复杂事件模式,可以将组成该模式的所有操作转化成一个个Petri网,并组合成一个大的Petri网。其中事件作为库所,当接收到一个原子事件,Petri网的一个库所获得令牌,代表与它通过有向弧连接的变迁被允许。当符合事件模式的变迁发生,那么它的所有输入库所的令牌将被消耗,对应的输出库所将产生令牌。Petri网中令牌传递的经过显示了事件检测的过程,当令牌到达最后一个库所,说明一个复杂事件被完全的检测出。如图2.2为复杂事件模式((EIIE2),E3)的Petri网,当接收到事件El,输入库所El的令牌被消耗,变迁tl发生,表示模式(E1IE2)的库所产生令牌,之后事件E3发生,输入库所E3产生令牌,变迁t3的所有输入库所都获得令牌,从而t3发生,最后库所((EllE2),F3)产生令牌,事件模式检测结束。 浙江大学硕士学位论文第2章复杂事件处理技术综述图2.2基于Petri图的事件检测方法图Petri网的表示算法非常简单,但它的缺点是当事件模式越来越复杂,组成的Petri网非常庞大,查询条件很多,算法执行速度较慢。因而,如何将Petri网分割成多个部分,分发到多个机器上并行处理是一个非常有意义的难题。若按事件操作符的粒度分割Petri网,每台机器执行Petri网的一部分,需要处理令牌的接收和传输。令牌到达最终库所节点时,即完成了复杂事件的检测过程。2.2.2基于有向图的事件检测方法事件有向图的每个叶子节点接收原子事件,每个内部节点代表一个事件处理的操作,节点之间通过有向边连接。当原子事件发生,相应的叶子节点被激活,从而激活与该节点相关联的其他节点。激活一个节点表示一个事件的发生,也会连续激活相关的多个节点,当最终的接收节点被激活时,复杂事件检测完成。-,、、(ElIE2).E3图2.3基于有向图的事件检测方法图E1事件到达,使得E1节点被激活,从而激活EllE2节点,ElfE2节点中存储事件状态,然后当E3事件发生时,E3节点被激活,从而激活(EllE2),E3节点,§ 浙江大学硕士学位论文第2章复杂事件处理技术综述由于(EIIE2),E3节点是一个合并操作,根据有向边的上一个节点已经存储EIIE2的发生,最终复杂事件((E1IE2),E3)被检测出。基于有向图的事件检测方法的优点是可以处理多个查询,一个有向图包含多个逻辑节点,过程相对简单,并且有利于分布式处理。缺点则是事件处理过程不如Petri网统一。根据操作符语义,有向图中的每个节点可以表示成不同的事件状态。Petri网union操作只要转发事件,而有向图的conjunction操作需要存储事件并处理。2.3复杂事件处理发展历程虽然事件、模式匹配等概念在二十多年前早被提出,近几年复杂事件处理技术又成为热门主题。复杂事件处理的基础是事件定义语言,操作语义,事件检测算法,和与数据库集成进行事件处理。事件流处理应用的出现又为复杂事件处理带来新的挑战,提出新的需求。分析比较复杂事件处理技术与主动数据库、数据流管理系统的异同点,能够更好的理解该技术。2.3.1主动数据库对于传统数据库,用户只能通过执行相应的数据库命令或应用程序对数据进行存取,相对传统数据库的被动性,主动数据库能够根据数据库状态,使用触发器等进行监控,条件触发时,主动响应做出反馈,执行某些操作【l21。主动数据库提供一个自动“监视”模块,通过事件检测并采取后续行动的方法被定义为ECA(Event.Condition.Action)规则[131。规则包括三个要素:事件、条件、动作。1)事件定义为由一些原子事件和一系列操作组成,原子事件如数据库系统在运行过程中发生的状态改变,用户可以根据具体需求定义简单或复杂事件。2)ECA的条件即检测事件模式的发生,如对某个特定的数据库状态的一种假设,可以用某种逻辑公式表示一个条件,也可依据逻辑运算构造更复杂的条件。3】当满足条件时,相应的动作将被触发。动作如执行一个外部程序,或完成 浙江大学硕士学位论文第2章复杂事件处理技术综述一组数据库操作,从而影响其他ECA规则的触发。当事件Event发生时,如果满足给定的条件Condition,然后执行相应操作Action。如输入两个股票报价(事件),第二个股票报价更低(条件),计算两个报价的价格差并将结果保存到数据库表中(动作)。主动数据库有多种实现途径,最常用的是基于事件驱动的ECA规则的触发器,但具有一些缺陷:11触发事件往往是简单事件。如对数据库操作的权限管理规则,对非标准数据库的相关完整性规则等,缺乏从简单事件构造复杂事件的能力,也没有完善的机制允许用户自由定义所需的事件规则。2)现有的触发器技术缺乏业界统一标准。因为各关系型数据库厂商实现触发器的途径不一样,其定义的语法和语义也各不相同,对软件环境具有较强的依赖性,不利于数据库的移植和代码的重构。31规则执行方式的不完备性。当事件发生前或发生后,如果满足条件,那么规则处于触发状态,动作将被执行。目前关系型数据库一般只支持立即执行方式,对于推迟到事务末尾执行的延迟式和具有并发/并行执行的并发式,由于实现机制的复杂性,目前尚未实现。2.3.2数据流管理系统DSMS(DataStreamManagementSystems)[141数据流管理系统与数据库具有一些相似处,而且可以处理大量的实时数据流输入。在实际处理过程中,数据从外部数据源或其他应用中以流的形式连续不断的流入,数据流序列具有数据量庞大、到达顺序不可控、流入速度不均匀等特点。DSMS最重要的特征是操纵持久化关系数据和连续数据流。支持连续数据流处理查询,如标准SQL.1ike数据库查询语言。数据库查询只执行一次,而连续查询是对事件流的无限执行。由于有限的时间和空间资源,DSMS不能存储所有的数据流再进一步连续查询。解决连续查询的通用技术是使用有限滑动窗口,常用的有时间窗口和长度窗口。查询结果可以持久化存储到数据库,或作为另一个事 浙江大学硕士学位论文第2章复杂事件处理技术综述件流输出。DSMS需要对数据流进行聚合计算,或与关系数据库关联进行某些属性的匹配。DSMS一般包含的模块有:1)输入适配器,由于数据流的实时性和持续性,可以对实时输入流起到一定的缓冲作用。2)由于数据量较大,对完整的数据流进行存储是没必要也是不可能的,因为用户只关心感兴趣的信息,因此,系统应存储最近有用的数据流,以及系统进行规则监控时需要访问的历史数据。3)系统进行连续查询,应具有查询存储器,提供修改查询,根据具体的查询条件采用不同的查询优化方法进行并发处理。4)输出适配器,将查询结果通过数据缓冲区输出。基于事件驱动的DSMS接收实时数据流输入,进行持续处理,不仅拥有处理复杂事件检测的功能,而且能根据事件规则进行计算分析从而采取措施,存储结果或重新演示。在商业智能方面,DSMS应用广泛,可以处理大量数据集,实现基于窗口机制的事件检测,进行连续查询操作,采取进度安排的优化调度策略(Scheduing)和负载脱落(Loadshedding)等措施提高处理性能。然而,因为系统的通用性,不能高效地实现复杂事件处理功能,因而数据流管理系统和复杂事件处理模型各有优劣,能够有效地把两者结合使用将发挥更大的优势。2.3.3专有的复杂事件处理系统传统数据库主要存储静态数据,持久化到硬盘中,再对存储的数据进行查询等操作。而CEP主要处理动态数据,是面向数据流的处理,基于内存的计算,更专注于复杂事件模式匹配,注重数据的时效性。复杂事件处理往往和SOA(ServiceOriemedArchitecture)面向服务的体系结构相结合,如图2.4所示。事件往往由企业信息系统、数据库、RFID读写器获取,在日常生活中,企业信息系统如ERP,SCM,CRM等产生成百上千的事件,这些事件通常是记录系统运行活动的数据和消息。事件收集后,首先由事件处理引擎EPA(EventProcessingAgent)进行预处理,包括过滤重复事件,修正错误,格式匹配等,然后事件被传输到事件总线,根据一定的规则,聚合为一个复杂事件模式,发送给订阅者,被检测的复杂事件驱动信息系统如BAM,BPM等执行其他 浙江大学硕士学位论文第2章复杂事件处理技术综述活动。其中,规则和模式可以通过模型工具预定义,也能从工作流中导出。这个架构主要获得事件进行聚合,将检测结果发送给事件订阅者,提高系统的敏捷性和响应性。图2.4企业信息系统中的复杂事件处理架构图2.4复杂事件处理引擎复杂事件处理系统包括:CEP规则集和CEP引擎。CEP规则规定处理事件的方法,反应了一定的条件。CEP规则衡量事件间的联系是否符合某种特定的条件,如果条件满足,那么规则触发。2.4.1复杂事件处理引擎特点复杂事件处理引擎的特斛151主要包括:1)CEP系统接收连续输入,可能是无限的事件流 浙江大学硕士学位论文第2章复杂事件处理技术综述2)事件流需要进行实时处理,要求较低延时3)输入的事件流不稳定,如事件到达比率多样,某些时刻事件数量巨大,部分事件在传输过程中丢失,事件的时间戳不准确等。4)来自外部的数据源实时输入的事件之间具有较强的时间关联性,而不像中央数据库或持久化存储中的数据没有时序性。5)CEP系统需要实时处理海量事件和查询操作,其中仅有一小部分是有意义的检测结果。6)CEP系统往往侧重在事件与事件模式的关系,而不是关注单一的事件。需要联合不同数据源的事件,从而推理出更高水平有意义的信息。7)与传统数据库相比,CEP系统处理侧重实时事件,而不是关注历史数据。8)CEP系统遵循数据主动、行为被动模式,实现连续处理,并通知用户,而传统的数据库遵循行为主动、数据被动模式,先存储数据,用户手动查询结果。目前已有的CEP引擎根据事件处理语言可以分为两大类:面向流和面向规则的CEP引擎。面向流的CEP引擎【161有MicrosoftStreamlnsight、OracleCEP、IBMSPADE、Esper等,而面向规则的CEP引擎[17】有IBMAmit、TIBCOBusinessEvents、JBossDroolsFusion等。在此选取两个较主流的开源引擎Esper和DroolsFusion进行简单介绍,下文将对这两种不同类型的规则引擎进行基本原理分析和性能测试比较。2.4.2EsperEsper是一个复杂事件处L里(CEP)和事件流处理(ESP,EventStreamProcessing)相结合的引擎,可以监控实时事件流,当事件发生时,满足特定模式,触发某些动作。这正好与数据库的操作顺序相反,一般数据库先存储数据后进行查询操作,而Esper存储查询条件,接收数据流的输入,匹配复杂事件模式。复杂事件处理已成为计算机发展的一个新趋势,目前已有数家企业专注复杂事件处理引擎的研究,投身到该市场中,常见的应用实例包括自动算法交易、BAM业务活动监控、 浙江大学硕士学位论文第2章复杂事件处理技术综述欺诈检测、模式检测、事态感知掣18】。Esper提供Java和C撑语言支持,是一个可嵌入式的轻量级复杂事件处理引擎,它的另一个优点是可以在开发环境中独立运行,更容易进行单元测试,同时引擎实现面向对象设计,支持动态类型,可以处理模式演化。Esper可以检测所有事件模式,从简单的与、或、非操作到复杂的状态机,拥有丰富的数据窗口,可以对数据集做交汇、合并处理,以及完备的事件模式语言和基于NFA正则表达式的模式匹配【19]。另外,Esper的EPL语言可扩展很好,使用lambda函数结构处理复杂事件分析。2.4.3DroolsFusionDroolsFusion是Drools业务逻辑继承平台的一部分,是支持CEP和ESP的事件处理引擎,在Drools专家系统规则引擎的基础上,增加了复杂事件处理模块,具有很多特征:·支持事件处理,具有合适的语义来定义·可以对事件进行过滤、关联、聚集、组合·支持事件流的处理●为了处理事件之间的时间关系,支持时间约束模型·使用滑动窗口保存有意义的事件●使用统一的时钟,支持会话作用域·允许CEP用例的事件容量定义·支持主动或被动激活规则·支持事件输入适配器Esper和DroolsFusion各有优势,Esper作为轻量级的复杂事件处理引擎,可以即插即用,处理性能也相当惊人,而DroolsFusion的优势在于使用Rete算法到更优化的ReteOO算法,和最新的PHREAK算法,通过节点共享、状态暂存等方式对规则进行优化,同时拥有较完善的规则管理工具,使得规则的定义、编辑、调试、部署更方便。针对海量的数据流,单一节点的复杂事件处理引擎往往不能14 浙江大学硕士学位论文第2章复杂事件处理技术综述满足高吞吐量、低延时的性能要求,因此,实现分布式复杂事件实时检测系统具有重要意义。2.5分布式实时流处理框架为了实现处理事件流的分布式复杂事件实时检测系统,采用Storm分布式实时流处理框架‘201。本节主要介绍Storm的框架,以及选择Storm的原因。Storm是一个分布式实时流处理平台,运行在Storm集群上的应用被称为拓扑结构(Topology)【2¨。2.5.1StormToplogy一个Storm的拓扑结构是整个计算的数据流图,其中的每个元素被称为Spout,或Bolt,中间通过数据流(Stream)传输。数据流是没有边界的数据元组(Tuple)序列,一个数据元组是一串任何类型的事件对象。数据流的输入来源是Spout节点,可以从外部应用程序读取数据,如股票交易数据、传感器测量值或程序的日志信息。数据流被Bolt节点消费,Bolt作为逻辑计算节点,处理数据流,可以发送到下一个Bolt节点进行进一步的逻辑计算。Bolt的处理逻辑可以是多样的,如对数据流进行过滤,聚集,连接等复合计算,也可将数据流存储到数据库。如图2.5是拓扑结构的一个例子。图2.5StormTopology图Topology可以认为是Storm运行计算逻辑的蓝图,在运行时,topology的每一个组件将运行一些任务(Task)。同一个组件中的每个任务执行相同的逻辑代码, 浙江大学硕士学位论文第2章复杂事件处理技术综述但是使用其他线程执行在不同实例。一个任务从输入队列接收一组事件,进行处理,也可发送新的tuple作为事件输出流。数据流可以根据流分组(S订eamGrouping)策略进行分发,如shufflinggrouping随机分发数据流,allgrouping广播式发送,每个Bolt都将接收到一份数据流,fieldgrouping按tuple的字段分组。总的来说,Topology代表一个完整的业务处理逻辑图,主要由Spout和Bolt组成,数据流在Spouts和BoRs之间流动。Storm集群可以同时运行多个Topologies。一旦Topology被提交,将永远运行,直到手动杀死进程。提交的Topology运行在Storm集群上拥有多个worker进程。每个worker运行Topology的一部分tasks,在运行过程中workers和tasks的数量不可以被改变。每个Bolt任务从输入队列接收数据,并发送数据给下一个Bok。而Spout只能发送数据。任务节点之间的交互都通过消息中间件完成。2.5.2StormClusterStorm集群包括一个主节点和多个工作节点。主节点Nimbus运行守护进程,负责接收提交的topologies,给I作节点布置任务,分配代码及故障检测。每个工作节点都会运行一个守护进程Supervisor,监听工作,控制工作进程的启动与销毁。此外,Zookeeper是针对大型分布式系统的可靠协调的开源系统[221,提供配置维护、命名服务、分布式同步、组服务等功能。一坠z。。keeper|Supervisor旦FNimbus㈤鼯Zookeeper㈢赢5upervsorL—————————_-1Supervisor|图2.6StormCluster图由于Nimbus和Supervisors是无状态,快速可恢复的,Storm依靠Zookeeper保存他们的配置和状态,使其具有很好的健壮性。Storm编程模型有利于开发者 浙江大学硕士学位论文第2章复杂事件处理技术综述建立topology,专注于应用逻辑,而不需要关心组件的分布、交互与底层网络传输。然而,即时是简单的拓扑结构,仍需要编写许多代码。值得关注的是Storm编程抽象逻辑与复杂事件处理过程较相似,Storm的数据(tuples)可以作为事件(evem),Spout代表事件源输入适配器,Bolt代表复杂查询操作,如对事件进行过滤、聚集、连接等。2.6本章小结本章主要阐述复杂事件处理技术的现状,首先对原始事件和复杂事件下定义,对基于Petri网和基于有向图的事件检测方法进行详细介绍,接着叙述主动数据库,数据流管理系统的特点,分析它们与复杂事件处理系统的异同点。同时对复杂事件处理引擎进行简单介绍,最后,为了实现分布式复杂事件实时检测系统引入分布式实时流处理框架Storm。 浙江大学硕士学位论文第3章复杂事件处理引擎选型第3章复杂事件处理引擎选型复杂事件处理引擎是目前较主流的信息系统,用于收集不同类型的事件,主动检测,系统地进行分析、联系、处理。CEP引擎的应用较为广泛,如网络传感器,业务活动监控,算法交易系统,面向服务架构等。CEP引擎的一个本质特征是实时处理事件。一般地,事件处理的越快,说明系统越好。检测结果越快速越具有优势。目前有许多竞争产品,每个都有独特的语言、架构、数据模型、数据处理CEP技术。然而,考虑到当前的技术平台各不相同,CEP引擎的基准遇到一系列的挑战【23]:11缺少统一标准。由于没有标准的查询语言、数据格式、语义和术语,很难提供统一的CEP引擎接口。2)多种领域的应用广泛。CEP已经被应用在许多独立的领域,每个领域都有自己特定的需求,这意味着需要设计多个工作负载和数据集实现多样的应用场景。3)指标。除了常用的指标:吞吐量,响应时间,正确性(由于事件到达的顺序可能导致复杂事件检测结果不准确),引擎还需要有能力适应不同负载的变化,可能的预测,事件重演,以及处理模糊模式等。目前已有的CEP引擎根据事件处理语言可以分为两大类:面向流和面向规则的CEP引擎。面向流的CEP引擎有MicrosoftStreamlnsight、OracleCEP、ⅢMSPADE、Esper等,而面向规则的CEP引擎有IBMAmit、TIBCOBusinessEvents、JBossDroolsFusion等。因此本章分别选取两个较主流的开源引擎Esper和DroolsFusion为代表,对面向流和面向规则的CEP引擎进行分析比较。3.1EsperEsper是一个事件流处理ESP和复杂事件处理CEP相结合的引擎,可以监控实时事件流,当事件发生,满足特定模式时,触发某些动作。Esper提供Java和C≠}语言支持,是一个可嵌入式的轻量级复杂事件处理引擎,它的另一个优点是可 浙江大学硕士学位论文第3章复杂事件处理引擎选型以在开发环境中独立运行,更容易进行单元测试,同时引擎实现面向对象设计,支持动态类型,可以处理模式演化。3.1.1事件流处理过程如图3.1描述了Esper的事件流处理过程,Esper的输入适配器接收大量高速的实时数据流,历史数据访问层获取数据库持久化数据,加载到Esper引擎中。Esper引擎可以注册Statement,并绑定一个监听器或订阅器,使用事件查询语言定义因果关系模式等规则,当查询条件满足时,监听器被触发,执行相应的动作,如由输出适配器输出检测结果。图3.1Esper事件流处理架构图Esper提供的两种机制:事件模式和事件流查询。11Esper的EPL事件处理语言描述基于表达式的事件模式匹配,通过状态机检测匹配期望存在的事件或事件组合。21Esper的事件流查询功能提供窗口、聚合、连接和分析等函数处理事件流。 浙江大学硕士学位论文第3章复杂事件处理引擎选型这些查询主要通过EPL语言实现,将需要构造的数据增加到一个事件流中,并基于事件驱动的复杂事件处理引擎,对实时流中的数据进行处理,获得需要的结果。3.1.2复杂事件模式匹配Esper查询语言提供丰富的语法,可以表达复杂的逻辑关系,可对事件进行过滤、流聚集,拥有滑动窗口,允许事件流之间的连接和外连接,允许访问关系型数据库,实现实时数据流与历史数据的集成等特征。Esper使用EPL语言表示事件规则处理复杂事件,表现形式与SQL语句类似,如表3.1所示。表3.1EPL事件规则定义EPL具有丰富的语义进行事件流处理,包括过滤、聚集、连接、事件窗口和因果模式匹配。在股票市场中,股票放量上涨是指成交量急剧上涨,股价也同步上涨的一种量价配合现象,量增价涨意味着该股将出现上升行情,如定义股票放量上涨的规则:30秒内,每5秒获取股票实时交易数据,若连续3次股票的成交量翻倍,股价上涨,那么判定该股有上升趋势。股票对象StockTiek包括股票代码stockid、股票名称stockname、股票价格price、交易股数volume、交易总额amount和交易时间timestamp。使用Esper语言定义股票放量上涨的规则如表3.2所示。20 浙江大学硕士学位论文第3章复杂事件处理引擎选型表3.2Esper股票放量上涨规则定义EPL语言与SQL语言很类似,以上的规则语句也较简单易懂,其中.>表示followby,定义三个连续发生的股票事件sl、s2、s3,都为StockTick类型。sl和s2两事件在10秒内发生,s2的股票价格大于s1的股票价格,并且成交量为s1的两倍,s2和s3同理,因此如果连续发生的三个股票事件符合这种事件模式,则判断为股票短时间内股票放量上涨。Esper使用动态状态树原理进行模式匹配,在编译过程中Esper会生成一棵多叉树evaluationtree[241。因此,根据pattem中的操作符优先级,Esper对股票放量上涨规则生成的动态状态树如图3.2所示,编译时,Esper生成的动态状态树包括RootState、EveryState、FollowbyState、FilterState四个节点,从根节点开始,匹配最左孩子节点,模式匹配顺序从(1)到(14),当第一个过滤条件满足时,FilterState退化,动态状态树新增GuardState节点,用于匹配timer:within条件,当满足时,然后匹配FilterState2,同理,匹配GuardState2,直到所有状态匹配,最终返回到根节点,此时,根节点做两部分处理,1)若RootState为true,把结果通知给Listener,2)重新启动子节点EveryState,开始Everypattern的匹配。整个匹配过程中,动态状态树在不断变化。2l 浙江大学硕士学位论文第3章复杂事件处理引擎选型图3.2Esper动态状态树图Esper处理一个事件的流程图如图3.3所示,首先EPRuntime发送事件,由EPRuntimeImpl处理事件,进行模式匹配,若匹配不成功,处理过程结束,若匹配到达根节点,监听器发现事件模式匹配成功,执行派遣工作,把匹配成功的事件增加到队列中,执行用户定义的后续操作。 浙江大学硕士学位论文第3章复杂事件处理引擎选型是processThreadWorkQueueend否图3.3Esper处理事件的流程图3.2DroolsFusionDroolsFusion是支持CEP和ESP的事件处理引擎,在Drools专家系统规则引擎的基础上,主要负责复杂事件处理行为的一个模块,满足业务规则和事件处理查询经常变动的需求,适应新市场条件,做出立即响应。3.2.1事件处理模式规则引擎一般可以处理数据和规则,计算应用结果,也没有太多的要求规则引擎应该如何呈现事实,也因为处理本身是时间无关的,这满足大部分应用场景。然而,一些应用需要实时或近实时处理事件,因此时效性变得越来越重要。DroolsFusion提供两种事件处理模式:云模式和流模式。f1)云模式CloudMode在云模式下,引擎不区分事件和事实,把工作空间内的事件视为事实,没有时间的概念,尽管事件在插入引擎时被赋予了时间戳,也不能判断事件的年龄,因为没有现在的概念,也不需要进行时钟同步。由于事件的无序性,没有自动的 浙江大学硕士学位论文第3章复杂事件处理引擎选型生命周期管理,引擎不需要对事件排序,看待所有的事件都在无序的云中,从而进行规则匹配,当不需要时只能显示的删除事件。(21流模式StreamMode当处理事件流时,需要选择流处理模式,在流模式下,插入到引擎的时间必须按时间顺序,引擎强制使用会话事件进行同步,因此可以处理多种事件之间的时间运算。流模式对复杂事件处理提供三种支持:滑动窗口,自动的生命周期管理,使用消极模式自动将规则延迟触发。Drools是面向规则的处理引擎,从产生式存储器获取规则集,从工作内存读取事件,通过基于ReteOO算法的推理引擎模式匹配,产生议程结果。ProductiOilMemoryInferenceEngine(Rete00/Leaps)PatternMatcherWorkingMemory图3.4Drools规则匹配模型图如图3.4为一个完整的Rete规则匹配流程:一个或多个事实被插入到Rete规则网络,网络根据配置的规则进行模式匹配,并为事实创建工作内存节点元素,对于触发规则的事件创建将要执行的动作并放入议程中,议程根据触发规则优先级确立触发次序,最后执行动作。3.2.2复杂事件模式匹配DroolsFusion采用Rete的改进算法ReteOO,实现面向对象设计,进行复杂模式的匹配。Rete算法[25】是一种高效的可用于实现规则产生式系统的模式匹配算24 浙江大学硕士学位论文第3章复杂事件处理引擎选型法。Rete网络是由四种节点构成,分别为:输入起始节点rootnode,单fact的条件匹配one—inputnode,多facts的联合two—inputnode,终止节点terminalnode。其中one—inputnode又可以细分为Typenode,用于定位事实属性和确定类型,Alphanode对事实的属性进行匹配判断。two·inputnode又称为Betanode,实现多个事实的关联与匹配。Drools规则定义语法为“whenconditions,thenactions”,如股票放量上涨的规则可以定义为如表3.3所示。表3.3DroolsFusion股票放量上涨规则定义packagestocktickimportvlis.zju.edu.cn.bean.StockTick;declareStockTick@role(event)endrule’stockrising‘dialect’'java”when$s1:StockTick(volume>0,price>0)fromentry·pointstockstream$s2:StockTick(thisafter[0,10s]$sl,stockid一$s1.stockid,volume>2(2+$s1.volume),price>=$s1.price)fromentry-pointstockstream$s3:StockTick(thisafter[0,10s]$s2,stockid一$s2.stockid,volume>2(2+$s2.volume),price>=$s2.price)fromentry—pointstockstreamthenSystem.out.prmtln(”stockrising!”);end输入股票数据流事件stockstream,检测连续发生三个股票事件,成交量翻倍增加,并且股票价格增长,则判为股票放量上涨。以上规则可以构建成一个Rete网络,如图3.5所示。 浙江大学硕士学位论文第3章复杂事件处理引擎选型≤≥一A1aNo>\,厂77≯八℃曲、BetaNode够、◆◇—0\、\∑/——~、坐/\\seiect映\rice>O\\澶\jiEnd图3.5DroolsFusion股票放量上涨规则的Rete图Rete算法的优点在于:1)节点共享(nodesharing),不同规则之间含有相同的模式,可以共享同一个节点,减少了规则中重复模式(pattern)的计算;2)状态保存,事实集合中的每次变化,其匹配后的状态都被保存在alpha和beta节点中,进行下一次匹配时,若事实集合发生变化,Rete算法通过保存操作过程中的状态,其实大部分结果不需要改变,避免大量的重复计算,适合事实集合变化不大的系统设计。3.3性能测试实验CEP引擎接收事件并进行规则匹配,其中许多事件是与规则无关的,通过发送一定比例的干扰事件模拟真实情况,发送的事件中部分能满足规则,另一部分事件与规则不匹配。调整比例参数,增加不相关事件的数量,测试不同的干扰事件数量对CEP引擎的影响。26 浙江大学硕士学位论文第3章复杂事件处理引擎选型性能测试在一台DellOptiplex330ogN上,Intel奔腾双核2.93Gt-lz处理器,3.2GB内存,WindowsⅫ操作系统。Esper和DroolsFusion都使用Javal.6版本。Esper4.7,DroolsFusion5.5。主要对吞吐量和延时两方面进行测试‘垌。3.3.1延时测试延时测试衡量一个模式被检测所花费的总时间,从发送第一个事件到引擎,直到模式被完全匹配的整个过程的时间开销。其中不考虑引擎初始化时间。发送连续的事件序列,延时公式为Latency(Xn一Ⅳm)=瓦。+R2+⋯+L。+k,+R2+⋯+矗。+疋n“bnck其中x。表示与模式完全匹配的事件序列,按正确的时间顺序发送。N。表示干扰事件,是与模式不相关的事件或顺序不匹配的事件。公式的计算结果为总时间开销,包括发送所有事件的时间和模式被检测到发送回调的时间。模式l:A_B(whereID=A.ID)_C(whereID=A.ID)表示ID相同的三个事件连续发生。第一个测试,无干扰事件:只发送A(1),B(1),C(1),测量从发送事件A到模式被检测的总时间。第二个测试,增加干扰事件,计算总时间开销,发送序列为A(1),YtimesB(-1),B(1),YtimesC(-1),C(1),其中Y分别取值为50,100,200,500,1000,2000,3000,4000,5000,6000,7000,8000,9000,10000。表3.4延时测试结果(单位ms)Y=0Y=100Y=200Y--500Y=1000Y=2000Y=3000Esper11142024313840Drools2436486693102118Y=4000Y=5000Y=6000Y=7000Y=8000Y=9000Y=10000Esper43444546505154Drools127136142204210218287Y=0,第一个无干扰事件的测试结果显示Esper延时更低。随着Y增加,干扰事件总数为2*Y,两个引擎的延时线性增长,说明干扰事件的数量对两个引擎的处理性能都有明显影响,并且如图3.6所示DroolsFusion的延时增长速度更快。27 浙江大学硕士学位论文第3章复杂事件处理引擎选型可以使引擎发挥更好的处理性能。同时也说明若能减少干扰事件数量,∞EXoC∞旦延时测试结果i—"-'0卜---Esperf/Drools FusionJ—_E}一f目√/r.i/r一,∥#..e99专9e。旷’00.20.40.60.811.21.41.61.82noiseeventsx104图3.6Esper和DroolsFusion的延时测试结果图3.3.2吞吐量测试吞吐量测试衡量引擎在多压力下的性能,向引擎发送大量事件,而且有多个事件模式需要检测。测试中的两个参数:事件总数,和事件噪音比率。吞吐量公式为:Throughput(Xn,‰)=Txl+Txz+⋯+瓦。+矗,+矗2+⋯+矗。+L口I曲口ck其中%表示与模式完全匹配的事件序列,按正确的时间顺序发送。Ⅳm表示干扰事件,是与模式不相关的事件或顺序不匹配的事件。公式的计算结果为总时间开销,包括发送所有事件的时间和模式被检测到发送回调的时间。三种测试模式:模式1:AandB(whereID=A.IO)-÷C(whereID=AID)模式2:c—D(whereID=C.ID),R 浙江大学硕士学位论文第3章复杂事件处理引擎选型模式3:AandC(whereID=A.ID)andD(whereID=A.ID)第一个测试,没有干扰事件:发送X次事件序列A(X),B(X),C()(),D(x),其中x取值为2,500,1000,2000,5000,10000,20000。事件总数为4*X,测量不同情况的时间开销。由于Esper和DroolsFusion都使用Java语言编写,因此在测试前对JVM进行参数设置,DroolsFusion测试时,设置参数“-Xms1G-Xmx1G”。测试结果如表3.5所示。表3.5吞吐量测试结果(单位ms)TotalEventsEsperDroolsFusionX=2843lX=5002,000138172X=1.0004,000234204X=2,0008.000405328X=5.00020,000862671X=10.00040,00016221016X=20.00080,00031841922X=50.000200,00077895219在无干扰事件的情况下,测试结果显示当事件个数较少时Esper的时间花销更小,即吞吐量更高,但随着X增加,事件数量越来越大,DroolsFusion显示出Rete算法的优越性,时间花销小于Esper,吞吐量更高。第二个测试,增加干扰事件,事件发送序列为:A(X),YtimesB(-1),B(X),C(X),YtimesC(-1),D(X)。其中x和Y同时增加:(X=2,Y=1),(X=500,Y=2),(X=1000,Y=3),(X=2000,Y=4),(X--5000,Y=5),(X=10000,Y=6),(X=20000,Y=7),(X=50000,Y=8)。表3.6有干扰事件的吞吐量测试结果(单位ins)(X,Y)V甜idEventsTotalEventsEsperDroolsFusion(2,1)812532(500,212,0004,000133203(1,000,3)4,00010,000235297(2,000,4)8.00024,000412438(5,000,5)20,00070,0009011016(10,000,6)40。000160,0001750218729 浙江大学硕士学位论文第3章复杂事件处理引擎选型l(20,000,7)80,000360,00033354328l(50,000,8)200,0001,000,0008415正确的事件序列为AⅨ),B(x),C(x),D(X),被发送x次,有效事件数量为4*X,干扰事件数量为2*X*Y。所以当X=50,000,Y=8时总的事件数量为4*X+2*X*Y=4*50.000+2*50.000*8=1,000,000,DroolsFusion处理100万事件时,由于Rete算法保存了事件匹配的中间结果,因此出现OutOflViemoryError错误,不在表中标注。为了与无干扰事件的测试结果作对比,将表3.5和表3.6总的事件数量除以处理时间转化为吞吐量如图3.7所示,当X=20,000,事件总数大于360,000时,引擎的吞吐量基本稳定。无干扰事件时,DroolsFusion的吞吐量比Esper更高,而当增加干扰事件时,Esper的吞吐量反而比DroolsFusion更高,每秒可以处理100,000个事件,因而说明,当规则数量一定,增加相同数量的干扰事件,对DroolsFusion处理总共事件的影响较大,Esper的处理性能更优。然而DroolsFusion使用Rete算法对规则进行优化,保存状态,更适合事件集合变化不大的应用。下文将详细叙述如何通过Storm和Esper结合实现分布式复杂事件实时检测。 浙江大学硕士学位论文第3章复杂事件处理引擎选型富矗芑m衣=3Q毛3巳工I---x104吞吐量测试结果O0.20.40.60.811.21.41.61.82xx104图3.7Esper和DroolsFusion的吞吐量测试结果图3.4综合比较实验结果显示Esper的处理性能更优,具有低延时、高吞吐量的优点,然而复杂处理事件引擎的设计需要考虑多种因素【27],如表3.7所示,对Esper与DroolsFusion的各方面进行比较。表3.7Esper与DroolsFusion比较EsperDroolsFusion事件定义语言易用性EPL(SQL-like语言)是集成事件流和静态数据是是事件定义的易修改是是处理多事件流是是可恢复性是掌否日志记录是是应用时间模型否有限 浙江大学硕士学位论文第3章复杂事件处理引擎选型消费VS非消费方法非消费非消费提取并使用事件中的数据是是事件模式检测是是时序关系好优秀聚合、否定等计算方法是是行动定义Java方法Java方法性能优秀好高可用性是+否Esper和DroolsFusion作为复杂事件处理引擎具有很多相似性:首先,Esper使用SQL—like语义编写查询规则,使得编程相对简单易学,Drools提供Java语言编写规则,whenconditions,thenactions。Esper可以对规则进行实时查询、增加和删除。在Drools中,规则被定义在文本文件中,编译成可执行的规则包,从而引擎中的这些规则包可以实时增加或删除。其次,Esper和Drools都支持数据流与静态数据的集成。Esper允许查询中使用用户定义的静态函数方法,同时允许连接访问数据库。Drools提供与Esper相似的方法,允许使用全局变量和全局方法,导入到规则和查询中调用。此外,Esper和Drools都不支持恢复性,只有商业版的Esper提供了系统崩溃后恢复的功能。Esper和Drools都支持日志记录,主要有利于系统调试;都支持扩展定义事件模式和事件间的时序关系。Esper允许对每一个复杂事件查询定义监听器,当事件模式匹配成功,所有导致该规则触发的事件作为参数传输。另一方面,Drools把事件作为最重要的,也可以导入全局的对象,在规则中的then子句中,任何动作将执行,通过调用导入的方法或事件。两者都支持使用Java方法定义的动作行为,引擎称之为模式匹配。然而,两者也具有一些不同处:首先,Esper将事件的每一类型都视为事件流,同时提供对多种事件流的定义,从而可以把事件插入到事件流中。Drools也可以接收不同事件流,支持不同类型的事件类型。另外,事件保存对事件流的引用,记录事件的来源,有利于事件因果追踪。32 浙江大学硕士学位论文第3章复杂事件处理引擎选型其次,Esper不提供应用时间模型,只提供引擎时间。Drools提供应用时间模型,但是要求事件必须按正确的时间顺序发送到引擎。此外,不得不提的是Esper支持point—in-time事件,而Drools中可以定义事件的持续时间,因而Drools拥有更丰富的时序操作。最大的不同点是Drools并没有提供高可用的特点,而EsperHA通过缓存、聚类、热备份实现可恢复性和高可用性。由于CEP引擎关于多种事件交互的模式匹配具有瓶颈,窗口的过期策略对查询的成本具有重要影响,若需要访问数据库存储的数据,吞吐量会下降,解决方法如预加载静态数据,可以提高性能,但前提是这些数据不是经常改变的,能够存储在内存中。因此,没有一个绝对优秀的CEP引擎适合所有应用场景,未来仍有改进的空间。综合比较分析,Esper作为轻量级复杂事件处理引擎,处理性能较优,本文将采用Esper作为复杂事件处理引擎,并结合分布式框架Storm,以实现更高实时性。3.5本章小结本章主要对不同类型的复杂事件处理引擎的基础原理的分析和比较,主要分为两大类:以Esper为代表的面向事件流的复杂事件处理引擎和以DroolsFusion为代表的面向规则的复杂事件处理引擎,分析事件流处理过程和复杂模式匹配,并对两个开源引擎进行实验与分析,探究其适合的应用场景和异同点,延时测试和吞吐量测试结果表明Esper的处理性能更优。 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现第4章分布式复杂事件实时检测系统设计与实现复杂事件检测是以事件为驱动,对信息系统的产生的海量数据进行实时处理,可用于检测系统中发生的特定行为模式,从而进行模式挖掘或事件预测等。复杂事件处理技术结合事件驱动架构和事件流处理,对数据的实时性要求较高,因此本文提出分布式复杂事件实时检测系统,采用复杂事件处理引擎Esper与分布式实时计算框架Storm的有效结合,以实现高吞吐量、低延时、复杂计算为目标。4.1数据分发策略为了获得更高的事件处理性能,采用并行事件检测方法。通过分析我们发现,大部分时间和消耗CPU的操作是事件的匹配过程。因此,当并行事件检测时,将事件分发,每个组件承担处理一部分事件。系统的数据主要包括实时事件流,历史数据和规则,数据分发的一般方法可以按照某属性或时间,为了减少干扰事件,有效利用复杂事件处理引擎的执行性能,本系统尽量把事件流与相关规则库集中在一个Esper引擎中处理,因此构造拓扑结构时,根据不同的规则分发和事件流分发,可以设计出多种拓扑结构。4.1.1基于事件流或规则分发的拓扑结构1)单节点若对复杂事件引擎不进行分布式框架处理,拓扑结构退化为单节点,即把所有规则和所有数据流集中流入一个EsperBolt,当规则集很大,事件流流速很快时,事件模式匹配性能下降,达不到系统性能需求。2)基于事件流分发的拓扑结构如图4.1所示,为了实现简单的分布式处理,可以根据事件类型或属性分发事件流,每个EsperBolt加载所有规则,而事件流按照每个域分组,Storm提供FieldsGrouping策略,将相同字段的事件分到同一个EsperBolt处理。如此,FieldsGrouping对事件流进行分组,减少每个EsperBolt处理的事件数量,可以提供处14 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现理性能,然而,这种拓扑结构的特点是规则相对简单,关注具体某类事件的事件模式。若规则不针对某类事件,而是检测所有事件流是否匹配某一事件模式,则该拓扑结构就退化为单节点。i,氡蠢黾泰N/夕j\I竺竺/。\/面i荔蕊小\\!:!:竺//7图4.1基于事件流分发的拓扑结构图31基于规则分发的拓扑结构若业务规则库中所有的规则可以分为几个大类,每个类别之问的规则不存在联系,则可以把规则分发在不同的EsperBolt中,事件流使用AllGrouping策略广播发送,每个EsperBolt都会收到所有数据流,从而检测事件模式。如图4.2所示,规则集rulesl,rules2,rules3无关,可以并列分组,若rules4规则较严格,匹配后的结果集是mlesl执行结果的子集,可以通过水平分组,由EsperBoltl先过滤部分规则不匹配的事件流,再传输给EsperBolt4对事件流进行rules4的匹配,同理rules2和rules5的分布。这种拓扑结构适合规则无关性特征明显的应用场景,减少单个节点的规则匹配数,可以提供处理性能,然而,由于事件流都会分发到每个EsperBolt,因此,与规则无关的事件就成为干扰事件,~定程度上会影响处理性能。⑨一S{言e 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现,/面面i卜、/,,,j\竺竺广\、,,面磊i於\\:竺!,//图4.2基于规则分发的拓扑结构图4)基于规则和事件流分发的拓扑结构若对规则集进行解析,分析出规则之间的相互联系,结合基于事件流分发和基于规则分发的拓扑结构,可以更有效的减少干扰事件与不相关规则之间的匹配,使规则和事件流集中在一个Esper引擎上进行处理,大大提高引擎的处理性能。如图4.3所示,rulesl,rules2,rules3是三类不相关的规则集,分别由3个EsperBolt加载,EsperBolt4和EsperBolt5匹配的规则集为EsperBoltl的子集,因此采用分流方式传输己满足条件的事件流,而EsperBolt6的处理逻辑可以是EsperBolt2和EsperBolt3的交集或并集,因此采用聚合的方式。能够合理利用规则特征构建基于规则和事件流分发的拓扑结构是最理想的目标。/<翌冀:/双\=:竺,,/严瓷[::蚕streams———·-t:::!!!参j、、默:,/百丢五面云卜、tStream八s竺!/\\“le”一/tStreams——————、\7。EsperBoltS八\\竺兰//tStreams/————、\\./7EsperBolt6\、tScreams入竺!/\\“le∞//tStreams,—————、\、、~一7西sperBolt7、图4.3基于规则和事件流分发的拓扑结构图璺⑨一 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现4.1.2构建拓扑结构本系统采用规则和事件流同时分发的策略,业务人员通过规则管理模块制定规则,解析所有规则之间的联系,生成一个合理的拓扑结构,Storm启动各节点加载相应规则,并实现事件流分发。首先,规则具有明显特征,一条规则往往关注一个或多个事件,因此它们是一对多的关系,而一个EsperBolt加载规则库的一部分,在理想的拓扑结构中,每个EsperBolt处理一个规则集,每个规则检测一个或多个事件,因此,EsperBolt、规则、事件之间的关系如图4.4所示。图4.4EsperBolt、rules、events关系图使用映射表记录三者关系,映射Map>表示boltid为key,rule集合为value,一对多关系,映射Map>表示ruleid为key,events为value,rule与event是一对多关系,又由于对事件进行多种规则检测,因此event与rule是多对多关系,从而推理出boltid与event也是多对多关系,如图4.5所不。图4.5EsperBolt、rule、event对应关系图较理想的动态拓扑结构是基于完备的规则解析器设计出理想的拓扑结构,采 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现用Storm的DirectGrouping策略,将规则和事件正确的分发到各个节点,减少规则冗余和干扰事件。本文实现的动态拓扑结构的解决方案是:实现简易的规则解析方法,分析规则与事件的关系,不考虑规则与规则之间的聚合与依赖,从而设计出按eventid和ruleid分组的策略,实现CustomStreamGrouping接口,制定具体业务逻辑的分组策略,基本过程是先按mleid将规则进行FieldsGrouping,根据event找出相关的rules,再进行FieldsGrouping,从而将规则与相关事件集中分发在同一EsperBolt进行处理。4.2架构设计4.2.1功能概述分布式复杂事件实时检测系统主要包括规则管理模块、事件收集器、分布式复杂事件检测模块、检测结果展示界面四大模块。其中分布式复杂事件检测模块最为核心。规则管理模块提供规则的编辑、编译、调试、部署的功能,系统提供基本规则模板,用户也可自定义复杂事件规则。事件收集器负责收集实时事件流,作为系统输入适配器,由用户指定事件类型和属性,将事件发送给复杂事件处理引擎进行模式检测。分布式复杂事件实时检测模块加载规则集,接收实时数据流,进行复杂事件模式检测,当特定事件序列发生时触发某些行为。本系统主要采用复杂事件处理引擎Esper与分布式实时计算框架Storm的有效结合,实现分布式复杂事件检测的实时性。由事件收集适配器作为Storm的数据输入,根据用户定义的规则集动态构造拓扑结构,通过规则或事件流的分发,实现复杂事件检测的并行处理。检测结果展示界面用于展示事件规则匹配的结果,从复杂事件检测引擎中获取检测结果信息,采用图形化界面进行直观展示。 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现业务人员图4.6用尸用例图业务人员根据业务需求使用规则管理模块制定规则,接入事件收集器数据流输入,系统运行后,可以通过展示界面查看检测结果。而管理员维护整个系统的所有模块,特别是分布式复杂事件实时检测模块的拓扑结构。各模块具体设计将在下文详细介绍。4.2.2总体架构根据分布式复杂事件实时检测系统的功能需求,本文设计的总体架构如图4.7所示。业务人员通过规则管理模块定义业务规则,规则编辑成功后保存在规则库中;接入系统的实时数据流使用事件收集器从外部收集,发送到消息队列中,或通过Storm的Spout直接从外部数据源读取业务数据流。分布式复杂事件实时检测模块实现Storm与Spring的集成,Storm根据Spring配置文件的信息初始化定义Spout和Bolt信息,其中Spout需要载/k--种类型的流:规则流,数据库历史数据流和实时事件流。Spout首先将规则进行分发,每个EsperBolt加载一部分规则集,构成完整的逻辑拓扑结构。EsperBolt启动前需要做的准备工作包括配置事件类型信息,载入初始化数据信息。启动后,EsperBolt接收Spout分发的规则流,并制定规则相应的触发动作,之后,EsperBolt接收流入的实时数据流进行模式匹配,若规则触发,监听器触发采取措施,如持久化检测结果到数据库,或将查询操作结果交由检测结果界面展示。10天 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现图4.7总体架构图首先系统启动前,用户配置业务规则和事件,使用规则管理模块制定业务规则,通过Spring配置文件定义事件类型,配置事件收集器的事件流输入接口,配置成功后启动系统,分布式复杂事件实时检测模块启动,从Spring配置文件初始化Spout和Bolt,并从规则管理模块加载规则库,构建拓扑结构,当启动事件流输入时,开始接收实时数据流输入,进行复杂事件检测,同时由界面动态展示检测结果,如图4.8所示。 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现O√用户制定业务规则、业务规则制定成功!定义事件类型,甲置事件流输入接口L/r、输入接口战功系统启动启动成功加载规则库。加载成功开启事t仁流输入r实时数据流输入检测结果查看检测结果展示4.3主要模块实现图4.8用户启动系统序列图4.3.1数据流输入分布式复杂事件实时检测系统接收来自不同数据源的事件流,用户可以定义感兴趣的事件规则,通过复杂事件处理技术对事件进行过滤、聚集、连接等复杂计算,匹配已定义的事件模式,从而进行预警或相应动作。通过分布式实时计算框架实现复杂事件检测的实时性,有效快速的采取措施,提高风险防范能力。系统的输入数据主要包括实时事件流、历史数据和规则三大类,设计通用的分布式复杂事件实时检测系统的数据流输入至关重要。1)事件流定义本系统设计通用事件类抽象为Event,包含事件时间戳,和一个Map存储所有属性名称与属性值。41 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现Event—fields:Map一timestamp:long+geFJelds0:Map+setFields(Map)*getTimestamp0:long+setTimestamp(10ng)图4.9通用事件类图事件收集器根据用户定义的事件类型和属性,把通用事件类型进行统一的格式转化。由于Storm是主动从多种数据源获得数据输入,主要有三种方式‘28]:●直接连接访问,外部设备作为服务端,Spout作为客户端,可以发送请求,从而读取消息,发送给bolts处理,如使用twitterstreamingAPI读取twitter消息。·消息队列,Storm具有主动性,数据源被存储在消息队列中,Spout从消息队列pop消息,常见的如从Redis中读取消息进行处理。·分布式远程过程调用DRPC,使用DRPCSpout从DRPC服务器端接收数据流进行处理。因此本系统主要使用第二种方式,使用事件收集器接入数据流,进行统一格式转化,发送到消息中间件,同时,分布式复杂事件实时处理模块的Spout从消息中间件实时读取消息。目前,使用Redis作为消息中间件,是一个高性能的key.value内存数据库,支持多种类型的value,插入读取操作简单,并且是原子性操作,效率较高。2)规则定义本文采用Esper复杂事件处理引擎进行事件模式匹配,规则由EPL语言定义,主要分为两大类:statement操作语句和query查询语句。其中statement是对事件定义的检测模式,主要面向应用,当模式匹配时,触发监听器执行动作,包括更新数据库等操作。而query可以对Esper运行窗口中的数据进行查询,主要面向用户,获得实时运行结果,进行界面展示,或将查询结果发送给用户。statement规则包括唯一标识ruleId,规则内容ruleContext,规则备注mleComment,规则状态mleStatus,事件集SeteventidSet。42 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现query规则除了包含statement相同的属性外,增加用户集SetuseridSet,将查询结果通知给感兴趣的用户。3)数据流定义事件收集器接收实时输入的数据流,用户需要制定事件流的类型和属性。Storm的Topology可以理解为数据流传输的有向图结构,每个Bolt节点需要确定输入流或输出流,其中上一个Spout或Bolt节点的输出流,即为当前Bolt节点的输入流,因此,输入流与输出流之间需要统一数据流定义规范,并且Topology中传输的数据流D唯一。Streanldr-componentId:Stringr-streamId:StringStreamld(Stringcomponentld)lStreamld(StringcomponentId.StringstreaⅢId)+getcomponentld0:String+getStreamld0:StringJ+equals(Object):booleanj+hashCode0:int图4.10StreamId类图数据流D,包括组件ID和数据流D。其中组件D即为Storm的Spout或Bolt的D,数据流Ⅲ默认为“default”,可以设置唯一数据流D名称。EventTypeDescriptor—name:String-fields:Fields—streamd:StringEventTypeDescrlptor(Stringname,S-[ring[]fields,StringstreamId)+getName0:String+getFields0:Fields+getStreamId0.String图4.1l事件类型描述类图针对事件流处理,如图4.11所示,事件类型描述EventTypeDescriptor包括事件名称name,事件属性fields,另外streamld唯一标识事件流,可以确定该事 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现件来自哪个事件流。Spout的输入流是从外部获得数据流输入,指定输入事件类inputEventType,在Spout中可以进行类型转换等操作后,输出数据流,因此,输出流包括事件类型名称和事件属性映射表,属性名称为主键,属性类型为值。设计Spout的数据流如图4.12所示。SpoutBean—inputEventType:String—outputEventType:String—outputFields:Map’getInputEventType0:String+setInputEventType(String)+getOutputEventType0:String+setOutputEventType(String)+getoutputFields0:Nap+setOutputFields(Map)图4.12SpoutBean类图Bolt的输入流为上一个Spout或Bolt节点,因此只需知道输入流类型,从Topology中可获得事件属性信息。在Bolt节点中进行逻辑计算后,输出数据流,因此,与Spout的输出流设计类似,包括事件类型名称和事件属性映射表。4.3.2分布式复杂事件实时检测模块分布式复杂事件实时检测模块主要是结合Storm分布式实时计算框架和Esper复杂事件处理引擎,由于Esper是轻量级引擎,而且Storm的优点是流式处理,两者有效结合,相得益彰,Storm使用Esper作为逻辑计算节点,从而不需要关注繁琐的逻辑代码,只需定义规则和事件流接口即可,使整个处理过程更加简单清晰。为了实现通用性,设计通用的事件流输入接口、规则输入接口、历史数据输入接口和通用逻辑处理类,具体实现如下。1)事件流输入类EventSpoutEventSpout从外部设备读取事件流,如内存数据库Redis,类图图4.13如所示,EventSpout包含事件属性fields,输出流收集器collector,数据库访问接口eventsRep。主要方法包括: 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现open方法,启动Storm,Spout加载拓扑结构上下文信息。nextTuple方法,主要用于读取消息并发射,如调用JedisPop从Redis读取消息,并发射数据流collector.emit(Listtuple)。declareOutputFields方法,声明输出流的属性。ack方法,当消息被完整处理时,接收确认的处理逻辑,如从消息队列中删除已经成功处理的消息。fail方法,针对消息传输超时或失败的情况,进行重发操作。close方法,在关闭Spout前需要关c|fj其他资源。EventSpout—fields:Fields—collactor:SpoutoutpuLCollectot【一eventsRep:EventsRepository+open(Map,TopologyContext,SpoutOutputColiector)+nextTuple0+declareoutputFields(OutputFieldsDeclarer)-ack(Object)+fail(Object)-close0+JedisPop0Object图4.13EventSpout类图2)规则输入类RuleSpoutRuleSpout加载规则库,并对规则进行分组发送,类图如图4.14所示,基本方法与EventSpout类似,在nextTuple方法中编写核心代码,设计topology,使用DirtectGrouping策略直接发送规则到制定Bolt,或根据属性进行FieldsGrouping,也可以AllGrouping广播分发。45 浙江大学硕士学位论文第4章分布式复杂事件实时捡测系统设计与实现RuleSpout—fields:Fields—collector:SpoutOutputCollector—rulesRep:Ru]esRepository+open(MaATopologyContext,SpoutOutputColleczor)+nextTuple0+declareoutputFields(OutputFieldsDeclarer)+ack(Object)+fail(Object)+close()图4.14RuleSpout类图3)历史数据输入类DataSpoutDataSpout用于静态数据,类图如图4.15所示,基本方法与EventSpout类似。nextTuple方法从数据库中访问数据,并发射给Bolts。静态数据包括:11对原始历史数据进行预处理后的统计结果,2)复杂事件处理检测结果,若系统宕机,可以加载检测结果作为Esper运行时窗口数据,增强系统可靠性,具体将在下文详细描述。【DataSpout—fields:Field8一collectorSpoutoutputCollectoo—dataRep:DataRepository+open(Map,Topologycontext,SpoutoutputC01lector)+nextTup]e0+declareoutputFields(0utputFieldsDeclarer)+ack(Object)1+fail(Object)+close0图4.15DataSpout类图4)通用逻辑处理类EsperBoltEsperBolt类设计使用典型的Builder模式,将复杂的Bolt对象的构建与表示分离,使用EsperBolt实现多种不同的表示。EsperBolt主要包括输入流和输出流配置,加载规则,逻辑处理交由Esper引擎进行处理。内部类Builder可以构建输入流建造者InputsBuilder,输出流建造者OutputsBuilder,声明规则建造者 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现StatementsBuilder,查询建造者QuerysBuilder,存储建造者KeysBuilder。EsperBolt类图如图4.16所示,私有属性主要包括三大类:1)EsperBolt的配置,包括输入流、输出流、规则、查询、数据、存储主键的定义。2)Esper引擎的框架,包括EPServiceProvider,EPRuntime,EPAdminstrator等。3)数据库交互方法EventsRepository。EsperB01t—inputAliases:Map一tupleTypes:Map一eventTypes:Map一statements:List一querys:Map一keys:Map>-epServiceProvider:EPServiceProvider-runtime:EPRuntime—admin:EPhdministrator—collector:OutputCollector一一taskid:int—eventsRepoEventsRepository—addInputA]ias(Streamld,String,Tup]eTypeDscripter)一addNamedOutput(String,String,String⋯)一addStatement(String)一addQuery(String,String)一addKeys(String.List)+prepare(Map,Top0109yContext,OutputCollec'cor)+execute(Tuple)+declareOutputFields(0utputFieldsDeclarer)+cleanup0+update(EventBean[].EventBean[])图4.16EsperBolt类图prepare方法可以配置拓扑结构上下文信息和该EsperBolt的配置,最主要的是配置Esper,并初始化,启动引擎EPRuntime,加载规则statements和querys,以及相应的监听器执行操作。execute方法是Bolt每接收一个事件就执行的逻辑,主要把事件发送到Esper引擎,或传递给下一个Bolt。declareOutputFields方法顾名思义就是声明输出流的属性。update方法,由于EsperBolt继承UpdateListener,当Esper引擎中事件模式匹配时,将触发update方法,把检测结果更新数据库操作。47 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现5)接入数据流,确定数据分发策略抽象业务逻辑,在XIVIL配置文件中,通过Spring定义事件流属性域EventSpout,规则属性域RuleSpout,和历史数据格式DataSpout,确定它们流向逻辑处理节点EsperBolt的分发策略,如图4.17所示。<;=o≯e::!:o墨e。“;=:≯=:三锉::≈;;!”饨二℃e‘“s:,:土:二o≥⋯):m#>“<一;:o#e=:j)(,五e§:>二/::#=,<,;=ope::j><一一基:11pat:£::0e:二::二::0:一一>(§!o∞:#?n^≈瞻。”=二二oS}o¥:导e0=f”≥(i:!:>《oeai:1^05·“:强.’7二二5.z?:.s:;.堪.e5;::.嚣o=:暑!a二”’‘;:o辩::i£tme-”o::≯::芝Y船:≈葛÷‘’vaZ矾=“i:二?⋯}’’;=o}o=:?:&及e。’’。i:≯i:F二e二矗5’’)口<’二:s:>t:,#:=带e::y’<一嚣二90:=”0a:&00=二:二=二0:一一>《譬=o书e:=¥oa难‘”矗}:暑铅:=:暑!ios”><二二#:、’<0e&£o:Bso’“o=;.虻二s,z-,r.;:o强.e5眷2r.毋o::暑!{二5’’≮;=o}e::?:酗&e。”o:带:=三一e£=≈≯}”Va二oe。“S::oi:{:a”’t£:o}e=甜o&f&e。’’:=昂=:己ejds8’<一二0:)<0e≈:0:a0:。”::譬.”二二5,:二:-5:0==.}s≯!r,耋。二:墨!i二”><一一:W搿ig0:=!^:_:*jeg。e豫t=0^o*j二0=0=y☆^=÷,jo、.?&=氍{z÷;o!蒂:÷每二o:!::x二t#:”>t;=。pe::j。o捌%e‘‘’二五≯::s=j:。”>盆(;=ope::i:雌。’+oo:≯::三Ve=:≈≯=”valje。’‘:=:!::i:二蠢es:二:”’,《#:。Pe==:oa地’“,¥犟=:F:j二矗s”j露(joe^o><。二:!:>(,£畿§o’?4.4关键技术研究图4.17XML配置文件4.4.1实时流与历史数据结合处理实时事件流和历史数据的结合用于解决两方面难题:1)由于规则千变万化,Esper引擎使用EPL语句描述多种事件模式规则,某些规则的匹配需要结合历史数据,如转账交易的监控规则,若当前交易额大于前 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现三个月转账金额的最大值,则认为这笔交易具有一定风险。该规则需要结合历史数据,计算前三个月转账金额的最大值,从而进行规则匹配。Esper提供EPL与SQL的结合,使用sql:database_name[“parameterized_sql_query'’]允许访问数据库,实现与历史数据的交互。考虑到Esper频繁访问数据库的效率低下,因此采用对历史数据进行预处理方法。●将规则进行分解,需要计算前三个月转账金额的最大值·DataSpout从数据库中加载前三个月历史数据,输入到BatchBolt,计算前三个月转账金额的最大值,供EsperBolt规则引擎处理,同时将统计结果更新到数据库中,如图4.18所示,HistorySpout用于加载前三个月转账交易。图4.18EsperBolt接收实时流和历史数据图2)对于窗1:3较长的规则,Esper受Java虚拟机的局限不适合存储大量数据,例如统计一年的事件总数,不应设置时间窗口为一年,每接收一个事件都进行计数,而是设置参数,每接收一个事件,检验时间是否满足条件,若满足,则计数加一。又如,统计每天服务器的用户访问量、每月用户访问量,可以利用每天用户访问量,再累计得出每月用户访问量。这类规则的条件相同,只有时间窗口不49 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现同,那么长窗口规则可以利用短窗口规则的匹配结果,如图4.19所示。因此,对于用户指定的长时间窗口规则,可以把规则进行分解,对历史数据进行预处理,减少复杂事件处理引擎的压力,更有效的执行检测。目前,依靠人为的对长窗口规则进行分解。图4.19EsperBolt结合实时统计结果和历史数据图4.4.2系统可靠性分布式复杂事件实时检测系统的可靠性要求系统连续不停机的运行,避免单点故障,不因某个物理机器宕机导致整个系统的崩溃,而且Storm框架提供三种处理系统故障的可靠API,保证消息的可靠处理。此外,当业务需求发生改变时,系统支持实时修改业务规则,实现动态生效。可扩展性包括横向扩展和纵向扩展。系统支持横向扩展,部署多个物理机器,随着业务需求的扩大,可以动态增加物理节点;同时也支持纵向扩展,满足服务器升级,随着硬件设备的升级而扩容,充分利用多核资源。首先,在保证消息处理方面,Storm框架提供三种处理系统故障的可靠API使用,包括:1)不可靠传输。事件在传输到目标地址的过程中发生崩溃,如果Spout产生事件比Bolt消费事件更快,那么Bolt的输入队列将溢出,导致内存溢出或内核错误,在这种情况下,Storm并没有控制事件队列长度。2)至少一次处理。Spout允许事件重发,如果在有限时间内acker没有收到确认消息,则认为事件丢失。Bolt接收一组事件tuple,并发送多组事件,只有发送的所有事件处理完成,Bolt接收到所有确认消息,tuple才能被认为处理完成。Storm使用mple树标记tuple之间的依赖,当目标队列已满事件组还未发射时,S0 浙江大学硕士学位论文第4章分布式复杂事件实时检测系统设计与实现tuple树可以避免缓存溢出。但产生的问题是Bolt需要两次确认消息,第一次接收事件并发送,随机生成一个64位整数作为消息的唯一标志,第二次接收事件处理完成的确认消息,检查这个标志。Storm提供ack方法若消息处理成功返回确认,和fail方法对传输超时或失败的消息进行处理逻辑。然而事件传输是不可靠的,中间可能发生错误,仅仅依靠超时检测丢失的事件组是不准确的,中间可能会发生重复事件的接收。3)有且仅有一次处理。Storm的最新版本trident引入事务处理事件模块,保证每一个Bolt有且仅有一次处理消息。然而,与至少传输一次模式相比,事务处理模式需要更多的消息传送和增加额外的全局状态。Storm提供可靠性机制,面临可能的失败场景,都能很好的避免数据丢失:1)当task节点挂掉,一个事件未收到确认,根据超时机制,将该事件标记为失败,重新处理。21当acker挂掉时,由这个acker跟踪的tuple都将超时,重新处理。3)当Spout挂掉时,若是从消息队列中读取消息,正在被处理的消息仍存在队列中。因此即使Nimbus,Supervisors,或者Workers在任何时间重启,Storm都能保证数据不丢失,继续正确执行Topology。由于Bolt加载Esper引擎进行逻辑处理,因此系统的可靠性还需考虑Esper引擎,系统采取的解决方案是每隔一秒把Esper运行时窗口数据持久化到数据库中。若系统宕机,重启时,增加初始化信息,加载宕机前Esper引擎运行时窗口的数据信息,尽量减小数据不一致。针对加载初始化数据,EsperBolt增加初始化规则语句statements,如表4.1所示,创建一分钟的时间窗口,若启动后的时刻与宕机前的时刻相同,设置amount加上宕机前的数据,否则增加一条新记录。表4.1初始化窗口规则语句含义EPL语句创建窗口createwindowMinuteWindow.win:time(1min)(iYearint,iMonthint,iDayhat,iHourint,iMinint,amountint) 浙江大学硕上学位论文第4章分布式复杂事件实时检测系统设计与实现初始化onMinuteInitEventasevmeNeMinuteWindowasmw窗口信息wheremw.iMin=ev.iMinandmw.iHour=ev.iHourandmw.iDay=ev.iDayandmw.iMonth=ev.iMonthandmw.iYear=ev.iYearwhenmatchedthenupdatesetamount=(ev.amount+mw.amount)whennotmatchedtheninsertselectev.iYearasWear,ev.iMonthasiMonth,ev.iDayasiDay,ev.iHourasiHour,ev.iMinasiMin,ev.amountasamount4.5本章小结本章为分布式复杂事件实时检测系统的设计与实现,提出复杂事件处理技术Esper与分布式实时计算框架Storm相结合,从需求分析到数据设计和系统总体架构,详细介绍了主要模块的实现和关键技术研究,探究复杂事件检测并行计算的可能性,以获得更高的吞吐量,更低的检测延时为目标。52 浙江大学硕士学位论文第5章股票预警应用案例第5章股票预警应用案例CEP系统在金融股票监控中具有广泛的应用,分析实时连续的股票报价信息,检测股票复杂事件模式,抓住可能的套利机会。例如,CEP系统接收股票市场的所有订单交易,检测出短时间内,多个订单提出更高的股票报价,说明该股票具有大量需求,又如检测发现某公司发布的股票报价具有上升趋势,暗示着一个具有重大意义的投资机会。股票预警帮助投资者在千变万化的股市上监控任何股票价格变动的情况。投资者可以定义价格涨跌、幅度、委比、量比等一系列的预警条件。最常用的股票预警软件,需要投资者下载电脑客户端,并一直运行,当规则匹配时,实时弹出预警消息,或短信通知,具有一定的局限性。本股票预警系统无需下载客户端,投资者无需每天守在电脑前盯着盘面而耽误处理其它事情,系统为投资者提供简单的规则定制,规则将在服务端加载运行,实现实时预警通知。5.1股票预警需求分析股票预警系统提供用户注册功能,注册成功后,用户可以制定对一只股票的价格或涨跌幅的预警规则,当股价到达预警价位或涨跌幅时,用户将自动收到邮件提醒。该邮件信息包含:股票代码、名称、当前价格、成交量、成交额、预警规则等。本系统提供股票规则定义模板,用户可以自定义股票规则。在已有分布式复杂事件实时检测系统的基础上,开发股票预警系统,针对各模块,管理员的用例图如图5.1所示。1)管理员定义事件类型为股票实时数据StockTick。2)制定基本股票规则模板。3)接入事件流输入,股票预警系统从外部设备获得实时股票数据,如EventSpout调用APl从新浪财经读取实时股票数据。4)数据库配置保存股票数据,和检测结果。5)Dashboard展示规则集触发的检测结果。S气 浙江大学硕士学位论文第5章股票预警应用案例管理员基本股票规///7———\刚。∥//弋竺!竺岁则模板——————7——事件类型、事件流输入\\\查看检测结果、\\\g诊\!!竺一/图5.1股票预警管理员需求用例图股票预警系统运行过程中,用户可以通过注册后,定制股票规则,系统将满足用户实时动态加载规则,及时发送预警通知的需求。用户主要访问规则管理模块,根据基本股票规则,设置参数,定制感兴趣的股票规则,也可自定义更复杂的股票规则,当规则匹配时,由分布式复杂事件实时检测模块发送预警通知。早一人一觥慨飘则—弋竺竺竺乡用户5.2事件和规则定义图5.2股票预警用户需求用例图5.2.1股票事件定义股票预警系统从新浪财经获得上海股市和深圳股市共2528只股票代码,通过新浪股票查询API获得实时股票数据信息,主要包括股票名称、股票代码、今日开盘价、昨日收盘价、当前价格、今日最高价、今日最低价、竞买价、竞卖价、成交量(股)、成交金额(元)、日期、时间等,因此设计实时股票数据信息StockTick如图5.3所示。天 浙江大学硕士学位论文第5章股票预警应用案例StockTiok·-stockid:String—stooknamu:String-pricedouble—volume:long【-Bmount:double卜_openprJce:double。一close口rice:double-maxprice:double—minprice:double—buyprice:double-sellprice:double-timestamp:DateStockTick()+get0/set0..图5.3股票实时数据信息StockTick类图股票历史数据信息StockData,包括股票代码,股票名称,日期,开盘价,收盘价,最高价,最低价,交易量,交易金额,如图5.4所示。股票历史数据存储在数据库中,根据规则需要加载历史数据。StockDato—stockidString—stockname:String—openprice:doub]e—closeprice:double-maxprice:doub]e-minprice:double—volume:long-amount:double-date:DateStockData0+get0/set0..图5.4股票历史数据信息StockData类图5.2.2股票规则定义股票规则的属性设计主要包括唯一标识ruleld,规则内容ruleContext,规则备注ruleComment,规则状态ruteStatus,事件集SetstockidSet,用户集SetuseridSet。其中stockidSet用于标记一个股票规则与其相关的股票代码,useridSet表示定制该规则的用户,当规则满足条件时,需要给这些用户发送预警邮件通知。股票预警系统提供用户指定规则的功能,因此规则管理模块提供基本股票规气S 浙江大学硕士学位论文第5章股票预警应用案例则模板,主要包括三大类:1)对单只股票实时数据的监控规则,2)结合股票历史数据的监控规则,3)对多只股票复杂模式的监控规则。1)对单只股票实时数据的监控规则个股主要针对价格、涨跌幅、成交量的监控规则定义,如表5.1所示:表5.1单只股票的监控规则定义股票规则内容EPL语句价格上破N元select丰fromStockTick(price>=N1价格下破N元select木fromStockTick(price<=N1今日涨幅大于N%select4fromStockTickwhere(price—closeprice)/closeprice>=N/100今日涨幅小于N%select+fromStockTickwhere(price-closeprice)/closeprice<=N/I00今日跌幅大于N%select水fromStockTickwhere(closeprice-price)/closeprice>=N/100今日跌幅小于N%select木fromStockTickwhere(closeprice—price)/closeprice<=N/1005分钟涨幅大于N%select木fromStockTick.win:time(5min)where(price—closeprice)/closeprice>=N/1005分钟跌幅大于N%select木fromStockTick.win:time(5min)where,closeprice-price)/closeprice>=N/1005分钟放量上攻select牛frompattern【every(sl=StockTick一>s2=StockTick(stockid—s1.stockidandvolume>=2宰s1.volumeandprice>=s1.priceandtimestamp.getTime()>s1.timestamp.getTime0)wheretimer:within(5mi小一>s3=StockTickrstockid—s2.stockidandvolume>=2木s2.volumeandprice>=s2.price 浙江大学硕士学位论文第5章股票预警应用案例andtimestamp.getTime()>s2.timestamp.getTime0)wheretimer:within(5min))】2)对单只股票历史数据的监控规则对股票历史数据的监控规则,如N天个股的K线规则定义,适合使用长度窗口定义规则,同时也可以把规则进行分解,对历史数据进行预处理,如所示对K线的监控规则,以“放量上攻”规则为例,分解计算每天成交量是否增长isAdvance,涨跌幅volatility,换手率turnover,从而检验连续N日,股票的成交量连续增长,涨幅大于V%,换手率大于T%,若三个条件都满足,则规则触发。通过分解规则,对历史数据进行预处理,可以大大减少重复计算,加快规则执行效率。表5.2股票历史数据的监控规则定义股票规则内容EPL语句连续N天收阴线select+fromStockData(closepriceopenprice,stocldd=X)win:length_batch(N)N日内阳线多于阴线createwindowStockLine.wm:length(N)(stockidstring,syear(即阳线的天数大于int,smonthint,sdayhat,isAdvanceboolean)select拿fromStockLinewhereisAdvance=trueN/2)groupbystockidhavingcount(+、>N/2放量上攻createwindowStatisticsData.win:length(N)(stockidstring,(成交量连续N曰放syearint,smonthhat,sdayint,isAdvanceboolean,volatility大,且每日股价涨幅double,turnoverdouble)select丰fromStatisticsDamwhereisAdvance:true均大于v%,换手率andvolatility>V/100andturnover>T/100大于T%)3)对多只股票复杂模式的监控规则对多只股票的监控,即对每只股票监控的组合,在相同时间间隔内,同一板 浙江大学硕士学位论文第5章股票预警应用案例块的两只股票同时上升,或不同板块的两只股票一个上升一个下降,都具有重要意义。又如连续发生的复杂模式,5分钟内A股票放量上涨,接着10分钟内同一板块的B股票也放量上涨,可能意味着这个板块的股票会有上升趋势。多只股票复杂模式的监控规则定义举例如表5.3所示。表5.3多只股票的监控规则定义股票规则内容EPL语句5分钟内,A股票价select率frompattem[格上破NI元,B股every(StockTick(stockid=A,price>2N1)票价格上破N2元andStockTick(stockid=B,price>N2))wheretimer:within(5min)]5分钟内,A股票涨select木frompa_ttem[幅大于N1,B股票跌every(StockTick(stockid=A,幅大于N2(,price—closeprice)/closeprice>=NI、andStockTick(stockid=B,(closeprice—pfice)/closeprice>=N2))wheretimer:within(5min)]5分钟内A股票价格select+frompattem【上涨,并且成交量翻every(sl=StockTick(stockid=A)倍,接着B股票也出->s2=StockTickrstockidiAandvolume>=2木s1.volumeandprice>=s1.price现价格上涨,成交量andtimestamp.getTime()>s1.timestamp.getTime0)翻倍wheretimer:within(5min))一>(s3=StockTick(stockid=B)->s4=StockTick(stockid=Bandvolume>=2+s3.volumeandprice>2s3.priceandfimestamp.getTime()>s3.timestamp.getTime0)wheretimer:within(5min))】 浙江大学硕士学位论文第5章股票预警应用案例5.3系统详细设计与实现5.3.1总体架构设计图5.5股票预警总体架构图股票预警系统的总体架构图如图5.5所示,系统提供用户定制股票规则的功能,由RuleSpout动态加载规则流,EventSpout接收股票实时事件流,DataSpout读取股票历史数据,从而根据规则和事件流分发策略构建拓扑结构,EsperBolt动态加载规则,规则触发时,及时向定制规则的用户发送预警通知,并存储检测结果。5.3.2拓扑结构实现由于股票监控规则往往是针对单只股票或多只股票,因此设计股票规则的属性stockidSet,表示与规则相关的股票代码。股票预警系统的拓扑结构设计根据股票代码进行分组,将相同股票代码的股票实时数据、股票历史数据、规则分发给 浙江大学硕士学位论文第5章股票预警应用案例同一个EsperBolt。自定义规则分组策略RuleBasedGrouping,和事件流分组策略EventStreamBasedGrouping,实现CustomStreamGrouping接口,完成方法publicListchooseTasks(inttaskld,Listvalues)。RuleBasedGrouping的chooseTasks中记录两个映射:Map>rule—tasks表示根据规则查找运行该规则的任务列表,以stockids为key,tasks为value:映射Map>event—tasks表示需要把事件发送到这些任务列表,以stockid为key,tasks为value。流程图如图5.6所示,首先根据事件对象属性values,默认values的第一个值为stockidSet,若ruletasks中已存在,直接返回tasks列表,若不存在,通过哈希函数,从可使用的targetTasks列表中选取一个task,存储到ruletasks,检查stockidSet中的每个stockid,eventtasks中是否包含该stockid,若已存在,更新任务列表,若不存在,新增一个记录stockid与task,最后返回这个task。 图5.6RuleBaseGrouping的chooseTasks方法流程图返回et(stockids)5.4股票连续放量上涨和缩量下跌实验与分析5.4.1实验内容与结果检验复杂事件处理模式匹配结果和实际观测结果的比较,设计复杂事件模式,若连续三个时刻的股票实时数据,价格不断上涨,并且成交量先翻倍后5倍增长,则判断该股票连续放量上涨:6l 浙江大学硕士学位论文第5章股票预警应用案例A£-÷Af+1(price≥Ai.priceandvolume≥2木Ai.volume)-÷Ai+2(price≥Ai+1.priceandvolume≥5}Ai+1.volume)其中Ai表示A事件在第i时刻发生,Ai,Ai+1,Ai+2表示连续的三个股票事件。同理,若连续三个时刻的股票实时数据,价格不断下跌,并且成交量连续两次都下降1/5,则判断该股票连续股票缩量下跌:Af一÷At+1(price≤At.priceandvolumesAt.volume/5)一At+2(price≤At+1.priceandvolume≤At+1.volume/5)根据新浪财经2013年5月20日SH600036招商银行的分时图,如图5.7所示。固2013/05/2015:。0价位:强85蝌i:13.87住黼霹忑r—————丽弱——一耋棼棼棼嚣一~⋯————一渤∞’∞:山脚㈧一№‰l“山月K5势15/e30分∞势灞器“Ⅻ戚变量:,i张幅‘。.。。麓蠢窭墨llI豳图5.7新浪财经2013年5月20日SH600036招商银行的分时图垒髯壹看劳分霉可以大致区分股票放量上涨和缩量下跌的时间区间:1)股票放量上涨时间区间为(09:55,10:16),(10:38,11:14),(14:15,14:34)2)股票缩量下跌时间区间为(09:30,09:36),(10:16,10:30),(13:22,13:51),(14:34,14:55)对当天该股票实时数据进行分析,放量上涨复杂事件模式处理结果如表5.4所示,V;表示Ai的成交量,T{表示Aj事件发生的时间。 浙江大学硕士学位论文第5章股票预警应用案例表5.4股票放量上涨程序运行结果yf+1Vi+2序号nVi+1Vi+271f丁f+1Ti+2y;yf+11972l3351020910009:39:4409:39:4909:39:543.456.242116003630051070010:05:3910:05:4410:05:493.1314.073189505047246064910:12:5910:13:0410:13:092.669.174125024640056975011:05:1511:05:2011:05:253.7112.28561001394419160013:28:3613:28:4113:28:462.2913.746300065005620014:17:0214:17:0714:17:122.178.657200078006440014:33:0214:33:0714:33:123.908.26股票放量上涨程序结果表明09:39,10:05,10:13,11:05,13:28,14:17,14:33这7个时刻,股票成交量骤增,连续放量,价格有上涨趋势,与分时图比较分析:1)09:39后股票价格有小幅上涨2)10:05,10:13位于上涨区f日q(09:55,10:16)3)11:05位于上涨区间(10:38,11:14),之后股票价格大幅上涨4114:17,14:33位于上涨区f日q(14:15,14:34),14:17之后股票价格大幅上涨以上6个时刻符合股票价格上涨趋势,但13:28处于股票价格下跌区间。表5.5股票缩量下跌程序运行结果序y,yf+1口yfVi+1Vi+2了1f71l+1Ti+2Vi+1Vi+2’了l1935002280020010:00:1410:00:1910:00:248.49114.0246064948351611010:13:0910:13:1410:13:199.537.913337153500060010:26:0910:26:1410:26:1967.438.334485507753120013:11:2113:ll:2613:11:3l6.276.46536686570050013:39:5613:40:0113:40:066.4711.4066492111800140013:44:1113:44:1613:44:215.518.437890218700130014:06:4714:06:5214:06:57lO.236.69883400799920014:08:2214:08:2714:08:3210.4339.99同理,股票缩量下跌程序结果如所示,表明10:00,10:13,10:26,13:11,13:39, 浙江大学硕士学位论文第5章股票预警应用案例13:44,14:06,14:08这8个时刻,股票成交量骤减,连续缩量,价格开始有下跌趋势,与分时图比较分析:1)10:00股票价格有小幅下跌2)10:26位于下跌区间(10:16,10:30)3)13:11股票价格微小变化,小幅下跌4)13:39,13:44位于下跌区间(13:21,13:51)5)14:06,14:08股票价格微小变化,小幅下跌以上7个时刻符合股票价格下跌趋势,但10:13时刻,股票价格只有微小变化,上涨或下跌并不明显。5.4.2实验结果分析股票复杂事件检测试验具有重要意义,根据连续股票事件的成交量放量或缩量,可以推断股票价格的上涨或下跌,通过程序对股票复杂事件处理,也有部分结果不符合事实,有一定的误报率。同时,由于成交量放量或缩量并没有明确定义,复杂事件模式中前后时间间隔股票成交量的比率参数可以由用户指定,从而指定用户感兴趣的股票预警规则。5.5不同拓扑结构股票预警实验与分析5.5.1实验内容与结果针对基于事件和规则分发的分布式复杂事件实时检测系统,构建不同的拓扑结构,可以通过设置Storm任务节点数和EsperBolt个数,对股票预警系统进行实验与分析。股票规则包括:1)500只股票,每只股票10个简单规则,共5000个单只股票规则,2)5000个复杂模式的监控规则,每个规则与两只股票相关,因此共有10000个股票规则。如图5.8所示,对股票预警系统设置Storm的工作节点数和EsperBolt参数N,构成不同的拓扑结构,进行实验。 浙江大学硕士学位论文第5章股票预警应用案例图5.8股票预警拓扑结构图实验采用三台双核2.93GHz处理器,4GB内存,Linux操作系统,使用Javal.6,Esper4.7,Storm0.9。系统启动运行,通过StormUI监控界面可以查看当前Storm集群的配置、运行情况、已提交的Topology的运行情况。StormUi鐾ClusterSummaryVernonNI蝌lbII篁q埘*聃sllPefy;s埘$Used赫嘴Freeslotslotats£。毛5£Jealto描fa§l嚣0孽012瑚5蚀33孽12SgTopologysummary;Name.埘Status辍燃Kb≈碟ogy&础T黼。polo种一’一{弼9嚣736《AC;IVESupervisorsummary槭.H口嗡658喇祷静篇}蝴d5娃孵-赫7轴筠9搬}7c8糊9如e58-l∞融lcb“’韩’鞴c转3如伽S瑚29{7毒Ⅸ蹲§辩t粕∞97醚藩蛐均硝me陬lmm_ltet's1m3s3e罐辩磷i擀神“Mce两-02medqcneo曲棼{群j蟛ucnU擗;meS}ol曩{m3熟{{m52s4赫2殆{NimbusConfiguration脚·Value慨}。o妇,印档,pg暾恕璋黼stO卿,吨O嗽ee辨f图5.9StormUI监控界面U刚#№系统启动加载如上文定义的10000个股票规则,发送匹配这些规则的股票事65 浙江大学硕士学位论文第5章股票预警应用案例件,对一个工作节点和三个工作节点进行实验,逐渐增加EsperBolt个数,进行延时测试和吞吐量测试实验。股票预警应用延时测试结果EsperBoltNumber图5.10股票预警应用延时测试结果图增加EsperBolt个数,构成不同的拓扑结构,对一个工作节点和三个工作节点的情况进行股票预警实验,测试结果如图5.10所示,当只有一个工作节点时,运行时间随着EsperBolt的个数增加有所波动,EsperBolt个数大于5时,延时基本趋于稳定,此时CPU约为67%,内存使用约3.7G,因此,增加EsperBolt并没有明显优势。对三个工作节点进行进一步测试,此时,每个工作节点的CPU为20%,内存使用约为2.9G。在相同的EsperBolt参数时,即相同的拓扑结构,三个工作节点中每个事件处理所需的平均延时小于一个工作节点平均延时,扩展比约为2:1。从而说明,增加物理工作节点,可以降低每个事件处理所需的平均延时。通过发送与规则不匹配的干扰事件,进行进一步的吞吐量测试,此时,有效 浙江大学硕士学位论文第5章股票预警应用案例事件占20%,干扰事件占80%,系统启动加载同样的10000个股票规则,发送有效事件和干扰事件,对一个工作节点和三个工作节点进行实验,逐渐增加EsperBolt个数,进行吞吐量测试实验。x104股票预警应用吞吐量测试结果—争1worker—lE卜3workel's一^—'o1worker(withnoise)f—_毛卜一3worke阽(w.thnoise) 广,一‘直/:_:矗./pP一矿幺一一L广一HH—卅j目曰日一一。l曼《;:^专专e◇eeeVVY’01234567891011EsperBoltNumber图5.11股票预警应用吞吐量测试结果图股票预警应用吞吐量测试结果如图5.11所示,一个工作节点和三个工作节点的测试结果都表明增加干扰事件使得系统的吞吐量有所提高。在无干扰事件情况下,随着EsperBolt个数的增加,吞吐量不断增加,并且相同条件下,三个工作节点的吞吐量约为一个工作节点时的两倍多,这也说明增加物理工作节点有利于提高系统吞吐量和降低事件处理的平均延时。5.5.2实验结果分析当一个worker节点工作时,CPU利用率和内存使用率较高,增加Bolt不能明显提高系统处理性能,随着worker节点的增加,和Bolt数量的增加,整个系9876543210_:△c口30Jc卜 浙江大学硕士学位论文第5章股票预警应用案例统的运行性能有所提高,从而验证分布式复杂事件实时检测的优越性。同时,为了更符合实际应用中只有部分事件符合规则的情况,增加干扰事件进行测试,系统处理每个事件的平均延时更低,吞吐量更高。5.6本章小结本章为基于分布式复杂事件实时检测的金融应用,针对股票预警系统进行需求分析,提供用户定制股票规则和动态加载规则功能。系统对实时股票事件进行连续放量上涨和缩量下跌规则的实时检测,同时通过设置任务节点和工作节点个数,对不同拓扑结构的情况进行实验和分析,从而说明增加任务节点和工作节点可以使系统发挥更好的性能。 浙江大学硕士学位论文第6章研究工作总结和展望第6章研究工作总结和展望6.1研究工作总结针对信息系统产生的大量连续事件,复杂事件检测技术以事件为驱动,敏捷快速的捕获实时事件流中存在的复杂事件模式,针对复杂事件处理技术对数据实时性要求较高,提出分布式复杂事件实时检测系统。首先,阐述复杂事件处理技术的事件检测方法,比较与主动数据库、数据流管理系统的异同点,接着,对不同类型的复杂事件处理引擎进行原理分析,探究基于事件流的复杂事件处理引擎和基于规则的复杂事件处理引擎之间的异同点,分别以Esper、DroolsFusion为代表进行实验分析。本文主要设计了一个通用的分布式复杂事件实时检测系统,详细阐述轻量级事件驱动架构和事件流实时处理的引擎Esper与分布式实时计算框架Storm的有效结合,设计通用的事件流和规则模板,提出基于事件流分发或基于规则分发的多种拓扑结构设计,适合在云环境下处理海量数据,以实现良好的可扩展性、更高的吞吐量,更低的检测延时为目标。同时,对系统可靠性和实时流与历史数据结合等关键技术进行研究。通用的分布式复杂事件实时检测系统适用于多种应用场景,数据源包括网络分组信息、实时交通数据、温度传感器等,在金融应用中,主要用于检测可疑资金转移、欺诈检测、市场趋势、用户习惯等模式,最后,本文实现实时股票预警系统,可以动态加载规则,允许用户自定义股票监控规则,实时检测股票事件模式,发送预警通知。同时,对股票短时间连续放量上涨和缩量下跌进行实验,对基于规则和事件流分发的股票实时预警系统进行性能测试实验。6.2未来工作展望本文提出的分布式复杂事件实时检测系统具有很好的通用性,良好的可扩展性,同时具有高吞吐量、低延时的优点,但系统采用开源的复杂事件处理引擎Esper69 浙江大学硕士学位论文第6章研究工作总结和展望和分布式实时计算框架Storm,两者的结合具有一定局限性。首先复杂事件模式涉及到多种事件交互联系,关系密切时,对分布式计算粒度的选择具有挑战性。其次,Storm的一个致命的弱点是不支持任务迁移到其他工作节点。一旦Topology被提交,每个任务被分配到具体的工作节点不能修改,除了使用手动的rebalance命令,而rebalance命令使用轮询round-robin方式重新分配工作节点,而不考虑每个节点的资源使用状况。本文实现了分布式复杂事件实时检测系统的基本功能,还有一些问题有待解决:1)Storm的Topology是静态的,必须启动前设计好,不能应对多变的业务逻辑,若要实现动态拓扑结构,需要自己修改Storm源码,实现Topology提交、激活、更新、热切换的功能。2)如何根据规则库,制定有效的Topology,需要实现一个完备的规则解析器,根据规则语义,进行词法语法分析,解析出规则间的互斥、依赖、汇聚、分流等关联关系,从而构建理想的拓扑结构,实现规则的共享和分解。3)目前,事件规则的定义主要靠人为定义,下一阶段,希望实现对历史数据和规则集进行模式挖掘,通过机器学习的方式获得更智能的规则。 浙江大学硕士学位论文参考文献参考文献[1]BarlowM.Real—TimeBigDataAnalytics:EmergingArchitecture[M].0’ReillyMedia,Inc.,2013.[2】LamC.Hadoopinaction[M].ManningPublicationsCo.,2010.[3]LuckhamDC.Thepowerofevents[M].Addison—WesleyReading,2002.[4]HyrminenJ.Experiencesinmobilephonefraud[C].2000.[5]BiaisB,WoolleyP.Highfrequencytrading[J].Manuscript,ToulouseUniversity,IDEI,2011.[6]TeamE.EsperReference[J].2006.[7]BaliM.DroolsJBossRules5,0:Developer’SGuide[M].PacktPublishing,2009.[8]WangF,LiuS,LiuP,eta1.Bridgingphysicalandvirtualworlds:complexeventprocessingforRFIDdatastreams[M].AdvancesinDatabaseTechnology—EDBT2006,Springer,2006,588—607.[9]ChakravarthyS.Streamdataprocessing:aqualityofserviceperspective:modeling,scheduling,loadshedding,andcomplexeventprocessing[M].Springer,2009.[10]NagyKA.DistributingComplexEventDetection[Z].2012.[11]EsparzaJ,NielsenM.DecidabilityissuesforPetrinets[J].Petrinetsnewsletter,1994.94:5-23.[12]PatonNW,DIAz0.Activedatabasesystems[J].ACMComputingSurveys(csuR),1999,3l(1):63—103.[13]DittrichKR,GatziuS,GeppertA.Theactivedatabasemanagementsystemmanifesto:ArulebaseofADBMSfeatures[M].RulesinDatabaseSystems,Springer,1995,1—17.【14]CugolaG,MargaraA.Processingflowsofinformation:Fromdatastreamtocomplexeventprocessing[J].ACMComputingSurveys,2012,44(3):15.[15]ZangC,FanY,LiuR.Architecture,implementationandapplicationofcomplexeventprocessinginenterpriseinformationsystemsbasedonRFtD[J].Information71 浙江大学硕士学位论文参考文献SystemsFrontiers,2008,10(5):543·553.[16]EtzionO,NiblettP.Eventprocessinginaction[M].ManningPublicationsCo.,2010.[17]mnicicD,FodorP,RudolphS,eta1.Arule-basedlanguageforcomplexeventprocessingandreasoning[M].WebReasoningandRuleSystems,Springer,2010,42—57.[18]李想,范玉顺,王宏安,等.实时复杂事件处理的最坏响应时间估算[J]-计算机研究与发展,2012,49(10):2054.2065.[19]WuE,DiaoY,RizviS.High—performancecomplexeventprocessingoverstreams[C].2006.[20]MarzN.Storm:Distributedandfault-tolerantrealtimecomputation[Z].OSCON,2012.[21]Schultz—MOLlerNP,MigliavaccaM,PietzuchP.Distributedcomplexeventprocessingwithqueryrewriting[C].2009.[22]陆平,钱煜明,朱科支.一种分布式复杂消息处理引擎的设计与实现[J].中兴通讯技术,2013,19(4):58.62.[23]MendesM,BizarroP,MarquesP.Aframeworkforperformanceevaluationofcomplexeventprocessingsystems[C].2008.[24]SaadatpoorA,MaC,WonhamWM.Supervisorycontroloftimedstatetreestructures[C].2008.[25]WalzerK,BreddinT,GrochM.RelativetemporalconstraintsintheRetealgorithmforcomplexeventdetection[C].2008.[26】WahlA,HollunderB.PerformanceMeasurementforCEPSystems[C].2012.[27]VukMijovi6SV.AsurveyandevaluationofCEPtools[Z].2010.[28]LeibiuskyJ,EisbmchG,SimonassiD.Gettingstartedwithstorm[M].O’ReillyMedia,Inc.,2012. 浙江大学硕士学位论文攻读硕士学位期间主要的研究成果攻读硕士学位期间主要的研究成果[1】冯普超,邵春翡,黄忠东捌、建伶.基于D—Ocean的金融风险监控系统.计算机研究与发展(增刊),2013.73 浙江大学硕士学位论文致谢致谢本文是我在浙江大学计算机科学与技术学院超大规模信息系统研究中心VLIS的学习和研究总结,这篇论文的完成,将为我两年半的研究生生涯画上一个圆满的句号,在此,我衷心感谢学校的老师,学长和同学对我的帮助和谆谆教导。首先,我由衷地感谢我的导师黄忠东副教授接纳我进入VLIS实验室,为我们提供了一个充满学术氛围的环境,并对我学习和生活上无微不至的关怀。回首两年半的实验室生活,从最初的迷茫到进入实际项目,特别感谢孙建伶教授对我的指导,在孙老师严谨的科研态度和精益求精的工作作风感染下,我逐渐明确自己的科研方向,不断学习掌握新技术,感谢余灵光师兄耐心指导我如何有效的做科研,一起探讨学术问题,到后来,当我面对项目中的困难,自己可以独立思考,探索解决方案,对自身学习和科研能力有了明显提高,使我在今后的工作和生活中受益匪浅。实验室的项目工作使我受益颇多,让我学会更好的沟通和交流,做好自己的本职工作,并且培养了更好的团队协作精神。感谢苌程老师,感谢我的组员王富鹏、冯普超、张铭明、姜栋、于天娇等人的互帮互助,同时非常感谢我的室友和朋友对我生活上帮助,和精神上的鼓励。最后,我要深深的感谢我的家人,感谢我的父母二十多年来对我的养育之恩,教导我为人处世,给我一个温馨的家庭,感谢我的弟弟和我一起分享生活的快乐与烦恼,你们的健康快乐是我最大的心愿。74邵春翡二零一四年一月于求是园 分布式复杂事件实时检测及其应用 作者: 邵春翡 学位授予单位: 浙江大学 本文链接:http://d.g.wanfangdata.com.cn/Thesis_Y2512159.aspx
还剩83页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

cjw0516

贡献于2016-05-11

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!