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

ASF GitHub Bot commented on BEAM-115:
-------------------------------------

GitHub user kennknowles opened a pull request:

    https://github.com/apache/beam/pull/1946

    [BEAM-115] Add proto definition for Runner API

    Be sure to do all of the following to help us incorporate your contribution
    quickly and easily:
    
     - [x] Make sure the PR title is formatted like:
       `[BEAM-<Jira issue #>] Description of pull request`
     - [x] Make sure tests pass via `mvn clean verify`. (Even better, enable
           Travis-CI on your fork and ensure the whole test matrix passes).
     - [x] Replace `<Jira issue #>` in the title with the actual Jira issue
           number, if there is one.
     - [x] If this contribution is large, please file an Apache
           [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.txt).
    
    ---
    
    These are the protocol buffers definitions corresponding to the Avro schema 
proposed in https://s.apache.org/beam-runner-api.
    
    Differences from the schema there:
    
     - Graph structure is decoupled from what data annotations the nodes
     - Adopted names from the Fn API's proto for things that overlap
     - Added explicit URNs and payloads for primitives
     - Added outline of state and timers
     - Added Environment URLs
    
    I would like to merge this and separately port the Fn API to use shared 
structures as appropriate, since that may involve more extensive coding work.
    
    Unlike #662, this is _not_ a WIP just for discussion. This is intended for 
immediate use as the serialization format for various pieces of the pipeline to 
unblock work on the Fn API.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/kennknowles/beam pipeline-proto

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/beam/pull/1946.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1946
    
----
commit 7bdd2869053bd3af7afdf68e36e1d54f868419ae
Author: Kenneth Knowles <k...@google.com>
Date:   2017-02-07T23:25:32Z

    Add proto definition for Runner API

----


> Beam Runner API
> ---------------
>
>                 Key: BEAM-115
>                 URL: https://issues.apache.org/jira/browse/BEAM-115
>             Project: Beam
>          Issue Type: Improvement
>          Components: beam-model-runner-api
>            Reporter: Kenneth Knowles
>            Assignee: Kenneth Knowles
>
> The PipelineRunner API from the SDK is not ideal for the Beam technical 
> vision.
> It has technical limitations:
>  - The user's DAG (even including library expansions) is never explicitly 
> represented, so it cannot be analyzed except incrementally, and cannot 
> necessarily be reconstructed (for example, to display it!).
>  - The flattened DAG of just primitive transforms isn't well-suited for 
> display or transform override.
>  - The TransformHierarchy isn't well-suited for optimizations.
>  - The user must realistically pre-commit to a runner, and its configuration 
> (batch vs streaming) prior to graph construction, since the runner will be 
> modifying the graph as it is built.
>  - It is fairly language- and SDK-specific.
> It has usability issues (these are not from intuition, but derived from 
> actual cases of failure to use according to the design)
>  - The interleaving of apply() methods in PTransform/Pipeline/PipelineRunner 
> is confusing.
>  - The TransformHierarchy, accessible only via visitor traversals, is 
> cumbersome.
>  - The staging of construction-time vs run-time is not always obvious.
> These are just examples. This ticket tracks designing, coming to consensus, 
> and building an API that more simply and directly supports the technical 
> vision.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to