[jira] [Commented] (BEAM-115) Beam Runner API

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

GitHub user kennknowles opened a pull request:

    https://github.com/apache/incubator-beam/pull/662

    [BEAM-115] WIP: JSON Schema definition of pipeline

    This is a json-schema sketch of the concrete schema from the [Pipeline Runner API proposal document](https://s.apache.org/beam-runner-api). Because our [serialization tech discussion](http://mail-archives.apache.org/mod_mbox/beam-dev/201606.mbox/%3CCAN_Ypr2ZPQG3OgPWu==kF-zztG06k0v5i0AY3DABCHJyvEr9pA@mail.gmail.com%3E) seemed to favor JSON on the front end and Proto on the backend, I made this quick port. The original Avro IDL definition is also on [a branch with a test](https://github.com/kennknowles/incubator-beam/blob/pipeline-model/model/pipeline/src/main/avro/org/apache/beam/model/pipeline/pipeline.avdl).
    
    Notes & Caveats:
     - I did not try to flesh out any more details; this was a straight port. There's plenty to add, but a PR seems like a place that will attract a desired kind of concrete discussion even in the current state.
     - Typing this makes my hands hurt. Luckily, it should change exceedingly rarely. There are many libraries that can generate json-schema in various ways, including Jackson itself, but I'm not so sure any of them are applicable.
     - Reading this makes my eyes hurt. This is a real problem. We need a readable spec, not just a test suite for validation.
     - I am not so sure that [the schema library](https://github.com/daveclayton/json-schema-validator) I've used to build my smoke test is a good long term choice. I chose it because it was Jackson-based.
     - I've left comments in the JSON even though that is frowned upon, and taken advantage of Jackson's feature to allow them. They can also go into `"description"` fields.
     - Perhaps we could write YAML and convert to json-schema with no loss of precision?
    
    Feel free to leave comments here about the schema or meta issues of e.g. where the schema should live and what libraries we might want to use.

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

    $ git pull https://github.com/kennknowles/incubator-beam pipeline-json-schema

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

    https://github.com/apache/incubator-beam/pull/662.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 #662
    
----
commit c5843ce10e782056c76157169eb5516bf18ed9e4
Author: Kenneth Knowles <kl...@google.com>
Date:   2016-06-10T15:51:02Z

    WIP: add JSON Schema definition of pipeline

----


> Beam Runner API
> ---------------
>
>                 Key: BEAM-115
>                 URL: https://issues.apache.org/jira/browse/BEAM-115
>             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 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.4#6332)