Github user rtudoran commented on a diff in the pull request:
https://github.com/apache/flink/pull/3590#discussion_r107616671
--- Diff:
flink-libraries/flink-table/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala
---
@@ -119,6 +150,57 @@ class DataStreamOverAggregate(
}
+ def createTimeBoundedProcessingTimeOverWindow(inputDS: DataStream[Row]):
DataStream[Row] = {
+
+ val overWindow: Group = logicWindow.groups.get(0)
+ val partitionKeys: Array[Int] = overWindow.keys.toArray
+ val namedAggregates: Seq[CalcitePair[AggregateCall, String]] =
generateNamedAggregates
+
+ val index =
overWindow.lowerBound.getOffset.asInstanceOf[RexInputRef].getIndex
+ val count = input.getRowType().getFieldCount()
+ val lowerboundIndex = index - count
+
+
+ val time_boundary =
logicWindow.constants.get(lowerboundIndex).getValue2 match {
+ case _: java.math.BigDecimal =>
logicWindow.constants.get(lowerboundIndex)
+ .getValue2.asInstanceOf[java.math.BigDecimal].longValue()
+ case _ => throw new TableException("OVER Window boundaries must be
numeric")
+ }
+
+ // get the output types
+ val rowTypeInfo =
FlinkTypeFactory.toInternalRowTypeInfo(getRowType).asInstanceOf[RowTypeInfo]
+
+ val result: DataStream[Row] =
+ // partitioned aggregation
+ if (partitionKeys.nonEmpty) {
+
+ val processFunction =
AggregateUtil.CreateTimeBoundedProcessingOverProcessFunction(
+ namedAggregates,
+ inputType,
+ time_boundary)
+
+ inputDS
+ .keyBy(partitionKeys: _*)
+ .process(processFunction)
+ .returns(rowTypeInfo)
+ .name(aggOpName)
+ .asInstanceOf[DataStream[Row]]
+ } else { // non-partitioned aggregation
+ val processFunction =
AggregateUtil.CreateTimeBoundedProcessingOverProcessFunction(
--- End diff --
@fhueske @sunjincheng121 I saw the explanation for this and i do agree
that because we operate on long initially we deserialize less data. However,
When we deserialzie a blob versus deserializing multiple values the performance
should be at least comparable if not better. But even putting this aside, have
in mind the more general processing: of supporting distinct, sort operations
and selection based on sort (top, limit...). In that case if you loose the
order you need O(NLogN) every time to recompute it. I do not believe it is a
better design to have them in a hashmap....
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
