專利名稱：Cep引擎和用于處理cep查詢的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及復(fù)雜事件處理(complex event processing, CEP)引擎和用于處理CEP 查詢的方法。
背景技術(shù)：
現(xiàn)代計(jì)算機(jī)系統(tǒng)經(jīng)常對(duì)數(shù)據(jù)流進(jìn)行操作，即對(duì)由傳感器、傳感器網(wǎng)絡(luò)或其他(一個(gè)或多個(gè))數(shù)據(jù)源捕捉的數(shù)據(jù)項(xiàng)的連續(xù)序列進(jìn)行操作，其中已經(jīng)接收到的數(shù)據(jù)項(xiàng)在更多數(shù)據(jù)項(xiàng)仍在被傳感器捕捉的同時(shí)被處理。經(jīng)處理數(shù)據(jù)項(xiàng)通常用于檢測(cè)時(shí)間關(guān)鍵復(fù)雜事件并用于生成相應(yīng)的警報(bào)和/或差錯(cuò)消息。典型的應(yīng)用場(chǎng)景是諸如設(shè)施監(jiān)視系統(tǒng)之類的安保系統(tǒng)，其中由讀卡器捕捉到的數(shù)據(jù)項(xiàng)的流被處理以便識(shí)別對(duì)設(shè)施內(nèi)的機(jī)密區(qū)域的未經(jīng)授權(quán)的訪問(wèn)或者進(jìn)入和離開建筑物的人的其他異常行為。其他應(yīng)用場(chǎng)景包括道路交通管理、位置跟蹤、醫(yī)療監(jiān)控、制造過(guò)程、網(wǎng)絡(luò)流量監(jiān)控、商業(yè)活動(dòng)監(jiān)控和欺騙檢測(cè)。雖然與單個(gè)數(shù)據(jù)項(xiàng)/事件有關(guān)的異常行為的檢測(cè)相當(dāng)簡(jiǎn)單明了(例如，在某個(gè)人的ID卡被讀卡器讀取時(shí)確定該卡已經(jīng)期滿)，但大多數(shù)現(xiàn)實(shí)生活場(chǎng)景要求檢測(cè)與流內(nèi)的多個(gè)數(shù)據(jù)項(xiàng)有關(guān)的更復(fù)雜情形(例如，某個(gè)人進(jìn)入了某個(gè)房間，但在預(yù)定量的時(shí)間之后沒(méi)有離開該房間)。在此上下文中，通常分析多個(gè)傳感器的數(shù)據(jù)，其中傳感器可包括硬件傳感器、 軟件傳感器、軟件應(yīng)用等等。此處理范例一般被稱為復(fù)雜事件處理(CEP)。復(fù)雜事件處理(CEP)引入了關(guān)于經(jīng)典數(shù)據(jù)庫(kù)技術(shù)的若干個(gè)重要的范例變化，在經(jīng)典數(shù)據(jù)庫(kù)技術(shù)中，數(shù)據(jù)是相對(duì)靜止的并且各種查詢可被編制來(lái)檢索期望的數(shù)據(jù)。然而，在 CEP中，查詢是比較固定的并且被饋送以持續(xù)到達(dá)的數(shù)據(jù)流。如上所述，CEP查詢通常關(guān)聯(lián)多個(gè)輸入數(shù)據(jù)項(xiàng)，尋找模式并且在觀察到某個(gè)模式時(shí)產(chǎn)生警報(bào)、差錯(cuò)消息等等形式的輸出事件?？傊珻EP應(yīng)用(也稱為CEP引擎)必須應(yīng)對(duì)以非常高的速率持續(xù)到達(dá)的非常瞬變的事件數(shù)據(jù)并且必須盡可能快地、在理想情況下實(shí)時(shí)地產(chǎn)生相應(yīng)的輸出事件/警報(bào)。這包括主存儲(chǔ)器內(nèi)的基于推送的處理(也稱為數(shù)據(jù)驅(qū)動(dòng)的處理)，這表示一種數(shù)據(jù)流方案，其中要處理的數(shù)據(jù)不是由處理運(yùn)算子(operator)根據(jù)需要或利用某種調(diào)度技術(shù)來(lái)請(qǐng)求(拉出) 的，而是在其變得可用時(shí)被直接提供(推送)給處理運(yùn)算子。美國(guó)專利US 7，676，461B2和 US 7，457，提供了關(guān)于復(fù)雜事件處理(CEP)的更多背景信息。當(dāng)處理CEP查詢時(shí)，數(shù)據(jù)流的表示模型對(duì)于諸如存儲(chǔ)器和CPU使用之類的資源要求以及對(duì)于CEP系統(tǒng)的活力和反應(yīng)時(shí)間都扮演著重要的角色。在現(xiàn)有技術(shù)中，已經(jīng)提出了兩種一般數(shù)據(jù)流表示模型正-負(fù)方案和時(shí)間區(qū)間方案。對(duì)于專門的CEP引擎已知另外的方案，并且將來(lái)的發(fā)展有可能給出另外的方案。正-負(fù)方案在科學(xué)界尤其是在美國(guó)廣泛普及。因此，源自于相應(yīng)的大學(xué)衍生公司的大多數(shù)商業(yè)上可得的CEP引擎使用此方案。作為數(shù)據(jù)流的時(shí)間性表示模型上的運(yùn)行示例，我們考慮向數(shù)據(jù)流的每個(gè)元素指派基于離散時(shí)間軸的有效性的模型。示例性的數(shù)據(jù)流在此示例被稱為“PersonshRoom”，并且攜帶著關(guān)于在房間內(nèi)的人(即，其姓名和年齡)的
3信息。數(shù)據(jù)流元素("Alex", 35)從時(shí)亥Ij 10 (包括時(shí)刻10)到時(shí)刻30 (不包括時(shí)刻30)是有效的(即，在房間中)，并且(“Jolie", 25)從時(shí)刻20(包括20)到40 (不包括40)是有效的。在正-負(fù)方案中，示例性的數(shù)據(jù)流將由元素((“Alex”，35)，10，+)表示，該元素表明 ("Alex", 35)在時(shí)亥Ij 10變得有效。在該示例中，此元素后面是元素((，，Jolie”，25)，20， +)，表明(“Alex”，3 在時(shí)刻20變得無(wú)效的元素((“Alex”，35)，30，-)，以及最終的元素 ((，，Jolie”，25)，40，-)。關(guān)于正-負(fù)方案的更多信息可在 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。時(shí)間區(qū)間方案是由馬爾堡大學(xué)等等傳播的。在上述示例性數(shù)據(jù)流 "PersonsInRoom"中，該流在時(shí)間區(qū)間方案中將由兩個(gè)流元素表示，第一個(gè)是(("Alex", 35)，[10，3))，表明(‘‘Alex”，35)在半開放時(shí)間區(qū)間[10，30)中是有效的，第二個(gè)是 ((‘‘Jolie”，25)，[20,40))，表明(‘‘Jolie”，25)在半開放區(qū)間[20，40)中是有效的。目前在申請(qǐng)人的CEP引擎RTM分析器中采用了時(shí)間區(qū)間方案。關(guān)于時(shí)間區(qū)間方案的更多信息可在 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)中找到。關(guān)于更多的數(shù)據(jù)流表示方案的額外信息可在JUrgen Kroner所著的“Continuous Queries over Data Streams-Semantics and Implementation，， (Dissertation， Philipps-University Marburg，Marburg，2007)中找到。對(duì)于大多數(shù)種類的查詢，正-負(fù)方案具有比時(shí)間區(qū)間方案更高的資源消耗。在一些情況下，此開銷可能是很大的。另一方面，存在這樣的場(chǎng)景，其中正-負(fù)方案可更早地產(chǎn)生結(jié)果，這增大了 CEP引擎的活力。如果快速回答是至關(guān)重要的，則這可能是相當(dāng)有利的。 作為簡(jiǎn)單的示例，我們考慮一個(gè)簡(jiǎn)單的過(guò)濾函數(shù)，其在上述示例性數(shù)據(jù)流“Persons^Room” 中只接受姓名以“Α”開始的人，從而此過(guò)濾函數(shù)接受數(shù)據(jù)流元素(“Alex”，35)，但拒絕(，， Jolie", 25)。如果使用正-負(fù)方案，則判定字符串是否開始于“A”的計(jì)算將必須被應(yīng)用到流中的所有四個(gè)數(shù)據(jù)流元素(見上)，從而接受第一和第三元素。利用時(shí)間區(qū)間方案，此計(jì)算必須被應(yīng)用兩次，因?yàn)橹挥袃蓚€(gè)流元素，在此情況下只接受第一個(gè)。與此示例類似，利用正-負(fù)方案，與時(shí)間區(qū)間方案相比，大多數(shù)計(jì)算必須被進(jìn)行兩次，從而時(shí)間區(qū)間方案在某些情況下是不那么處理密集的。至于活力，我們考慮一個(gè)總計(jì)函數(shù)，其對(duì)流內(nèi)有效的數(shù)據(jù)流元素計(jì)數(shù)。兩個(gè)示例性表示的結(jié)果將如下((1)，10，+)、((1),20,-), ((2),20,+),(⑵， 30，-)、((1)，30，+)、((1)，40，-)和(⑴，[10，20))、((2)，[20，30))、((1)，[30,40))?！?”在時(shí)刻20變成有效計(jì)數(shù)的信息對(duì)于正負(fù)方案可在時(shí)刻20被發(fā)出，而在時(shí)間區(qū)間方案中此信息通常將在時(shí)刻30被發(fā)出，因?yàn)橄到y(tǒng)必須等待計(jì)數(shù)2再次變得無(wú)效，以便確定2的有效區(qū)間。與之不同，正-負(fù)方案使用單獨(dú)的元素來(lái)發(fā)送關(guān)于2再次變得無(wú)效的信息。結(jié)果， 正-負(fù)方案在此情況下具有活力方面的優(yōu)點(diǎn)?，F(xiàn)今有多種 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。由于上述的各種已知的數(shù)據(jù)表示模型的不同關(guān)注點(diǎn)、優(yōu)點(diǎn)和缺點(diǎn)，所有已知的 CEP引擎都只專攻這些方案之一，同時(shí)接受其缺點(diǎn)。乍看起來(lái)，這是沒(méi)有缺點(diǎn)的，因?yàn)槔缯?負(fù)方案和時(shí)間區(qū)間方案都產(chǎn)生邏輯上等同的結(jié)果，從而在特定的CEP引擎中只使用這些方案之一似乎就足夠了。只使用一種方案也具有只需要實(shí)現(xiàn)和維護(hù)所選擇的方案的益處。然而，限于一種特殊的方案意味著對(duì)于某些種類的查詢要忍受該方案的缺陷，取決于特定CEP應(yīng)用場(chǎng)景的要求這可能是不利的。因此，本發(fā)明的技術(shù)問(wèn)題是提供一種改進(jìn)的CEP引擎和相應(yīng)的方法，其允許依據(jù)特定的要求來(lái)對(duì)CEP查詢進(jìn)行更高效的處理，從而至少部分克服上述的現(xiàn)有技術(shù)的缺點(diǎn)。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的一個(gè)方面，此問(wèn)題由一種用于處理數(shù)據(jù)流上的CEP查詢的復(fù)雜事件處理(CEP)引擎來(lái)解決。在權(quán)利要求1的實(shí)施例中，CEP引擎包括a.解析器，適用于將接收到的CEP查詢解析成邏輯查詢圖；以及b.轉(zhuǎn)化器，適用于根據(jù)多個(gè)數(shù)據(jù)流表示之一將邏輯查詢圖轉(zhuǎn)化成物理查詢計(jì)劃 (physical query plan)；胃中c.邏輯查詢圖獨(dú)立于多個(gè)數(shù)據(jù)流表示。因此，實(shí)施例定義了一種用于處理數(shù)據(jù)流上的CEP查詢的復(fù)雜事件處理引擎(CEP 引擎)。與處理傳統(tǒng)數(shù)據(jù)庫(kù)查詢的已知方案類似，由CEP引擎接收到的CEP查詢首先被解析器解析，從而被變換成邏輯查詢圖。邏輯查詢圖隨后被CEP引擎的轉(zhuǎn)化器轉(zhuǎn)化成物理查詢計(jì)劃，該物理查詢計(jì)劃最終負(fù)責(zé)執(zhí)行查詢。轉(zhuǎn)化器執(zhí)行的轉(zhuǎn)化是根據(jù)多個(gè)數(shù)據(jù)流表示之一的，所述多個(gè)數(shù)據(jù)流表示例如是上述的正-負(fù)方案、時(shí)間區(qū)間方案或任何其他適當(dāng)?shù)姆桨浮?優(yōu)選地，只有這個(gè)轉(zhuǎn)化對(duì)于各個(gè)數(shù)據(jù)流表示模型有部分不同。重要的是，所產(chǎn)生的邏輯查詢圖是獨(dú)立于數(shù)據(jù)流表示模型的。作為示例，我們考慮在以上進(jìn)一步說(shuō)明的示例性數(shù)據(jù)流“PersonshRoom”中詢問(wèn) “房間內(nèi)年齡最高到30歲的人的年齡是多大？ ”的CEP查詢。此CEP查詢對(duì)于數(shù)據(jù)流在SQL 中可被編制為“SELECT age FROM PersonsInRoom WHERE age <=30”。將此 CEP 查詢解析成邏輯查詢圖將得到圖1所示的邏輯查詢圖。此邏輯查詢圖表示為了處理該CEP查詢而必須采取的動(dòng)作，即選擇流“PersonshRoom”內(nèi)的人的年齡并且檢查其年齡是否是30以下。從圖1可以看出，此邏輯查詢圖只定義為處CEP查詢要做什么的邏輯結(jié)構(gòu)，而沒(méi)有涉及任何種類的具體時(shí)間性數(shù)據(jù)流表示方案。轉(zhuǎn)化器隨后將此邏輯查詢圖轉(zhuǎn)化成物理查詢計(jì)劃，該物理查詢計(jì)劃由能夠執(zhí)行 CEP查詢的具體運(yùn)算子構(gòu)成。根據(jù)正-負(fù)方案的示例性物理查詢計(jì)劃在圖加中示出?？梢钥闯觯宋锢聿樵冇?jì)劃依賴于具體的時(shí)間性表示方案(正-負(fù)方案)，因?yàn)槠浔仨毧紤]各個(gè)數(shù)據(jù)流元素是如何構(gòu)建起來(lái)的。在圖2b中示出了另一個(gè)物理查詢計(jì)劃，即用于時(shí)間區(qū)間方案的那個(gè)。結(jié)果，在本發(fā)明中，在同一 CEP引擎內(nèi)能夠并行支持多種不同的數(shù)據(jù)流表示方案， 尤其是正-負(fù)方案和時(shí)間區(qū)間方案，而無(wú)需對(duì)CEP引擎的許多組件(例如解析器)進(jìn)行費(fèi)力且易于出錯(cuò)的特定于表示模型的適應(yīng)性修改。這優(yōu)選是通過(guò)使所使用的數(shù)據(jù)流表示模型成為查詢轉(zhuǎn)化過(guò)程和CEP引擎的組件(尤其是查詢圖)的參數(shù)來(lái)實(shí)現(xiàn)的，這將在下文中進(jìn)一步更詳細(xì)說(shuō)明。由于根據(jù)本發(fā)明，實(shí)際的數(shù)據(jù)流表示模型只是盡可能晚地(S卩，在物理查詢計(jì)劃級(jí)別上)影響CEP查詢(預(yù))處理，本CEP引擎提供了利用依據(jù)特定要求最適當(dāng)?shù)姆桨竵?lái)執(zhí)行CEP查詢的機(jī)會(huì)。例如，如果對(duì)于給定的CEP查詢，活力是至關(guān)重要的，則可選擇正-負(fù)方案，而為了大大降低系統(tǒng)負(fù)擔(dān)，可以使用時(shí)間區(qū)間方案。然而，所選擇的表示模型根據(jù)本發(fā)明是CEP引擎的參數(shù)，從而無(wú)論數(shù)據(jù)流表示模型如何，CEP查詢本身以及從其生成的邏輯查詢圖都是相同的。在本發(fā)明的一個(gè)方面中，CEP引擎包括優(yōu)化器，該優(yōu)化器適用于優(yōu)化邏輯查詢圖以產(chǎn)生優(yōu)化邏輯查詢圖，其中優(yōu)化邏輯查詢圖獨(dú)立于多個(gè)數(shù)據(jù)流表示。因此，在上述的解析和轉(zhuǎn)化步驟之間發(fā)生的可選的優(yōu)化過(guò)程也是獨(dú)立于數(shù)據(jù)流表示方案的。參考上述圖1、加和 2b的示例性查詢計(jì)劃，對(duì)于本領(lǐng)域的技術(shù)人員來(lái)說(shuō)很明顯的，它們從處理角度來(lái)看不是非常靈巧。這是因?yàn)槊總€(gè)元素被投影到“年齡”屬性，即使該元素之后被過(guò)濾掉也是如此。因此，如圖3中的優(yōu)化邏輯查詢圖所示來(lái)修改計(jì)劃，將會(huì)好得多。重要的是，本發(fā)明的優(yōu)化器可獨(dú)立于時(shí)間性數(shù)據(jù)流表示模型地執(zhí)行此優(yōu)化。尤其，可以只利用(獨(dú)立于表示模型的) 邏輯查詢圖來(lái)執(zhí)行優(yōu)化。進(jìn)行這些優(yōu)化是優(yōu)化器的本來(lái)任務(wù)。在另一方面中，物理查詢計(jì)劃包括獨(dú)立于多個(gè)數(shù)據(jù)流表示的至少一個(gè)查詢構(gòu)建塊。因此，物理查詢計(jì)劃的構(gòu)建塊優(yōu)選地也僅在那些依賴于所使用的數(shù)據(jù)流表示的部分中有所不同。例如，諸如線程數(shù)據(jù)流、同步、通信和/或管理之類的各種方面優(yōu)選是獨(dú)立于實(shí)際數(shù)據(jù)流表示來(lái)進(jìn)行的。作為示例，方向“a是否小于或等于30”在圖加和2b所示的兩個(gè)物理查詢計(jì)劃的兩個(gè)過(guò)濾操作中都是相同的。這是因?yàn)檫^(guò)濾的語(yǔ)義不依賴于數(shù)據(jù)流表示模型，而只依賴于數(shù)據(jù)。結(jié)果，檢查“a是否小于或等于30”所需的指令可由轉(zhuǎn)化器以相同的方式生成，獨(dú)立于特定的表示模型。這不僅大大減少了實(shí)現(xiàn)精力，而且還促進(jìn)了同一 CEP引擎內(nèi)的所有數(shù)據(jù)流表示的互用性。另外，優(yōu)化器可適用于選擇多個(gè)數(shù)據(jù)流表示之一，并且轉(zhuǎn)化器可適用于根據(jù)所選擇的數(shù)據(jù)流表示將邏輯查詢圖轉(zhuǎn)化成物理查詢計(jì)劃。因此，在本發(fā)明的這個(gè)方面中，優(yōu)化器選擇最適合于給定的CEP查詢的數(shù)據(jù)流表示模型。在上述方面中，優(yōu)化器的能力被更加強(qiáng)了，因?yàn)閮?yōu)化器還適合于為各個(gè)CEP查詢選擇時(shí)間性數(shù)據(jù)流表示模型。當(dāng)優(yōu)化器嘗試找出最優(yōu)解決方案時(shí)，其能夠?qū)Σ煌目赡芙鉀Q方案評(píng)級(jí)。此評(píng)級(jí)可由優(yōu)化器基于諸如“最低數(shù)目的年齡比較”之類的用戶選擇的優(yōu)選項(xiàng)來(lái)執(zhí)行。如上所述，獨(dú)立于方案，對(duì)于年齡比較，在投影之前執(zhí)行過(guò)濾的查詢計(jì)劃可能更好。時(shí)間區(qū)間方案中的過(guò)濾運(yùn)算子與正-負(fù)方案中相比只需要進(jìn)行一半數(shù)目的比較(因?yàn)橹挥幸话霐?shù)目的流元素；見上)。因此，如果只有這兩個(gè)方案可用，則對(duì)于圖1所示的示例性計(jì)劃和更少計(jì)算的目標(biāo)，優(yōu)化器將選擇時(shí)間區(qū)間方案。其他方案也是可能的，例如讓用戶選擇數(shù)據(jù)流表示模型，例如對(duì)于每個(gè)查詢選擇或者通過(guò)設(shè)定CEP引擎的相應(yīng)用戶優(yōu)選項(xiàng)來(lái)選擇。還可由本CEP引擎的推薦系統(tǒng)基于來(lái)自查詢優(yōu)化的信息來(lái)建議用戶。在這個(gè)方面中，作為讓用戶定義某些配置優(yōu)選項(xiàng)(例如，“我總是優(yōu)選更少計(jì)算”;見上)的替換或附加，本發(fā)明的系統(tǒng)可向用戶呈現(xiàn)優(yōu)化器的發(fā)現(xiàn)(正-負(fù)對(duì)于活力來(lái)說(shuō)更好，但時(shí)間區(qū)間對(duì)于CPU使用來(lái)說(shuō)更好)并讓其做出決定。尤其，推薦系統(tǒng)只需要呈現(xiàn)那些對(duì)于各數(shù)據(jù)流表示方案不同的事實(shí)，而可以忽略對(duì)于所有方案都相同的那些。例如，存儲(chǔ)器使用是查詢計(jì)劃的質(zhì)量的重要標(biāo)準(zhǔn)。但對(duì)于上述示例，兩個(gè)計(jì)劃都(幾乎)不需要存儲(chǔ)器。因此，在推薦系統(tǒng)的推薦期間將不提及存儲(chǔ)器使用。當(dāng)然，上述方案的組合也是可能的。作為替換或附加，CEP引擎還可適用于在CEP查詢的處理期間改變所選擇的數(shù)據(jù)流表示。因此，關(guān)于使用哪個(gè)數(shù)據(jù)流表示的決定甚至可在以后被改變，例如基于改變后的數(shù)據(jù)流特性和/或由CEP引擎收集的更好的統(tǒng)計(jì)信息。作為示例，我們考慮我們的示例性總計(jì)查詢(對(duì)房間中的人計(jì)數(shù))中的希望針對(duì)以下標(biāo)準(zhǔn)優(yōu)化CEP查詢處理的用戶“平均上， 我需要在計(jì)數(shù)變化之后的至少10個(gè)時(shí)間單位后更新計(jì)數(shù)。如果是這樣，則我優(yōu)選需要更少計(jì)算的方案”。關(guān)于數(shù)據(jù)流的典型統(tǒng)計(jì)量是元素到達(dá)的頻率。如果此統(tǒng)計(jì)量表示某個(gè)元素平均起來(lái)每2個(gè)時(shí)間單位到達(dá)，則優(yōu)化器可選擇時(shí)間區(qū)間方案，因?yàn)榇朔桨感枰俚挠?jì)算。 如果數(shù)據(jù)流隨著時(shí)間的過(guò)去而減慢并且現(xiàn)在平均起來(lái)每12個(gè)時(shí)間單位才遞送一個(gè)元素， 則計(jì)數(shù)將不會(huì)像用戶請(qǐng)求的那樣頻繁地變化，并且優(yōu)化器可決定切換到正-負(fù)方案以便增大活力。必要的查詢變換隨后可應(yīng)用新的選擇。在另一方面中，CEP引擎還包括至少一個(gè)運(yùn)算子轉(zhuǎn)化器，該至少一個(gè)運(yùn)算子轉(zhuǎn)化器適用于把CEP查詢要處理的至少一個(gè)數(shù)據(jù)流的數(shù)據(jù)元素從第一數(shù)據(jù)流表示轉(zhuǎn)化到第二數(shù)據(jù)流表示。因此，在這個(gè)方面中，甚至根本不需要為給定的CEP查詢選擇單個(gè)數(shù)據(jù)流表示模型。例如，通過(guò)插入將數(shù)據(jù)項(xiàng)從一個(gè)表示模型轉(zhuǎn)化到另一個(gè)的運(yùn)算子，CEP引擎可在同一查詢圖內(nèi)采用若干個(gè)數(shù)據(jù)流表示方案。結(jié)果，查詢處理的每個(gè)部分可得益于手邊的適當(dāng)方案。 例如，時(shí)間區(qū)間方案中表示的數(shù)據(jù)流元素，例如元素((X)，[start, end))可被轉(zhuǎn)化成根據(jù)正負(fù)方案的兩個(gè)元素((X)，start, +)和((χ)，end,-)。相反，在接收到((χ)，start, +)之后，從正-負(fù)方案到時(shí)間區(qū)間方案的轉(zhuǎn)換可等待元素((X)，end，-)，然后傳送((X)，[start， end)) ο另外，提供了一種用于對(duì)數(shù)據(jù)流上的CEP查詢進(jìn)行(預(yù))處理的方法，其中該方法包括以下步驟將接收到的CEP查詢解析成邏輯查詢圖以及根據(jù)多個(gè)數(shù)據(jù)流表示之一將邏輯查詢圖轉(zhuǎn)化成物理查詢計(jì)劃，其中邏輯查詢圖獨(dú)立于多個(gè)數(shù)據(jù)流表示。本發(fā)明的方法的實(shí)施例的另外的有利修改在另外的從屬權(quán)利要求中限定。最后，本發(fā)明涉及一種計(jì)算機(jī)程序，包括用于實(shí)現(xiàn)上述方法中的任何一種的指令。


在以下詳細(xì)描述中，參考以下附圖進(jìn)一步描述本發(fā)明的當(dāng)前優(yōu)選的實(shí)施例圖1 根據(jù)本發(fā)明實(shí)施例的CEP查詢的示例性邏輯查詢圖；圖加根據(jù)本發(fā)明實(shí)施例的遵循正-負(fù)方案的示例性物理查詢計(jì)劃；圖2b 根據(jù)本發(fā)明實(shí)施例的遵循時(shí)間區(qū)間方案的示例性物理查詢計(jì)劃；圖3 根據(jù)本發(fā)明實(shí)施例的示例性優(yōu)化邏輯查詢圖；圖4 根據(jù)本發(fā)明實(shí)施例的CEP引擎的示意性概覽；圖5 示出本發(fā)明實(shí)施例的示例性Java實(shí)現(xiàn)的類圖；以及圖6 根據(jù)本發(fā)明實(shí)施例在(預(yù))處理CEP查詢時(shí)涉及的階段的示意性概覽。
具體實(shí)施例方式下面，將針對(duì)如圖1中示意性示出的用于(預(yù))處理數(shù)據(jù)流上的CEP查詢的方法來(lái)描述本發(fā)明的當(dāng)前優(yōu)選的實(shí)施例，該方法是由CEP引擎1執(zhí)行的?？梢钥闯觯珻EP引擎1包括解析器100、可選的優(yōu)化器200以及轉(zhuǎn)化器300。CEP引擎1適用于接收一個(gè)或多個(gè)CEP 查詢10。解析器100把接收到的CEP查詢10解析成邏輯查詢圖20。邏輯查詢圖20在圖1 的示例性實(shí)施例中被優(yōu)化器200優(yōu)化以產(chǎn)生優(yōu)化邏輯查詢圖20’。優(yōu)化邏輯查詢圖20’和 /或邏輯查詢圖20是轉(zhuǎn)化器300的輸入，轉(zhuǎn)化器300產(chǎn)生物理查詢計(jì)劃30，物理查詢計(jì)劃 30最終可被執(zhí)行來(lái)給出根據(jù)CEP查詢10來(lái)自一個(gè)或多個(gè)數(shù)據(jù)流的查詢結(jié)果。雖然圖1所示的實(shí)施例專注于用于對(duì)給定的CEP查詢進(jìn)行預(yù)處理的組件，但應(yīng)明白，本CEP引擎1可包括另外的組件，例如執(zhí)行引擎(在圖1中未示出)，用于最終執(zhí)行所生成的物理查詢計(jì)劃30 以便給出CEP查詢10所期望的查詢結(jié)果。本發(fā)明主要依靠識(shí)別出CEP引擎的哪些方面依賴于數(shù)據(jù)流的表示模型，哪些方面不依賴。雖然數(shù)據(jù)流表示模型對(duì)計(jì)算有實(shí)質(zhì)影響，但許多CEP引擎組件，例如授權(quán)或認(rèn)證， 是完全獨(dú)立于具體表示的(因?yàn)樗鼈儾粎⑴c查詢執(zhí)行過(guò)程本身，因此完全不受數(shù)據(jù)流表示方案的影響)，而其他可能只是將所選擇的方案存儲(chǔ)為參數(shù)。因此，為了支持若干個(gè)數(shù)據(jù)流表示模型，提供相應(yīng)版本的其余系統(tǒng)組件就足夠了。例如，可在運(yùn)行時(shí)向CEP引擎添加或從 CEP引擎去除CEP查詢。為了能夠找到要去除的CEP查詢，其可被存儲(chǔ)在一倉(cāng)庫(kù)中，該倉(cāng)庫(kù)允許查找到執(zhí)行該查詢的物理運(yùn)算子。在此倉(cāng)庫(kù)內(nèi)，還可存儲(chǔ)關(guān)于哪個(gè)方案當(dāng)前被用于執(zhí)行該查詢的信息。從而，用于查詢的時(shí)間性表示模型成為了該倉(cāng)庫(kù)的參數(shù)，而其不影響倉(cāng)庫(kù)的主功能。但是，即使在負(fù)責(zé)執(zhí)行CEP查詢10的CEP引擎的物理查詢圖30真的依賴于所使用的表示模型時(shí)，許多其組件的許多方面仍獨(dú)立于所使用的表示模型。例如，過(guò)濾運(yùn)算子將始終對(duì)(一個(gè)或多個(gè))輸入數(shù)據(jù)流中包含的事件的數(shù)據(jù)部分應(yīng)用過(guò)濾謂詞(filter predicate)，無(wú)論與事件相關(guān)聯(lián)的時(shí)間性信息是如何被表示的。這允許了對(duì)于不同的表示模型實(shí)現(xiàn)若干個(gè)版本的系統(tǒng)構(gòu)建塊。另一個(gè)重要的發(fā)現(xiàn)是(邏輯)查詢圖的基本結(jié)構(gòu)對(duì)于時(shí)間性表示模型通常是沒(méi)有差別的。與獨(dú)立于向系統(tǒng)指定查詢的技術(shù)的數(shù)據(jù)庫(kù)系統(tǒng)(例如SQL語(yǔ)言和/或基于圖的圖形用戶界面(GUI))類似，CEP引擎通常創(chuàng)建表示基本查詢結(jié)構(gòu)的邏輯圖。此邏輯查詢計(jì)劃 20隨后作為優(yōu)化器200的查詢優(yōu)化的對(duì)象。然后，此邏輯查詢計(jì)劃20和/或優(yōu)化邏輯查詢計(jì)劃20’被轉(zhuǎn)化成物理查詢圖30，該物理查詢圖30被用于執(zhí)行CEP查詢10。本發(fā)明在若干個(gè)階段影響此過(guò)程首先，邏輯轉(zhuǎn)化/解析100獨(dú)立于數(shù)據(jù)流表示地發(fā)生。然后，表示模型優(yōu)選被用作轉(zhuǎn)化過(guò)程300的參數(shù)。從而，甚至轉(zhuǎn)化300對(duì)于每個(gè)方案也不會(huì)有太多差別，而是依據(jù)所需的方案選擇相應(yīng)的構(gòu)建塊，但盡可能地獨(dú)立。例如，SQL WHERE語(yǔ)句的過(guò)濾謂詞可獨(dú)立于時(shí)間性表示模型地被轉(zhuǎn)化成查詢謂詞操作。示例件實(shí)現(xiàn)下面，將說(shuō)明如圖2中所示的本發(fā)明的CEP引擎1的一些部分的基于Java的實(shí)現(xiàn)。 應(yīng)當(dāng)注意，Java只是多種適當(dāng)?shù)木幊陶Z(yǔ)言中的一種，本發(fā)明可用任何其他編程語(yǔ)言來(lái)實(shí)現(xiàn)。通用運(yùn)算子實(shí)現(xiàn)為了高效地執(zhí)行混合數(shù)據(jù)表示模型(即，支持各種不同的數(shù)據(jù)流表示模型)，示例性實(shí)現(xiàn)方式使用Java模板來(lái)使表示模型成為運(yùn)算子框架的參數(shù)。這反映在接口 GeneralPushOperator的定義中(參見圖幻，其是以下進(jìn)一步說(shuō)明的所有運(yùn)算子的基礎(chǔ)interface GeneralPushOperator<1, 0, IE extends GeneralElement<I>, OE extends GeneralElement<0>>I和0參數(shù)將輸入和輸出的類型參數(shù)化，而IE和OE將其表示參數(shù)化為事件流的元素。GeneralElement的子接口被用于指定不同的時(shí)間性表示模型，例如正-負(fù)(PnElement) 或時(shí)間區(qū)間方案(Element)。利用這些參數(shù)，接口對(duì)于某個(gè)數(shù)據(jù)流表示方案例如時(shí)間區(qū)間方案定義運(yùn)算子的屬性interface PushOperator<I, 0>extends GeneralPushOperator〈I，0，Element〈I>，Element〈0>>現(xiàn)在可對(duì)若干個(gè)數(shù)據(jù)流表示方案以通用方式實(shí)現(xiàn)具體運(yùn)算子。例如，可在以下類中定義過(guò)濾操作class GeneralPushFilter<T, TE extends GeneralElement<T>>extends AbstractUnarySingleGeneralPushOperator<T, T，TE，TE>這些通用實(shí)現(xiàn)隨后可被進(jìn)一步專門化到某個(gè)數(shù)據(jù)流表示方案，例如時(shí)間區(qū)間方案class PushFilter<T>extends GeneralPushFilter<T, Element<T>>implements PushOperator<T, T>上述技術(shù)的一個(gè)非常重要的優(yōu)點(diǎn)在于，專門的版本僅對(duì)于其構(gòu)造器參數(shù)略有變化，而它們中的大多數(shù)經(jīng)由其共同的超類被共享。圖2以簡(jiǎn)化的UML類圖的形式示出了對(duì)于時(shí)間區(qū)間和正-負(fù)方案的上述過(guò)濾實(shí)現(xiàn)的示例。注意，主要實(shí)現(xiàn)精力花在左側(cè)的類，而右側(cè)的專門化沒(méi)有花費(fèi)很多額外精力并且可以很容易地對(duì)額外的方案完成。獨(dú)立于方案的查詢表示CEP查詢10首先被轉(zhuǎn)化/解析100成邏輯查詢圖20，其完全獨(dú)立于之后用于執(zhí)行CEP查詢10的數(shù)據(jù)流表示模型。邏輯查詢圖20現(xiàn)在可經(jīng)歷查詢優(yōu)化200。另外，關(guān)于選擇哪個(gè)數(shù)據(jù)流表示模型來(lái)執(zhí)行的決定可基于邏輯查詢圖20和/或優(yōu)化邏輯查詢圖20’來(lái)做出。
圖3示出了將CEP查詢10變換成依賴于方案的物理運(yùn)算子圖30所需的大多數(shù)工作可獨(dú)立于所選擇的時(shí)間性表示方案發(fā)生。方案參數(shù)化的查詢轉(zhuǎn)化邏輯查詢圖20和/或優(yōu)化邏輯查詢圖20’隨后被轉(zhuǎn)化 300成用于執(zhí)行CEP查詢10的運(yùn)算子圖30。轉(zhuǎn)化300優(yōu)選取若干個(gè)參數(shù)(QueryTranslator queryTrans 1 ator, Node node,TranslationOptions transIationOptions)“node”表示要被查詢轉(zhuǎn)化器“queryTranslator”轉(zhuǎn)化300的邏輯查詢計(jì)劃20/ 優(yōu)化邏輯查詢計(jì)劃20’的節(jié)點(diǎn)，而轉(zhuǎn)化選項(xiàng)的選項(xiàng)“TranslationOptions”指定要用于轉(zhuǎn)化 300的方案，等等interface TranslationOptions{Approach getTargetApproach()；...相應(yīng)的轉(zhuǎn)化過(guò)程300現(xiàn)在利用給定的數(shù)據(jù)流表示方案產(chǎn)生轉(zhuǎn)化。為此，其可計(jì)算獨(dú)立于方案的共同參數(shù)并且可以只執(zhí)行一個(gè)或多個(gè)微小的依賴于方案的修改。例如，過(guò)濾器的查詢謂詞“theta”的計(jì)算可獨(dú)立于目標(biāo)方案完成(然而由于共同接口其仍被傳遞到轉(zhuǎn)化過(guò)程)
MetaDataPredicate<Record> theta =
queryTranslator .translate (Nodes. getNoc^node, PREDICATE), translationOptions);
switch (translationOptions.getTargetApproach()) {
case TIME_INTERVAL: return new PushFilter<Record>(…)；
case POSITIVE_NEGATIVE: return new
PnPushFilter<Record>(...); · _混合方案使用為了利用用于執(zhí)行CEP查詢10的多個(gè)方案支持運(yùn)算子圖，可以提供將一個(gè)或多個(gè)經(jīng)處理的數(shù)據(jù)流中包括的事件從一個(gè)表示模型轉(zhuǎn)換到另一個(gè)的運(yùn)算子。例如，PushToPnPush運(yùn)算子從時(shí)間區(qū)間轉(zhuǎn)換到正-負(fù)方案class PushToPnPush<T>extends AbstractUnarySingIeGeneraIPushOperator<T, Τ, Element<T>, PnElement<T>>方案選擇對(duì)要使用的數(shù)據(jù)流表示方案的選擇可服從用戶選擇。在一些實(shí)施例中， 基于諸如優(yōu)選低資源消耗或高活力之類的用戶指定，這可由優(yōu)化器200通過(guò)分析所涉及的運(yùn)算子并基于所支持的數(shù)據(jù)流表示方案訪問(wèn)關(guān)于其屬性的相應(yīng)預(yù)定評(píng)級(jí)來(lái)完成。
權(quán)利要求
1.一種復(fù)雜事件處CEP引擎(1)，用于處理數(shù)據(jù)流上的CEP查詢(10)，其中所述CEP引擎⑴包括a.解析器(100)，適用于將接收到的CEP查詢(10)解析成邏輯查詢圖Q0)；以及b.轉(zhuǎn)化器(300)，適用于根據(jù)多個(gè)數(shù)據(jù)流表示之一將所述邏輯查詢圖00)轉(zhuǎn)化成物理查詢計(jì)劃(30)；其中c.所述邏輯查詢圖00)獨(dú)立于所述多個(gè)數(shù)據(jù)流表示。
2.如權(quán)利要求1所述的CEP引擎，還包括優(yōu)化器000)，該優(yōu)化器(200)適用于優(yōu)化所述邏輯查詢圖00)以產(chǎn)生優(yōu)化邏輯查詢圖00’)，其中所述優(yōu)化邏輯查詢圖Q0’)獨(dú)立于所述多個(gè)數(shù)據(jù)流表示。
3.如權(quán)利要求1或2所述的CEP引擎，其中，所述物理查詢計(jì)劃(30)包括獨(dú)立于所述多個(gè)數(shù)據(jù)流表示的至少一個(gè)查詢構(gòu)建塊。
4.如在前權(quán)利要求2或3中任何一項(xiàng)所述的CEP引擎，其中，所述優(yōu)化器(200)適用于選擇所述多個(gè)數(shù)據(jù)流表示之一，并且所述轉(zhuǎn)化器(300)適用于根據(jù)所選擇的數(shù)據(jù)流表示將所述邏輯查詢圖00)轉(zhuǎn)化成物理查詢計(jì)劃(30)。
5.如在前權(quán)利要求所述的CEP引擎，還適用于在所述CEP查詢(10)的處理期間改變所選擇的數(shù)據(jù)流表示。
6.如在前權(quán)利要求中任何一項(xiàng)所述的CEP引擎，還包括至少一個(gè)運(yùn)算子轉(zhuǎn)化器，該至少一個(gè)運(yùn)算子轉(zhuǎn)化器適用于把所述CEP查詢(10)要處理的至少一個(gè)數(shù)據(jù)流的數(shù)據(jù)元素從第一數(shù)據(jù)流表示轉(zhuǎn)化到第二數(shù)據(jù)流表示。
7.一種用于處理數(shù)據(jù)流上的CEP查詢(10)的方法，其中所述方法包括以下步驟a.將接收到的CEP查詢(10)解析(100)成邏輯查詢圖Q0)；以及b.根據(jù)多個(gè)數(shù)據(jù)流表示之一將所述邏輯查詢圖00)轉(zhuǎn)化(300)成物理查詢計(jì)劃 (30)；其中c.所述邏輯查詢圖00)獨(dú)立于所述多個(gè)數(shù)據(jù)流表示。
8.如權(quán)利要求7所述的方法，還包括優(yōu)化(200)所述邏輯查詢圖00)以產(chǎn)生優(yōu)化邏輯查詢圖00’ )的步驟，其中所述優(yōu)化邏輯查詢圖00’ )獨(dú)立于所述多個(gè)數(shù)據(jù)流表示。
9.如權(quán)利要求7或8所述的方法，其中，所述物理查詢計(jì)劃(30)包括獨(dú)立于所述多個(gè)數(shù)據(jù)流表示的至少一個(gè)查詢構(gòu)建塊(310)。
10.如在前權(quán)利要求8或9中任何一項(xiàng)所述的方法，其中，所述優(yōu)化(200)包括選擇所述多個(gè)數(shù)據(jù)流表示之一，并且所述轉(zhuǎn)化(300)包括根據(jù)所選擇的數(shù)據(jù)流表示將所述邏輯查詢圖00)轉(zhuǎn)化成物理查詢計(jì)劃(30)。
11.如在前權(quán)利要求所述的方法，包括在所述CEP查詢(10)的處理期間改變所選擇的數(shù)據(jù)流表示的步驟。
12.如在前權(quán)利要求中任何一項(xiàng)所述的方法，還包括用至少一個(gè)運(yùn)算子把所述CEP查詢(10)要處理的至少一個(gè)數(shù)據(jù)流的數(shù)據(jù)元素從第一數(shù)據(jù)流表示轉(zhuǎn)化到第二數(shù)據(jù)流表示。
13.一種計(jì)算機(jī)程序，包括用于實(shí)現(xiàn)如在前權(quán)利要求7-12中任何一項(xiàng)所述的方法的指令。
全文摘要
本發(fā)明提供了CEP引擎和用于處CEP查詢的方法。本發(fā)明涉及一種復(fù)雜事件處理CEP引擎(1)，用于處理數(shù)據(jù)流上的CEP查詢(10)，其中CEP引擎(1)包括a.解析器(100)，適用于將接收到的CEP查詢(10)解析成邏輯查詢圖(20)；以及b.轉(zhuǎn)化器(300)，適用于根據(jù)多個(gè)數(shù)據(jù)流表示之一將邏輯查詢圖(20)轉(zhuǎn)化成物理查詢計(jì)劃(30)；其中c.邏輯查詢圖(20)獨(dú)立于所述多個(gè)數(shù)據(jù)流表示。
文檔編號(hào)G06F17/30GK102567541SQ20111046218
公開日2012年7月11日 申請(qǐng)日期2011年12月22日 優(yōu)先權(quán)日2010年12月22日
發(fā)明者克里斯多夫·漢斯, 尤爾根·克萊默, 杜比亞斯·里門施耐德, 邁克爾·卡馬特 申請(qǐng)人:軟件股份公司