flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-1293) Add support for out-of-place aggregations
Date Mon, 01 Dec 2014 14:25:12 GMT

    [ https://issues.apache.org/jira/browse/FLINK-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229829#comment-14229829

ASF GitHub Bot commented on FLINK-1293:

Github user fhueske commented on the pull request:

    Thanks for your pull request!
    Great piece of work. Well commented, plenty of tests, nice!
    Apart from Scala API support, there are several ways how this PR could be extended:
    1. Extend aggregation support for Flink's mutable value types (IntValue, DoubleValue,
...), i.e., sum() and avg() on numeric *Value types
    2. Add support for POJO data types and allowing aggregations of their members (output
would still be tuples). This would mean to extract the aggregation fields by name in the initial
Map operator.
    3. Do the aggregations internally on *Value types, which would mean to transform Java
Standard types into *Values in the first Map operator. This would reduce object allocations
and GC pressure. 
    The question is how much do we want to squeeze into this PR. 
    I'd say let's add support for Scala and treat the other issues as improvements over this
    @he-sk If you want to try the Scala API support, you could have a look at how the old
Aggregation operator was ported.

> Add support for out-of-place aggregations
> -----------------------------------------
>                 Key: FLINK-1293
>                 URL: https://issues.apache.org/jira/browse/FLINK-1293
>             Project: Flink
>          Issue Type: Improvement
>          Components: Java API, Scala API
>    Affects Versions: 0.7.0-incubating
>            Reporter: Viktor Rosenfeld
>            Assignee: Viktor Rosenfeld
>            Priority: Minor
> Currently, the output of an aggregation is of the same type as the input. This restriction
has to major drawbacks:
> 1. Every tuple field can only be used in one aggregation because the aggregations result
is stored in the field.
> 2. Aggregations having a return type that is different from the input type, e.g., count
or average, cannot be implemented.
> It would be nice to have the aggregation return any kind of tuple as a result, so the
restrictions above no longer apply.
> See also:
> - https://github.com/stratosphere/stratosphere/wiki/Design-of-Aggregate-Operator
> - http://apache-flink-incubator-mailing-list-archive.1008284.n3.nabble.com/Hi-Aggregation-support-td2311.html

This message was sent by Atlassian JIRA

View raw message