flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rtudoran <...@git.apache.org>
Subject [GitHub] flink pull request #3590: [FLINK-5654] - Add processing time OVER RANGE BETW...
Date Thu, 23 Mar 2017 15:14:02 GMT
Github user rtudoran commented on a diff in the pull request:

    --- 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 
    FYI i also tested the serialization. I have 3 cases
    1) serializing/deserializing independently 1M Long values
    It takes on a large memory server
    Serialization of 1M Longs1189
    DeSerialization of 1M Longs3174
    and on a small laptop
    Serialization of 1M Longs3038
    DeSerialization of 1M Longs9635
    2) serializing/deserializing  1M Long values all kept in a Queue
    It takes on a large memory server
    Serialization of blob263
    DeSerialization of blob161
    and on a small laptop
    Serialization of blob1498
    DeSerialization of blob435
    3) Serializing/Deserializing 1M Tuples10<Long,Long....> all kept in one queue
    On the server
    Serialization of blob with large Tuples7309
    DeSerialization of blob with large Tuples3569
    What we can conclude:
    1) Even if we do serialization on a Long, but on a lot of numbers it takes a large amount
of time
    2) It offers higher performance to keep these longs in one object (e.g. one queue and
we can still have the order)
    3) if we add to the MapState example also individual serialization/deserialization of
actual objects the time will become comparable or grater than serializing and deserializing
the wholle object structure as a whole.
    3) not to deserialize everything we can also keep the data into a MapState which we access
based on the order from the queue. What do you think?
    ...i believe this offers the highest performance but pays the price of keeping Long values

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 infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message