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

ASF GitHub Bot commented on FLINK-2398:
---------------------------------------

Github user StephanEwen commented on the pull request:

    https://github.com/apache/flink/pull/988#issuecomment-128405914
  
    +1 for rebalancing automatically between operators of different DOP. The 
batch API does the same. But it should really be "rebalance", not a form of 
forward that typically creates skew.
    
    I am somewhat indifferent to the sink-or-no-sink question. The batch API 
requires sinks strictly, and it makes total sense there. For streaming, it may 
be different.
    
    If we require sinks, we should have a simple function `sink()` or so, which 
marks the operation as sink, so we don't force people to implement a 
*discarding sink* or so unnecessarily.


> Decouple StreamGraph Building from the API
> ------------------------------------------
>
>                 Key: FLINK-2398
>                 URL: https://issues.apache.org/jira/browse/FLINK-2398
>             Project: Flink
>          Issue Type: Improvement
>          Components: Streaming
>            Reporter: Aljoscha Krettek
>            Assignee: Aljoscha Krettek
>
> Currently, the building of the StreamGraph is very intertwined with the API 
> methods. DataStream knows about the StreamGraph and keeps track of splitting, 
> selected names, unions and so on. This leads to the problem that is is very 
> hard to understand how the StreamGraph is built because the code that does it 
> is all over the place. This also makes it hard to extend/change parts of the 
> Streaming system.
> I propose to introduce "Transformations". A transformation hold information 
> about one operation: The input streams, types, names, operator and so on. An 
> API method creates a transformation instead of fiddling with the StreamGraph 
> directly. A new component, the StreamGraphGenerator creates a StreamGraph 
> from the tree of transformations that result from program specification using 
> the API methods. This would relieve DataStream from knowing about the 
> StreamGraph and makes unions, splitting, selection visible transformations 
> instead of being scattered across the different API classes as fields.



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

Reply via email to