beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Knowles (JIRA)" <>
Subject [jira] [Commented] (BEAM-854) ReifyTimestampAndWindows explodes windows
Date Thu, 27 Oct 2016 23:03:59 GMT


Kenneth Knowles commented on BEAM-854:

Ah, my mistake. You are correct. This needlessly harms performance for the first {{GBK}} after
{{Window.into(SlidingWindows)}} (and similar).

The former is the better approach.  A semantic element exists within a single window. The
compressed representation is an implementation detail. We don't need a new primitive; it can
be folded into the semantics of GBKO.

The latter violates/alters the Beam model with broad consequences - pathological computations
based on the set of windows, runner being unable to transparently explode/not explode as it
pleases, elements in zero windows. And I conjecture that any DoFn that respects the model
is as efficiently executed when looping over the windows is lifted outside {{@ProcessElement}}.

We should talk about how and why this impacts SDF.

> ReifyTimestampAndWindows explodes windows
> -----------------------------------------
>                 Key: BEAM-854
>                 URL:
>             Project: Beam
>          Issue Type: Bug
>            Reporter: Eugene Kirpichov
>            Assignee: Kenneth Knowles
> Commit
changed the fn from accessing the collection of windows to accessing the windows one-by-one,
which causes this DoFn to explode them, which (I suppose) hurts performance, since this Fn
is quite important: it's a part of GroupByKey in the Spark runner and Direct runner, part
of Splittable DoFn, part of GBKViaGBKO, and part of GatherAllPanes.
> I can see a couple of ways to fix this:
> - Make this be a primitive transform, with runner-specific support to keep the windows
> - Allow any DoFn to access the compressed representation explicitly using a Collection<BoundedWindow>
> I'm personally in favor of the latter because it automatically benefits all runners.

This message was sent by Atlassian JIRA

View raw message