flink 復雜事件

這篇博客文章試圖總結CEP領域中的技術，并介紹它們的主要功能和不足。 有時似乎過度使用了CEP一詞（就像'ESB'一樣），下面的內容反映了我們對它的理解和理解。

ESPER（ http://esper.codehaus.org/ ）是流行的開源組件，可用于Java的復雜事件處理（CEP）。 它包括對基于滑動時間或長度窗口的模式匹配和流處理的豐富支持。 盡管對“ CEP”一詞進行了激烈的討論（ http://www.dbms2.com/2011/08/25/renaming-cep-or-not /），但ESPER似乎非常適合CEP術語，因為借助ESPER的EPL（事件處理語言），它似乎能夠從一系列簡單事件中真正識別出“復雜事件”。

最近，在尋找用于實時CEP的開源解決方案時，我們的小組偶然發現了Twitter的Storm項目（ https://github.com/nathanmarz/storm ）。 它聲稱與Yahoo的S4最具有可比性，并且與Esper和Streambase等“復雜事件處理”系統處于同一空間。 我不確定Streambase，但是更深入地研究Storm項目使它看起來與CEP和ESPER解決方案大不相同。 與S4同上（ http://incubator.apache.org/s4/ ）。 盡管S4和Storm似乎擅長于分布式模式下的實時流處理，并且它們看上去（如他們聲稱的那樣）是“實時Hadoop”，但它們似乎沒有提供匹配模式的規定（因此表示復雜事件）。 搜索（我們的研究可能與之相關的）CEP定義導致以下項目符號（ http://colinclark.sys-con.com/node/1985400 ），其中包括以下四個作為系統/解決方案的先決條件被稱為CEP組件/項目/解決方案：

• 領域特定語言
• 連續查詢
• 時間或長度窗口
• 時間模式匹配

在當前版本的S4和Storm項目中，似乎缺少完全支持時間/長度窗口和時間模式匹配的連續查詢。 可能是由于它們的嬰兒期，他們將來會逐漸成熟以包含這些功能。 到目前為止，它們似乎只適合預處理事件流，然后再將其傳遞給ESPER等CEP引擎。 他們的分布式處理能力（la map-reduce模式）可以幫助加快預處理速度，在此情況下，可以過濾事件，或者通過一些查找/計算等來豐富事件。還進行了一些嘗試，將Storm與Esper集成（ http://tomdzk.wordpress.com/2011/09/28/storm-esper/ ）。

雖然像S4和Storm這樣的處理系統缺少CEP的重要功能，但基于ESPER的系統具有受內存限制的缺點。 事件太多或時間窗口過長可能會導致ESPER內存不足。 如果使用ESPER處理實時流（例如來自社交媒體的實時流），則ESPER內存中將積累大量數據。 總體而言，問題陳述是為大數據發明CEP解決方案。 在更好的層面上，問題陳述包括設計CEP解決方案，以處理機載（批處理）和飛行中（實時）數據。

用DarkStar的術語（ http://www.eventprocessing-communityofpractice.org/EPS-presentations/Clark_EP.pdf ），要求是“實時匹配注冊的模式，在數據庫中發現類似的模式”。 由于受內存限制是一個限制，因此，如果可以找到某種凝聚內存事件的機制，可能會很有用。 但是，壓縮后的數據仍然應該有意義，并保留原始流的上下文。

DarkStar使用符號聚合近似值（ http://www.cs.ucr.edu/~eamonn/SAX.htm ）進行此操作，他們聲稱通過將SAX與AsterData的nCluster一起使用來滿足上述要求，nCluster是mpp（大規模并行）使用基于SQL / MapReduce（ http://www.asterdata.com/resources/mapreduce.php ）的嵌入式分析引擎處理數據庫）。

待續（隨著我們的進一步研究）…

參考：來自我們的JCG合作伙伴 Abhishek Jain 的復雜（事件）世界 ? 在NS.Infra博客上。

翻譯自: https://www.javacodegeeks.com/2012/03/complex-event-world.html

flink 復雜事件

總結

以上是生活随笔為你收集整理的flink 复杂事件_复杂的（事件）世界的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。