beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BEAM-115) Beam Runner API
Date Thu, 28 Apr 2016 23:19:12 GMT


ASF GitHub Bot commented on BEAM-115:

GitHub user kennknowles opened a pull request:

    [BEAM-115] Make in-process GroupByKey consistent with Beam model

    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](
    The commits in this PR stand individual but have strong dependencies. They each build
towards making the `InProcessPipelineRunner` correspond to the intended runner API / Beam

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

    $ git pull InProcessGroupByKey

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

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

    This closes #262
commit 6f3eeb4fada9fa72763980f26af8949141dbbe51
Author: Kenneth Knowles <>
Date:   2016-04-28T22:50:32Z

    Add WindowMatchers.isWindowedValue(<value matcher>)

commit 34ec15d6a5923287f4db0db63083c37b87c030b7
Author: Kenneth Knowles <>
Date:   2016-04-28T22:51:40Z

    Add accessors for sub-coders of KeyedWorkItemCoder

commit 91643088f4032898cf67973b032d86a528eca199
Author: Kenneth Knowles <>
Date:   2016-04-28T23:12:21Z

    Encapsulate cloning behavior of in-process ParDo evaluator
    This will make way for using the evluator in contexts where cloning
    is not appropriate, such as evaluator GroupAlsoByWindow

commit 753787ff0eb10c524f336e9af837ed442f005121
Author: Kenneth Knowles <>
Date:   2016-04-28T23:13:24Z

    Make in-process GroupByKey respect future Beam model
    This introduces top-level classes:
     - InProcessGroupByKey, which expands like GroupByKeyViaGroupByKeyOnly
       but with different intermediate PCollection types.
     - InProcessGroupByKeyOnly, which outputs KeyedWorkItem<K, V>. This existed
       already under a different name.
     - InProcessGroupAlsoByWindow, which is evaluated directly and
       accepts input elements of type KeyedWorkItem<K, V>.


> Beam Runner API
> ---------------
>                 Key: BEAM-115
>                 URL:
>             Project: Beam
>          Issue Type: Improvement
>          Components: runner-core
>            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
>  - 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

View raw message