beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pei He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BEAM-696) Side-Inputs non-deterministic with merging main-input windows
Date Mon, 03 Oct 2016 23:00:25 GMT

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

Pei He commented on BEAM-696:
-----------------------------

For merging windows, DataflowPipelineRunner does "defer running anything that looks up the
combine side-input until it has grouped and merged windows".

For each fired pane, combine fn methods (such as addInput, mergeAccumulators, extractOutput)
will see the same side inputs. So, it is semantically consistent for CombineFns.

Still, it is non-deterministic, because non-merging windows' trigger firing is non-deterministic.

Action Item for me is "to clarify the semantic requirements for side inputs in CombineFns".

> Side-Inputs non-deterministic with merging main-input windows
> -------------------------------------------------------------
>
>                 Key: BEAM-696
>                 URL: https://issues.apache.org/jira/browse/BEAM-696
>             Project: Beam
>          Issue Type: Bug
>          Components: beam-model
>            Reporter: Ben Chambers
>            Assignee: Pei He
>
> Side-Inputs are non-deterministic for several reasons:
> 1. Because they depend on triggering of the side-input (this is acceptable because triggers
are by their nature non-deterministic).
> 2. They depend on the current state of the main-input window in order to lookup the side-input.
This means that with merging
> 3. Any runner optimizations that affect when the side-input is looked up may cause problems
with either or both of these.
> This issue focuses on #2 -- the non-determinism of side-inputs that execute within a
Merging WindowFn.
> Possible solution would be to defer running anything that looks up the side-input until
we need to extract an output, and using the main-window at that point. Specifically, if the
main-window is a MergingWindowFn, don't execute any kind of pre-combine, instead buffer all
the inputs and combine later.
> This could still run into some non-determinism if there are triggers controlling when
we extract output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message