復瑣事件處理技術概覽（一）

 

翻譯前言：我在理解復瑣事件處理（CEP）方面一直有這樣的困惑--爲何這種計算模式是有效的，可以分析獲得有用的結果？爲何它會快？我始終尚未找到我指望的答案。不像map-reduce模型，google的論文很是清楚的描述了它的場景；或者disruptor框架，原做者清晰地解釋了它爲何會快。在試圖理解CEP的過程當中，我準備翻譯一些我認爲有啓發性的文章，但願也對你們有用。這篇文章的原文《An Overview of Complex Event Processing》很是長，我將把它分紅幾篇來翻譯。

劉斌華原創翻譯，轉載請註明出處 http://www.cnblogs.com/Binhua-Liu/p/5325346.html

 

什麼是事件處理（Event Processing）？

在咱們周圍的世界，每小時每分鐘每一秒，人的大腦會受到或順序發生的，或同時發生的，無窮無盡的事情的轟炸，這些事件當即看來是也許是徹底沒有意義的，甚至有些古怪的，但隨着愈來愈多的事情發生，咱們能夠開始瞭解他們的之間相關性和重要性。

 

例如，咱們聽到遠處的歡呼聲，咱們看到氣球在空中飛舞，音樂開始播放，警車和盛裝着的拖着木偶的卡車的出現，坐在車上揮舞着人們，緊隨其後的救護車，和今天的日期是7月4日。單獨來看，這些事件可能意味着任何事情，可是在一塊兒呢？這極可能是一次獨立日狂歡巡遊！

 

咱們的大腦能夠很容易地在一眨眼的功夫肯定這一事實 --- 雖然不是過於簡單。用計算方式來定義，咱們能夠描述一個「巡遊事件模式」，以下所示：

 

一輛（或多輛）警車+後面的/後面的/毗鄰的+一輛（或多輛）狂歡卡車+後面的/後面的/毗鄰的+一個（或多個）揮動的人++後面的/後面的/毗鄰的+一輛（或多輛）應急車輛+在哪裏能夠聽到音樂+今天的日期是7月4日

 

你的大腦並不侷限這樣的工做模式：發送信息，等待，直到有一個迴應，而後進行一系列固定步驟的操做，以完成某項工做。正如這個例子中，它可以把正在發生的一系列事件，和相關的外部因素好比今天的日期，都關聯起來，並理解當前發生的是「巡遊事件模式」。

 

因此，當你瞭解更多關於復瑣事件處理（Complex Event Processing）-- 咱們專一於的這種技術 -- 你將知道它如何利用從不一樣地方獲取的，連續的，流動的，永無止境的信息，來當即地理解正在發生的事情，以及在很不久的未來要發生的事情。這又常常被稱爲實時態勢感知 （Real-Time Situation Awareness）。

這與商業計算的關聯

現在在計算機世界的問題是數據的增殖。信息從許多不一樣的系統，以巨大的數量，在不一樣的時間，以不一樣的速度抵達，其中一些信息對某些系統，人或進程如今就很重要，而另一些能夠先存儲供之後再恢復和決策。爲何咱們如今會面臨數據增殖的問題呢？

 

這裏涉及許多問題，但這裏僅列出少數幾個主要的：

• 計算能力的成本和複雜環境傳感器設備的成本已經變得不那麼昂貴

• 聯網能力的增長，而且變得更加智能

• 不少不一樣的功能計算模塊（財務系統，生產系統，銷售系統，等等）被分解，重寫，從而知足來越多的業務需求。

• 新的計算機解決方案要求超越企業自己而擴散到合做夥伴和客戶，這樣就把愈來愈多的數據來源和其餘輸入帶入到系統中。

• 像面向服務的架構（SOA）這樣的計算技術架構變得愈來愈成功，帶來了更加複雜的可重用的生態系統。

• 大數據（Big Data）爆炸，這個詞如今普遍用於描述那些大批量的，高速的，各類各樣的非結構化的，來源於社交網站、手機和許多其餘源頭的信息。

• 企業經營上對IT團隊不斷增加的指望 -- 要求他們對市場的狀況進行更有效地、實時地響應

 

咱們進步和這些複雜的系統致使往計算機應用系統中「傾倒」的信息愈來愈龐大，咱們已經達到一個「臨界點」-- 傳統的點至點式的，或者請求- 應答式的解決方案變得失效，難以維護和不可擴展。

 

一個公司的經營可能被瞬間發生的事件所影響，這些事件不只來之於內部的，能夠理解的，「溫馨」的小世界裏，而多是來自於外部的事件，如「物聯網」-- 實時傳感器裝置能夠測量和報告不少的狀況，包括「溫度忽然升高致使的食物儲存設施的突發的危險」或「由全球定位系統位置跟蹤的海運集裝箱從被傳感器檢測到被未經受權地開箱」。

 

對一家公司經營的直接影響也可能來自於日益強大的社交媒體對全球商業環境帶來的改變，例如Twitter，即時通信應用等。數以百萬計的人在同一時間能夠同時對某個新產品給予差評，強調某個迫切須要修改的產品設計。這勢必會影響利潤，甚至顯著影響企業的價值。所以，如今的公司不可避免地受到正面或負面事件的影響而疲於奔命。

 

在過去，可能追溯到15年前，商業應用不得屈就於那些當時可用的計算技術所採用的那些固定的方法，結構和接口（好比關係數據庫），信息必須先被靜態的插入和保存，只有在此以後用戶才能夠再分析和響應。傳統的JEE（Java Enterprise Edition）應用服務器中廣泛的實現 -- 期待客戶端應用程序發送的一個初始的請求，而後大多數狀況下大量的代碼邏輯只是用於從頭至尾地處理這個請求，而後才能返回給客戶端響應。這些技術正在並將繼續提供那些更可能是基於批處理的，實時性較差的解決方案。而新的，更低時延的，更快的，基於內存的中間件產品現已上市。

 

基於事件驅動架構（Event-Driven）的系統本質上是更敏捷的，更好地被「武裝」起來來處理這些類型的狀況 -- 處理那些橫跨整個業務基礎設施和衆多業務部門「孤島」（如財務，生產和銷售等部門），須要被當即解釋和處理的事件。這些類型的系統，一旦當它們探測到外部和商業環境的改變，就能聯繫上下文並執行策略。而不是預約義一些天天晚上執行的任務，甚至是那些每次都要有人手動運行的任務來處理。

 

做爲與大數據相關的，在將來數年將顯著增加的問題 -- 即在信息的採集、管理並可以在可接受的時間範圍進行處理方面，事件驅動技術（特別是復瑣事件處理），能夠爲更高級的「智能」和決策提供快速的，更接近「事件發生時間點」的，原始的數據流。

 

所以，事件驅動技術的好處是在應對數據增殖方面，把傳統的數據處理方法，改成把信息描述爲實時的事件（能夠是在任何地方發生的事情），提供了聰明地分解事件、路由事件、過濾事件、關聯事件的能力，所以在大多數狀況下，分散的事件能夠進化爲全面的，穩固的，容易理解的商業事件，使企業能相對更好地觀察，控制和適應瞬息萬變的狀況。

 

待續。。。