To Share, or not to Share Online Event Trend Aggregation Over Bursty Event Streams
Olga Poppe, Chuan Lei, Lei Ma, Allison Rozet, Elke A. Rundensteiner
TTo Share, or not to Share Online Event Trend AggregationOver Bursty Event Streams
Technical ReportOlga Poppe, Chuan Lei, Lei Ma, Allison Rozet, and Elke A. Rundensteiner January, 2021 Microsoft Gray Systems Lab, One Microsoft Way, Redmond, WA 98052 IBM Research, Almaden, 650 Harry Rd, San Jose, CA 95120 Worcester Polytechnic Institute, Worcester, MA 01609 MathWorks, 1 Apple Hill Dr, Natick, MA [email protected], [email protected], [email protected],[email protected], [email protected]
Copyright © 2021 by authors. Permission to make digital or hard copies of all or part of this work for personal use is grantedwithout fee provided that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, topost on servers or to redistribute to lists, requires prior specific permission. a r X i v : . [ c s . D B ] M a r Contents
AMLET
Approach in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
AMLET
Execution Techniques 7
Abstract
Complex event processing (CEP) systems continuously evaluate large workloads of patternqueries under tight time constraints. Event trend aggregation queries with Kleene patterns arecommonly used to retrieve summarized insights about the recent trends in event streams. State-of-art methods are limited either due to repetitive computations or unnecessary trend construc-tion. Existing shared approaches are guided by statically selected and hence rigid sharing plansthat are often sub-optimal under stream fluctuations. In this work, we propose a novel frameworkH
AMLET that is the first to overcome these limitations. H
AMLET introduces two key innovations.First, H
AMLET adaptively decides whether to share or not to share computations dependingon the current stream properties at run time to harvest the maximum sharing benefit. Second,H
AMLET is equipped with a highly efficient shared trend aggregation strategy that avoids trendconstruction. Our experimental study on both real and synthetic data sets demonstrates thatH
AMLET consistently reduces query latency by up to five orders of magnitude compared to thestate-of-the-art approaches.
Sensor networks, web applications, and smart devices produce high velocity event streams. Indus-tries use Complex Event Processing (CEP) technologies to extract insights from these streams usingKleene queries [9, 15, 45], i.e., queries with Kleene plus “+” operator that matches event sequencesof any length, a.k.a. event trends [32]. Since these trends can be arbitrarily long and complex andthere also tends to be a large number of them, they are typically aggregated to derive summarizedinsights [36]. CEP systems must thus process large workloads of these event trend aggregationqueries over high-velocity streams in near real-time.
Example 1.
Complex event trend aggregation queries are used in Uber and DoorDash for price computation,forecasting, scheduling, and routing [30]. With hundreds of users per district, thousands of transactions, andmillions of districts nationwide, real-time event analytics has become a challenging task.In Figure 1, the query workload computes various trip statistics such as the number, total duration, andaverage speed of trips per district. Each event in the stream is of a particular event type, e.g., Request,Pickup, Dropoff. Each event is associated with attributes such as a time stamp, district, speed, driver, andrider identifiers.Query q focuses on trips in which the driver drove to a pickup location but did not pickup a riderwithin 30 minutes since the request. Each trip matched by q corresponds to a sequence of one ride Requestevent, followed by one or more Travel events (expressed by the Kleene plus operator “+”), and not followedby a Pickup event. All events in a trip must have the same driver and rider identifiers as required by thepredicate [driver, rider]. Query q targets Pool riders who were dropped off at their destination. Query q tracks riders who cancel their accepted requests while the drivers were stuck in slow-moving traffic. All threequeries contain the expensive Kleene sub-pattern T + that matches arbitrarily long event trends. Thus, onemay conclude that sharing T + always leads to computational savings. However, a closer look reveals thatthe actual sharing benefit depends on the current stream characteristics. Indeed, trips are affected by manyfactors, from time and location to specific incidents, as the event stream fluctuates. Figure 1:
Event trend aggregation queries
Challenges . To enable shared execution of trend aggregation queries, we must tackle the fol-lowing open challenges.
Exponential complexity versus real-time response . Construction of event trends matched by a Kleenequery has exponential time complexity in the number of matched events [32, 45]. To achievereal-time responsiveness, shared execution of trend aggregation queries should thus adopt onlinestrategies that compute trend aggregates on-the-fly while avoiding this expensive trend construc-tion [33, 34]. However, shared execution applied to such online trend aggregation incurs additionalchallenges not encountered by the shared construction of traditional queries [22]. In particular,we must avoid constructing these trends, while capturing critical connections among shared sub-trends compactly to validate predicates of each query. For example, query q in Figure 1 may matchall events of type Travel , while queries q and q may only match some of them due to their predi-cates. Consequently, different trends will be matched by these queries. On first sight it appears thatresult validation requires the construction of all trends per query, which would defeat the goal ofonline aggregation. To address this dilemma, we must develop a correct yet efficient shared onlinetrend aggregation strategy. Benefit versus overhead of sharing . One may assume that the more sub-patterns are shared, thegreater the performance improvement will be. However, this assumption does not always hold dueto the overhead caused by maintaining intermediate aggregates of sub-patterns to ensure correct-ness of results. The computational overhead incurred by shared query execution does not alwaysjustify the savings achievable compared to baseline non-shared execution. For example, sharingquery q with the other two queries in Figure 1 will not be beneficial if there are only few Pool re-quests and the travel speed is above 10 mph. Hence, we need to devise a lightweight benefit modelthat accurately estimates the benefit of shared execution of multiple trend aggregation at runtime.
Bursty event streams versus light-weight sharing decisions . The actual sharing benefit can vary overtime due to the nature of bursty event streams. Even with an efficient shared execution strategy andan accurate sharing benefit model, a static sharing solution may not always lead to computationalsavings. Worse yet, in some cases, a static sharing decision may do more harm than good. Due todifferent predicates and windows of queries in Figure 1, one may decide at compile time that thesequeries should not be shared. However, a large burst of
Pool requests may arrive and the trafficmay be moving slowly (i.e., speed below 10 mph) in rush hour, making sharing of these queries beneficial. For this, a dynamic sharing optimizer, capable of adapting to changing arrival rates,data distribution, and other cost factors, must be designed. Its runtime sharing decisions must belight-weight to ensure real-time responsiveness.
Approach Kleene Online Sharingclosure aggregation decisions
MCEP [22] (cid:88) − staticS HARON [35] − (cid:88) staticG RETA [33] (cid:88) (cid:88) not sharedH
AMLET (ours) (cid:88) (cid:88) dynamic
Table 1:
Approaches to event trend aggregation
State-of-the-Art Approaches . While there are approaches to shared execution of multiple Kleenequeries [19, 22], they first construct all trends and then aggregate them. Even if trend constructionis shared, its exponential complexity is not avoided [32, 45]. Thus, even the most recent approach,MCEP [22] is 76–fold slower than H
AMLET as the number of events scales to 10K events per win-dow (Figure 9(a)). Recent work on event trend processing [33, 34, 35] addresses this performancebottleneck by pushing the aggregation computation into the pattern matching process. Such on-line methods manage to skip the trend construction step and thus reduce time complexity of trendaggregation from exponential to quadratic in the number of matched events. Among these onlineapproaches, G
RETA [33] is the only approach that supports Kleene closure. Unfortunately, G
RETA neglects sharing opportunities in the workload and instead processes each query independentlyfrom others. On the other hand, while S
HARON [35] considers sharing among queries, it does notsupport Kleene closure. Thus, it is restricted to fixed-length event sequences. Further, its shared ex-ecution strategy is static and thus misses runtime sharing opportunities. Our experiments confirmthat these existing approaches fail to cope with high velocity streams with 100K events per window(Figures 11(a) and 11(b)). Table 1 summarizes the approaches mentioned above with respect to thechallenges of shared execution of multiple trend aggregation queries.
Proposed Solution . To address these challenges, we now propose the H
AMLET approach thatsupports online aggregation over Kleene closure while dynamically deciding which subset of sub-patterns should be shared by which trend aggregation queries and for how long depending onthe current characteristics of the event stream. The H
AMLET optimizer leverages these streamcharacteristics to estimate the runtime sharing benefit. Based on the estimated benefit, it instructsthe H
AMLET executor to switch between shared and non-shared execution strategies. Such fine-grained decisions allow H
AMLET to maximize the sharing benefit at runtime. The H
AMLET runtimeexecutor propagates shared trend aggregates from previously matched events to newly matchedevents in an online fashion, i.e., without constructing event trends.
Contributions . H
AMLET offers the following key innovations.1. We present a novel framework H
AMLET for optimizing a workload of queries computingaggregation over Kleene pattern matches, called event trends. To the best of our knowledge, H AM - LET is the first to seamlessly integrate the power of online event trend aggregation and adaptiveexecution sharing among queries.2. We introduce the H
AMLET graph to compactly capture trends matched by queries in the workload. We partition the graph into smaller graphlets by event types and time. H
AMLET thenselectively shares trend aggregation in some graphlets among multiple queries.3. We design a lightweight sharing benefit model to quantify the trade-off between the benefit ofsharing and the overhead of maintaining the intermediate trend aggregates per query at runtime.4. Based on the benefit of sharing sub-patterns, we propose an adaptive sharing optimizer. Itselects a subset of queries among which it is beneficial to share this sub-pattern and determines thetime interval during which this sharing remains beneficial.5. Our experiments on several real world stream data sets demonstrate that H
AMLET achievesup to five orders of magnitude performance improvement over state-of-the-art approaches.
Outline.
Section 2 describes preliminaries. Sections 3 and 4 describe the core H
AMLET tech-niques: online trend aggregation and dynamic sharing optimizer. We present experiments, reviewrelated work and conclude the paper in Sections 6, 7, and 8, respectively.
Time is represented by a linearly ordered set of time points ( T , ≤ ) , where T ⊆ Q + are the non-negative rational numbers. An event e is a data tuple describing an incident of interest to theapplication. An event e has a time stamp e.time ∈ T assigned by the event source. An event e belongs to a particular event type E , denoted e.type=E and described by a schema that specifies theset of event attributes and the domains of their values. A specific attribute attr of E is referred toas E. attr . Table 2 summarizes the notation.Events are sent by event producers (e.g., vehicles and mobile devices) to an event stream I . Weassume that events arrive in order by their time stamps. Existing approaches to handle out-of-orderevents can be applied [11, 26, 27, 41].An event consumer (e.g., Uber stream analytics) continuously monitors the stream with eventqueries . We adopt the commonly used query language and semantics from SASE [9, 44, 45]. Thequery workload in Figure 1 is expressed in this language. We assume that the workload is static.Adding or removing a query from a workload requires migration of the execution plan to a newworkload which can be handled by existing approaches [24, 48]. Definition 1. ( Kleene Pattern ) A pattern P can be in the form of E , P + , ( NOT P ), SEQ ( P , P ) , ( P ∨ P ) , or ( P ∧ P ) , where E is an event type, P , P are patterns, + is a Kleene plus, NOT is a negation,
SEQ is an event sequence, ∨ is a disjunction, and ∧ is a conjunction. P and P are called sub-patterns of P .If a pattern P contains a Kleene plus operator, P is called a Kleene pattern. Definition 2. ( Event Trend Aggregation Query ) An event trend aggregation query q consists of fiveclauses: • Aggregation result specification (
RETURN clause), • Kleene pattern P ( PATTERN clause) as per Definition 1, • Predicates θ (optional WHERE clause),
Notation Description e. time Time stamp of event ee. type
Type of event eE. attr
Attribute attr of event type E start ( q ) Start types of the pattern of query q end ( q ) End types of the pattern of query q pt ( E, q ) Predecessor types of event type E w.r.t query q pe ( e, q ) Predecessor events of event e w.r.t query qn Number of events per window g Number of events per graphlet b Number of events per burst k Number of queries in the workload Qk s Number of queries that share the graphlet G E with other queries k n Number of queries that do not share the graphlet G E with other queries p Number of predecessor types per type per query s Number of snapshots s c Number of snapshots created from one burst of events s p Number of snapshots propagated in one shared graphlet
Table 2:
Table of notations • Grouping G (optional GROUPBY clause), and • Window w ( WITHIN/SLIDE clause).
Definition 3. ( Event Trend ) Let q be a query per Definition 2. An event trend tr = ( e , . . . , e k ) corre-sponds to a sequence of events that conform to the pattern P of q . All events in a trend tr satisfy predicates θ , have the same values of grouping attributes G , and are within one window w of q . Aggregation of Event Trends . Within each window specified by the query q , event trendsare grouped by the values of grouping attributes G . Aggregates are then computed per group.H AMLET focuses on distributive (
COUNT , MIN , MAX , SUM ) and algebraic aggregation functions (
AVG )since they can be computed incrementally [16]. Let E be an event type, attr be an attribute of E ,and e be an event of type E . While COUNT ( ∗ ) returns the number of all trends per group, COUNT ( E ) computes the number of all events e in all trends per group. SUM ( E. attr ) ( AVG ( E. attr ) ) calculatesthe summation (average) of the value of attr of all events e in all trends per group. MIN ( E. attr ) ( MAX ( E. attr ) ) computes the minimal (maximal) value of attr for all events e in all trends per group. AMLET
Approach in a Nutshell
Given a workload of event trend aggregation queries Q and a high-rate event stream I , the Multi-query Event Trend Aggregation Problem is to evaluate the workload Q over the stream I such thatthe average query latency of all queries in Q is minimal. The latency of a query q ∈ Q is measuredas the difference between the time point of the aggregation result output by the query q and thearrival time of the last event that contributed to this result.We design the H AMLET framework in Figure 2 to tackle this problem. To reveal all sharingopportunities in the workload at compile time, the H AMLET
Optimizer identifies sharable queries
Figure 2: H AMLET
Framework and translates them into a Finite State Automaton-based representation, called the merged querytemplate (Section 3.1). Based on this template, the optimizer reveals which sub-patterns couldpotentially be shared by which queries. At runtime, the optimizer estimates the sharing benefit de-pending on the current stream characteristics to make fine-grained sharing decisions. Each sharingdecision determines which queries share the processing of which Kleene sub-patterns and for howlong (Section 4). These decisions along with the template are encoded into the runtime configura-tion to guide the executor. H AMLET
Executor partitions the stream by the values of grouping attributes. To enable sharedexecution despite different windows of sharable queries, the executor further partitions the streaminto panes that are sharable across overlapping windows [10, 17, 24, 25]. Based on the mergedquery template for each set of sharable queries, the executor compactly encodes matched trendswithin a pane into the H
AMLET graph. More precisely, matched events are modeled as nodes, whileevent adjacency relations in a trend are edges of the graph. Based on this graph, we incrementallycompute trend aggregates by propagating intermediate aggregates along the edges from previouslymatched events to new events – without constructing the actual trends. This reduces the timecomplexity of trend aggregation from exponential to quadratic in the number of matched eventscompared to two-step approaches [19, 22, 32, 45].The H
AMLET graph is partitioned into sub-graphs, called graphlets, by event type and timestamps to maximally expose runtime opportunities to share these graphlets among queries. Sincethe value of aggregates may be differ for distinct queries, we capture these aggregate values perquery as ”snapshots” and share the propagation of snapshots through shared graphlets (Section 3.3).Lastly, the executor implements the sharing decisions imposed by the optimizer. This mayinvolve dynamically splitting a shared graphlet into several non-shared graphlets or, vice-versa,merging several non-shared graphlets into one shared graphlet (Section 4.2).
AMLET
Execution Techniques
Assumptions . To keep the discussion focused on the core concepts, we make simplifying assump-tions in Sections 3 and 4. We drop them to extend H
AMLET to the broad class of trend aggregationqueries (Definition 2) in Section 5. These assumptions include: (1) queries compute the numberof trends per window
COUNT ( ∗ ) ; (2) query patterns do not contain disjunction, conjunction nornegation; and (3) Kleene plus operator is applied to an event type and appears once per query.In Section 3.1, we describe the workload and stream partitioning. We introduce strategies for processing queries without sharing in Section 3.2 versus with shared online trend aggregation inSection 3.3. In Section 4, we present the runtime optimizer that makes these sharing decisions. Given that the workload may contain queries with different Kleene patterns, aggregation functions,windows, and groupby clauses, H
AMLET takes the following pre-processing steps: (1) it breaks theworkload into sets of sharable queries at compile time; (2) it then constructs the H
AMLET querytemplate for each sharable query set; and (3) it partitions the stream by window and groupbyclauses for each query template at runtime.
Definition 4. ( Shareable Kleene Sub-pattern ) Let Q be a workload and E be an event type. Assume thata Kleene sub-pattern E + appears in queries Q E ⊆ Q and | Q E | > . We say that E + is shareable by queries Q E . However, sharable Kleene sub-patterns cannot always be shared due to other query clauses. Forexample, queries having
COUNT ( ∗ ) , MIN ( E. attr ) or MAX ( E. attr ) can only be shared with queries thatcompute these same aggregates. In contrast, since AVG ( E. attr ) is computed as SUM ( E. attr ) dividedby COUNT ( E ) , queries computing AVG ( E. attr ) can be shared with queries that calculate SUM ( E. attr ) or COUNT ( E ) . We therefore define sharable queries below. Definition 5. ( Sharable Queries ) Two queries are sharable if their patterns contain at least one sharableKleene sub-pattern, their aggregation functions can be shared, their windows overlap, and their groupingattributes are the same.
To facilitate the shared runtime execution of each set of sharable queries, each pattern is con-verted into its Finite State Automaton-based representation [9, 14, 44, 45], called query template .We adopt the state-of-the-art algorithm [33] to convert each pattern in in the workload Q into itstemplate.Figure 3(a) depicts the template of query q with pattern SEQ ( A, B +) . States, shown as rect-angles, represent event types in the pattern. If a transition connects a type E with a type E in atemplate of a query q , then events of type E precede events of type E in a trend matched by q . E is called a predecessor type of E , denoted E ∈ pt ( E , q ) . A state without ingoing edges is a starttype , and a state shown as a double rectangle is an end type in a pattern. Example 2.
In Figure 3(a), events of type B can be preceded by events of types A and B in a trend matched by q , i.e., pt ( B, q ) = { A, B } . Events of type A are not preceded by any events, pt ( A, q ) = ∅ . Events of type A start trends and events of type B end trends matched by q , i.e., start ( q ) = { A } and end ( q ) = { B } . Our H
AMLET system processes the entire workload Q instead of each query in isolation. Toexpose all sharing opportunities in Q , we convert the entire workload Q into one H AMLET querytemplate . It is constructed analogously to a query template with two additional rules. First, eachevent type is represented in the merged template only once. Second, each transition is labeled bythe set of queries for which this transition holds. (a) Query q (b) Workload Q = { q , q } Figure 3:
Tem-plate (a) Non-shared G
RETA graph (b) Shared H
AMLET graph
Figure 4:
Non-shared vs shared execution
Example 3.
Figure 3(b) depicts the template for the workload Q = { q , q } where query q has pattern SEQ ( A, B +) and query q has pattern SEQ ( C, B +) . The transition from B to itself is labeled by two queries q and q . This transition corresponds to the shareable Kleene sub-pattern B + in these queries (highlightedin gray). The event stream is first partitioned by the grouping attributes. To enable shared executiondespite different windows of sharable queries, H
AMLET further partitions the stream into panes that are sharable across overlapping windows [10, 17, 24, 25]. The size of a pane is the greatestcommon divisor (gcd) of all window sizes and window slides. For example, for two windows ( WITHIN min SLIDE min ) and ( WITHIN min SLIDE min ) , the gcd is 5 minutes. In this example,a pane contains all events per 5 minutes interval. For each set of sharable queries, we apply theH AMLET optimizer and executor within each pane.
For the non-shared execution, we describe below how the H
AMLET executor leverages state-of-the-art online trend aggregation approach [33] to compute trend aggregates for each query indepen-dently from all other queries . Given a query q , it encodes all trends matched by q in a query graph.The nodes in the graph are events matched by q . Two events e (cid:48) and e are connected by an edge if e (cid:48) and e are adjacent in a trend matched by q . The event e (cid:48) is called a predecessor event of e . Atruntime, trend aggregates are propagated along the edges. In this way, we aggregate trends online,i.e., without actually constructing them.Assume a query q computes the number of trends COUNT ( ∗ ) . When an event e is matched by q , e is inserted in the graph for q and the intermediate trend count of e (denoted count ( e, q ) ) iscomputed. count ( e, q ) corresponds to the number of trends that are matched by q and end at e . If e is of start type of q , e starts a new trend. Thus, count ( e, q ) is incremented by one (Equation 1). Inaddition, e extends all trends that were previously matched by q . Thus, count ( e, q ) is incrementedby the sum of the intermediate trend counts of the predecessor events of e that were matched by q (denoted pe ( e, q ) ) (Equation 2). The final trend count of q is the sum of intermediate trend counts (a) Snapshot x at graphlet level (b) Snapshots x and y at graphlet level (c) Snapshot z at event level Figure 5:
Snapshots at graphlet and event levels
Trend count b xb x + count ( b , Q ) =2 xb x + count ( b , Q ) + count ( b , Q ) = 4 xb x + count ( b , Q ) + count ( b , Q )+ count ( b , Q ) = 8 x Table 3:
Shared propagationof x within B Query q Query q x sum ( A , q ) =2 sum ( C , q ) =1 y value ( x, q )+ sum ( B , q )+ sum ( A , q ) =2+15 ∗ value ( x, q )+ sum ( B , q )+ sum ( C , q ) =1+15 ∗ Table 4:
Values of snapshots x and y per query Query q Query q z value ( x, q )+ count ( b , q )+ count ( b , q ) =8 value ( x, q )+ count ( b , q ) =2 y value ( x, q )+ sum ( B , q )+ sum ( A , q ) =34 value ( x, q )+ sum ( B , q )+ sum ( C , q ) =15 Table 5:
Values of snapshots z and y per query of all matched events of end type of q (Equation 3). start ( e, q ) = , if e . type ∈ start ( q )0 , otherwise (1) count ( e, q ) = start ( e, q ) + (cid:88) e (cid:48) ∈ pe ( e,q ) count ( e (cid:48) , q ) (2) fcount ( q ) = (cid:88) e . type ∈ end ( q ) count ( e, q ) (3) Example 4.
Continuing Example 3, a graph is maintained per each query in the workload Q = { q , q } inFigure 4(a). For readability, we sort all events by their types and timestamps. Events of types A , B , and C are displayed as gray, white, and striped circles, respectively. We highlight the predecessor events of event b by edges. All other edges are omitted for compactness. When b arrives, two trends ( a , b ) and ( a , b ) arematched by q . Thus, count ( b , q ) = count ( a , q ) + count ( a , q ) = 2 . However, only one trend ( c , b ) is matched by q . Thus, count ( b , q ) = count ( c , q ) = 1 . Complexity Analysis . Figure 4(a) illustrates that each event of type B is stored and processedonce for each query in the workload Q , introducing significant re-computation and replicationoverhead. Let k denote the number of queries in the workload Q and n the number of events. Eachquery q stores each matched event e and computes the intermediate count of e per Equation 2. Allpredecessor events of e must be accessed, with e having at most n predecessor events. Thus, thetime complexity of non-shared online trend aggregation is computed as follows: NonShared ( Q ) = k × n (4) Events that are matched by k queries are replicated k times (Figure 4(a)). Each event storesits intermediate trend count. In addition, one final result is stored per query. Thus, the spacecomplexity is O ( k × n + k ) = O ( k × n ) . In Equation 4, the overhead of processing each event once per query in the workload Q is repre-sented by the multiplicative factor k . Since the number of queries in a production workload mayreach hundreds to thousands [37, 43], this re-computation overhead can be significant. Thus, wedesign an efficient shared online trend aggregation strategy that encapsulates bursts of events ofthe same type in a graphlet such that the propagation of trend aggregates within these graphletscan be shared among several queries. Definition 6. ( Graphlet ) Let q ∈ Q be a query and T be a set of event types that appear in the pattern of q .A graphlet G E is a graph of events of type E , if no events of type E (cid:48) ∈ T, E (cid:48) (cid:54) = E, are matched by q duringthe time interval ( e f .time, e l .time ) , where e f .time and e l .time are the timestamps of the first and the lastevents in G E , respectively. If new events can be added to a graphlet G E without violating the constraintsabove, the graphlet G E is called active. Otherwise, G E is called inactive. Definition 7. ( Shared Graphlet, H AMLET
Graph ) Let E + be a Kleene sub-pattern that is shareable byqueries Q E ⊆ Q (Definition 4). We call a graphlet G E of events of type E a shared graphlet. The set of allinterconnected shared and non-shared graphlets for a workload Q is called a H AMLET graph.
Example 5.
In Figure 4(b), matched events are partitioned into six graphlets A – B by their types andtimestamps. For example, graphlets B and B are of type B . They are shared by queries q and q . Incontrast to the non-shared strategy in Figure 4(a), each event is stored and processed once for the entireworkload Q . Events in A – C are predecessors of events in B , while events in A – C are predecessors ofevents in B . For readability, only the predecessor events of b are highlighted by edges in Figure 4(b). Allother edges are omitted. a and a are predecessors of b only for q , while c is a predecessor of b only for q . Example 5 illustrates the following two challenges of online shared event trend aggregation.
Challenge 1 . Given that event b has different predecessors for queries q and q , the computa-tion of the intermediate trend count of b (and all other events in graphlets B and B ) cannot bedirectly shared by queries q and q . Challenge 2 . If queries q or q have predicates, then not all previously matched events arequalified to contribute to the trend count of a new event. Assume that the edge between events b and b holds for q but not for q due to predicates, and all other edges hold for both queries. Then count ( b , q ) contributes to count ( b , q ) , but count ( b , q ) does not contribute to count ( b , q ) .We tackle these challenges by introducing snapshots . Intuitively, a snapshot is a variable thatits value corresponds to an intermediate trend aggregate per query. In Figure 4(b), the propagationof a snapshot x within graphlet B is shared by queries q and q . We store the values of x perquery (e.g., x = 2 for q and x = 1 for q ). ( Snapshot at Graphlet Level ) Let E (cid:48) and E be distinct event types. Let E + be a Kleenesub-pattern that is shared by queries Q E ⊆ Q , q ∈ Q E . Let E (cid:48) ∈ pt ( E, q ) and G E (cid:48) and G E be graphlets ofevents of types E (cid:48) and E , respectively. Assume for any events e (cid:48) ∈ G E (cid:48) , e ∈ G E , e (cid:48) .time < e.time holds.A snapshot x of the graphlet G E (cid:48) is a variable whose value is computed per query q and corresponds to theintermediate trend count of the query q at the end of the graphlet G E (cid:48) . value ( x, q ) = sum ( G E (cid:48) , q ) = (cid:88) e (cid:48) ∈ G E (cid:48) count ( e (cid:48) , q ) (5) The propagation of snapshot x through the graphlet G E follows Equation 2 and is shared by queries Q E . Example 6.
When graphlet B starts, a snapshot x is created. x captures the intermediate trend countof query q ( q ) based on the intermediate trend counts of all events in graphlet A ( C ). x is propagatedthrough graphlet B as shown in Figure 5(a) and Table 3.Analogously, when graphlet B starts, a new snapshot y is created. The value of y is computed forqueries q ( q ) based on the value of x for q ( q ) and graphlets B and A ( C ). Figure 5(b) illustrates theconnections between snapshots and graphlets. The edges from graphlets A and A ( C and C ) hold onlyfor query q ( q ). Other edges hold for both queries q and q .Table 4 captures the values of snapshots x and y per query. For compactness, sum ( A , q ) denotes thesum of intermediate trend counts of all events in A that are matched by q (Equation 5). When the snapshot y is created, the value of x per query is plugged in to obtain the value of y per query. The propagation of y through B is shared by q and q . In this way, only one snapshot is propagated at a time to keep the overheadof snapshot maintenance low. To enable shared trend aggregation despite expressive predicates, we now introduce snapshotsat the event level.
Definition 9. ( Snapshot at Event Level ) Let G E be a graphlet that is shared by queries Q E ⊆ Q . Let q , q ∈ Q E and e , e ∈ G E be events such that the edge ( e , e ) holds for q but does not hold for q due topredicates. A snapshot z is the intermediate trend count of e that is computed for q and q per Equation 2and propagated through the graphlet G E for all queries in Q E . Example 7.
In Figure 5(c), assume that the edge between events b and b holds for query q but notfor query q due to predicates. All other edges hold for both queries. Then, count ( b , q ) contributes to count ( b , q ) , but count ( b , q ) does not contribute to count ( b , q ) . To enable shared processing of graphlet B despite predicates, we introduce a new snapshot z as the intermediate trend count of b and propagateboth snapshots x and z within graphlet B . Table 5 summarizes the values of z and y per query. Shared Online Trend Aggregation Algorithm computes the number of trends per query q ∈ Q in the stream I . For simplicity, we assume that the stream I contains events within one pane. Foreach event e ∈ I of type E , Algorithm 1 constructs the H AMLET graph and computes the trendcount as follows. H AMLET graph construction (Lines 4–14). When an event e of type E is matched by a query q ∈ Q , e is inserted into a graphlet G E that stores events of type E (Line 14). if there is no active graphlet G E of events of type E , we create a new graphlet G E , mark it as active and store it in theH AMLET graph G (Lines 7–8). If the graphlet G E is shared by queries Q E ⊆ Q , then we create asnapshot x at graphlet level (Line 9). x captures the values of intermediate trend counts per queryper Equation 5 at the end of graphlet G E (cid:48) that stores events of type E (cid:48) , E (cid:48) ∈ pt ( E, q ) . We save thevalue of x per query in the table of snapshots S (Lines 10–13). Also, for each query q ∈ Q withevent types T , we mark all graphlets G E (cid:48) of events of type E (cid:48) ∈ T, E (cid:48) (cid:54) = E, as inactive (Lines 4–6). Trend count computation (Lines 16–24). If G E is shared by queries Q E ⊆ Q and the set of pre-decessor events of e is identical for all queries q ∈ Q E , then we compute count ( e, q ) per Equation 2(Lines 16–18). If G E is shared but the sets of predecessor events of e differ among the differentqueries in Q E due to predicates, then we create a snapshot y as the intermediate trend count of e (Line 19). We compute the value of y for each query q ∈ Q E per Equation 2 and save it in the tableof snapshots S (Line 20). If G E is not shared, the algorithm defaults to the non-shared trend countpropagation per Equation 2 (Line 21). If E is an end type for a query q ∈ Q , we increment the finaltrend count of q in the table of results R by the intermediate trend count of e for q per Equation 3(Lines 22–23). Lastly, we return the table of results R (Line 24). Theorem 3.1.
Algorithm 1 returns correct event trend count for each query in the workload Q .Proof Sketch. Correctness of the graph construction for a single query and the non-shared trendcount propagation through the graph as defined in Equation 2 are proven in [33]. Correctness ofthe snapshot computation per query as defined in Equation 5 follows from Equation 2. Algorithm 1propagates snapshots through the H
AMLET graph analogously to trend count propagation throughthe G
RETA graph defined in [33].
Data Structures . Algorithm 1 utilizes the following physical data structures.(1) H AMLET graph G is a set of all graphlets. Each graphlet has two metadata flags active and shared (Definitions 6 and 7).(2) A hash table of snapshot coefficients per event e . The intermediate trend count of e maybe an expression composed of several snapshots. In Figure 5(c), count ( b , Q ) = 4 x + z . Suchcomposed expressions are stored in a hash table per event that maps a snapshot to its coefficient.In this example, x (cid:55)→ and z (cid:55)→ for b .(3) A hash table of snapshots S is a mapping from a snapshot x and a query q to the value of x for q (Tables 4 and 5).(4) A hash table of trend count results R is a mapping from a query q to its corresponding trendcount. Complexity Analysis . We use the notations in Table 2 and Algorithm 1. For each event e that is matched by a query q ∈ Q , Algorithm 1 computes the intermediate trend count of e in anonline fashion. This requires access to all predecessor events of e . In the worst case, n previouslymatched events are the predecessor events of e . Since the intermediate trend count of e can be anexpression that is composed of s snapshots, the intermediate trend count of e is stored in the hashtable that maps snapshots to their coefficients. Thus, the time complexity of intermediate trendcount computation is O ( n × s ) . In addition, the final trend count is updated per query q if E is H AMLET shared online trend aggregation
Input:
Query workload Q , event stream I , H AMLET graph G , hash table of snapshots S Output:
Hash table of results R G ← ∅ , S, R ← empty hash tables for each event e ∈ I with e.type = E do // H AMLET graph construction for each q ∈ Q with event types T do for each E (cid:48) ∈ T, E (cid:48) (cid:54) = E do G E (cid:48) ← getGraphlet ( G, E (cid:48) ) , G E (cid:48) . active ← false if not G E . active then G E ← createGraphlet () , G E . active ← true , G ← G ∪ G E if G E . shared by Q E ⊆ Q then x ← createSnapshot () for each q ∈ Q E do for each E (cid:48) ∈ pt ( E, q ) , E (cid:48) (cid:54) = E do G E (cid:48) ← getGraphlet ( G, E (cid:48) ) S ( x, q ) ← S ( x, q ) + sum ( G E (cid:48) , q ) // Eq. 5 insert e into G E // Trend count computation if G E . shared by Q E ⊆ Q then if ∀ q ∈ Q E pe ( e, q ) are identical then count ( e, Q E ) ← count ( e, q ) // Eq. 2 else y ← createSnapshot () , count ( e, Q E ) = y for each q ∈ Q E do S ( y, q ) ← count ( e, q ) // Eq. 2 else count ( e, q ) // Eq. 2 for each q ∈ Q do if E ∈ end ( q ) then R ( q ) ← R ( q ) + count ( e, q ) // Eq. 3 return R an end type of q in O ( k × s ) time. In summary, the time complexity of trend count computation is O ( n × ( n × s + k × s )) = O ( n × s ) since n ≥ k .In addition, Algorithm 1 maintains snapshots to enable shared trend count computation. Tocompute the values of s snapshots for each query q in the workload of k queries, the algorithmaccesses g events in t graphlets G E (cid:48) of events of type E (cid:48) ∈ T, E (cid:48) (cid:54) = E . Thus, the time complexity ofsnapshot maintenance is O ( s × k × g × t ) . In summary, time complexity of Algorithm 1 is computedas follows: Shared ( Q ) = n × s + s × k × g × t (6)Algorithm 1 stores each matched event in the H AMLET graph once for the entire workload.Each shared event stores a hash table of snapshot coefficients. Each non-shared event stores itsintermediate trend count. In addition, the algorithm stores snapshot values per query. Lastly, thealgorithm stores one final result per query. Thus, the space complexity is O ( n + n × s + s × k + k ) = O ( n × s + s × k ) . We first model the runtime benefit of sharing trend aggregation (Section 4.1). Based on this benefitmodel, our H
AMLET optimizer makes runtime sharing decisions for a given set of queries (Sec-tion 4.2). Lastly, we describe how to choose a set of queries that share a Kleene sub-pattern (Sec-tion 4.3).
On the up side, shared trend aggregation avoids the re-computation overhead for each query in theworkload. On the down side, it introduces overhead to maintain snapshots. Next, we quantify thetrade-off between shared versus non-shared execution.Equations 4 and 6 determine the cost of non-shared and shared strategies of all events within thewindow for the entire workload Q based on stream statistics. In contrast to these coarse-grainedstatic decisions, the H AMLET optimizer makes fine-grained runtime decisions for each burst ofevents for a sub-set of queries Q E ⊆ Q . Intuitively, a burst is a set of consecutive events of type E ,the processing of which can be shared by queries Q E that contain a E + Kleene sub-pattern. TheH
AMLET optimizer decides at runtime if sharing a burst is beneficial. In this way, beneficial sharingopportunities are harvested for each burst at runtime.
Definition 10. ( Burst of Events ) Let E + be a sub-pattern that is sharable by queries Q E . Let T be the setof event types that appear in the patterns of queries Q E , E ∈ T . A set of events of type E within a paneis called a burst B E , if no events of type E (cid:48) ∈ T, E (cid:48) (cid:54) = E, are matched by the queries Q E during the timeinterval ( e f .time, e l .time ) , where e f .time and e l .time are the timestamps of the first and the last events in B E , respectively. If no events can be added to a burst B E without violating the above constraints, the burst B E is called complete. Within each pane, events that belong to the same burst are buffered until a burst is complete.The arrival of an event of type E (cid:48) or the end of the pane indicates that the burst is complete. In thefollowing, we refer to complete bursts as bursts for compactness.H AMLET restricts event types in a burst for the following reason. Assuming that a burst con-tained an event e of type E (cid:48) , the event e could be matched by one query q but not by anotherquery q in Q E . Snapshots would have to be introduced to differentiate between the aggregates of q and q (Section 3.3). Maintenance of these snapshots may reduce the benefit of sharing. Thus,the previous sharing decision may have to be reconsidered as soon as the first event arrives that ismatched by some queries in Q E . Definition 11. ( Dynamic Sharing Benefit ) Let E + be a Kleene sub-pattern that is shareable by queries Q E , B E be a burst of events of type E , b be the number of events in B E , s c be the number of snapshotsthat are created from this burst B E , and s p be the number of snapshots that are propagated to compute theintermediate trend counts for the burst B E . Let G E denote a shared graphlet and G iE denote a set of non-shared graphlets (one graphlet per each query in Q E ). Other notations are consistent with previous sections(Table 2). The benefit of sharing a graphlet G E by the queries Q E is computed as the difference between the cost ofthe non-shared and shared execution of the burst B E . Shared ( G E , Q E ) = b × n × s p + s c × k × g × t NonShared ( G iE , Q E ) = k × b × n Benefit ( G E , Q E ) = NonShared ( G iE , Q E ) − Shared ( G E , Q E ) (7) If Benefit ( G E , Q E ) > , then it is beneficial to share trend aggregation within the graphlet G E by thequeries Q E . Based on Definition 12, we conclude that the more queries k share trend aggregation, the moreevents g are in shared graphlets, and the fewer snapshots s c and s p are maintained at a time, thehigher the benefit of sharing will be. Based on this conclusion, our dynamic H AMLET optimizerdecides to share or not to share online trend aggregation (Section 4.2).
Definition 12. ( Dynamic Sharing Benefit ) Let E + be a Kleene sub-pattern that is shareable by queries Q E , b be the number of events of type E in a burst, s c be the number of snapshots that are created from thisburst, and s p be the number of snapshots that are propagated to compute the intermediate trend counts forthe burst. Let G E denote a shared graphlet and G iE denote a set of non-shared graphlets (one graphlet pereach query in Q E ). Other notations are consistent with previous sections (Table 2).The benefit of sharing a graphlet G E by the queries Q E is computed as the difference between the cost ofthe non-shared and shared execution of the event burst. Shared ( G E , Q E ) = s c × k × g × p + b × (log ( g ) + n × s p ) NonShared ( G iE , Q E ) = k × b × (log ( g ) + n ) Benefit ( G E , Q E ) = NonShared ( G iE , Q E ) − Shared ( G E , Q E ) (8) If Benefit ( G E , Q E ) > , then it is beneficial to share trend aggregation within the graphlet G E by thequeries Q E . Based on Definition 12, we conclude that the more queries k share trend aggregation, the moreevents g are in shared graphlets, and the fewer snapshots s c and s p are maintained at a time, thehigher the benefit of sharing will be. Based on this conclusion, our dynamic H AMLET optimizerdecides to share or not to share online trend aggregation (Section 4.2).
Our dynamic H
AMLET optimizer monitors the sharing benefit depending on changing stream con-ditions at runtime. Let B + be a sub-pattern sharable by queries Q B = { q , q } . In Figure 6, paneboundaries are depicted as dashed vertical lines and bursts of newly arrived events of type B areshown as bold empty circles. For each burst, the optimizer has a choice of sharing (Figure 6(a)) (a) Shared B (b) Non-shared B (c) Shared B (d) Non-shared B , B (e) Non-shared B , B (f) Shared B Figure 6:
Dynamic sharing decisions. Decision to merge B in (a) and (b). Decision to split B in (c) and (d).Decision to merge B in (e) and (f). versus not sharing (Figure 6(b)). It concludes that it is beneficial to share based on calculations inEquation 9. Shared ( B , Q B ) = 4 × × × × × NonShared ( { B , B } , Q B ) = 2 × × Benefit ( B , Q B ) = 56 −
44 = 12 > (9) Decision to Split . However, when the next burst of events of type B arrives, a new snapshot y has to be created due to predicates during the shared execution in Figure 6(c). In contrast, thenon-shared strategy processes queries q and q independently from each other (Figure 6(d)). Nowthe overhead of snapshot maintenance is no longer justified by the benefit of sharing (Equation 10). Shared ( B , Q B ) = 4 × × × × × NonShared ( { B , B } , Q B ) = 2 × ×
11 = 88
Benefit ( B , Q B ) = 88 −
120 = − < (10)Thus, the optimizer decides to split the shared graphlet B into two non-shared graphlets B and B for the queries q and q respectively in Figure 6(d). Newly arriving events of type B thenmust be inserted into both graphlets B and B . Their intermediate trend counts are computedseparately for the queries q and q . The snapshot x is replaced by its value for the query q ( q )within the graphlet B ( B ). The graphlets A and C are collapsed. Decision to Merge . When the next burst of events of type B arrives, we could either continuethe non-shared trend count propagation within B and B (Figure 6(e)) or merge B and B intoa new shared graphlet B (Figure 6(f)). The H AMLET optimizer concludes that the latter option ismore beneficial in Equation 11. As a consequence, a new snapshot z is created as input to B . z consolidates the intermediate trend counts of the snapshot x and the graphlets B – B per query q and q . Shared ( B , Q B ) = 4 × × × × × NonShared ( { B , B } , Q B ) = 2 × ×
15 = 120
Benefit ( B , Q B ) = 120 −
76 = 44 > (11) . The runtime sharing decision per burst has constant time complexitybecause it simply plugs in locally available stream statistics into Equation 8. A graphlet split comesfor free since we simply continue graph construction per query (Figure 6(d)). Merging graphletsrequires creation of one snapshot and calculation of its values per query (Figure 6(f)). Thus, thetime complexity of merging is O ( k × g × t ) (Equation 6). Since our workload is fixed (Section 2), thenumber of queries k and the number of types t per query are constants. Thus, the time complexityof merge is linear in the number of events per graphlet g . Merging graphlets requires storing thevalue of one snapshot per query. Thus, its space complexity is O ( k ) . To relax the assumption from Section 4.2 that a set of queries Q E that share a Kleene sub-pattern E + is given, we now select a sub-set of queries Q E from the workload Q for which sharing E + isthe most beneficial among all other sub-sets of Q . In general, the search space of all sub-sets of Q isexponential in the number of queries in Q since all combinations of shared and non-shared queriesin Q are considered. For example, if Q contains four queries, Figure 7 illustrates the search spaceof 12 possible execution plans of Q . Groups of queries in braces are shared. For example, the plan(134)(2) denotes that queries 1, 3, 4 share their execution, while query 2 is processed separately. Thesearch space ranges from maximally shared (top node) to non-shared (bottom node) plans. Eachplan has its execution cost associated with it. For example, the cost of the plan (134)(2) is computedas the sum of Shared ( G E , { , , } ) and N onShared ( G iE , (Equation 8). The goal of the dynamicH AMLET optimizer is to find a plan with minimal execution cost.
Figure 7:
Search space of sharing plans
Traversing the exponential search space for each Kleene sub-pattern and each burst of eventswould jeopardize real-time responsiveness of H
AMLET . Fortunately, most plans in this search spacecan be pruned without loosing optimality (Theorems 4.1 and 4.2). Intuitively, Theorem 4.1 statesthat it is always beneficial to share the execution of a query that introduces no new snapshots.
Theorem 4.1.
Let E + be a Kleene sub-pattern that is shared by a set of queries Q E and not shared by a setof queries Q N , Q E ∩ Q N = ∅ , k s = | Q E | , and k n = | Q N | . For a burst of events of type E , let q ∈ Q E bea query that does not introduce new snapshots due to predicates for this burst of events (Definition 9). Thenthe following follows: Shared ( Q E ) + NonShared ( Q N ) ≤ Shared ( Q E \ { q } ) + NonShared ( Q N ∪ { q } ) Proof.
Equation 12 summarizes the cost of sharing the execution of queries Q E where q ∈ Q E . Shared ( Q E ) + NonShared ( Q N )= k s × s c × g × p + b × (log ( g ) + n × s p )+ k n × b × (log ( g ) + n ) (12)Now assume the execution of q is not shared with other queries in Q E . That is, q is removedfrom set Q E and added to set Q N . Then, k s is decremented by one and k n is incremented by one inEquation 13. All other cost factors remain unchanged. In particular, the number of created s c andpropagated s p snapshots do not change. Shared ( Q E \ { q } ) + NonShared ( Q N ∪ { q } )= ( k s − × s c × g × p + b × (log ( g ) + n × s p )+ ( k n + 1) × b × (log ( g ) + n ) (13)Equations 12 and 13 differ by one additive factor ( s c × g × p ) if q is shared versus one additivefactor ( b × (log ( g ) + n )) if q is not shared. These additive factors are underlined in Equations 12and 13. Since s c ≤ b , g ≤ n , and the number of predecessor types p per type per query is negligiblecompared to other cost factors, we conclude that ( s c × g × p ) ≤ ( b × (log ( g ) + n )) , i.e., it is beneficialto share the execution of q with other queries in Q E .We formulate the following pruning principle per Theorem 4.1. Snapshot-Driven Pruning Principle . Plans at Level 2 of the search space that do not sharequeries that introduced no snapshots are pruned. All descendants of such plans are also pruned.
Example 8.
In Figure 7, assume queries 1 and 3 introduced no snapshots, while queries 2 and 4 introducedsnapshots. Then, four plans are considered because they share queries 1 and 3 with other queries. Theseplans are highlighted by frames. The other eight plans are pruned since they are guaranteed to have higherexecution costs.
Theorem 4.2 below states that if it is beneficial to share the execution of a query q with otherqueries Q , a plan that processes the query q separately from other queries Q E ⊆ Q will have higherexecution costs than a plan that shares q with Q E . The reverse of the statement also holds. Namely,if it is not beneficial to share the execution of a query q with other queries Q , a plan that sharesthe execution of q with other queries Q E ⊆ Q will have higher execution costs than a plan thatprocesses q separately from Q E . Let E + be a Kleene sub-pattern that is shareable by a set of queries Q , Q = Q E ∪ Q N , and q ∈ Q E . Then:If Shared ( Q ) ≤ Shared ( Q \ { q } ) + NonShared ( q ) , (14) then Shared ( Q E ) + NonShared ( Q N ) ≤ Shared ( Q E \ { q } ) + NonShared ( Q N ∪ { q } ) (15) This statement also holds if we replace all ≤ by ≥ .Proof Sketch. In Equation 14, if we do not share the execution of query q with queries Q and theexecution costs increase, this means that the cost for re-computing q is higher than the cost ofmaintenance of snapshots introduced by q due to predicates. Similarly in Equation 15, if we movethe query q from the set of queries Q E that share their execution to the set of queries Q N thatare processed separately, the overhead of recomputing q will dominate the overhead of snapshotmaintenance due to q . The reverse of Theorem 4.2 can be proven analogously.We formulate the following pruning principle per Theorem 4.2. Benefit-Driven Pruning Principle . Plans at Level 2 of the search space that do not share a querythat is beneficial to share are pruned. Plans at Level 2 of the search space that share a query that isnot beneficial to share are pruned. All descendants of such plans are also pruned.
Example 9.
In Figure 7, if it is beneficial to share query 2, then we can safely prune all plans that processquery 2 separately. That is, the plan (134)(2) and all its descendants are pruned. Similarly, if it is notbeneficial to share query 4, we can safely exclude all plans that share query 4. That is, all siblings of (123)(4)and their descendants are pruned. The plan (123)(4) is chosen (highlighted by a bold frame).
Consequence of Pruning Principles . Based on all plans at Levels 1 and 2 of the search space, theoptimizer classifies each query in the workload as either shared or non-shared. Thus, it chooses theoptimal plan without considering plans at levels below 2.
Complexity Analysis . Given a burst of new events, let m be the number of queries that intro-duce new snapshots to share the processing of this burst of events. The number of plans at Levels1 and 2 of the search space is m + 1 . Thus both time and space complexity of sharing plan selectionis O ( m ) . Theorem 4.3.
Within one burst, H AMLET has optimal time complexity.Proof.
For a given burst of events, H
AMLET optimizer makes a decision to share or not to share de-pending on the sharing benefit in Section 4.2. If it is not beneficial to share, each query is processedseparately and has optimal time complexity [33]. If it is beneficial to share a pattern E + by a set ofqueries Q E , the time complexity is also optimal since it is optimal for one query q ∈ Q E [33] andother queries in Q E are processed for free. The set of queries Q E is chosen such that the benefit ofsharing is maximal (Theorems 4.1 and 4.2). Granularity of H
AMLET
Sharing Decision . H
AMLET runtime sharing decisions are made perburst of events (Section 4.2). There can be several bursts per window (Definition 10). Within one burst, H AMLET has optimal time complexity (Theorem 4.3). According to the complexity analysisin Section 4.2, the choice of the query set has linear time complexity in the number of queries m that introduce snapshots due to predicates. By Section 4.3, the merge of graphlets has linear timecomplexity in the number of events g per graphlet. H AMLET would be optimal per window if itcould make sharing decisions at the end of each window. However, waiting until all events perwindow arrive could introduce delays and jeopardise real-time responsiveness. Due to this lowlatency constraint, H
AMLET makes sharing decisions per burst, achieving significant performancegain over competitors (Section 6.2).
While we focused on simpler queries so far, we now sketch how H
AMLET can be extended tosupport a broad class of trend aggregation queries as per Definition 2.
Disjunctive or Conjunctive Pattern . Let P be a disjunctive or a conjunctive pattern and P , P be its sub-patterns (Definition 1). In contrast to event sequence and Kleene patterns, P does notimpose a time order constraint upon trends matched by P and P . Let COUNT ( P ) denote thenumber of trends matched by P . COUNT ( P ) can be computed based on COUNT ( P ) and COUNT ( P ) as defined below. The processing of P and P can be shared. Let P , be the pattern that de-tects trends matched by both P and P . Let C , = COUNT ( P , ) , C = COUNT ( P ) − C , , and C = COUNT ( P ) − C , . C , is subtracted to avoid counting trends matched by P , twice.Disjunctive pattern ( P ∨ P ) matches a trend that is a match of P or P . COUNT ( P ∨ P ) = C + C + C , .Conjunctive pattern ( P ∧ P ) matches a pair of trends tr and tr where tr is a match of P and tr is a match of P . COUNT ( P ∧ P ) = C ∗ C + C ∗ C , + C ∗ C , + (cid:0) C , (cid:1) since each trenddetected only by P (not by P ) is combined with each trend detected only by P (not by P ). Inaddition, each trend detected by P , is combined with each other trend detected only by P , onlyby P , or by P , . Pattern with Negation
SEQ ( P , NOT
N, P ) is split into positive SEQ ( P , P ) and negative N sub-patterns at compile time. At runtime, we maintain separate graphs for positive and negativesub-patterns. When a negative sub-pattern N finds a match e n , we disallow connections frommatches of P before e n to matches of P after e n . Aggregates are computed the same way [33]. Nested Kleene Pattern P = ( SEQ ( P , P +))+ . Loops exist at template level but not at graphlevel because previous events connect to new events in a graph but never the other way around dueto temporal order constraints (compare Figures 3 and 4(b)). The processing of P and its sub-patterscan be shared by several queries containing these patterns as illustrated by Example 10. Figure 8: H AMLET query template for Q Consider query q with pattern ( SEQ ( A, B +))+ and query q with pattern ( SEQ ( C, B +))+ .Figure 8 shows the merged template for the workload Q = { q , q } . In contrast to the template in Figure 3(b),there are two additional transitions (from B to A for q and from B to C for q ) forming two additional loopsin the template. Therefore, in addition to predecessor type relations in Example 2 ( pt ( B, q ) = { A, B } and pt ( B, q ) = { C, B } ), two new predecessor type relations exist. Namely, pt ( A, q ) = { B } and pt ( C, q ) = { B } .Consider the stream in Figure 4(b). Similarly to Example 5, events in A – C are predecessors of eventsin B , while events in A – C are predecessors of events in B . Because of the additional predecessor type re-lations in the template in Figure 8, events in B are predecessors of events in A – C . Due to these additionalpredecessor event relations, more trends are now captured in the H AMLET graph in Figure 4(b) and the in-termediate and final trend counts have now higher values. However, Definitions 6–12 and Theorems 4.1–4.3hold and Algorithm 1 applies to share trend aggregation among queries in the workload Q . Infrastructure . We have implemented H
AMLET in Java with JDK 1.8.0 181 running on Ubuntu14.04 with 16-core 3.4GHz CPU and 128GB of RAM. Our code is available online [1]. We executeeach experiment three times and report their average results here.
Data Sets . We evaluate H
AMLET using four data sets. • New York city taxi and Uber real data set [8] contains 2.63 billion taxi and Uber trips in New YorkCity in 2014–2015. Each event carries a time stamp in seconds, driver and rider identifiers, pick-upand drop-off locations, number of passengers, and price. The average number of events per minuteis 200. • Smart home real data set [2] contains 4055 million measurements for 2125 plugs in 40 houses.Each event carries a timestamp in seconds, measurement, house identifiers, and voltage measure-ment value. The average number of events per minute is 20K. • Stock real data set [5] contains up to 20 years of stock price history. Our sample data contains2 million transaction records of 220 companies for 8 hours. Each event carries a time stamp inminutes, company identifier, price, and volume. The average number of events per minute is 4.5K. • Ridesharing data set was created by our stream generator to control the rate and distributionof events of different types in the stream. This stream contains events of 20 event types such asrequest, pickup, travel, dropoff, cancel, etc. Each event carries a time stamp in seconds, driver andrider ids, request type, district, duration, and price. The attribute values are randomly generated.The average number of events per minute is 10K.
Event Trend Aggregation Queries . For each data set, we generated workloads similar to queries q – q in Figure 1. We experimented with the two types of workloads described below. • The first workload focuses on sharing Kleene closure because this is the most expensiveoperator in event trend aggregation queries (Definition 2.2). Further, the sharing of Kleene clo-sure is a much overlooked topic in the literature; while the sharing of other query clauses (win- dows, grouping, predicates, and aggregation) has been well-studied in prior research and sys-tems [10, 17, 24, 25, 28]. Thus, queries in this workload are similar to Examples 2–9. Namely, theyhave different patterns but their sharable Kleene sub-pattern, window, groupby clause, predicates,and aggregates are the same. We evaluate this workload in Figures 9–11. • The second workload is more diverse since the queries have sharable Kleene patterns oflength ranging from 1 to 3, windows sizes ranging from 5 to 20 minutes, different aggregates (e.g.,COUNT, AVG, MAX, etc.), as well as groupbys and predicates on a variety of event types. Weevaluate this workload in Figures 12–13.The rate of events differs in different real data sets [8, 2, 5] that we used in our experiments. Thewindow sizes are also different in the query workloads per data set. To make the results comparableacross data sets, we vary the number of events per minute by a speed-up factor; which correspondsto the number of events per window divided by the window size in minutes. The default numberof events per minute per data set is included in the description of each data set. Unless statedotherwise, the workload consists of 50 queries. We vary major cost factors (Definition 12), namely,the number of events and the number of queries.
Methodology . We experimentally compare H
AMLET to the following state-of-the-art approaches: • MCEP [22] is the most recently published state-of-the-art shared two-step approach. MCEPconstructs all event trends prior to computing their aggregation. As shown in [22], it shares eventtrend construction. It outperforms other shared two-step approaches SPASS [38] and MOTTO [47]. • S HARON [35] is a shared approach that computes event sequence aggregation online. That is,it avoids sequence construction by incrementally maintaining a count for each pattern. S
HARON does not support Kleene closure. To mimic Kleene queries, we flatten them as follows. For eachKleene pattern E + , we estimate the length l of the longest match of E + and specify a set of fixed-length sequence queries that cover all possible lengths up to l . • G RETA [33] supports Kleene closure and computes event trend aggregation online, i.e, with-out constructing all event trends. It achieves this online event trend aggregation by encoding allmatched events and their adjacency relationships in a graph. However, G
RETA does not optimizefor sharing a workload of queries. That is, each query is processed independently as described inSection 3.2.
Metrics . We measure latency in seconds as the average time difference between the time point ofthe aggregation result output by a query in the workload and the arrival time of the latest event thatcontributed to this result.
Throughput corresponds to the average number of events processed byall queries per second.
Peak memory consumption , measured in bytes, corresponds to the maximalmemory required to store snapshot expressions for H
AMLET , the current event trend for MCEP,aggregates for S
HARON , and matched events for H
AMLET , MCEP, and G
RETA . H AMLET versus State-of-the-art Approaches . In Figures 9 and 10, we measure all metrics of allapproaches while varying the number of events per minute from 10K to 20K and the number ofqueries in the workload from 5 to 25. We intentionally selected this setting to ensure that the two- step approach MCEP, the non-shared approach G RETA , and the fixed-length sequence aggregationapproach S
HARON terminate within hours. (a) Latency vs events (b) Latency vs queries(c) Throughput vs events (d) Throughput vs queries
Figure 9: H AMLET versus state-of-the-art approaches (Ridesharing)
With respect to throughput, H
AMLET consistently outperforms S
HARON by 3–5 orders of mag-nitude, G
RETA by 1–2 orders of magnitude, and MCEP 7–76-fold (Figures 9(c) and 9(d)). We ob-serve similar improvement with respect to latency in Figures 9(a) and 9(b). While H
AMLET termi-nates within 25 milliseconds in all cases, S
HARON needs up to 50 minutes, G
RETA up to 3 seconds,and MCEP up to 1 second. With respect to memory consumption, H
AMLET , G
RETA , and MCEPperform similarly, while S
HARON requires 2–3 orders of magnitude more memory than H
AMLET in Figure 10.Such poor performance of S
HARON is not surprising because S
HARON does not natively sup-port Kleene closure. To detect all Kleene matches, S
HARON runs a workload of fixed-length se-quence queries for each Kleene query. As Figure 9 illustrates, this overhead dominates the latencyand throughput of S
HARON . In contrast to S
HARON , G
RETA and MCEP terminate within a fewseconds in this low setting because both approaches not only support Kleene closure but also op-timize its processing. In particular, G
RETA computes trend aggregation without constructing thetrends but does not share trend aggregation among different queries in the workload. MCEP sharesthe construction of trends but computes trend aggregation as a post-processing step. Due to theselimitations, H
AMLET outperforms both G
RETA and MCEP with respect to all metrics.However, the low setting in Figures 9 and 10 does not reveal the full potential of H
AMLET . Thusin Figure 11, we compare H
AMLET to the most advanced state-of-the-art online trend aggregationapproach G
RETA using two real data sets. We measure latency and throughput, while varyingthe number of events per minute and the number of queries in the workload. H
AMLET consistently (a) Memory vs events (b) Memory vs queries Figure 10: H AMLET vs state-of-the-art (Ridesharing) outperforms G
RETA with respect to throughput and latency by 3–5 orders of magnitude. In practicethis means that the response time of H
AMLET is within half a second, while G
RETA runs up to 2hours and 17 minutes for 400 events per minute in Figure 11(a).
Dynamic versus Static Sharing Decision . Figures 12 and 13 compare the effectiveness of H AM - LET dynamic sharing decisions to static sharing decisions. Each burst of events that can be sharedcontains 120 events on average in the stock data set. Our H
AMLET dynamic optimizer makes shar-ing decisions at runtime per each burst of events (Section 4.1). The H
AMLET executor splits andmerges graphlets at runtime based on these optimization instructions (Section 4.2). The number ofall graphlets ranges from 400 to 600, while the number of shared graphlets ranges from 360 to 500.In this way, H
AMLET efficiently shares the beneficial Kleene sub-patterns within a subset of queriesduring its execution.In Figures 12(a), 12(c) and 13(a), as the number of events per minute increases from 2K to 4K,the number of snapshots maintained by the H
AMLET executor grows from 4K to 8K. As soon asthe overhead of snapshot maintenance outweighs the benefits of sharing, the H
AMLET optimizerdecides to stop sharing. The H
AMLET executor then splits these shared graphlets (Section 4.2). TheH
AMLET dynamic optimizer shares approximately 90% of bursts. The rest 10% of the bursts arenot shared which substantially reduces the number of snapshots by around 50% compared to theshared execution.In contrast, the static optimizer decides to share certain Kleene sub-patterns by a fixed set ofqueries during the entire window. Since these decisions are made at compile time, they do notincur overhead at runtime. However, these static decisions do not take the stream fluctuations intoaccount. Consequently, these sharing decisions may do more harm than good by introducing sig-nificant CPU overhead of snapshot maintenance, causing non-beneficial shared execution. Duringthe entire execution, the static optimizer always decides to share, and the number of snapshotsgrows dramatically from 10K to 20K. Therefore, our H
AMLET dynamic sharing approach achieves21–34% speed-up and 27–52% throughput improvement compared to the executor that obeys tostatic sharing decisions.We observe similar gains of H
AMLET with respect to memory consumption in Figure 13(a).H
AMLET reduces memory by 25% compared to the executor based on static sharing decisions be-cause the number of snapshots introduced by H
AMLET dynamic sharing decisions is much less (a) Latency vs events (NYC) (b) Latency vs events (SH)(c) Throughput vs events (NYC) (d) Throughput vs events (SH)(e) Memory vs events (NYC) (f) Memory vs events (SH)(g) Latency vs queries (h) Throughput vs queries Figure 11: H AMLET versus state-of-the-art approaches (NY City Taxi (NYC) and Smart Home (SH) data sets) than the number of snapshots introduced by the static sharing decisions.We also vary the number of queries in the workload from 20 to 100, and we observe similargains by H
AMLET dynamic sharing optimizer in terms of latency, throughput, and memory (de-picted in Figures 12(b), 12(d), and 13(b)). H
AMLET can effectively leverage the beneficial sharingopportunities within a large query workload. (a) Latency vs events (b) Latency vs queries(c) Throughput vs events (d) Throughput vs queries Figure 12:
Dynamic versus static sharing decisions (Stock data set) (a) Memory vs events (b) Memory vs queries
Figure 13:
Dynamic versus static sharing decisions (Stock data set)
Lastly, we measured the runtime overhead of the H
AMLET dynamic sharing decisions. Eventhough the number of sharing decisions ranges between 400 and 600 per window, the latency in-curred by these decisions stays within 20 milliseconds (less than 0.2% of total latency per window)because these decisions are light-weight (Section 4.2). Also, the latency of one-time static workloadanalysis (Section 3.1) stays within 81 milliseconds. Thus, we conclude that the overhead of dynamicdecision making and static workload analysis are negligible compared to their gains.
Complex Event Processing Systems (CEP) have gained popularity in the recent years [3, 4, 6, 7].Some approaches use a Finite State Automaton (FSA) as an execution framework for pattern match-ing [9, 14, 44, 45]. Others employ tree-based models [31]. Some approaches study lazy match detec- tion [23], compact event graph encoding [32], and join plan generation [21]. We refer to the recentsurvey [15] for further details. While these approaches support trend aggregation, they constructtrends prior to their aggregation. Since the number of trends is exponential in the number of eventsper window [36, 45], such two-step approaches do not guarantee real-time response [33, 34]. Worseyet, they do not leverage sharing opportunities in the workload. The re-computation overhead issubstantial for workloads with thousands of queries. Online Event Trend Aggregation.
Similarly to single-event aggregation, event trend aggrega-tion has been actively studied. A-Seq [36] introduces online aggregation of event sequences, i.e.,sequence aggregation without sequence construction. G
RETA [33] extends A-Seq by Kleene clo-sure. Cogra [34] further generalizes online trend aggregation by various event matching semantics.However, none of these approaches addresses the challenges of multi-query workloads, which isour focus.
CEP Multi-query Optimization follows the principles commonly used in relational databasesystems [40], while focusing on pattern sharing techniques. RUMOR [19] defines a set of rulesfor merging queries in NFA-based RDBMS and stream processing systems. E-Cube [28] insertssequence queries into a hierarchy based on concept and pattern refinement relations. SPASS [38]estimates the benefit of sharing for event sequence construction using intra-query and inter-queryevent correlations. MOTTO [47] applies merge, decomposition, and operator transformation tech-niques to re-write pattern matching queries. Kolchinsky et al. [22] combine sharing and patternreordering optimizations for both NFA-based and tree-based query plans. However, these ap-proaches do not support online aggregation of event sequences, i.e., they construct all event se-quences prior to their aggregation, which degrades query performance. To the best of our knowl-edge, S
HARON [35] and Muse [39] are the only solutions that support shared online aggregation.However, S
HARON does not support Kleene closure. Worse yet, S
HARON and Muse make staticsharing decisions. In contrast, H
AMLET harnesses additional sharing benefit thanks to dynamicsharing decisions depending on the current stream properties.
Multi-query Processing over Data Streams.
Sharing query processing techniques are well-studied for streaming systems. NiagaraCQ [13] is a large-scale system for processing multiplecontinuous queries over streams. TelegraphCQ [12] introduces a tuple-based dynamic routing forinter-query sharing [29]. AStream [20] shares computation and resources among several queriesexecuted in Flink [4]. Several approaches focus on sharing optimizations given different predicates,grouping, or window clauses [10, 17, 18, 24, 25, 42, 46]. However, these approaches evaluate Select-Project-Join queries with windows and aggregate single events. They do not support CEP-specificoperators such as event sequence and Kleene closure that treat the order of events as a first-classcitizen. Typically, they require the construction of join results prior to their aggregation. In contrast,H
AMLET not only avoids the expensive event trend construction, but also exploits the sharingopportunities among trend aggregation queries with diverse Kleene patterns. H AMLET integrates a shared online trend aggregation execution strategy with a dynamic sharingoptimizer to maximize the benefit of sharing. It monitors fluctuating streams, recomputes the shar-ing benefit, and switches between shared and non-shared execution at runtime. Our experimentalevaluation demonstrates substantial performance gains of H
AMLET compared to state-of-the-art.
Acknowledgments
This work was supported by NSF grants IIS-1815866, IIS-1018443, CRI-1305258, the U.S. Depart-ment of Agriculture grant 1023720, and the U.S. Department of Education grant P200A150306.
References [1] https://github.com/LeiMa0324/Hamlet .[2] DEBS 2014 grand challenge: Smart homes. https://debs.org/grand-challenges/2014/ .[3] Esper. .[4] Flink. https://flink.apache.org/ .[5] Historical stock data. .[6] Microsoft StreamInsight. https://technet.microsoft.com/en-us/library/ee362541%28v=sql.111%29.aspx .[7] Oracle Stream Analytics. .[8] Unified New York City taxi and Uber data. https://github.com/toddwschneider/nyc-taxi-data .[9] J. Agrawal, Y. Diao, D. Gyllstrom, and N. Immerman. Efficient pattern matching over eventstreams. In
SIGMOD , pages 147–160, 2008.[10] A. Arasu and J. Widom. Resource sharing in continuous sliding-window aggregates. In
VLDB ,pages 336–347, 2004.[11] B. Chandramouli, J. Goldstein, and D. Maier. High-performance dynamic pattern matchingover disordered streams.
PVLDB , 3(1):220–231, 2010.[12] S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W. Hong, S. Kr-ishnamurthy, S. Madden, V. Raman, F. Reiss, and M. A. Shah. TelegraphCQ: Continuousdataflow processing for an uncertain world. In
CIDR , 2003. [13] J. Chen, D. J. DeWitt, F. Tian, and Y. Wang. NiagaraCQ: A scalable continuous query systemfor internet databases. In SIGMOD , page 379–390, 2000.[14] A. Demers, J. Gehrke, B. Panda, M. Riedewald, V. Sharma, and W. White. Cayuga: A generalpurpose event monitoring system. In
CIDR , pages 412–422, 2007.[15] N. Giatrakos, E. Alevizos, A. Artikis, A. Deligiannakis, and M. Garofalakis. Complex eventrecognition in the Big Data era: A survey.
PVLDB , 29(1):313–352, 2020.[16] J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow, andH. Pirahesh. Data cube: A relational aggregation operator generalizing group-by, cross-tab,and sub-totals.
Data Min. Knowl. Discov. , pages 29–53, 1997.[17] S. Guirguis, M. A. Sharaf, P. K. Chrysanthis, and A. Labrinidis. Three-level processing ofmultiple aggregate continuous queries. In
ICDE , pages 929–940, 2012.[18] M. A. Hammad, M. J. Franklin, W. G. Aref, and A. K. Elmagarmid. Scheduling for sharedwindow joins over data streams. In
VLDB , page 297–308, 2003.[19] M. Hong, M. Riedewald, C. Koch, J. Gehrke, and A. Demers. Rule-based multi-query opti-mization. In
EDBT , pages 120–131, 2009.[20] J. Karimov, T. Rabl, and V. Markl. AStream: Ad-hoc shared stream processing. In
SIGMOD ,page 607–622, 2019.[21] I. Kolchinsky and A. Schuster. Join query optimization techniques for complex event process-ing applications. In
PVLDB , pages 1332–1345, 2018.[22] I. Kolchinsky and A. Schuster. Real-time multi-pattern detection over event streams. In
SIG-MOD , pages 589–606, 2019.[23] I. Kolchinsky, I. Sharfman, and A. Schuster. Lazy evaluation methods for detecting complexevents. In
DEBS , pages 34–45, 2015.[24] S. Krishnamurthy, C. Wu, and M. Franklin. On-the-fly sharing for streamed aggregation. In
SIGMOD , pages 623–634, 2006.[25] J. Li, D. Maier, K. Tufte, V. Papadimos, and P. A. Tucker. No pane, no gain: Efficient evaluationof sliding window aggregates over data streams. In
SIGMOD , pages 39–44, 2005.[26] J. Li, K. Tufte, V. Shkapenyuk, V. Papadimos, T. Johnson, and D. Maier. Out-of-order pro-cessing: A new architecture for high-performance stream systems. In
VLDB , pages 274–288,2008.[27] M. Liu, M. Li, D. Golovnya, E. A. Rundensteiner, and K. T. Claypool. Sequence pattern queryprocessing over out-of-order event streams. In
ICDE , pages 784–795, 2009. [28] M. Liu, E. Rundensteiner, K. Greenfield, C. Gupta, S. Wang, I. Ari, and A. Mehta. E-Cube:Multi-dimensional event sequence analysis using hierarchical pattern query sharing. In SIG-MOD , pages 889–900, 2011.[29] S. Madden, M. Shah, J. M. Hellerstein, and V. Raman. Continuously adaptive continuousqueries over streams. In
SIGMOD , page 49–60, 2002.[30] H. Mai, B. Liu, and N. Cherukuri. Introducing AthenaX, Uber engineering’s open sourcestreaming analytics platform. https://eng.uber.com/athenax/ , 2017.[31] Y. Mei and S. Madden. ZStream: A cost-based query processor for adaptively detecting com-posite events. In
SIGMOD , pages 193–206, 2009.[32] O. Poppe, C. Lei, S. Ahmed, and E. Rundensteiner. Complete event trend detection in high-rate streams. In
SIGMOD , pages 109–124, 2017.[33] O. Poppe, C. Lei, E. A. Rundensteiner, and D. Maier. Greta: Graph-based real-time event trendaggregation. In
VLDB , pages 80–92, 2017.[34] O. Poppe, C. Lei, E. A. Rundensteiner, and D. Maier. Event trend aggregation under rich eventmatching semantics. In
SIGMOD , pages 555–572, 2019.[35] O. Poppe, A. Rozet, C. Lei, E. A. Rundensteiner, and D. Maier. Sharon: Shared online eventsequence aggregation. In
ICDE , pages 737–748, 2018.[36] Y. Qi, L. Cao, M. Ray, and E. A. Rundensteiner. Complex event analytics: Online aggregationof stream sequence patterns. In
SIGMOD , pages 229–240, 2014.[37] R. Ramakrishnan, B. Sridharan, J. R. Douceur, P. Kasturi, B. Krishnamachari-Sampath, K. Kr-ishnamoorthy, P. Li, M. Manu, S. Michaylov, R. Ramos, N. Sharman, Z. Xu, Y. Barakat, C. Dou-glas, R. Draves, S. S. Naidu, S. Shastry, A. Sikaria, S. Sun, and R. Venkatesan. Azure Data LakeStore: A hyperscale distributed file service for big data analytics. In
SIGMOD , page 51–63,2017.[38] M. Ray, C. Lei, and E. A. Rundensteiner. Scalable pattern sharing on event streams. In
SIG-MOD , pages 495–510, 2016.[39] A. Rozet, O. Poppe, C. Lei, and E. A. Rundensteiner. Muse: Multi-query event trend aggrega-tion. In
CIKM , page 2193–2196, 2020.[40] T. K. Sellis. Multiple-query optimization.
ACM Trans. Database Syst. , 13(1):23–52, 1988.[41] U. Srivastava and J. Widom. Flexible time management in data stream systems. In
PODS ,pages 263–274, 2004.[42] G. Theodorakis, A. Koliousis, P. Pietzuch, and H. Pirk. LightSaber: Efficient window aggrega-tion on multi-core processors. In
SIGMOD , page 2505–2521, 2020. [43] C. Wu, A. Jindal, S. Amizadeh, H. Patel, W. Le, S. Qiao, and S. Rao. Towards a learningoptimizer for shared clouds. PVLDB , 12(3):210–222, 2018.[44] E. Wu, Y. Diao, and S. Rizvi. High-performance Complex Event Processing over streams. In
SIGMOD , pages 407–418, 2006.[45] H. Zhang, Y. Diao, and N. Immerman. On complexity and optimization of expensive queriesin CEP. In
SIGMOD , pages 217–228, 2014.[46] R. Zhang, N. Koudas, B. C. Ooi, D. Srivastava, and P. Zhou. Streaming multiple aggregationsusing phantoms. In
VLDB , pages 557–583, 2010.[47] S. Zhang, H. T. Vo, D. Dahlmeier, and B. He. Multi-query optimization for complex eventprocessing in SAP ESP. In
ICDE , pages 1213–1224, 2017.[48] Y. Zhu, E. A. Rundensteiner, and G. T. Heineman. Dynamic plan migration for continuousqueries over data streams. In