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

Gyula Fora commented on FLINK-2283:
-----------------------------------

I understand your point but what I am trying to say that this operator is that 
this operator with it's current specification is not really a window operation. 
(because infinite window is not really a window)

State discard is clearly specified as never happening in this case, so there is 
no exiration like you would assume for a window operation. Increasing number of 
keys is a problem no matter how this is implemented, but this should be handled 
by the state backend and this should not be a real issue as inactive keys can 
be lazily retrieved when necessary.

So I think there are 2 questions here:

- Do we want to have an operator with the semantics of the current rolling 
group-reduce?
- If we do, how do we implement it?

For the first I don't see why not as the state limitation can be overcome by 
the state backend. For the second, why would we chose a windowed implementation 
when it only adds complexity over the trivial map implementation.

> Make grouped reduce/fold/aggregations stateful using Partitioned state
> ----------------------------------------------------------------------
>
>                 Key: FLINK-2283
>                 URL: https://issues.apache.org/jira/browse/FLINK-2283
>             Project: Flink
>          Issue Type: Improvement
>          Components: Streaming
>    Affects Versions: 0.10
>            Reporter: Gyula Fora
>            Assignee: Márton Balassi
>            Priority: Minor
>
> Currently the inner state of the grouped aggregations are not persisted as an 
> operator state. 
> These operators should be reimplemented to use the newly introduced 
> partitioned state abstractions which will make them fault tolerant and 
> scalable for the future.
> A suggested implementation would be to use a stateful mapper to implement the 
> desired behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to