Have you considered the sliding window, which is already part of standard SQL? We propose to support it in streaming SQL also. Here is an example:
SELECT orderId, price, AVG(price) OVER (ORDER BY orderTime ROWS 5 PRECEDING) FROM Orders (This is a non-streaming query, but you can add the STREAM keyword to get a streaming query.) Given orders 1 .. 20, then order 10 would show the average for orders 5 .. 10 inclusive, order 11 would show the average for orders 6 .. 11, and so forth. In streaming queries, windows are often used in the GROUP BY clause, but we do not use a GROUP BY here. The OVER clause with sliding windows does not aggregate rows. If 20 rows come in, then 20 rows go out. It makes sense, because each row cannot have its own window if multiple rows are squashed into one. Julian > On Sep 26, 2016, at 12:53 AM, Radu Tudoran <[email protected]> wrote: > > Hi, > > First of all let me introduce myself - My name is Radu Tudoran and I am > working in the field of Big Data processing with a high focus on streaming > and more recently in the area of SQL. > > I wanted to raise a question/proposal for discussion in the community: > > Based on our requirements I realized that I would need to create a window > (e.g. hop window) that would move on every incoming element based. The syntax > that I have in mind for it is > > HOP(column_name, # EVENT , INTERVAL # ) (or should it rather be # ELEMENT > instead of EVENT?) > > I wanted to check with you what do you think about such a grammar to go > directly in Calcite? I think it is relevant for streaming scenarios where you > do not necessary have events coming at regular time interval but you would > still like to react on every event. > As an example you can consider a stock market application where you would > always compute for every new offer the average over the last hour. > > Best regards,
