A Formal Query Language and Automata Model for Aggregation in Complex Event Recognition
Abstract
Complex Event Recognition (CER) systems are used to identify complex patterns in event streams, such as those found in stock markets, sensor networks, and other similar applications. An important task in such patterns is aggregation, which involves summarizing a set of values into a single value using an algebraic function, such as the maximum, sum, or average, among others. Despite the relevance of this task, query languages in CER typically support aggregation in a restricted syntactic form, and their semantics are generally undefined.
In this work, we present a first step toward formalizing a query language with aggregation for CER. We propose to extend Complex Event Logic (CEL), a formal query language for CER, with aggregation operations. This task requires revisiting the semantics of CEL, using a new semantics based on bags of tuples instead of sets of positions. Then, we present an extension of CEL, called Aggregation CEL (ACEL), which introduces an aggregation operator for any commutative monoid operation. The operator can be freely composed with previous CEL operators, allowing users to define complex queries and patterns. We showcase several queries in practice where ACEL proves to be natural for specifying them. From the computational side, we present a novel automata model, called Aggregation Complex Event Automata (ACEA), that extends the previous proposal of Complex Event Automata (CEA) with aggregation and filtering features. Moreover, we demonstrate that every query in ACEL can be expressed in ACEA, illustrating the effectiveness of our computational model. Finally, we study the expressiveness of ACEA through the lens of ACEL, showing that the automata model is more expressive than ACEL.
Keywords and phrases:
Streams, complex event recognition, query language, aggregationCopyright and License:
2012 ACM Subject Classification:
Information systems Stream management ; Theory of computation Database theory ; Theory of computation Database query languages (principles)Funding:
The work of Bourhis was supported by a French government grant managed by the Agence Nationale de la Recherche under the France 2030 program, reference ANR-23-PECL-0008. The work of Riveros and Salas was supported by ANID Fondecyt Regular project 1230935 and ANID – Millennium Science Initiative Program – Code ICN17_002.Editors:
Balder ten Cate and Maurice FunkSeries and Publisher:
Leibniz International Proceedings in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik
1 Introduction
Complex Event Recognition (CER) systems are a group of data stream management systems for the detection of special events in real-time, called complex events, that satisfy a pattern, considering their position, the order, and other constraints between them [17, 12]. Some examples of its use are maritime monitoring [26], network intrusion detection [24], industrial control systems [21], and real-time analytics [30]. In the literature, people have proposed multiple systems and query languages based on different formalisms for approaching complex events, such as automata-based, logic-based, tree-based, or a combination of them [17]. Examples of CER systems developed in academic and industrial contexts include SASE [34], EsperTech [1], and CORE [9, 7], among others.
A problem in CER systems is that their query languages, used to declare complex events, are, unfortunately, underspecified with respect to both their syntax and semantics. As observed in previous works [36, 15, 11, 5], CER query languages in systems typically lack a simple, compositional, and denotational semantics. In general, its semantics is defined indirectly through examples [2, 10], or by translation into evaluation models [25, 31, 33]. Recently, this issue in CER systems has been studied more thoroughly, and a query language that has successfully defined the semantics of several CER operators is Complex Event Logic (CEL) [19, 20], alongside a computational model called Complex Event Automata (CEA), which is based on the theory of finite state transducers and symbolic automata.
An open problem in formalizing CER query language is that several interesting queries in practice include aggregation, which previous proposals have not addressed. Aggregation refers to any subprocess in a query that combines and merges several (most often numerical) values into a single one [18], such as taking the average, the sum, or the maximum of a list of values. Examples of CER systems that used aggregation are SASE [14, 35], EsperTech [1], GLORIA [23], GRETA [28], and others [17, 12]. For illustrating a prototypical query with aggregation, consider the following (simplified) query from SASE [35, p. 3]:
ΨQ1: PATTERN seq(JobStart a, Mapper+ b[ ], JobEnd c) ΨWHERE a.job_id = b[i].job_id and a.job_id = c.job_id ΨRETURN AVG(b[ ].period), MAX(b[ ].period)
Intuitively, the previous query aims to retrieve the average and maximum periods from a list of running times of mappers. For this, it looks for events from the stream, in the “PATTERN” clause that match the pattern: a JobStart typed event, followed by one or more Mapper events, and finally a JobEnd event. In turn, it uses the “WHERE” clause to ensure that each event matching the pattern has the same id attribute, and finally, it returns the average and maximum of the events that meet the conditions.
Previous proposals for formalizing CER query languages do not include such queries with aggregation, as they must not only detect and retrieve complex events but also produce new events and values. In particular, aggregation queries cannot be defined by logics like CEL or computational models like CEA, or any other formalization of CER as it is currently defined. These issues imply that CER query languages with aggregation are difficult to compare, unclear how to compose queries, and difficult to evaluate (i.e., without knowing the real meaning of a query). Furthermore, computational models for compiling queries with aggregation are not well understood, and systems usually rely on ad-hoc evaluation strategies suitable for specific queries and patterns.
In this work, we propose an extension of the logic CEL, and its corresponding computational model CEA, to express queries with aggregation, which we call Aggregation Complex Event Logic (ACEL) and Aggregation Complex Event Automata (ACEA), respectively. Our main goal is to design a logic and computational model, with a formal semantics that formalizes aggregation in CER and serves as a base for all CER languages.
For extending CEL with aggregation, we need to revisit its semantics. One of the first problems to arise with the current semantics of CEL is that a CEL formula retrieves the positions in the streams that fire the complex events, but it does not allow the creation of new values or events. For this reason, we propose a new, equivalent semantics for CEL that returns events instead of positions. Additionally, since we also need to maintain duplicates for aggregation, we extend the semantics by using bags of events instead of sets. We then prove that the new semantics is equivalent to the previous one. Interestingly, the new semantics enable us to define new relevant operators for CER, such as attribute projection.
To formalize the aggregation in CER, we consider a general setting of aggregation based on aggregate functions [22, 18]; these are functions that go from a bag of values to single values, and they aim to summarize information (like count, sum, etc). By using this general framework of aggregation functions, they support our proposal in providing a general framework for aggregation in CER. Furthermore, we introduce an operator for variables named and , attributes named a and b, and aggregation function , which takes a bag of events stored in and -operates it corresponding attribute a, storing the result in another attribute b of an event in another variable . We formally define its syntax and semantics in Section 5. An advantage of this definition is that we can compose the operator and every other operator in CEL. We show that most CER queries with aggregation from previous works are definable with ACEL.
An advantage of CEL is that one can characterize its expressive power with the so-called Complex Event Automata (CEA); specifically, that for every CEL formula, there exists an equivalent CEA, and vice versa. The practical relevance of this result is that CEL is useful for users to define queries, where CEA is useful for systems to evaluate them. In this work, we aim to achieve an equivalent result, so our next step was to find a machine model that can extend CEA and formally define ACEL. We introduce an automata model with aggregation for ACEL, which we call Aggregation Complex Event Automata (ACEA), an extension of CEA with registers to aggregate values. This extension employs the same concept of operating values in transitions and maintaining registers as cost register automata [4]. Specifically, in each transition, an ACEA takes an event and updates its register with those new values. Then, it performs an operation based on the assignments, checks if it satisfies a predicate, and finally, it creates a new tuple with the aggregated values. One of our main results is that we can compile every ACEL formula into an ACEA, namely, we can prove that the expressive power of ACEL is a subset of ACEA.
Outline.
We present the preliminaries in Section 2. In Section 3, we discuss the necessary changes in CEL semantics and we show a new operator, projection by attribute. In Section 4, we discuss the setting of aggregate functions. In Section 5, we formally introduce ACEL, and we introduce ACEA in Section 6, to study the compilation of CEL formulas into ACEA and its equivalence with CEA. We conclude and discuss future work in Section 7. An extended version with all missing proofs and examples can be found in [8].
2 Preliminaries
Sets, intervals, and mappings.
Given a set , we denote by the set of all finite subsets of . We denote by the natural numbers. Given with , we denote by the set and by the interval over . As usual, we write to denote a function from the set to where every element in has an image. A mapping is a partial function that maps a finite number of elements from to elements over . We write to denote a mapping from to . We denote by the domain of (i.e., all such that is defined), and by the image of . We will usually use the notation to define a mapping with , and for every . Furthermore, for a map and we write to specify a new map that extends mapping to .
Bags.
A bag or multiset (with own identity) is a mapping where is a finite set of identifiers (or ids) and is the underlying set of the bag. Given any bag , we refer to these components as and , respectively. For example, a bag (where is repeated twice) can be represented with a mapping where and . In general, we will use the standard notation for bags to denote the bag whose identifiers are and for each . We will use to refer to the union of bags: for every bags and , we define the bag such that and where if and , otherwise. In other words, we take the disjoint union of the identifiers mapping every identifier to its corresponding element in or . Further, we define as the set of all finite bags that one can form from a set .
Computational model.
We assume the model of random access machines (RAM) with uniform cost measure, and addition and subtraction as basic operations [3]. This implies, for example, that the access to a lookup table (i.e., a table indexed by a key) takes constant time. These are common assumptions in the literature of the area [9, 32].
3 Revisiting the semantics of Complex Event Logic
In this section, we revisit the semantics of CEL [20] and present a new semantics based on tuples instead of positions. We then prove the equivalence between the two versions. This new semantics allows, for example, the definition of a new operator for CEL, called attribute-projection, which cannot be defined with the old semantics. Furthermore, the new semantics is crucial to introduce aggregation in CEL in the next section.
Events and streams.
We fix a countably infinite set of attribute names and a countably infinite of data values (e.g. integers, strings). An (untyped) event is a pair such that maps attribute names from to data values in , and is the time of the event [16] (we prefer to use discrete time, which is enough for our purposes). Intuitively, defines the data of the event (i.e., as a tuple). We denote by the value of the attribute assigned by (i.e., ). If is not defined on attribute a, then we write . Furthermore, for the sake of simplification we also denote (note, however, that is not an attribute). We define by the set of attributes of , namely, . We write to denote the set of all events over attributes names and data values . We will usually use bold letters a, b, and c to denote attribute names in and (normal) letters , , and to denote data values in .
Fix now a finite set of event types and assume that and . In this work, we assume the existence of a distinguished attribute that defines the type of an event. Specifically, let be an attribute such that . For every event , we assume that and is the type of . Notice that could be typed (i.e., ) or untyped in which case we have . A schema is a function where is a finite set of attributes. We say that an event satisfies the schema if, and only if, is a typed event and . In particular, untyped events do not satisfy a schema by definition.
Let be a schema. A stream over a schema is an (arbitrary long) sequence of typed events such that, for every , it holds that satisfies and . In other words, a stream consists of typed events according to and every time of an event is the position in the stream. Note that we defined the type and time of an event for its later use in the semantics of CEL. The first will allow us to know the attributes of each event when we compile CEL into an automata model, and the second will allow us to differentiate between tuples by adding its origin in the stream [6].
Example 1.
As a running example, consider that we have a stream that is emitting buy and sell events of particular stocks [9]. Here, we assume a schema with attributes and that represents the name of the stock (e.g., INTL for intel) and its price (e.g., US$80), respectively. We have two types, called BUY and SELL, and . A possible stream could be the following:
Note that each event contains a type (i.e., BUY or SELL), its attributes values (i.e., and ) and its time (i.e., the position above the event). Further, each event satisfies .
The notion of a renaming of a event will be useful in this work (e.g., see Section 6). Formally, we define a renaming as a mapping . We say that an event is consistent with a renaming iff and, if , then for every . Given an event consistent with , we define the renamed event such that and for every attribute . In other words, renames some attributes a of to . We define by the set of all renamings over .
Predicates of events.
A predicate is a possibly infinite set of events. For instance, could be the set of all events such that . In our examples, we will use the notation where , , and is a binary relation over to denote the predicate . We say that an event satisfies predicate , denoted , if, and only if, . We generalize this notation from events to a bag of events such that if, and only if, for every .
In this work, we assume a fix set of predicates that is close under intersection, negation, and renaming, namely, , , and for every and where and , the set of all events, is a predicate in that we usually denote by TRUE.
Complex events.
In this work, we will use a slightly different definition of complex event: we will store events inside valuations, instead of storing positions like in [9]. Formally, fix a finite set of variables, which includes all event types (i.e. ). Let be a stream of length . A complex event of is a triple where , , and is a function from variables to finite bags of events. Intuitively, and marks the beginning and end of the interval where the complex event happens, and stores the events in the interval that fired the complex event. In the following, we will usually denote to denote a complex event of and omit if the stream is clear from the context. We will use , , and to denote the interval , the start , and the end of , respectively. Further, by some abuse of notation we will also use for to denote the bag of .
The following operations on complex events will be useful throughout the paper. We define the union of complex events and , denoted by , as the complex event such that , , and for every . Further, we define the projection over of a complex event , denoted by , as the complex event such that and whenever , and , otherwise. Finally, we denote by the complex event with the trivial function such that for every .
A new semantics for CEL.
In this work, we use the Complex Event Logic (CEL) introduced in [20] and implemented in CORE [9] as our basic query language for CER. However, we revisit its semantics in order to extend it with aggregation. In particular, we use the same CEL syntax as in [20] which is given by the following grammar:
where is an event type, is a variable, is a predicate, and is a finite set of variables. Similar to [20, 9], we define the semantics of a CEL formula over a stream , recursively, as a set of complex events over . The main difference is the notion of complex events, that now contains events instead of positions. In Figure 1, we define the semantics of each CEL operator like in [9, 20]. Given a formula , the semantics defines a set of complex events. Notice that has a set-semantics and, instead, complex events store bags of events.
Next, we present an example for showing how to use the syntax and semantics of CEL to extract complex events from streams (see also Section 5). In this example, we use conjunction and disjunction in filtering that one can read them as:
for every CEL formula , variables , and predicates .
Example 2 (from [9]).
Consider the stream from Example 1. Suppose that we are interested in all triples of SELL events where the first is a sale of Microsoft over US$100, the second is a sale of Intel (of any price), and the third is a sale of Amazon below US$2000. Then, we can specify this pattern by the following CEL formula:
Intuitively, the expression specifies that we want to see three SELL events that we named by the variables , and , respectively. The semicolon operator () indicates non-contiguous sequencing among them, namely, there could be more events between them. Finally, the clause requires the data of the events to satisfy the necessary restrictions.
As we already mentioned, in this work we change the semantics used in [20, 9] to use events instead of positions, called it here event-based semantics. The old semantics of CEL, called position-based semantics, was obtained by outputting complex events of the form where a mapping such that . Namely, contains the positions of the events that participates in . One can easily see that the event-based semantics of CEL is equivalent to the position-based semantics where -th position must be replaced by the -th event of the stream. In other words, we have the following equivalence.
Theorem 3.
The (old) position-based semantics of CEL is equivalent to the (new) event-based semantics of CEL.
A formalization of the previous statement can be found in [8].
A new operator for projecting attributes.
An advantage of providing a new event-based semantics is that one can extend CEL with new operators, such as aggregation, which we will discuss in the next chapters. More interestingly, we can introduce new natural operators for managing complex events that cannot be defined using the old semantics in [20]. In this work, we use events instead of positions, which makes it possible to extend the CEL syntax with the attribute-projection operator, an operator for projecting tuples within complex events. Formally, we extend the syntax of CEL formulas with the following operator:
where is an arbitrary CEL formula, is a variable in , and is a list of attributes in . Intuitively, it means that it will only consider the attributes in in the events that are in the variable .
We define the formal semantics of the attribute-projection operator recursively as follows. For a list of attributes and an event , we define as the new event such that , , and whenever .
Let where each is an event. Then:
Intuitively, given a complex event with , the projection formula above creates a new complex event which has the same interval than and events in variables , but it redefines events in as .
4 Modelling aggregate functions in CER
Before introducing our logic for aggregation, we present a framework to model aggregate functions in CER based on monoids. Our goal is to present a logic that is as general as possible, encompassing most of the aggregations queries used in practice, such as , , , or . In the following, we recall the definitions of monoids and aggregate functions. We end by stating our main assumptions regarding aggregation in CER.
Monoids.
A monoid is an algebraic structure where forms a semigroup and is an identity element over . Similar to semigroups, we will further assume that is commutative. For example, the natural numbers with addition or with product form commutative monoids. Other examples are with and with . Given a commutative monoid , a finite bag and a function we define the operator: , namely, the generalization of from a binary operator to a set of elements. In particular, if , we define . In the sequel, we will use or for denoting arbitrary commutative monoid over some set .
Aggregate functions.
In this work, we consider the most general definition of an aggregate function that can be defined through a monoid (see [22]). Specifically, an aggregate function is a function from a bag of values to values, formally, for some set of values . An aggregate function is self-decomposable if there exists a commutative monoid111In [22], the definition of self-decomposable is not given in terms of a monoid. However, one can easily see that the definition in [22] implies the existence of a monoid. such that for every disjoint bags . Examples of functions that are self-decomposable are , , , and . For instance, is equal to if , to if , and to , otherwise. Similarly, is equal to if , to if , and to otherwise. Finally, is equal to if , to if , and otherwise.
Unfortunately, in practice not all aggregate function are self-decomposable; however, most of them can still be decomposed before we apply a simple operation. Formally, an aggregate function is called decomposable if there exist a function and a self-decomposable aggregate function such that . Furthermore, we assume that can be computed in constant time (i.e., in the RAM model). This last condition is necessary, as we want to perform a simple operation (i.e., constant time), as the final step after has completed the aggregation, and not to be powerful enough to perform the aggregation itself.
Every self-decomposable functions is also decomposable (i.e., where is the identity function). Other examples of aggregate functions that are decomposable (but not self-decomposable) are and . For instance, one can define as where and where is the standard pointwise sum of pairs, and . Another example is the which can be defined as such that , , and . In both cases, one can check that is a self-decomposable function and can be computed in constant time in the RAM model.
Notice that, although self-decomposable functions can be decomposed through a monoid, they are not entirely specified by it (e.g., ). Nevertheless, as the following lemma shows, we can restrict to monoids by first mapping the values to the underlying monoid.
Lemma 5.
is self-decomposable if, and only if, there exist a commutative monoid and a function such that for every bag .
Given the previous lemma, we say that is strong self-decomposable if there exists a pair such that is a commutative monoid and is the identity function. In other words, can be directly defined by a commutative monoid. The functions that are strong self-decomposable are , , and . On the other hand, needs to map each value to before adding them.
For the sake of simplification, in the following we assume that all aggregate functions are strong self-decomposable. In other words, we can directly define the semantics of the aggregate functions through a commutative monoids. We can make this assumption since the functions and (i.e., of decomposable aggregate functions) can be computed in constant time when the each data item is read or after the aggregation is done, like, for example, the function to map a single element to 1 (e.g., ), and the final function to calculate the difference between two elements (e.g., ), or divide one by the other (e.g., ). This assumption considerably simplifies our setting, allowing us to focus on the most relevant details of aggregation without discarding relevant aggregate functions from practice.
5 Aggregation complex event logic
In this section, we present our proposal to extend CEL with aggregation. Specifically, we demonstrate how to extend CEL with an operation for aggregations, building upon previous work experience. We provide examples of how this new operator is sufficient to model most queries used in earlier works. We start by introducing the algebraic structure for modelling aggregate functions, which we then use to define the aggregation operator in CEL.
The algebraic structure for aggregation.
Recall that and are our fix sets of attributes names and data values, respectively. We fix an algebraic structure:
over such that each forms a commutative monoid for every . For example, forms such an algebraic structure where we assume that for every . Without loss of generality, we assume that and for every and (if this is not the case, one can extend with a fresh value NULL). The purpose of NULL is to define the aggregation operator over events where an attribute is not defined (i.e., for some ).
The single-attribute aggregation operator.
Our goal is to extend the syntax of CEL with an aggregation operator that aggregates values in a single event. For the sake of presentation, we will first introduce the operation for a single attribute to then show how to extend it to multiple attributes.
Specifically, we extend the CEL syntax with the single-attribute aggregation operator, called Aggregation CEL (ACEL), as follows:
where is an arbitrary CEL formula, and are variables in , a and b are attributes names in , and is a binary operator from where forms a monoid. Intuitively, the syntax means that the aggregation will create a new event that will be stored at the variable , such that will have a single attribute b that stores the -aggregation of the a-attribute of events in . We define the formal semantics of the single aggregation operator recursively as follows. Let be a stream. Then:
Intuitively, given a complex event with , the aggregation formula above creates a new complex event which has the same interval and events than except that has an additional event (i.e., ) and . In case that , it will return the identity of . Further, the new event has , namely, the last time inside . Notice that the event is always well-defined, since we assume that, if a is not defined for some , it holds that and then .
In the following, we use some special notation for useful functions like , , instead of . For example, if we use the sum function, we write . Further, recall that, although we use commutative monoids to define the semantics, this semantics can easily be generalized to decomposable aggregate functions like , , or . Therefore, without loss of generality, we also write, for example, although strictly speaking is not a strong self-decomposable aggregate function.
Example 6.
Consider again the setting as in Examples 1 and 2. Now we are interested in getting the maximum price in a sequence of Intel sales between a Microsoft and an Amazon sale under the same constrains and store it in an attribute MAX in a variable . Then, we can specify this query by using the aggregation operator as:
As the reader can check from the semantics of , the max value in the intel sequence will be stored in a new event at the variable .
Example 7.
For a second example, suppose that now we are interested in getting the length of a sequence in a trend between prices 100 and 2000 and store it in an attribute QNT in a variable . Further, we want to also check that this length is greater than . Then, we can express the query as:
Notice that, although in the previous example the aggregation was applied over a simple CEL formula (i.e., at the topmost level), in ACEL all operators, including the aggregation operator, can be freely composed. In particular, we can apply a filter (e.g. ) over an aggregation that was computed.
The multi-attribute aggregation operator.
We present now the generalization of the aggregation operator to multiple attributes. Although this generalized version is more verbose, it is needed in practice for aggregating different sets simultaneously in different attributes. We extend the syntax of CEL with the (multi-attribute) aggregation operator:
where is an arbitrary CEL formula, and are variables in , and are attributes names in , and are binary operators from . Intuitively, the syntax states that the aggregation will create a new event with attributes that will be stored at the variable , such that each attribute will store the -aggregation of the -attribute of events in .
Given a stream , the formal semantics of the generalization of is given as follows:
Intuitively, the general version of allows to define several attributes by performing aggregation over the attributes , respectively. The idea is similar to the single-attribute aggregation operator but with several attributes at once.
In Appendix A (see also [8]), we show how to use ACEL to specify some examples from previous academic proposals and real-life systems. In particular, we present examples from the literature where the multi-attribute aggregation operator is required. Similar to the simple-attribute aggregation operator, in ACEL, one can freely compose all operators, including this new aggregation operator. We conclude this section by discussing several relevant design decisions we made in defining the aggregation operator in CEL.
Why this semantics for aggregation in CEL?
There are multiple ways to define a semantics for aggregation in CEL; however, our proposal for CEL and ACEL has some crucial design decisions that need to be justified. Specifically, we propose a semantics that (1) outputs a set of complex events (i.e., no repetitions), (2) each complex event contains bags of events, and (3) each event has a timestamp that defines the time when it arrives or was created. Indeed, we could consider other alternatives, such as a semantics that outputs bags of complex events, sets inside a complex event, or events without a timestamp, or any combination of these alternatives. In the following, we discuss why we proposed a semantics based on (1), (2), and (3), and what the consequences are of taking other alternatives.
For (1), if we choose a semantics based on bags of complex events, independent of the other choices, we will get a semantics that outputs duplicated results depending on how we specify the query. For example, assume a bag-based semantics and a user writes the query:
over a stream where and are the types of the events (i.e., the data in the attributes is not relevant). If we evaluate over with a bag-based semantics, we will have the same result multiple times (potentially exponentially many times) depending on how many were captured for each result. Instead, a set-based semantics ensures that each complex event appears only once, no matter how the query is specified.
For (2), if we choose that each variable inside a complex event maps to a set of events, instead of a bag of events, we could get some answers that do not consider some results as they will be taken as repeated elements. For example, if we consider a query:
and a stream , first we will get two matches (one from and the other from ), then we will make the aggregation in each of them, but the result of each aggregation is the same (i.e., ), they come from different values and they will not be saved as two different values, so finally the outer aggregation will be applied over one element and not two.
Finally, for (3), if we consider that each event that arrives or is created does not have a timestamp (i.e., a mark of origin), then we can still lose some information during aggregation (even if we used bags inside complex events to store events). For example, consider the query
for some subformulas and . For formula over some stream, the results of the aggregation in the left and right parts of the disjunction (i.e., ) could be equal, and it will be impossible to differentiate which part the aggregation is coming from when we apply the operator. Instead, by assuming that each event has a timestamp (even those created through aggregation), for , there will be at least two outputs, and we can differentiate the position where the aggregation was performed.
It is important to note that another semantics for CEL and the aggregation operator is possible, and our argument above does not invalidate them. However, there could be consequences for the query language with unintuitive behavior for the users. In this work, we have chosen to focus on a semantics based on (1), (2), and (3), studying its properties, and reserve the study of other variants of the logic for future work.
Expressive power of ACEL.
When introducing a new operator, such as aggregation, one wants it to model only what it is meant to; however, combining it with other operators can lead to unexpected properties that can be expressed. In particular, combining the aggregate operator with filters is very powerful, as it allows one to check equivalence between events. For example, consider the following query with aggregation and filtering:
Intuitively, the previous query checks that an event of type (naming it ) happens after an event of type (naming it ) and the values of attribute a in both events separately, saving those values in attributes and of variable in one event. Then, the query filters it by checking if the values of attributes and are equal, as they correspond to the same event. Finally, it projects variables and . One can see that the query correlates events from different types only using aggregation and filter operators over single events, as it generates two new variables in an event with the aggregation, that come from two different events, and then it uses filter which only is applied to a single event.
This unexpected behaviour of combining aggregation with filtering is an interesting side effect that could lead to a better understanding of aggregation in CER. Note that observing this interaction between aggregates, filters, and other operators will not be possible without having a concrete and formal semantics of the query language.
6 Automata model for aggregation in CER
Here we present an automata model for aggregation that extends complex event automata with registers similar to the model of cost register automata [4]. We start by recalling the model of complex event automata (CEA) to provide then the necessary definitions for introducing our new automata model for aggregation.
CEA.
A Complex Event Automaton (CEA) [20, 9] is a tuple where is a finite set of states, is a finite transition relation, is the initial state, and is the set of final states. A run of over stream from positions to is a sequence of transition:
such that is the initial state of and for every it holds that and . A run is accepting if . An accepting run of over from to naturally defines the complex event such that for every . If position and are clear from the context, we say that is a run of over . Finally, we define the semantics of over a stream as:
CEA was crucial to capture the expressiveness of CEL, compile queries from CEL into CEA, and efficiently evaluate them. Unfortunately, one can easily notice that CEA are not useful for our ACEL semantics, since there is no way to remember the values of the attributes that we have seen to do the aggregation. In other words, there is no mechanism for aggregating values and producing new events as in the new semantics of ACEL. We will show how to overcome these shortcomings in the next definitions.
Expressions.
Recall that is a fixed set of attributes and a fix set of data values. Further, recall that in Section 5 we fix an algebraic structure of the form () over such that each forms a commutative monoid for every . We define an -expression (or just expression) as a syntactical formula over and generated by the grammar:
where and . We define the set of all -expressions by . For any expression we denote by the set of all attributes in . Given an event and an expression such that , we define the semantics of over , denoted by , as the value in of evaluating by replacing every by .
Example 8.
Let , the expressions and , and an event where , and . Then the result of each expression and over the event are and , respectively.
Assignments.
An -assignment (or just assignment when and are clear from the context) is a program that assigns attributes in to expressions in . Formally, an assignment is defined as a mapping . Similar to expressions, we define to be all the attributes used in expressions of , and all the attributes that are assigned. Given an event and an -assignment such that , the semantics of an assignment over is an event such that and for every . In other words, is the result of applying the assignment with the values in the event . We denote the set of all -assignments by .
Example 9.
Consider again the setting of Example 8 and the assignment defined as: . Here, we think as a program where the left side of is updated with the right side, namely, . Then, .
Finally, we recall the notion of renamings (Section 3) and define updates of events that will be useful for our automata model. So, remember that a renaming is defined as , which maps each attribute to a new attribute. We can note that a renaming is also a particular case of an assignment such that . Also, recall that we define by the set of all tuple renaming over . Given events and , we define the update of by , denoted by , as a new event such that and if , and otherwise.
Aggregation Complex Event Automata.
We are ready to define the model of CEA with aggregation. An Aggregation Complex Event Automaton (ACEA) is a tuple where is a finite set of states, is the initial state, are the final states, and:
is a finite transition relation where is the set of all mappings that maps a variable to a finite bag of renamings . A transition specifies that can move from state to state after reading an event, by updating some internal registers with and checking a condition (over the registers) with . Similar to CEA, will be in charge of creating the outputs of the complex event where the renamings will create new tuples in the variable coming from the values stored in the internal registers. We assume that the renamings in for a transition of the form are consistent with , namely, for every .
A pair is a configuration of where and is an event which represents the current values of the attributes. For the sake of simplification, in ACEA, we use attributes as “registers” for storing temporary values. For this reason, the configuration represents that the automata is in the state and the registers (i.e., a subset of attributes) store the current computed values.
Let be a stream. A run of over stream from positions to is a sequence of configurations and transitions:
such that is the initial state , is the empty event (i.e., ), and for every , , is a configuration of with , and . Also, it must hold that . Intuitively, the new values are produced by first updating by the new event (i.e., ) and then operate by the assignment . After the new values are computed, we check if they satisfy the predicate of the transition.
Similar to CEA, a run is accepting if . An accepting run like () of over from to defines the complex event such that:
for every . Finally, we define the semantics of over a stream as:
Example 10.
Consider the ACEL query from Example 6. We can obtain the same result with the ACEA in Figure 2 where , and . Further, , and . Intuitively, in the first transition, initializes a register m (i.e., an attribute) with and checks that the price and name attributes satisfy the predicate , by storing the name in n and the price in p. Then, it waits in maintaining the registers. After, in the next transition it updates the maximum value in m with the new price and again checks that the name satisfies . Then, in the loop of , it repeats the same as the previous transition or it maintains the registers. Finally, in the last transition, it maintains the maximum value in m and verifies that the attributes name and price satisfy . The mappings , , and are in charge of outputting the events in variables , , and , respectively. Further, is in charge of producing the final event in variable that contains the max-aggregate of Intel’s prices.
A first natural question to answer is whether the expressive power of the new model ACEA includes queries defined by CEA or not. Similar to the question of ACEL versus CEL, CEA outputs complex events with positions, where our new model outputs complex events with events among other new features. Below, we show that a ACEA can define every CEA by mapping the positions of the stream to the events.
Theorem 11.
ACEA can define the same as CEA over streams over a schema , namely, for every CEA there exists an ACEA such that for every over .
Equivalence with ACEL.
The first main goal of this paper is to provide a query language with a formal and denotational semantics for performing aggregation in CER. The second main goal is to provide a computational model to compile queries from this language. In the following result, we show that ACEA is a computational model to fulfill this goal. Specifically, we show that every formula in ACEL can be compiled into a ACEA, proving that the model has all the feature to perform complex event extraction and aggregation.
Theorem 12.
Let be a schema. For every ACEL formula , there exists an ACEA such that for every stream over .
We present the proof in [8]. It goes by induction over the formula showing how to compile each operator into an ACEA. The standard CEL operators follow a similar construction to that in [20] (except the AND operator), but here we also have to make sure that the registers are correctly maintained to produce the output.
It is important to remark that ACEA is a hybrid automata model that needs to perform computation (i.e., for the aggregation), check filters (i.e., for the predicates), and produce outputs (i.e., events). Therefore, in designing the model, we seek an equilibrium that fulfills all these goals and, simultaneously, is as simple as possible. This simplicity could be helpful for understanding its expressiveness and designing efficient evaluation algorithms.
Despite its simplicity, ACEA has more expressive power than ACEL, namely, there are queries that can be defined with ACEA but not with ACEL. For example, consider the monoid of natural numbers (i.e., ). Given a stream , one can define an ACEA with one register that always doubles the current value and outputs its content in an event . Intuitively, ACEL with cannot specify this query since it can only produce values that grow linearly with respect to the sum of all values in the stream. Even if we restrict the use of registers in a copyless manner (see copyless cost register automaton in [4]), one can design ACEA that cannot be specified by ACEL. For instance, given the previous stream, one can code an ACEA that produces a complex event with the sequence of events: (i.e., by adding in a register the input values and outputting its content in each transition). Given that in ACEL, each value of an event can contribute to a finite number of new events, one cannot specify this in ACEL. Therefore, ACEA is more expressive than ACEL, and it is an interesting open problem to characterize ACEL in terms of restrictions over ACEA. We leave this problem for future work.
7 Future Work
This paper provides logical foundations for aggregation in CER but leaves several open problems for future work. One relevant open problem is to better understand the equivalence between ACEL and ACEA, namely, which ACEA can be written in ACEL. Another interesting question is to understand the expressive power of aggregation combined with filters and other operators (see Section 5). Finally, a crucial line of research for making ACEL work in practice is to study how to evaluate ACEL queries efficiently, finding enumeration algorithms that, given an ACEA and a stream, run with constant update time and constant delay enumeration.
References
- [1] Esper Enterprise Edition Website. https://www.espertech.com/, 2025. [Accessed 23-06-2025].
- [2] Asaf Adi and Opher Etzion. Amit-the situation manager. The VLDB journal, 13:177–203, 2004.
- [3] Alfred V Aho and John E Hopcroft. The design and analysis of computer algorithms. Pearson Education India, 1974.
- [4] Rajeev Alur, Loris D’Antoni, Jyotirmoy V. Deshmukh, Mukund Raghothaman, and Yifei Yuan. Regular functions and cost register automata. In LICS, pages 13–22, 2013. doi:10.1109/LICS.2013.65.
- [5] Alexander Artikis, Alessandro Margara, Martín Ugarte, Stijn Vansummeren, and Matthias Weidlich. Complex event recognition languages: Tutorial. In DEBS, pages 7–10. ACM, 2017. doi:10.1145/3093742.3095106.
- [6] Mikołaj Bojańczyk. Transducers with origin information. In ICALP, pages 26–37, 2014.
- [7] Kyle Bossonney, Nicolás Buzeta, Vicente Calisto, Juan-Eduardo López, Cristian Riveros, and Stijn Vansummeren. CORE+: A complex event recognition engine in C++. In SIGMOD demo, pages 47–50, 2025. doi:10.1145/3722212.3725090.
- [8] Pierre Bourhis, Cristian Riveros, and Amaranta Salas. A formal query language and automata model for aggregation in complex event recognition. CoRR, abs/2601.00967, 2026.
- [9] Marco Bucchi, Alejandro Grez, Andrés Quintana, Cristian Riveros, and Stijn Vansummeren. CORE: a complex event recognition engine. VLDB, 15(9):1951–1964, 2022. doi:10.14778/3538598.3538615.
- [10] Gianpaolo Cugola and Alessandro Margara. Raced: an adaptive middleware for complex event detection. In ARM, pages 1–6, 2009.
- [11] Gianpaolo Cugola and Alessandro Margara. TESLA: a formally defined event specification language. In DEBS, pages 50–61. ACM, 2010. doi:10.1145/1827418.1827427.
- [12] Gianpaolo Cugola and Alessandro Margara. Processing flows of information: From data stream to complex event processing. ACM Computing Surveys (CSUR), 44(3):1–62, 2012. doi:10.1145/2187671.2187677.
- [13] Alan J. Demers, Johannes Gehrke, Biswanath Panda, Mirek Riedewald, Varun Sharma, and Walker M. White. Cayuga: A general purpose event monitoring system. In CIDR, pages 412–422, 2007. URL: http://cidrdb.org/cidr2007/papers/cidr07p47.pdf.
- [14] Yanlei Diao, Neil Immerman, and Daniel Gyllstrom. SASE+: An agile language for kleene closure over event streams. UMass Technical Report, 2007.
- [15] Antony Galton and Juan Carlos Augusto. Two approaches to event definition. In DEXA, pages 547–556, 2002. doi:10.1007/3-540-46146-9_54.
- [16] Julián García and Cristian Riveros. Complex event recognition under time constraints: Towards a formal framework for efficient query evaluation. Proc. ACM Manag. Data, 3(2):94:1–94:17, 2025. doi:10.1145/3725231.
- [17] Nikos Giatrakos, Elias Alevizos, Alexander Artikis, Antonios Deligiannakis, and Minos Garofalakis. Complex event recognition in the big data era: a survey. The VLDB Journal, 29:313–352, 2020. doi:10.1007/S00778-019-00557-W.
- [18] Michel Grabisch, Jean-Luc Marichal, Radko Mesiar, and Endre Pap. Aggregation functions, volume 127. Cambridge University Press, 2009.
- [19] Alejandro Grez, Cristian Riveros, and Martín Ugarte. A formal framework for complex event processing. In ICDT, volume 127, pages 5:1–5:18, 2019. doi:10.4230/LIPIcs.ICDT.2019.5.
- [20] Alejandro Grez, Cristian Riveros, Martín Ugarte, and Stijn Vansummeren. A formal framework for complex event recognition. ACM TODS, 46(4):16:1–16:49, 2021. doi:10.1145/3485463.
- [21] Mikell P Groover. Automation, production systems, and computer-integrated manufacturing. Pearson Education India, 2016.
- [22] Paulo Jesus, Carlos Baquero, and Paulo Sérgio Almeida. A survey of distributed data aggregation algorithms. IEEE Communications Surveys & Tutorials, 17(1):381–404, 2014. doi:10.1109/COMST.2014.2354398.
- [23] Lei Ma, Chuan Lei, Olga Poppe, and Elke A Rundensteiner. Gloria: Graph-based sharing optimizer for event trend aggregation. In SIGMOD, pages 1122–1135, 2022. doi:10.1145/3514221.3526145.
- [24] Biswanath Mukherjee, L Todd Heberlein, and Karl N Levitt. Network intrusion detection. IEEE network, 8(3):26–41, 1994. doi:10.1109/65.283931.
- [25] Peter R Pietzuch, Brian Shand, and Jean Bacon. A framework for event composition in distributed systems. In Middleware, pages 62–82. Springer, 2003. doi:10.1007/3-540-44892-6_4.
- [26] Manolis Pitsikalis, Alexander Artikis, Richard Dreo, Cyril Ray, Elena Camossi, and Anne-Laure Jousselme. Composite event recognition for maritime monitoring. In DEBS, pages 163–174, 2019. doi:10.1145/3328905.3329762.
- [27] Olga Poppe, Chuan Lei, Lei Ma, Allison Rozet, and Elke A Rundensteiner. To share, or not to share online event trend aggregation over bursty event streams. In SIGMOD, pages 1452–1464, 2021. doi:10.1145/3448016.3452785.
- [28] Olga Poppe, Chuan Lei, Elke A. Rundensteiner, and David Maier. GRETA: graph-based real-time event trend aggregation. VLDB, 11(1):80–92, 2017. doi:10.14778/3151113.3151120.
- [29] Olga Poppe, Chuan Lei, Elke A Rundensteiner, and David Maier. Event trend aggregation under rich event matching semantics. In SIGMOD, pages 555–572, 2019. doi:10.1145/3299869.3319862.
- [30] BS Sahay and Jayanthi Ranjan. Real time business intelligence in supply chain analytics. Information Management & Computer Security, 16(1):28–48, 2008. doi:10.1108/09685220810862733.
- [31] Nicholas Poul Schultz-Møller, Matteo Migliavacca, and Peter Pietzuch. Distributed complex event processing with query rewriting. In DEBS, pages 1–12, 2009.
- [32] Luc Segoufin. Enumerating with constant delay the answers to a query. In ICDT, pages 10–20, 2013. doi:10.1145/2448496.2448498.
- [33] Walker White, Mirek Riedewald, Johannes Gehrke, and Alan Demers. What is “next” in event processing? In PODS, pages 263–272, 2007. doi:10.1145/1265530.1265567.
- [34] Eugene Wu, Yanlei Diao, and Shariq Rizvi. High-performance complex event processing over streams. In SIGMOD, pages 407–418, 2006. doi:10.1145/1142473.1142520.
- [35] Haopeng Zhang, Yanlei Diao, and Neil Immerman. On complexity and optimization of expensive queries in complex event processing. In SIGMOD, 2014.
- [36] Detlef Zimmer and Rainer Unland. On the semantics of complex events in active database management systems. In ICDE, pages 392–399, 1999. doi:10.1109/ICDE.1999.754955.
Appendix A Examples from practice
In the following, we present several queries obtained from the literature and show how to model them with ACEL. Given the operators introduced in the previous sections, recall that we define ACEL as any formula that uses the standard operators of CEL (Section 2), the aggregation operator (Section 5), or a combination of them. We start this section by introducing some new operators and predicates that work as syntax sugar for ACEL to define practical queries. Then we present three queries with aggregation obtained from three different CER proposals and specify them by using ACEL.
A.1 Useful operators in ACEL for specifying real-life queries
To specify CER queries in practice, the following operator will be useful. Let be any event type. We define the ACEL formula with CEL such that:
where we assume that can also be used as a variable name (i.e., ). In other words, finds the first event of -type in an interval and discard all other events in between. As an example, one can use this operator to succinctly define the CEL query that finds all -events directly followed by an event. We define this operator for its later use in examples appearing from other systems.
Let a be an attribute. We also define some auxiliary predicates that will be use with the operator to correlate two or more events. Recall that we define a predicate as a possibly infinite subset of events and we generalize from events to a multiset of events such that if, and only if, for every . For specifying queries in practice, we need some special multisets predicates that cannot be defined directly as a generalization of normal predicates. Formally, a multiset predicate is a subset of multisets of events, namely, . For example, the generalization of an (event) predicate to multisets of events is a multiset predicate. These multisets predicates defined below will allow us to (1) ensure that the pattern has the same value at attribute a, (2) the value of an attribute is increasing, or (3) the value of an attribute is decreasing, respectively. More specifically, we define the following three multiset predicates. For a multiset of events and two events , let be the logical formula that checks if is the successor of in , formally, and there does not exist such that and .
-
1.
We define the auxiliary predicate as:
-
2.
We define the auxiliary predicate as:
-
3.
Finally, we define the auxiliary predicate as:
Following ACEL syntax and semantics, we use the above predicates with variables in . For example, we write to define that all events in variable must satisfy . Similar as for standard predicates, we use conjunction and disjunction in as a syntax sugar for composing filters or using , respectively.
In the following we provide several examples from previous literature and how we can specify them by using ACEL.
Example 13.
We use as an example an adaptation of a query extracted from ESPER’s documentation [1], which says:
“This example statement demonstrates the idea by selecting a total price per customer over pairs of events (ServiceOrder followed by a ProductOrder event for the same customer id within 1 minute), occurring in the last 2 hours, in which the sum of price is greater than 100, and using a where clause to filter on name.”
The difference between this example and the original one is that we do not consider group-by, window and slide operators and a slightly different filter. The query in ESPER’s query language is the following:
Q13: SELECT a.custId, sum(a.price + b.price) FROM PATTERN [every a=ServiceOrder -> b=ProductOrder(custId = a.custId)] WHERE a.name in (b.name) HAVING sum(a.price + b.price) > 100
We can define Q2 by using ACEL as follows:
Example 14.
We use as an example an adaptation of query “” extracted from HAMLET’s paper [27, p. 1], which says
“All events in a trip must have the same driver and rider identifiers as required by the predicate [driver, rider] (…). Query tracks riders who cancel their accepted requests while the drivers were stuck in slow-moving traffic. All three queries contain the expensive Kleene sub-pattern T+ that matches arbitrarily long event trends.”
The difference between this example and the original one is that this does not considers within, slide and group-by operators.
Q14: RETURN T.district, COUNT(*), SUM(T.duration) PATTERN SEQ(Request R, Travel T+, Cancel C) WHERE [driver, rider]
A formula equivalent to the previous query in CEL with aggregation could be the following:
Example 15.
We use as an example an adaptation of the query “” extracted from COGRA’s paper [29, p. 1], which says:
“Query detects minimal and maximal heartbeat during passive physical activities (e.g., reading, watching TV). Query consumes a stream of heart rate measurements of intensive care patients. Each event carries a time stamp in seconds, a patient identifier, an activity identifier, and a heart rate. For each patient, detects contiguously increasing heart rate measurements during a time window of 10 minutes that slides every 30 seconds. No measurements may be skipped in between matched events per patient, as expressed by the contiguous semantics.”
The difference between this example and the original one is that this version does not considers within, group-by, and slide operators. The query is:
Q15: RETURN patient, MIN(M.rate), MAX(M.rate) PATTERN Measurement M+ SEMANTICS contiguous WHERE [patient] AND M.rate < NEXT(M).rate AND M.activity = passive
An ACEL formula equivalent to the previous query could be the following:
One can check that formula specifies the same query as Q3 with the difference is that has a formal and denotational semantics.
