复杂事件处理(Complex event processing, CEP) 是多事件的事件处理概念,其目标是在事件集合(事件流、事件云)中识别用户定义的有意义事件。CEP采用诸如检测许多事件的复杂模式,事件关联和抽象以及事件层次结构等技术。此外,CEP 还会检查事件之间的关系,例如因果关系,成员资格和时间安排,以及事件驱动的流程。
以下是用户可以使用CEP跟踪的有意义事件:
-
欺诈检测 - 每天交易10 万元可能不代表欺诈行为,但在很短时间内(一个小时内)快速连续交易100万元以上可能代表欺诈行为。
-
实时物流 - 由 GPRS 监控的物流运送车应遵循交付货物的运送路线。如果路线在很短的时间内发生变化,则可能意味着物流运送车司机采取了捷径。但是,如果此更改持续超过两个小时,则可能意味着异常行为。
-
业务活动监控 - 在证券交易过程中,可以在 10 分钟内买卖多个公司的 100 万股。 但是,如果一家公司的一百万只股票被市场利率较低的多个交易者买入,则可能代表股价操纵行为。
-
交通流量控制 - 在 2 小时内通过道路传感器检测到有 100 辆车被认为是正常的。但在 15 分钟内通过传感器检测到有 100 辆车则代表交通堵塞。
所有以上示例都表示在一个时间范围内的一组事事件中的异常状态变化。通常,要使 CEP 系统正常工作,需要执行以下功能:
-
事件检测: 来自事件云或来自事件流。
-
事件关联: 对于时间和非时间相关的事件,以及聚合事件。
-
事件抽象: 从原子事件中组合复杂事件。
一个事件(event)是在特定时间范围内在受监视环境中的特定时间点的事实状态的显著变化。
在 Drools 中,工作内存中对象的状态可以在规则处理期间更改,如果在一个时间范围内,对象经历了重大变化,则将事件对象插入工作内存区域。因此,事件将被存储为事实(Fact)。一个事件(Event)可以变成事实 Fact,反之则不可以。
要符合资格作为事件,事实 Fact 应符合以下准则:
-
事件是不可变的 - 事件是过去发生的变更记录,因此无法更改。
-
事件具有强烈的时间限制 - 规则相关的事件通常要要相对于彼此在不同时间点发生的多个事件的相关性。
-
事件管理生命周期 - 因为事件是不可变的并且具有时间约束,所以它们通常仅在指定的时间段内感兴趣。 这意味着引擎可以自动管理事件的生命周期。
-
事件使用滑动窗口 - 因为所有事件都有与之关联的时间戳,所以可以在它们上面定义和使用滑动窗口,允许在一段时间内创建值聚合规则,例如特定时间段内事件值的平均值。
事件可以声明为:
-
基于时间间隔:基于时间间隔的事件具有持续时间并持久化到工作内存中,直到其持续时间已经过去。
-
时间点:时间点事件没有持续时间,可以被视为持续时间为零的基于时间间隔的事件。
为了能够在CEP场景中管理事件需要能够将事实与时间帧相关联,以便检测重大变化,Drools已经对DRL语言实施了几项增强功能,以便管理事件。如下为声明一个事件示例:
declare MyEventFact
@role( event)
@timestamp( ts )
@duration( life )
@expires( death )
end
-
@role( event)
- 声明 Fact 对象为一个事件 -
@timestamp( ts )
- 声明事件发生的时间 -
@duration( life )
- 声明事件在规则引擎中持续的时间 -
@expires( death )
- 声明事件在规则引擎中被删除的时间,@expires 与事件流一起使用。
一个行为建模平台能智能地感知行为和模式,通过区隔任何仅将规则,流程或事件视为主要建模概念的狭隘建模视角来实现。为了有效地实现行为建模的灵活性和功能,平台必须扩展和利用 Drools Fusion 模块中可用的复杂事件处理时间特征。
CEP 场景具有以下几个共同特征:
-
通常会有大量的事件,但只有一小部分事件是真正感兴趣的。
-
事件是不可变的,因为它们是状态变化的记录。
-
事件的规则和查询必须以反应模式运行,例如对事件模式的检测做出反应。
-
相关事件之间存在时间关系。
-
个人活动并不重要。 该系统关注相关事件的模式及其关系。
-
系统执行事件的组合和聚合。
基于这些一般共同特征,Drools Fusion 定义了一组目标,以便正确支持复杂事件处理:
-
优先支持具有适当语义的事件。
-
检测,关联,汇总和撰写事件。
-
支持事件流的处理。
-
支持时间约束来模拟事件之间的时间关系。
-
支持有特点含义事件的滑动窗口。
-
支持会话范围的统一时钟。
Drools 提供了两种处理事件的方式:CLOUD,STREAM。
-
CLOUD 处理模式是默认处理模式。在 CLOUD 模式下运行时,规则引擎会查看工作内存中的所有事实(Fact),无论它们是常规事实(Fact)还是事件。虽然事件有时间戳,但没有时间流动的概念。在此模式下,引擎应用其通常的多对多模式匹配算法,使用规则约束来查找匹配的元组,激活和触发规则。
-
当业务场景是需要处理事件流时,STREAM 处理模式是应选择的模式。相比较常规处理,STREAM 处理模式添加了一些常见要求,但启用这些需求使流事件处理变的更加简单。 使用 STREAM 模式需要添加的主要要求如下:
-
每个流中的事件必须按时间顺序排列。 例如,在给定流内,首先发生的事件必须首先插入引擎。
-
引擎使用会话时钟强制流之间的同步。 尽管应用程序不需要在流之间强制执行时间排序,但使用非时间同步流可能会导致意外结果。
-