CEP的设计模式2-模式介绍（全文完）

ORACLE的CEP提供了丰富的设计模式

一、事件过滤 Event Filtering

问题域： 查找特定的事件，抛弃不需要的事件

情境：（Scenario）

   假设一个事件流（symbol， lastBid， lastAsk）
   查找所有事件里面 symbol 为“AAA”

解决方案：

SELECT *
FROM stockstream [NOW]
WHERE symbol = ‘AAA’

这里为何需要一个窗口操作：

1、过滤器是在关系上操作的，因此需要将流事件转换为一个关系
2、逻辑上来说，我们是无法在无边界的事件流上工作分析的，因此需要增加一个流事件的时间约束
3、注意：一些案列中捷径允许的 如 now 不指定[注：以后待补充]


二、 New event detection 新事件检测

问题：
    查询一个流事件中指定的新数据

场景：
    上报那些自从上次事件后发生改变价格的股票
    如果没有发生改变，就不上报


SELECT * FROM stockstream [NOW]


生成关系还是流？


生成一个关系：在时间T上，包含的所有的事件集合。
注意是需要时间T上的，而不需要时间T-1的
使用RELATION-STREAM  操作   ISTREAM （ insert stream）


因为我们感兴趣的是last event，所以使用操作操作 [ROWS 1] 替换 [NOW].


解决：
ISTREAM(
SELECT *
FROM stockstream [ROWS 1]
)


将一个事件插入到流，如何体现是新事件？为何用ROWS 1


三、 Event partitioning 事件的分区

问题：
我们需要将事件流进行窗口分区

解决：

ISTREAM (

SELECT *
FROM stockstream
[PARTITION BY symbol ROWS 1]
)
分区后结果

四、Event enrichment 事件收敛

问题：

 通过稍微有点静态的关系数据从一个事件流中进行事件收敛

场景：
 考虑：  股票关系，符号，公司名称，公司总部所在地
 从行情事件流中找出最后出价大5.0的股票，并找出公司所在地

解决：
SELECT event.symbol, location
FROM stockstream [NOW] AS event,
stockrelation AS data
WHERE event.symbol = data.symbol AND
event.lastBid > 5.0

为何需要指定一个事件流的窗口操作，而不是为关系指定一个窗口操作
因为关系已经是瞬时的，已经含有时间边界

五、Event aggregation事件集成

问题：
将一些事件集成到一个新的复杂事件汇总中

场景：
输出一个股票，10秒之内的平均价格


4S  输出 已经是平均价格
9S  输出 AAA 的平均价格
         BBB的 平均价格
15S 输出  BBB的 9s 和15S的平均价格
20S 输出  BBB的 平均价格， 在10S内，只有第15S的事件

解决：
SELECT symbol, AVG(lastBid), AVG(lastAsk)
FROM stockstream [RANGE 10 seconds]
GROUP BY symbol


窗口范围操作是一个流对关系的操作
它定义了一个时间范围来保持事件，事件在范围之外的将被移出窗口
如果我们对于每个信号的平均值感兴趣，那么我们可以使用group by 操作

六、Event correlation 事件的相关性

问题：
事件相关性分析从一个或者多个事件流中获取公共模式

场景：
考虑 BIDSTREAM 和 ASKSTREAM，分别含有 下面事件内容
bid（symbol, bidPrice, customer）
ask ( symbol,askPrice, customer)


相关性分析是指：10秒内发生的，相同symbol的bids和asks

解决：
SELECT bid.symbol, bidPrice, bid.cust, askPrice, ask.cust,
FROM bidstream [RANGE 10 seconds] AS bid,
askstream [RANGE 10 seconds] AS ask
WHERE bid.symbol = ask.symbol


可以在两个事件流中执行规则连接操作，包括外部连接

七、应用时间


问题域：
需要用应用视图时间取代cpu时间
这个情况在事件来自于不同的机器的时候，特别有用，需要一种同步方式


场景：
再次考虑 bid和ask 事件流


bid 和ask 需要交易进行的机器上的时间戳
 


因为我们时间是约定在10秒内，这样，第一个事件可以被计算，
但是实际上，开始的2个事件可以一起到达，而第三个会延迟
 


因此9.5和10.0的事件会被关联分析


解决办法：


事件需要考虑用户时间的时间戳作为事件的属性取代当前系统时间

八、缺失事件检测

问题域：
如果期望的时间内，一些事件缺失提供警告

场景：
考虑一个SALESTREAM 事件流，事件类型（customer order shipment） and 订单ID


如果10秒内，一个订单之后没有跟随shipment事件到来，则发出警告

解决：

SELECT "DELAYED" as alertType, orders.orderId,
FROM salestream MATCH_RECOGNIZE (
PARTITION BY orderId
MEASURES
CustOrder.orderId AS orderId
PATTERN (CustOrder NotTheShipment*) DURATION 10 SECONDS
DEFINE
CustOrder AS (type = ‘ORDER’),
NotTheShipment AS ((NOT (eventType = ‘ SHIPMENT’)))
) AS orders

结论：
1、在线的处理，不必存储到磁盘
2、声明方法
3、可以处理无边界的数据集（事件）
4、强大的时间构造
5、通过模式匹配来寻找复杂的关系
6、通过相关代数来转换事件-关系和 关系-事件
7、丰富的事件设计模式