程式員的量化交易之路(2)----Esper文檔學習之技術概覽(1)1. CEP和事件序列分析2. CEP和關系型資料庫4. 需要的第三方庫

在接下來的20個工作日中，我将堅持翻譯或者略翻譯esper的官方文檔。

為什麼需要學習esper，因為我們需要了解複合事件處理 complex event processing (cep)。在量化交易系統中，cep是必不可少的。它負責處理海量的實時事件。

關于cep更多知識，大家可以翻閱網絡相關資料。我這裡集中在學習開源的cep系統，esper。。

今天開始第一篇：技術概覽。

esper引擎主要解決現實中某類應用對事件的分析和響應的需求。這類需求的典型代表有：

1）商業管理和自動化（商業事件監聽，bam，異常事件緊急處理）

2）金融（程式化交易，欺詐檢測，風險管理）

3）網絡和應用的監管（入侵檢測，sla監管）

4）傳感網絡應用（rfid讀取，生産線的控制和排程，空中航線監管）

這類應用的共同點就是需要實時地處理事件event（消息message），或者至少是接近實時。這種系統也叫complex event processing(cep)，或者事件序列分析。這類系統的關鍵特性是吞吐量、延遲性和複雜邏輯的需求。

1）高吞吐量 - 應用需要處理大量的事件（每秒處理1000至100k）

2）低延時 - 應用需要在事件發生時立即做出響應（從幾毫秒到數秒内）

3） 複合計算 - 應用支援對事件的複雜處理，例如事件之間的模式(patterns among events)，過濾事件(filter events)，合并特定時間視窗或者長度視窗的事件，事件序列的合并，基于事件缺失的觸發處理。

esper 引擎就是為了簡化應用實作cep功能而生。

關系型資料庫和sql語言主要是面向絕大多數資料是靜态資料，大多數查詢是簡單查詢的場景。大多數資料庫也是将資料儲存在磁盤上（除了in-memory 資料庫），它們的優化也是針對磁盤存取的。

為了從資料庫中擷取資料，那麼必須對資料庫進行查詢。如果應用每秒需要得到資料10次，那麼勢必觸發10次資料庫查詢，這中方法很難擴充到每秒成千上萬的查詢量。

當資料的資料需要更新時，資料庫的trigger會被激發，然後這種資料庫觸發器執行速度很慢，并且不擅長複雜的條件檢測和邏輯處理。

in-memory資料庫比傳統的關系型資料庫更适合cep應用，因為它具備更好的性能。但，它并沒有為cep的實時查詢結果以及事件序列分析進行設計和優化。

3. esper作為cep引擎

esper和關系型資料不一樣的點在于，它并不儲存資料，相反，它儲存查詢。而資料是通過查詢來處理。當一個資料（event）來到時，它将通過我們預訂的查詢語句，決定下一個動作。

esper提供兩種機制處理事件流：事件模闆(event patterns)和事件流查詢（event stream queries）

esper提供事件模闆語言，用于基于表達式(expression-based)的事件模闆比對。模闆比對引擎是通過狀态機來實作的。這種方法可以處理預料的事件序列、事件缺失和事件融合。它也提供了事件在時間方面上的相關性分析。

esper也提供了事件序列查詢方法，用于滿足cep應用對事件序列的分析需求。事件序列查詢(event series queries)提供視窗(window)，統計(aggregation)，合并(join)和分析函數，用于處理事件流。這些查詢遵循epl文法。epl有點類似與sql，但它是處理視圖（view）的，而非表格（table）。視圖，代表了對一個事件序列的處理以及産生新的事件序列。

esper 采用統一的api接口提供的這兩種方法。

esper需要如下第三方庫：

1）antl

2） cglib

3） apache commons logging ，log4j.

4）junit

5）mysql的連接配接庫

本章完畢。。。