Mailing-List: contact commits-help@beam.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@beam.apache.org
Date: Fri, 24 Feb 2017 02:10:45 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: commits@beam.incubator.apache.org
Message-ID: <JIRA.12950173.1458016224000.50594.1487902245123@Atlassian.JIRA>
In-Reply-To: <JIRA.12950173.1458016224000@Atlassian.JIRA>
References: <JIRA.12950173.1458016224000@Atlassian.JIRA> <JIRA.12950173.1458016224596@jira-lw-us.apache.org>
Subject: [jira] [Commented] (BEAM-115) Beam Runner API
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 24 Feb 2017 02:10:52 -0000


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

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

GitHub user kennknowles opened a pull request:

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

    [BEAM-115] Concretize generic bits of the Runner API graph structure

    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).
    
    ---
    
    R: @dhalperi @robertwb 
    
    This gets rid of the excessive generic design of `GraphNode` and restores it to the original design wherein each node is a `PTransform`. I have also merged the `bytes` of the SDK-specific data and the `Any` that is SDK-independent data, since as has been pointed out we won't need both.

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

    $ git pull https://github.com/kennknowles/beam inline-runner-api

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

    https://github.com/apache/beam/pull/2094.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 #2094
    
----
commit cc46d194cacbfb2244fde837f01b2ba0f2cedcdb
Author: Kenneth Knowles <klk@google.com>
Date:   2017-02-24T01:51:10Z

    Inline PTransform to GraphNode, removing generic design
    
    The GraphNode structure was made more generic to allow the Runner API
    and Fn API to share the graph data structure while carrying distinct
    payloads on nodes and edges. It seems that the Runner API was already
    sufficiently flexible for the Fn API to use its existing payload
    design.

commit 47289b5bc3a452e2866fb6515b55c7ef5d2835a8
Author: Kenneth Knowles <klk@google.com>
Date:   2017-02-24T02:06:56Z

    Condense FunctionSpec, merging data and params

----


> 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)