Cep引擎和用于处理cep查询的方法
专利名称：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<I>, OE extends GeneralElement<0>>I和0参数将输入和输出的类型参数化，而IE和OE将其表示参数化为事件流的元素。GeneralElement的子接口被用于指定不同的时间性表示模型，例如正-负(PnElement) 或时间区间方案(Element)。利用这些参数，接口对于某个数据流表示方案例如时间区间方案定义运算子的属性interface PushOperator<I, 0>extends GeneralPushOperator〈I，0，Element〈I>，Element〈0>>现在可对若干个数据流表示方案以通用方式实现具体运算子。例如，可在以下类中定义过滤操作class GeneralPushFilter<T, TE extends GeneralElement<T>>extends AbstractUnarySingleGeneralPushOperator<T, T，TE，TE>这些通用实现随后可被进一步专门化到某个数据流表示方案，例如时间区间方案class PushFilter<T>extends GeneralPushFilter<T, Element<T>>implements PushOperator<T, T>上述技术的一个非常重要的优点在于，专门的版本仅对于其构造器参数略有变化，而它们中的大多数经由其共同的超类被共享。图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<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>(...); · _混合方案使用为了利用用于执行CEP查询10的多个方案支持运算子图，可以提供将一个或多个经处理的数据流中包括的事件从一个表示模型转换到另一个的运算子。例如，PushToPnPush运算子从时间区间转换到正-负方案class PushToPnPush<T>extends AbstractUnarySingIeGeneraIPushOperator<T, Τ, Element<T>, PnElement<T>>方案选择对要使用的数据流表示方案的选择可服从用户选择。在一些实施例中， 基于诸如优选低资源消耗或高活力之类的用户指定，这可由优化器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日
发明者克里斯多夫·汉斯, 尤尔根·克莱默, 杜比亚斯·里门施耐德, 迈克尔·卡马特 申请人:软件股份公司
技术领域：
本发明涉及复杂事件处理(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<I>, OE extends GeneralElement<0>>I和0参数将输入和输出的类型参数化，而IE和OE将其表示参数化为事件流的元素。GeneralElement的子接口被用于指定不同的时间性表示模型，例如正-负(PnElement) 或时间区间方案(Element)。利用这些参数，接口对于某个数据流表示方案例如时间区间方案定义运算子的属性interface PushOperator<I, 0>extends GeneralPushOperator〈I，0，Element〈I>，Element〈0>>现在可对若干个数据流表示方案以通用方式实现具体运算子。例如，可在以下类中定义过滤操作class GeneralPushFilter<T, TE extends GeneralElement<T>>extends AbstractUnarySingleGeneralPushOperator<T, T，TE，TE>这些通用实现随后可被进一步专门化到某个数据流表示方案，例如时间区间方案class PushFilter<T>extends GeneralPushFilter<T, Element<T>>implements PushOperator<T, T>上述技术的一个非常重要的优点在于，专门的版本仅对于其构造器参数略有变化，而它们中的大多数经由其共同的超类被共享。图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<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>(...); · _混合方案使用为了利用用于执行CEP查询10的多个方案支持运算子图，可以提供将一个或多个经处理的数据流中包括的事件从一个表示模型转换到另一个的运算子。例如，PushToPnPush运算子从时间区间转换到正-负方案class PushToPnPush<T>extends AbstractUnarySingIeGeneraIPushOperator<T, Τ, Element<T>, PnElement<T>>方案选择对要使用的数据流表示方案的选择可服从用户选择。在一些实施例中， 基于诸如优选低资源消耗或高活力之类的用户指定，这可由优化器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日
发明者克里斯多夫·汉斯, 尤尔根·克莱默, 杜比亚斯·里门施耐德, 迈克尔·卡马特 申请人:软件股份公司
最新回复(0)