Cep引擎和用於處理cep查詢的方法
2023-10-11 21:18:59 2
專利名稱：Cep引擎和用於處理cep查詢的方法
技術領域：
本發明涉及複雜事件處理(complex event processing, CEP)引擎和用於處理CEP 查詢的方法。
背景技術：
現代計算機系統經常對數據流進行操作，即對由傳感器、傳感器網絡或其他(一個或多個)數據源捕捉的數據項的連續序列進行操作，其中已經接收到的數據項在更多數據項仍在被傳感器捕捉的同時被處理。經處理數據項通常用於檢測時間關鍵複雜事件並用於生成相應的警報和/或差錯消息。典型的應用場景是諸如設施監視系統之類的安保系統，其中由讀卡器捕捉到的數據項的流被處理以便識別對設施內的機密區域的未經授權的訪問或者進入和離開建築物的人的其他異常行為。其他應用場景包括道路交通管理、位置跟蹤、醫療監控、製造過程、網絡流量監控、商業活動監控和欺騙檢測。雖然與單個數據項/事件有關的異常行為的檢測相當簡單明了(例如，在某個人的ID卡被讀卡器讀取時確定該卡已經期滿)，但大多數現實生活場景要求檢測與流內的多個數據項有關的更複雜情形(例如，某個人進入了某個房間，但在預定量的時間之後沒有離開該房間)。在此上下文中，通常分析多個傳感器的數據，其中傳感器可包括硬體傳感器、 軟體傳感器、軟體應用等等。此處理範例一般被稱為複雜事件處理(CEP)。複雜事件處理(CEP)引入了關於經典資料庫技術的若干個重要的範例變化，在經典資料庫技術中，數據是相對靜止的並且各種查詢可被編制來檢索期望的數據。然而，在 CEP中，查詢是比較固定的並且被饋送以持續到達的數據流。如上所述，CEP查詢通常關聯多個輸入數據項，尋找模式並且在觀察到某個模式時產生警報、差錯消息等等形式的輸出事件。總之，CEP應用(也稱為CEP引擎)必須應對以非常高的速率持續到達的非常瞬變的事件數據並且必須儘可能快地、在理想情況下實時地產生相應的輸出事件/警報。這包括主存儲器內的基於推送的處理(也稱為數據驅動的處理)，這表示一種數據流方案，其中要處理的數據不是由處理運算子(operator)根據需要或利用某種調度技術來請求(拉出) 的，而是在其變得可用時被直接提供(推送)給處理運算子。美國專利US 7，676，461B2和 US 7，457，提供了關於複雜事件處理(CEP)的更多背景信息。當處理CEP查詢時，數據流的表示模型對於諸如存儲器和CPU使用之類的資源要求以及對於CEP系統的活力和反應時間都扮演著重要的角色。在現有技術中，已經提出了兩種一般數據流表示模型正-負方案和時間區間方案。對於專門的CEP引擎已知另外的方案，並且將來的發展有可能給出另外的方案。正-負方案在科學界尤其是在美國廣泛普及。因此，源自於相應的大學衍生公司的大多數商業上可得的CEP引擎使用此方案。作為數據流的時間性表示模型上的運行示例，我們考慮向數據流的每個元素指派基於離散時間軸的有效性的模型。示例性的數據流在此示例被稱為「PersonshRoom」，並且攜帶著關於在房間內的人(即，其姓名和年齡)的
3信息。數據流元素("Alex", 35)從時亥Ij 10 (包括時刻10)到時刻30 (不包括時刻30)是有效的(即，在房間中)，並且(「Jolie", 25)從時刻20(包括20)到40 (不包括40)是有效的。在正-負方案中，示例性的數據流將由元素((「Alex」，35)，10，+)表示，該元素表明 ("Alex", 35)在時亥Ij 10變得有效。在該示例中，此元素後面是元素((，，Jolie」，25)，20， +)，表明(「Alex」，3 在時刻20變得無效的元素((「Alex」，35)，30，-)，以及最終的元素 ((，，Jolie」，25)，40，-)。關於正-負方案的更多信息可在 Arvind Arasu, Shivnath Babu 禾口 Jennifer Widom所著的"The CQL Continuous Query Language Semantic Foundations and Query Execution，，(VLDB Journal, 15(2) : 121 — 142，2006)禾口 Thanaa Μ· Ghanem、 Moustafa A. Hammad> Mohamed F. Mokbel> Walid G. Aref 禾口 Ahmed K. Elmagarmid 所著的 「Incremental Evaluation of Sliding-Window Queries over Data Streams，， (IEEE Transactions on Knowledge and Data Engineering(TKDE)，19 (1) :57-72, 2007)中找至丨J。時間區間方案是由馬爾堡大學等等傳播的。在上述示例性數據流 "PersonsInRoom"中，該流在時間區間方案中將由兩個流元素表示，第一個是(("Alex", 35)，[10，3))，表明(『『Alex」，35)在半開放時間區間[10，30)中是有效的，第二個是 ((『『Jolie」，25)，[20,40))，表明(『『Jolie」，25)在半開放區間[20，40)中是有效的。目前在申請人的CEP引擎RTM分析器中採用了時間區間方案。關於時間區間方案的更多信息可在 Jiirgen KrSmer禾口 Bernhard Seeger 所著的"A Temporal Foundation for Continuous Queries over Data Streams，，(Technical Report,No. 38,Department of Mathematics and Computer Science,University of Marburg,July 2004. Ilth International Conference on Management of Data (COMAD)，January 6-8，Goa-India)、Jiirgen KrSmer禾口 Bernhard Seeger所著的「Semantics and implementation of continuous sliding window queries over data streams，，(ACM Trans. Database Syst. 34(1) :(2009))禾口 Roger S. Barga、 Jonathan Goldstein、Mohamed H. Ali、Mingsheng Hong 所著的 「Consistent Streaming Through Time :A Vision for Event Stream Processing，，(CIDR 2007 :363-374)中找到。關於更多的數據流表示方案的額外信息可在JUrgen Kroner所著的「Continuous Queries over Data Streams-Semantics and Implementation，， (Dissertation， Philipps-University Marburg，Marburg，2007)中找到。對於大多數種類的查詢，正-負方案具有比時間區間方案更高的資源消耗。在一些情況下，此開銷可能是很大的。另一方面，存在這樣的場景，其中正-負方案可更早地產生結果，這增大了 CEP引擎的活力。如果快速回答是至關重要的，則這可能是相當有利的。 作為簡單的示例，我們考慮一個簡單的過濾函數，其在上述示例性數據流「Persons^Room」 中只接受姓名以「Α」開始的人，從而此過濾函數接受數據流元素(「Alex」，35)，但拒絕(，， Jolie", 25)。如果使用正-負方案，則判定字符串是否開始於「A」的計算將必須被應用到流中的所有四個數據流元素(見上)，從而接受第一和第三元素。利用時間區間方案，此計算必須被應用兩次，因為只有兩個流元素，在此情況下只接受第一個。與此示例類似，利用正-負方案，與時間區間方案相比，大多數計算必須被進行兩次，從而時間區間方案在某些情況下是不那麼處理密集的。至於活力，我們考慮一個總計函數，其對流內有效的數據流元素計數。兩個示例性表示的結果將如下((1)，10，+)、((1),20,-), ((2),20,+),(⑵， 30，-)、((1)，30，+)、((1)，40，-)和(⑴，[10，20))、((2)，[20，30))、((1)，[30,40))。「2」在時刻20變成有效計數的信息對於正負方案可在時刻20被發出，而在時間區間方案中此信息通常將在時刻30被發出，因為系統必須等待計數2再次變得無效，以便確定2的有效區間。與之不同，正-負方案使用單獨的元素來發送關於2再次變得無效的信息。結果， 正-負方案在此情況下具有活力方面的優點。現今有多種 CEP 弓I 擎可用，例如 WestGlobal Vantify、Progress Apama> StreamBase、SQLstream、ruleCore、WebSphere Business Events、IBM System S/ InfoSphere Streams、 Tibco BusinessEvents、 SAP/Sybase/Coral8/Aleri、 UC 4 Senactive> Event Zero、Active Insight、Pion CEP、Esper/EsperTech、ETAILS、 Intelligent Event Processor、JBossDrools Fusion、Truviso、Oracle、Microsoft Streamlnsight、Nastel、EventGnosis 禾口 Informatica。由於上述的各種已知的數據表示模型的不同關注點、優點和缺點，所有已知的 CEP引擎都只專攻這些方案之一，同時接受其缺點。乍看起來，這是沒有缺點的，因為例如正-負方案和時間區間方案都產生邏輯上等同的結果，從而在特定的CEP引擎中只使用這些方案之一似乎就足夠了。只使用一種方案也具有隻需要實現和維護所選擇的方案的益處。然而，限於一種特殊的方案意味著對於某些種類的查詢要忍受該方案的缺陷，取決於特定CEP應用場景的要求這可能是不利的。因此，本發明的技術問題是提供一種改進的CEP引擎和相應的方法，其允許依據特定的要求來對CEP查詢進行更高效的處理，從而至少部分克服上述的現有技術的缺點。
發明內容
根據本發明的一個方面，此問題由一種用於處理數據流上的CEP查詢的複雜事件處理(CEP)引擎來解決。在權利要求1的實施例中，CEP引擎包括a.解析器，適用於將接收到的CEP查詢解析成邏輯查詢圖；以及b.轉化器，適用於根據多個數據流表示之一將邏輯查詢圖轉化成物理查詢計劃 (physical query plan)；胃中c.邏輯查詢圖獨立於多個數據流表示。因此，實施例定義了一種用於處理數據流上的CEP查詢的複雜事件處理引擎(CEP 引擎)。與處理傳統資料庫查詢的已知方案類似，由CEP引擎接收到的CEP查詢首先被解析器解析，從而被變換成邏輯查詢圖。邏輯查詢圖隨後被CEP引擎的轉化器轉化成物理查詢計劃，該物理查詢計劃最終負責執行查詢。轉化器執行的轉化是根據多個數據流表示之一的，所述多個數據流表示例如是上述的正-負方案、時間區間方案或任何其他適當的方案。 優選地，只有這個轉化對於各個數據流表示模型有部分不同。重要的是，所產生的邏輯查詢圖是獨立於數據流表示模型的。作為示例，我們考慮在以上進一步說明的示例性數據流「PersonshRoom」中詢問 「房間內年齡最高到30歲的人的年齡是多大？ 」的CEP查詢。此CEP查詢對於數據流在SQL 中可被編制為「SELECT age FROM PersonsInRoom WHERE age <=30」。將此 CEP 查詢解析成邏輯查詢圖將得到圖1所示的邏輯查詢圖。此邏輯查詢圖表示為了處理該CEP查詢而必須採取的動作，即選擇流「PersonshRoom」內的人的年齡並且檢查其年齡是否是30以下。從圖1可以看出，此邏輯查詢圖只定義為處CEP查詢要做什麼的邏輯結構，而沒有涉及任何種類的具體時間性數據流表示方案。轉化器隨後將此邏輯查詢圖轉化成物理查詢計劃，該物理查詢計劃由能夠執行 CEP查詢的具體運算子構成。根據正-負方案的示例性物理查詢計劃在圖加中示出。可以看出，此物理查詢計劃依賴於具體的時間性表示方案(正-負方案)，因為其必須考慮各個數據流元素是如何構建起來的。在圖2b中示出了另一個物理查詢計劃，即用於時間區間方案的那個。結果，在本發明中，在同一 CEP引擎內能夠並行支持多種不同的數據流表示方案， 尤其是正-負方案和時間區間方案，而無需對CEP引擎的許多組件(例如解析器)進行費力且易於出錯的特定於表示模型的適應性修改。這優選是通過使所使用的數據流表示模型成為查詢轉化過程和CEP引擎的組件(尤其是查詢圖)的參數來實現的，這將在下文中進一步更詳細說明。由於根據本發明，實際的數據流表示模型只是儘可能晚地(S卩，在物理查詢計劃級別上)影響CEP查詢(預)處理，本CEP引擎提供了利用依據特定要求最適當的方案來執行CEP查詢的機會。例如，如果對於給定的CEP查詢，活力是至關重要的，則可選擇正-負方案，而為了大大降低系統負擔，可以使用時間區間方案。然而，所選擇的表示模型根據本發明是CEP引擎的參數，從而無論數據流表示模型如何，CEP查詢本身以及從其生成的邏輯查詢圖都是相同的。在本發明的一個方面中，CEP引擎包括優化器，該優化器適用於優化邏輯查詢圖以產生優化邏輯查詢圖，其中優化邏輯查詢圖獨立於多個數據流表示。因此，在上述的解析和轉化步驟之間發生的可選的優化過程也是獨立於數據流表示方案的。參考上述圖1、加和 2b的示例性查詢計劃，對於本領域的技術人員來說很明顯的，它們從處理角度來看不是非常靈巧。這是因為每個元素被投影到「年齡」屬性，即使該元素之後被過濾掉也是如此。因此，如圖3中的優化邏輯查詢圖所示來修改計劃，將會好得多。重要的是，本發明的優化器可獨立於時間性數據流表示模型地執行此優化。尤其，可以只利用(獨立於表示模型的) 邏輯查詢圖來執行優化。進行這些優化是優化器的本來任務。在另一方面中，物理查詢計劃包括獨立於多個數據流表示的至少一個查詢構建塊。因此，物理查詢計劃的構建塊優選地也僅在那些依賴於所使用的數據流表示的部分中有所不同。例如，諸如線程數據流、同步、通信和/或管理之類的各種方面優選是獨立於實際數據流表示來進行的。作為示例，方向「a是否小於或等於30」在圖加和2b所示的兩個物理查詢計劃的兩個過濾操作中都是相同的。這是因為過濾的語義不依賴於數據流表示模型，而只依賴於數據。結果，檢查「a是否小於或等於30」所需的指令可由轉化器以相同的方式生成，獨立於特定的表示模型。這不僅大大減少了實現精力，而且還促進了同一 CEP引擎內的所有數據流表示的互用性。另外，優化器可適用於選擇多個數據流表示之一，並且轉化器可適用於根據所選擇的數據流表示將邏輯查詢圖轉化成物理查詢計劃。因此，在本發明的這個方面中，優化器選擇最適合於給定的CEP查詢的數據流表示模型。在上述方面中，優化器的能力被更加強了，因為優化器還適合於為各個CEP查詢選擇時間性數據流表示模型。當優化器嘗試找出最優解決方案時，其能夠對不同的可能解決方案評級。此評級可由優化器基於諸如「最低數目的年齡比較」之類的用戶選擇的優選項來執行。如上所述，獨立於方案，對於年齡比較，在投影之前執行過濾的查詢計劃可能更好。時間區間方案中的過濾運算子與正-負方案中相比只需要進行一半數目的比較(因為只有一半數目的流元素；見上)。因此，如果只有這兩個方案可用，則對於圖1所示的示例性計劃和更少計算的目標，優化器將選擇時間區間方案。其他方案也是可能的，例如讓用戶選擇數據流表示模型，例如對於每個查詢選擇或者通過設定CEP引擎的相應用戶優選項來選擇。還可由本CEP引擎的推薦系統基於來自查詢優化的信息來建議用戶。在這個方面中，作為讓用戶定義某些配置優選項(例如，「我總是優選更少計算」;見上)的替換或附加，本發明的系統可向用戶呈現優化器的發現(正-負對於活力來說更好，但時間區間對於CPU使用來說更好)並讓其做出決定。尤其，推薦系統只需要呈現那些對於各數據流表示方案不同的事實，而可以忽略對於所有方案都相同的那些。例如，存儲器使用是查詢計劃的質量的重要標準。但對於上述示例，兩個計劃都(幾乎)不需要存儲器。因此，在推薦系統的推薦期間將不提及存儲器使用。當然，上述方案的組合也是可能的。作為替換或附加，CEP引擎還可適用於在CEP查詢的處理期間改變所選擇的數據流表示。因此，關於使用哪個數據流表示的決定甚至可在以後被改變，例如基於改變後的數據流特性和/或由CEP引擎收集的更好的統計信息。作為示例，我們考慮我們的示例性總計查詢(對房間中的人計數)中的希望針對以下標準優化CEP查詢處理的用戶「平均上， 我需要在計數變化之後的至少10個時間單位後更新計數。如果是這樣，則我優選需要更少計算的方案」。關於數據流的典型統計量是元素到達的頻率。如果此統計量表示某個元素平均起來每2個時間單位到達，則優化器可選擇時間區間方案，因為此方案需要更少的計算。 如果數據流隨著時間的過去而減慢並且現在平均起來每12個時間單位才遞送一個元素， 則計數將不會像用戶請求的那樣頻繁地變化，並且優化器可決定切換到正-負方案以便增大活力。必要的查詢變換隨後可應用新的選擇。在另一方面中，CEP引擎還包括至少一個運算子轉化器，該至少一個運算子轉化器適用於把CEP查詢要處理的至少一個數據流的數據元素從第一數據流表示轉化到第二數據流表示。因此，在這個方面中，甚至根本不需要為給定的CEP查詢選擇單個數據流表示模型。例如，通過插入將數據項從一個表示模型轉化到另一個的運算子，CEP引擎可在同一查詢圖內採用若干個數據流表示方案。結果，查詢處理的每個部分可得益於手邊的適當方案。 例如，時間區間方案中表示的數據流元素，例如元素((X)，[start, end))可被轉化成根據正負方案的兩個元素((X)，start, +)和((χ)，end,-)。相反，在接收到((χ)，start, +)之後，從正-負方案到時間區間方案的轉換可等待元素((X)，end，-)，然後傳送((X)，[start， end)) ο另外，提供了一種用於對數據流上的CEP查詢進行(預)處理的方法，其中該方法包括以下步驟將接收到的CEP查詢解析成邏輯查詢圖以及根據多個數據流表示之一將邏輯查詢圖轉化成物理查詢計劃，其中邏輯查詢圖獨立於多個數據流表示。本發明的方法的實施例的另外的有利修改在另外的從屬權利要求中限定。最後，本發明涉及一種電腦程式，包括用於實現上述方法中的任何一種的指令。
在以下詳細描述中，參考以下附圖進一步描述本發明的當前優選的實施例圖1 根據本發明實施例的CEP查詢的示例性邏輯查詢圖；圖加根據本發明實施例的遵循正-負方案的示例性物理查詢計劃；圖2b 根據本發明實施例的遵循時間區間方案的示例性物理查詢計劃；圖3 根據本發明實施例的示例性優化邏輯查詢圖；圖4 根據本發明實施例的CEP引擎的示意性概覽；圖5 示出本發明實施例的示例性Java實現的類圖；以及圖6 根據本發明實施例在(預)處理CEP查詢時涉及的階段的示意性概覽。
具體實施例方式下面，將針對如圖1中示意性示出的用於(預)處理數據流上的CEP查詢的方法來描述本發明的當前優選的實施例，該方法是由CEP引擎1執行的。可以看出，CEP引擎1包括解析器100、可選的優化器200以及轉化器300。CEP引擎1適用於接收一個或多個CEP 查詢10。解析器100把接收到的CEP查詢10解析成邏輯查詢圖20。邏輯查詢圖20在圖1 的示例性實施例中被優化器200優化以產生優化邏輯查詢圖20』。優化邏輯查詢圖20』和 /或邏輯查詢圖20是轉化器300的輸入，轉化器300產生物理查詢計劃30，物理查詢計劃 30最終可被執行來給出根據CEP查詢10來自一個或多個數據流的查詢結果。雖然圖1所示的實施例專注於用於對給定的CEP查詢進行預處理的組件，但應明白，本CEP引擎1可包括另外的組件，例如執行引擎(在圖1中未示出)，用於最終執行所生成的物理查詢計劃30 以便給出CEP查詢10所期望的查詢結果。本發明主要依靠識別出CEP引擎的哪些方面依賴於數據流的表示模型，哪些方面不依賴。雖然數據流表示模型對計算有實質影響，但許多CEP引擎組件，例如授權或認證， 是完全獨立於具體表示的(因為它們不參與查詢執行過程本身，因此完全不受數據流表示方案的影響)，而其他可能只是將所選擇的方案存儲為參數。因此，為了支持若干個數據流表示模型，提供相應版本的其餘系統組件就足夠了。例如，可在運行時向CEP引擎添加或從 CEP引擎去除CEP查詢。為了能夠找到要去除的CEP查詢，其可被存儲在一倉庫中，該倉庫允許查找到執行該查詢的物理運算子。在此倉庫內，還可存儲關於哪個方案當前被用於執行該查詢的信息。從而，用於查詢的時間性表示模型成為了該倉庫的參數，而其不影響倉庫的主功能。但是，即使在負責執行CEP查詢10的CEP引擎的物理查詢圖30真的依賴於所使用的表示模型時，許多其組件的許多方面仍獨立於所使用的表示模型。例如，過濾運算子將始終對(一個或多個)輸入數據流中包含的事件的數據部分應用過濾謂詞(filter predicate)，無論與事件相關聯的時間性信息是如何被表示的。這允許了對於不同的表示模型實現若干個版本的系統構建塊。另一個重要的發現是(邏輯)查詢圖的基本結構對於時間性表示模型通常是沒有差別的。與獨立於向系統指定查詢的技術的資料庫系統(例如SQL語言和/或基於圖的圖形用戶界面(GUI))類似，CEP引擎通常創建表示基本查詢結構的邏輯圖。此邏輯查詢計劃 20隨後作為優化器200的查詢優化的對象。然後，此邏輯查詢計劃20和/或優化邏輯查詢計劃20』被轉化成物理查詢圖30，該物理查詢圖30被用於執行CEP查詢10。本發明在若干個階段影響此過程首先，邏輯轉化/解析100獨立於數據流表示地發生。然後，表示模型優選被用作轉化過程300的參數。從而，甚至轉化300對於每個方案也不會有太多差別，而是依據所需的方案選擇相應的構建塊，但儘可能地獨立。例如，SQL WHERE語句的過濾謂詞可獨立於時間性表示模型地被轉化成查詢謂詞操作。示例件實現下面，將說明如圖2中所示的本發明的CEP引擎1的一些部分的基於Java的實現。 應當注意，Java只是多種適當的程式語言中的一種，本發明可用任何其他程式語言來實現。通用運算子實現為了高效地執行混合數據表示模型(即，支持各種不同的數據流表示模型)，示例性實現方式使用Java模板來使表示模型成為運算子框架的參數。這反映在接口 GeneralPushOperator的定義中(參見圖幻，其是以下進一步說明的所有運算子的基礎interface GeneralPushOperator<1, 0, IE extends GeneralElement, OE extends GeneralElement>I和0參數將輸入和輸出的類型參數化，而IE和OE將其表示參數化為事件流的元素。GeneralElement的子接口被用於指定不同的時間性表示模型，例如正-負(PnElement) 或時間區間方案(Element)。利用這些參數，接口對於某個數據流表示方案例如時間區間方案定義運算子的屬性interface PushOperatorextends GeneralPushOperator〈I，0，Element〈I>，Element〈0>>現在可對若干個數據流表示方案以通用方式實現具體運算子。例如，可在以下類中定義過濾操作class GeneralPushFilter<T, TE extends GeneralElement>extends AbstractUnarySingleGeneralPushOperator這些通用實現隨後可被進一步專門化到某個數據流表示方案，例如時間區間方案class PushFilterextends GeneralPushFilter<T, Element>implements PushOperator上述技術的一個非常重要的優點在於，專門的版本僅對於其構造器參數略有變化，而它們中的大多數經由其共同的超類被共享。圖2以簡化的UML類圖的形式示出了對於時間區間和正-負方案的上述過濾實現的示例。注意，主要實現精力花在左側的類，而右側的專門化沒有花費很多額外精力並且可以很容易地對額外的方案完成。獨立於方案的查詢表示CEP查詢10首先被轉化/解析100成邏輯查詢圖20，其完全獨立於之後用於執行CEP查詢10的數據流表示模型。邏輯查詢圖20現在可經歷查詢優化200。另外，關於選擇哪個數據流表示模型來執行的決定可基於邏輯查詢圖20和/或優化邏輯查詢圖20』來做出。
圖3示出了將CEP查詢10變換成依賴於方案的物理運算子圖30所需的大多數工作可獨立於所選擇的時間性表示方案發生。方案參數化的查詢轉化邏輯查詢圖20和/或優化邏輯查詢圖20』隨後被轉化 300成用於執行CEP查詢10的運算子圖30。轉化300優選取若干個參數(QueryTranslator queryTrans 1 ator, Node node,TranslationOptions transIationOptions)「node」表示要被查詢轉化器「queryTranslator」轉化300的邏輯查詢計劃20/ 優化邏輯查詢計劃20』的節點，而轉化選項的選項「TranslationOptions」指定要用於轉化 300的方案，等等interface TranslationOptions{Approach getTargetApproach；...相應的轉化過程300現在利用給定的數據流表示方案產生轉化。為此，其可計算獨立於方案的共同參數並且可以只執行一個或多個微小的依賴於方案的修改。例如，過濾器的查詢謂詞「theta」的計算可獨立於目標方案完成(然而由於共同接口其仍被傳遞到轉化過程)
MetaDataPredicate theta =
queryTranslator .translate (Nodes. getNoc^node, PREDICATE), translationOptions);
switch (translationOptions.getTargetApproach) {
case TIME_INTERVAL: return new PushFilter(…)；
case POSITIVE_NEGATIVE: return new
PnPushFilter(...); · _混合方案使用為了利用用於執行CEP查詢10的多個方案支持運算子圖，可以提供將一個或多個經處理的數據流中包括的事件從一個表示模型轉換到另一個的運算子。例如，PushToPnPush運算子從時間區間轉換到正-負方案class PushToPnPushextends AbstractUnarySingIeGeneraIPushOperator<T, Τ, Element, PnElement>方案選擇對要使用的數據流表示方案的選擇可服從用戶選擇。在一些實施例中， 基於諸如優選低資源消耗或高活力之類的用戶指定，這可由優化器200通過分析所涉及的運算子並基於所支持的數據流表示方案訪問關於其屬性的相應預定評級來完成。
權利要求
1.一種複雜事件處CEP引擎(1)，用於處理數據流上的CEP查詢(10)，其中所述CEP引擎⑴包括a.解析器(100)，適用於將接收到的CEP查詢(10)解析成邏輯查詢圖Q0)；以及b.轉化器(300)，適用於根據多個數據流表示之一將所述邏輯查詢圖00)轉化成物理查詢計劃(30)；其中c.所述邏輯查詢圖00)獨立於所述多個數據流表示。
2.如權利要求1所述的CEP引擎，還包括優化器000)，該優化器(200)適用於優化所述邏輯查詢圖00)以產生優化邏輯查詢圖00』)，其中所述優化邏輯查詢圖Q0』)獨立於所述多個數據流表示。
3.如權利要求1或2所述的CEP引擎，其中，所述物理查詢計劃(30)包括獨立於所述多個數據流表示的至少一個查詢構建塊。
4.如在前權利要求2或3中任何一項所述的CEP引擎，其中，所述優化器(200)適用於選擇所述多個數據流表示之一，並且所述轉化器(300)適用於根據所選擇的數據流表示將所述邏輯查詢圖00)轉化成物理查詢計劃(30)。
5.如在前權利要求所述的CEP引擎，還適用於在所述CEP查詢(10)的處理期間改變所選擇的數據流表示。
6.如在前權利要求中任何一項所述的CEP引擎，還包括至少一個運算子轉化器，該至少一個運算子轉化器適用於把所述CEP查詢(10)要處理的至少一個數據流的數據元素從第一數據流表示轉化到第二數據流表示。
7.一種用於處理數據流上的CEP查詢(10)的方法，其中所述方法包括以下步驟a.將接收到的CEP查詢(10)解析(100)成邏輯查詢圖Q0)；以及b.根據多個數據流表示之一將所述邏輯查詢圖00)轉化(300)成物理查詢計劃 (30)；其中c.所述邏輯查詢圖00)獨立於所述多個數據流表示。
8.如權利要求7所述的方法，還包括優化(200)所述邏輯查詢圖00)以產生優化邏輯查詢圖00』 )的步驟，其中所述優化邏輯查詢圖00』 )獨立於所述多個數據流表示。
9.如權利要求7或8所述的方法，其中，所述物理查詢計劃(30)包括獨立於所述多個數據流表示的至少一個查詢構建塊(310)。
10.如在前權利要求8或9中任何一項所述的方法，其中，所述優化(200)包括選擇所述多個數據流表示之一，並且所述轉化(300)包括根據所選擇的數據流表示將所述邏輯查詢圖00)轉化成物理查詢計劃(30)。
11.如在前權利要求所述的方法，包括在所述CEP查詢(10)的處理期間改變所選擇的數據流表示的步驟。
12.如在前權利要求中任何一項所述的方法，還包括用至少一個運算子把所述CEP查詢(10)要處理的至少一個數據流的數據元素從第一數據流表示轉化到第二數據流表示。
13.一種電腦程式，包括用於實現如在前權利要求7-12中任何一項所述的方法的指令。
全文摘要
本發明提供了CEP引擎和用於處CEP查詢的方法。本發明涉及一種複雜事件處理CEP引擎(1)，用於處理數據流上的CEP查詢(10)，其中CEP引擎(1)包括a.解析器(100)，適用於將接收到的CEP查詢(10)解析成邏輯查詢圖(20)；以及b.轉化器(300)，適用於根據多個數據流表示之一將邏輯查詢圖(20)轉化成物理查詢計劃(30)；其中c.邏輯查詢圖(20)獨立於所述多個數據流表示。
文檔編號G06F17/30GK102567541SQ20111046218
公開日2012年7月11日 申請日期2011年12月22日 優先權日2010年12月22日
發明者克裡斯多夫·漢斯, 尤爾根·克萊默, 杜比亞斯·裡門施耐德, 麥可·卡馬特 申請人:軟體股份公司