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 Fri, 08 Apr 2016 01:01:25 GMT


ASF GitHub Bot commented on BEAM-115:

GitHub user kennknowles opened a pull request:

    [BEAM-115] Move expansion of Window.Bound into particular runners

    As per the [Runner API design](
this makes `Window.into` very explicitly a primitive, and moves the subsidiary primitives
to top level classes in the `util/` (aka miscellaneous) directory, eventually to move to some
appropriate final location for "runner utilities" or to be removed entirely.

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

    $ git pull Window

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 #147
commit d944b5e724dbc372969d83820a450134a031a21a
Author: Kenneth Knowles <>
Date:   2016-04-08T00:34:19Z

    Move expansion of Window.Bound into particular runners
    In the Beam model, windowing is a primitive concept. The expansion provided
    by the SDK is not implementable except via access to privileged methods
    not intended for Beam pipeline authors.
    This change is a precursor to eliminating these privileged entirely.


> 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