複雜事件處理簡介
概念
什麼是複雜事件處理
複雜事件處理(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
一個行為建模平臺能智慧地感知行為和模式,通過區隔任何僅將規則,流程或事件視為主要建模概念的狹隘建模視角來實現。為了有效地實現行為建模的靈活性和功能,平臺必須擴充套件和利用 Drools Fusion 模組中可用的複雜事件處理時間特徵。
CEP 場景具有以下幾個共同特徵:
-
通常會有大量的事件,但只有一小部分事件是真正感興趣的。
-
事件是不可變的,因為它們是狀態變化的記錄。
-
事件的規則和查詢必須以反應模式執行,例如對事件模式的檢測做出反應。
-
相關事件之間存在時間關係。
-
個人活動並不重要。 該系統關注相關事件的模式及其關係。
-
系統執行事件的組合和聚合。
基於這些一般共同特徵,Drools Fusion 定義了一組目標,以便正確支援複雜事件處理:
-
優先支援具有適當語義的事件。
-
檢測,關聯,彙總和撰寫事件。
-
支援事件流的處理。
-
支援時間約束來模擬事件之間的時間關係。
-
支援有特點含義事件的滑動視窗。
-
支援會話範圍的統一時鐘。
事件處理的兩種模式
Drools 提供了兩種處理事件的方式:CLOUD,STREAM。
-
CLOUD 處理模式是預設處理模式。在 CLOUD 模式下執行時,規則引擎會檢視工作記憶體中的所有事實(Fact),無論它們是常規事實(Fact)還是事件。雖然事件有時間戳,但沒有時間流動的概念。在此模式下,引擎應用其通常的多對多模式匹配演算法,使用規則約束來查詢匹配的元組,啟用和觸發規則。
-
當業務場景是需要處理事件流時,STREAM 處理模式是應選擇的模式。相比較常規處理,STREAM 處理模式添加了一些常見要求,但啟用這些需求使流事件處理變的更加簡單。 使用 STREAM 模式需要新增的主要要求如下:
-
每個流中的事件必須按時間順序排列。 例如,在給定流內,首先發生的事件必須首先插入引擎。
-
引擎使用會話時鐘強制流之間的同步。 儘管應用程式不需要在流之間強制執行時間排序,但使用非時間同步流可能會導致意外結果。
-