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

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

Github user mxm commented on the pull request:

    https://github.com/apache/flink/pull/931#issuecomment-125979125
  
    Thanks for the pull request @zentol!
    
    +1 for removing the dill library. As far as I can see, we handle all the 
serialization ourselves now. We only used the Dill library to serialize the 
user-defined function alongside with the operator. Now, the operator is 
extracted from the plan which has been distributed in the Python files to the 
nodes beforehand. The plan is only send once to generate the Java execution 
plan. The old behavior was to serialize the operator, pass it to Java, and sent 
it back again during execution. Performance-wise the new implementation could 
even be a bit faster.
    
    +1 for explicitly passing the file paths. Java and Python have different 
ways to determine temporary file paths and this has been a problem in the 
passed on some platforms.
    
    Your changes are sensible and this looks to merge.
    
    Changes look sensible and good to me.


> [Py] Rework operator distribution
> ---------------------------------
>
>                 Key: FLINK-1927
>                 URL: https://issues.apache.org/jira/browse/FLINK-1927
>             Project: Flink
>          Issue Type: Improvement
>          Components: Python API
>    Affects Versions: 0.9
>            Reporter: Chesnay Schepler
>            Assignee: Chesnay Schepler
>            Priority: Minor
>             Fix For: 0.9
>
>
> Currently, the python operator is created when execution the python plan 
> file, serialized using dill and saved as a byte[] in the java function. It is 
> then deserialized at runtime on each node.
> The current implementation is fairly hacky, and imposes certain limitations 
> that make it hard to work with. Chaining, or generally saving other 
> user-code, always requires a separate deserialization step after 
> deserializing the operator.
> These issues can be easily circumvented by rebuilding the (python) plan on 
> each node, instead of serializing the operator. The plan creation is 
> deterministic, and every operator is uniquely identified by an ID that is 
> already known to the java function.
> This change will allow us to easily support custom serializers.



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

Reply via email to