[
https://issues.apache.org/jira/browse/FLINK-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938107#comment-15938107
]
ASF GitHub Bot commented on FLINK-5654:
---------------------------------------
Github user fhueske commented on the issue:
https://github.com/apache/flink/pull/3590
Thanks for the update @rtudoran. I haven't looked at the changes yet. Just
a few general remarks to your comments:
1. thanks!
2. we do not use tests which are based on manual timing of operations.
These tests are typically very fragile and take a lot of time. The test harness
I was pointing to solves this issue by controlling the processing time service
of the ProcessFunction, i.e., we can control the time. See how
[WindowOperatorTest#testProcessingTimeTumblingWindows()](https://github.com/apache/flink/blob/master/flink-streaming-java/src/test/java/org/apache/flink/streaming/runtime/operators/windowing/WindowOperatorTest.java#L1080)
controls processing time using the [KeyedOneInputStreamOperatorTestHarness](
https://github.com/apache/flink/blob/master/flink-streaming-java/src/test/java/org/apache/flink/streaming/util/KeyedOneInputStreamOperatorTestHarness.java).
3. Using `ValueState` has the overhead of always serializing and
deserializing all data. The actual access inside the deserialized data is
probably much less of an issue than the de/serialization + object
instantiations itself. With `MapState` we can get ordered access to elements by
accessing only the `Long` keys. This will also help for the operations you
mentioned.
4. In order to use `MapState` we would need to use the
`NullByteKeyExtractor` approach, since non-keyed operators only support
`ListState`
Best, Fabian
> Add processing time OVER RANGE BETWEEN x PRECEDING aggregation to SQL
> ---------------------------------------------------------------------
>
> Key: FLINK-5654
> URL: https://issues.apache.org/jira/browse/FLINK-5654
> Project: Flink
> Issue Type: Sub-task
> Components: Table API & SQL
> Reporter: Fabian Hueske
> Assignee: radu
>
> The goal of this issue is to add support for OVER RANGE aggregations on
> processing time streams to the SQL interface.
> Queries similar to the following should be supported:
> {code}
> SELECT
> a,
> SUM(b) OVER (PARTITION BY c ORDER BY procTime() RANGE BETWEEN INTERVAL '1'
> HOUR PRECEDING AND CURRENT ROW) AS sumB,
> MIN(b) OVER (PARTITION BY c ORDER BY procTime() RANGE BETWEEN INTERVAL '1'
> HOUR PRECEDING AND CURRENT ROW) AS minB
> FROM myStream
> {code}
> The following restrictions should initially apply:
> - All OVER clauses in the same SELECT clause must be exactly the same.
> - The PARTITION BY clause is optional (no partitioning results in single
> threaded execution).
> - The ORDER BY clause may only have procTime() as parameter. procTime() is a
> parameterless scalar function that just indicates processing time mode.
> - UNBOUNDED PRECEDING is not supported (see FLINK-5657)
> - FOLLOWING is not supported.
> The restrictions will be resolved in follow up issues. If we find that some
> of the restrictions are trivial to address, we can add the functionality in
> this issue as well.
> This issue includes:
> - Design of the DataStream operator to compute OVER ROW aggregates
> - Translation from Calcite's RelNode representation (LogicalProject with
> RexOver expression).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
