複合事件處理CEP簡介
什麼是複合事件處理？
這是一個IT事件爆發的時代，各種IT系統之間或系統內部，每天產生大量事件。系統在關鍵點打日誌、系統之間交流資訊，都是事件。但我們對這些事件往往視而不見，當成垃圾一股腦兒全扔了。其實只要處理得當，垃圾也可以變成資源。
複合事件處理（CEP，Complex Event Processing）是一種基於動態環境中事件流的分析技術，事件在這裡通常是有意義的狀態變化，通過分析事件間的關係，利用過濾、關聯、聚合等技術，根據事件間的時序關係和聚合關係制定檢測規則，持續地從事件流中查詢出符合要求的事件序列，最終分析得到更復雜的複合事件，主要用於網路詐欺識別等防止犯罪，銀行等金融行業防止，以及風險規避和營銷決策等。
首先，CEP是一種框架。和其他框架一樣，它也提供了一套流程或一種標準。CEP提供的則是一套處理複合事件（complex event)的流程。其次，CEP的特點和核心能力在於可以便捷地處理複合事件。CEP之所以有這樣的能力，是由於它可以處理多輸入對多輸出的對映關係，“複合(complex)”也正是相對於傳統的單一輸入和單一輸出而言的。CEP多個輸入之間的關係可以是獨立的，也可以是相關的，它的多個輸出亦是如此。舉個例子：
輸入：
- 面板感覺溫度下降
- 鼻子感覺溼氣很重
- 耳朵聽到遠方雷聲
- 眼睛看到烏雲閃電
判斷模組得出結論：即將下雨
輸出：
- 把衣服收到屋內
- 出門要帶傘
最後，CEP天然擁有強大的可擴充套件性（Scalability）。因為輸出可以很方便的轉化為下一個系統的輸入，所以可以用串聯、級聯等多種方式連線不同的CEP系統，從而組合成一個複合系統，以應對複雜的業務需求。
複合事件處理過程包括：
- 格式化：將事件獲取模組得到的事件資訊轉化為內部處理的形式
- 預處理：將事件按照欄位內容進行處理
- 模式偵測：將數個事件複合起來，找出複合事件
- 事件發派：將複合事件傳送到相應的處理模組
- 執行動作：處理模型按照事件狀況執行相應的動作
複合事件處理系統中的關鍵模組：
- EPL解析器：複雜事件處理系統中EPL語言被解析器解析為處理引擎能理解的語言（類SQL解析器）。
- 規則管理：管理EPL。
- 事件接入：通過SOA、ESB、MOM、讀取日誌等方式將訊息接入。
- 預處理：將事件依據欄位內容進行處理。
- CEP引擎：找出事件關聯。
- 資料模型：維護內部資料。
- 事件發派：將已經發現的複合事件發派到負責處理的行動模組中。
- 行動模組：對複合事件採取行動。
此外，CEP系統的輔助工具有：
- 規則製作工具
- 報表輸出工具
- 實時儀表板
事件應該包含一些基本的要素：型別、發生事件以及更多的一些定義屬性。通常需要關聯多個事件進行分析處理，其中事件間的關係主要有5種：
- 時間順序關係：動作事件和動作事件之間，動作事件和狀態變化事件之間，都存在時間順序。
- 聚合關係：動作事件和動作事件之間，狀態事件和狀態事件之間都存在聚合關係。即個體的聚合形成整體集合。
- 層次關係：動作事件和動作事件之間，狀態事件和狀態事件之間都存在層次關係，即父類事件和子類事件的層次關係，從父類到子類是具體化，從子類到父類是泛化。
- 依賴關係：事物的狀態屬性之間彼此的依賴關係和約束關係。
- 因果關係：對於完整的動作過程，結果狀態為果，初始狀態和動作都可以視為原因。類比哲學上論述事物如何發展也是有兩個因素的，一是內部本質，二是外部作用。
複合事件處理面臨的挑戰：
- 減少應用儲存資料（在分析資料之前）造成的延遲
- 能夠持續，實時地分析多個數據流
- 能夠關聯不同資料流中的事件，從而發現新的相關情形
- 能夠迅速響應新發現的危險或機會
- 能夠迅速的將先前發現的規律應用到新的資料流分析模型中
- 能夠利用已有的應用開發能力快速開放新的高效能，高擴充套件度的應用
- 確保應用和系統的連貫性。
CEP 依賴下面的一組技術：
- Event-pattern detection 事件模式
- Event abstraction 事件抽象
- Event filter 事件過濾
- Event aggregation and transformation 事件聚合和傳輸
- Modeling event hierarchies 模型化事件層次結構
- Detecting relationships (such as causality, membership or timing) between events 事件間關係檢測（比如因果、從屬或者時間先後等）
- Abstracting event-driven processes 事件驅動過程抽象
事件處理語言（EPL，Event processing language）用於系統中制定和查詢感興趣的事件序列，通常是類SQL的語句，從SQL語句中擴充套件而來。
相關開源專案：
- Esper： http://www.espertech.com/esper/
- Drools Fusion： http://www.drools.org/
- FlinkCEP： https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html
- Siddhi： https://github.com/wso2/siddhi
- EventStore: https://github.com/EventStore/EventStore
CEP和實時計算有什麼關係
實時計算也是一種框架，負責提供低延遲的計算服務，這樣就給人一種“實時”的感覺，它本身並不關心被計算的是什麼。大部分實時計算框架採用了流式(stream)計算的方法，是因為該方法可以很好地滿足實時計算的設計需求。CEP和實時計算其實是屬於兩個不同領域的框架，但兩者在業務和具體實現的需求下，緊密地結合到了一起。CEP只是提供了一種處理複合事件的框架，並沒有對時效性做嚴格要求。我們也可以用傳統技術實現CEP系統，只不過從事件發生到結果獲取，再到採取行動，中間的延遲很大。而我們通常希望降低這種延遲，來獲取更大的業務價值。實時計算恰恰提供了一種低延遲的計算服務，所以多數CEP系統在實現其計算模組時採用了實時計算的技術。
再者，如同前面提到的，CEP較佳的設計模式是管線架構設計。這種設計可以讓事件像水一樣流過各個處理模組，它和實時計算的流式計算非常相似。基於這個共同點，CEP和實時計算緊密地結合在一起。總的來說，我感覺兩者的關係是：實時計算提供了一種底層的計算服務，CEP可以架構其上。
CEP應用案例：滴滴
實時營銷
- 地理圍欄
- 乘客線上冒泡1min內沒有發單
- 乘客下單後2min內沒有被司機接單
- 乘客在不同業務線之間的比價行為
異常檢測（事後回溯->提前干預）
- 司機開始計費後12小時還未更新成下一狀態
- 企業級乘客2min內連續重複傳送3個以上訂單
- 同一使用者5min內重複進線5次
- 訂單超時未支付