Calcite has extended SQL and relational algebra in order to support streaming queries.
- An example schema
- A simple query
- Filtering rows
- Projecting expressions
- Tumbling windows
- Tumbling windows, improved
- Hopping windows
- GROUPING SETS
- Filtering after aggregation
- Sub-queries, views and SQL’s closure property
- Converting between streams and relations
- The “pie chart” problem: Relational queries on streams
- Table constructor
- Sliding windows
- Cascading windows
- Joining streams to tables
- Joining streams to streams
- State of the stream
Streams are collections to records that flow continuously, and forever. Unlike tables, they are not typically stored on disk, but flow over the network and are held for short periods of time in memory.
Streams complement tables because they represent what is happening in the present and future of the enterprise whereas tables represent the past. It is very common for a stream to be archived into a table.
Like tables, you often want to query streams in a high-level language based on relational algebra, validated according to a schema, and optimized to take advantage of available resources and algorithms.
Calcite’s SQL is an extension to standard SQL, not another ‘SQL-like’ language. The distinction is important, for several reasons:
- Streaming SQL is easy to learn for anyone who knows regular SQL.
- The semantics are clear, because we aim to produce the same results on a stream as if the same data were in a table.
- You can write queries that combine streams and tables (or the history of a stream, which is basically an in-memory table).
- Lots of existing tools can generate standard SQL.
If you don’t use the
STREAM keyword, you are back in regular
An example schema
Our streaming SQL examples use the following schema:
Orders (rowtime, productId, orderId, units)- a stream and a table
Products (rowtime, productId, name)- a table
Shipments (rowtime, orderId)- a stream
A simple query
Let’s start with the simplest streaming query:
This query reads all columns and rows from the
Like any streaming query, it never terminates. It outputs a record whenever
a record arrives in
Control-C to terminate the query.
STREAM keyword is the main extension in streaming SQL. It tells the
system that you are interested in incoming orders, not existing ones. The query
is also valid, but will print out all existing orders and then terminate. We call it a relational query, as opposed to streaming. It has traditional SQL semantics.
Orders is special, in that it has both a stream and a table. If you try to run
a streaming query on a table, or a relational query on a stream, Calcite gives
Just as in regular SQL, you use a
WHERE clause to filter rows:
Use expressions in the
SELECT clause to choose which columns to return or
We recommend that you always include the
rowtime column in the
clause. Having a sorted timestamp in each stream and streaming query makes it
possible to do advanced calculations later, such as
GROUP BY and
There are several ways to compute aggregate functions on streams. The differences are:
- How many rows come out for each row in?
- Does each incoming value appear in one total, or more?
- What defines the “window”, the set of rows that contribute to a given output row?
- Is the result a stream or a relation?
There are various window types:
- tumbling window (GROUP BY)
- hopping window (multi GROUP BY)
- sliding window (window functions)
- cascading window (window functions)
and the following diagram shows the kinds of query in which to use them:
First we’ll look a tumbling window, which is defined by a streaming
GROUP BY. Here is an example:
The result is a stream. At 11 o’clock, Calcite emits a sub-total for every
productId that had an order since 10 o’clock, timestamped 11 o’clock.
At 12 o’clock, it will emit
the orders that occurred between 11:00 and 12:00. Each input row contributes to
only one output row.
How did Calcite know that the 10:00:00 sub-totals were complete at 11:00:00,
so that it could emit them? It knows that
rowtime is increasing, and it knows
CEIL(rowtime TO HOUR) is also increasing. So, once it has seen a row
at or after 11:00:00, it will never see a row that will contribute to a 10:00:00
A column or expression that is increasing or decreasing is said to be monotonic.
If column or expression has values that are slightly out of order, and the stream has a mechanism (such as punctuation or watermarks) to declare that a particular value will never be seen again, then the column or expression is said to be quasi-monotonic.
Without a monotonic or quasi-monotonic expression in the
GROUP BY clause,
not able to make progress, and it will not allow the query:
Monotonic and quasi-monotonic columns need to be declared in the schema.
The monotonicity is
enforced when records enter the stream and assumed by queries that read from
that stream. We recommend that you give each stream a timestamp column called
rowtime, but you can declare others to be monotonic,
orderId, for example.
We discuss punctuation, watermarks, and other ways of making progress below.
Tumbling windows, improved
The previous example of tumbling windows was easy to write because the window
was one hour. For intervals that are not a whole time unit, say 2 hours or
2 hours and 17 minutes, you cannot use
CEIL, and the expression gets more
Calcite supports an alternative syntax for tumbling windows:
As you can see, it returns the same results as the previous query. The
function returns a grouping key that is the same for all the rows that will end
up in a given summary row; the
TUMBLE_END function takes the same arguments
and returns the time at which that window ends;
there is also a
TUMBLE has an optional parameter to align the window.
In the following example,
we use a 30 minute interval and 0:12 as the alignment time,
so the query emits summaries at 12 and 42 minutes past each hour:
Hopping windows are a generalization of tumbling windows that allow data to be kept in a window for a longer than the emit interval.
For example, the following query emits a row timestamped 11:00 containing data from 08:00 to 11:00 (or 10:59.9 if we’re being pedantic), and a row timestamped 12:00 containing data from 09:00 to 12:00.
In this query, because the retain period is 3 times the emit period, every input
row contributes to exactly 3 output rows. Imagine that the
generates a collection of group keys for incoming row, and places its values
in the accumulators of each of those group keys. For example,
HOP(10:18:00, INTERVAL '1' HOUR, INTERVAL '3') generates 3 periods
This raises the possibility of allowing user-defined partitioning functions
for users who are not happy with the built-in functions
We can build complex complex expressions such as an exponentially decaying moving average:
- a row at
11:00:00containing rows in
- a row at
11:00:01containing rows in
The expression weighs recent orders more heavily than older orders. Extending the window from 1 hour to 2 hours or 1 year would have virtually no effect on the accuracy of the result (but use more memory and compute).
Note that we use
HOP_START inside an aggregate function (
SUM) because it
is a value that is constant for all rows within a sub-total. This
would not be allowed for typical aggregate functions (
If you are familiar with
GROUPING SETS, you may notice that partitioning
functions can be seen as a generalization of
GROUPING SETS, in that they
allow an input row to contribute to multiple sub-totals.
The auxiliary functions for
can be used inside aggregate functions, so it is not surprising that
HOP_END can be used in the same way.
GROUPING SETS is valid for a streaming query provided that every
grouping set contains a monotonic or quasi-monotonic expression.
ROLLUP are not valid for streaming query, because they will
produce at least one grouping set that aggregates everything (like
GROUP BY ()).
Filtering after aggregation
As in standard SQL, you can apply a
HAVING clause to filter rows emitted by
Sub-queries, views and SQL’s closure property
HAVING query can be expressed using a
WHERE clause on a
HAVING was introduced in the early days of SQL, when a way was needed to
perform a filter after aggregation. (Recall that
WHERE filters rows before
they enter the
GROUP BY clause.)
Since then, SQL has become a mathematically closed language, which means that any operation you can perform on a table can also perform on a query.
The closure property of SQL is extremely powerful. Not only does it render
HAVING obsolete (or, at least, reduce it to syntactic sugar), it makes views
Sub-queries in the
FROM clause are sometimes referred to as “inline views”,
but really, they are more fundamental than views. Views are just a convenient
way to carve your SQL into manageable chunks by giving the pieces names and
storing them in the metadata repository.
Many people find that nested queries and views are even more useful on streams than they are on relations. Streaming queries are pipelines of operators all running continuously, and often those pipelines get quite long. Nested queries and views help to express and manage those pipelines.
And, by the way, a
WITH clause can accomplish the same as a sub-query or
Converting between streams and relations
Look back at the definition of the
Is the view a stream or a relation?
It does not contain the
STREAM keyword, so it is a relation.
However, it is a relation that can be converted into a stream.
You can use it in both relational and streaming queries:
This approach is not limited to views and sub-queries.
Following the approach set out in CQL , every query
in streaming SQL is defined as a relational query and converted to a stream
STREAM keyword in the top-most
STREAM keyword is present in sub-queries or view definitions, it has no
At query preparation time, Calcite figures out whether the relations referenced in the query can be converted to streams or historical relations.
Sometimes a stream makes available some of its history (say the last 24 hours of data in an Apache Kafka  topic) but not all. At run time, Calcite figures out whether there is sufficient history to run the query, and if not, gives an error.
The “pie chart” problem: Relational queries on streams
One particular case where you need to convert a stream to a relation occurs in what I call the “pie chart problem”. Imagine that you need to write a web page with a chart, like the following, that summarizes the number of orders for each product over the last hour.
Orders stream only contains a few records, not an hour’s summary.
We need to run a relational query on the history of the stream:
If the history of the
Orders stream is being spooled to the
we can answer the query, albeit at a high cost. Better, if we can tell the
system to materialize one hour summary into a table,
maintain it continuously as the stream flows,
and automatically rewrite queries to use the table.
The story for
ORDER BY is similar to
The syntax looks like regular SQL, but Calcite must be sure that it can deliver
timely results. It therefore requires a monotonic expression on the leading edge
ORDER BY key.
Most queries will return results in the order that they were inserted, because the engine is using streaming algorithms, but you should not rely on it. For example, consider this:
The rows with
productId = 30 are apparently out of order, probably because
Orders stream was partitioned on
productId and the partitioned streams
sent their data at different times.
If you require a particular ordering, add an explicit
Calcite will probably implement the
UNION ALL by merging using
which is only slightly less efficient.
You only need to add an
ORDER BY to the outermost query. If you need to,
GROUP BY after a
UNION ALL, Calcite will add an
implicitly, in order to make the GROUP BY algorithm possible.
VALUES clause creates an inline table with a given set of rows.
Streaming is disallowed. The set of rows never changes, and therefore a stream would never return any rows.
Standard SQL features so-called “analytic functions” that can be used in the
SELECT clause. Unlike
GROUP BY, these do not collapse records. For each
record that goes in, one record comes out. But the aggregate function is based
on a window of many rows.
Let’s look at an example.
The feature packs a lot of power with little effort. You can have multiple
functions in the
SELECT clause, based on multiple window specifications.
The following example returns orders whose average order size over the last 10 minutes is greater than the average order size for the last week.
For conciseness, here we use a syntax where you partially define a window
WINDOW clause and then refine the window in each
You could also define all windows in the
WINDOW clause, or all windows inline,
if you wish.
But the real power goes beyond syntax. Behind the scenes, this query is maintaining two tables, and adding and removing values from sub-totals using with FIFO queues. But you can access those tables without introducing a join into the query.
Some other features of the windowed aggregation syntax:
- You can define windows based on row count.
- The window can reference rows that have not yet arrived. (The stream will wait until they have arrived).
- You can compute order-dependent functions such as
What if we want a query that returns a result for every record, like a sliding window, but resets totals on a fixed time period, like a tumbling window? Such a pattern is called a cascading window. Here is an example:
It looks similar to a sliding window query, but the monotonic
expression occurs within the
PARTITION BY clause of the window. As
the rowtime moves from from 10:59:59 to 11:00:00,
FLOOR(rowtime TO HOUR) changes from 10:00:00 to 11:00:00,
and therefore a new partition starts.
The first row to arrive in the new hour will start a
new total; the second row will have a total that consists of two rows,
and so on.
Calcite knows that the old partition will never be used again, so removes all sub-totals for that partition from its internal storage.
Analytic functions that using cascading and sliding windows can be combined in the same query.
Joining streams to tables
There are two kinds of join where streams are concerned: stream-to-table join and stream-to-stream join.
A stream-to-table join is straightforward if the contents of the table are not changing. This query enriches a stream of orders with each product’s list price:
What should happen if the table is changing? For example, suppose the unit price of product 10 is increased to 0.35 at 11:00. Orders placed before 11:00 should have the old price, and orders placed after 11:00 should reflect the new price.
One way to implement this is to have a table that keeps every version
with a start and end effective date,
ProductVersions in the following
The other way to implement this is to use a database with temporal support
(the ability to find the contents of the database as it was at any moment
in the past), and the system needs to know that the
rowtime column of
Orders stream corresponds to the transaction timestamp of the
For many applications, it is not worth the cost and effort of temporal support or a versioned table. It is acceptable to the application that the query gives different results when replayed: in this example, on replay, all orders of product 10 are assigned the later unit price, 0.35.
Joining streams to streams
It makes sense to join two streams if the join condition somehow forces them to remain a finite distance from one another. In the following query, the ship date is within one hour of the order date:
Note that quite a few orders do not appear, because they did not ship within an hour. By the time the system receives order 10, timestamped 11:24:11, it has already removed orders up to and including order 8, timestamped 10:18:07, from its hash table.
As you can see, the “lock step”, tying together monotonic or quasi-monotonic columns of the two streams, is necessary for the system to make progress. It will refuse to execute a query if it cannot deduce a lock step.
It’s not only queries that make sense against streams;
it also makes sense to run DML statements (
and also their rarer cousins
REPLACE) against streams.
DML is useful because it allows you do materialize streams or tables based on streams, and therefore save effort when values are used often.
Consider how streaming applications often consist of pipelines of queries, each query transforming input stream(s) to output stream(s). The component of a pipeline can be a view:
or a standing
These look similar, and in both cases the next step(s) in the pipeline
can read from
LargeOrders without worrying how it was populated.
There is a difference in efficiency: the
INSERT statement does the
same work no matter how many consumers there are; the view does work
proportional to the number of consumers, and in particular, does no
work if there are no consumers.
Other forms of DML make sense for streams. For example, the following
UPSERT statement maintains a table that materializes a summary
of the last hour of orders:
Punctuation allows a stream query to make progress even if there are not enough values in a monotonic key to push the results out.
(I prefer the term “rowtime bounds”, and watermarks are a related concept, but for these purposes, punctuation will suffice.)
If a stream has punctuation enabled then it may not be sorted but is nevertheless sortable. So, for the purposes of semantics, it is sufficient to work in terms of sorted streams.
By the way, an out-of-order stream is also sortable if it is t-sorted (i.e. every record is guaranteed to arrive within t seconds of its timestamp) or k-sorted (i.e. every record is guaranteed to be no more than k positions out of order). So queries on these streams can be planned similarly to queries on streams with punctuation.
And, we often want to aggregate over attributes that are not time-based but are nevertheless monotonic. “The number of times a team has shifted between winning-state and losing-state” is one such monotonic attribute. The system needs to figure out for itself that it is safe to aggregate over such an attribute; punctuation does not add any extra information.
I have in mind some metadata (cost metrics) for the planner:
- Is this stream sorted on a given attribute (or attributes)?
- Is it possible to sort the stream on a given attribute? (For finite relations, the answer is always “yes”; for streams it depends on the existence of punctuation, or linkage between the attributes and the sort key.)
- What latency do we need to introduce in order to perform that sort?
- What is the cost (in CPU, memory etc.) of performing that sort?
We already have (1), in BuiltInMetadata.Collation. For (2), the answer is always “true” for finite relations. But we’ll need to implement (2), (3) and (4) for streams.
State of the stream
The following features are presented in this document as if Calcite supports them, but in fact it does not (yet). Full support means that the reference implementation supports the feature (including negative cases) and the TCK tests it.
- Stream on view
- Relational query on stream
- Streaming windowed aggregation (sliding and cascading windows)
- Check that
STREAMin sub-queries and views is ignored
- Check that streaming
ORDER BYcannot have
- Limited history; at run time, check that there is sufficient history to run the query.
To do in this document
- Re-visit whether you can stream
OVERclause to define window on stream
- Consider whether to allow
ROLLUPin streaming queries, with an understanding that some levels of aggregation will never complete (because they have no monotonic expressions) and thus will never be emitted.
- Fix the
UPSERTexample to remove records for products that have not occurred in the last hour.
- DML that outputs to multiple streams; perhaps an extension to the standard
The following functions are not present in standard SQL but are defined in streaming SQL.
FLOOR(dateTime TO intervalType)rounds a date, time or timestamp value down to a given interval type
CEIL(dateTime TO intervalType)rounds a date, time or timestamp value up to a given interval type
HOP(t, emit, retain)returns a collection of group keys for a row to be part of a hopping window
HOP(t, emit, retain, align)returns a collection of group keys for a row to be part of a hopping window with a given alignment
TUMBLE(t, emit)returns a group key for a row to be part of a tumbling window
TUMBLE(t, emit, align)returns a group key for a row to be part of a tumbling window with a given alignment
TUMBLE(t, e) is equivalent to
TUMBLE(t, e, TIME '00:00:00').
TUMBLE(t, e, a) is equivalent to
HOP(t, e, e, a).
HOP(t, e, r) is equivalent to
HOP(t, e, r, TIME '00:00:00').
-  Arvind Arasu, Shivnath Babu, and Jennifer Widom (2003) The CQL Continuous Query Language: Semantic Foundations and Query Execution.
-  Apache Kafka.
-  Apache Samza.
-  SamzaSQL.
-  Peter A. Tucker, David Maier, Tim Sheard, and Leonidas Fegaras (2003) Exploiting Punctuation Semantics in Continuous Data Streams.
-  Tyler Akidau, Alex Balikov, Kaya Bekiroglu, Slava Chernyak, Josh Haberman, Reuven Lax, Sam McVeety, Daniel Mills, Paul Nordstrom, and Sam Whittle (2013) MillWheel: Fault-Tolerant Stream Processing at Internet Scale.