beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Halperin (JIRA)" <>
Subject [jira] [Commented] (BEAM-92) Data-dependent sinks
Date Thu, 03 Mar 2016 17:23:18 GMT


Daniel Halperin commented on BEAM-92:

Abstractly, this is very easy to accomplish when the Sink is replaced by a DoFn. You can generate
a KV<SinkT, T> with a ParDo(element -> KV.of(where(element), element))). Then a GroupByKey
will give you a KV<SinkT, Iterable<T>> and then all the elements can be written
to the sink.

However, of course, given that a single worker is processing all the elements, this will essentially
be single-threaded writing.

This seems much more complicated when taking into account fault tolerance, finalizers, etc.
Lots of design to do here.

> Data-dependent sinks
> --------------------
>                 Key: BEAM-92
>                 URL:
>             Project: Beam
>          Issue Type: New Feature
>            Reporter: Eugene Kirpichov
> Current sink API writes all data to a single destination, but there are many use cases
where different pieces of data need to be routed to different destinations where the set of
destinations is data-dependent (so can't be implemented with a Partition transform).
> One internally discussed proposal was an API of the form:
> {code}
> PCollection<Void> PCollection<T>.apply(
>     Write.using(DoFn<T, SinkT> where,
>                 MapFn<SinkT, WriteOperation<WriteResultT, T>> how)
> {code}
> so an item T gets written to a destination (or multiple destinations) determined by "where";
and the writing strategy is determined by "how" that produces a WriteOperation (current API
- global init/write/global finalize hooks) for any given destination.
> This API also has other benefits:
> * allows the SinkT to be computed dynamically (in "where"), rather than specified at
pipeline construction time
> * removes the necessity for a Sink class entirely
> * is sequenceable w.r.t. downstream transforms (you can stick transforms onto the returned
PCollection<Void>, while the current returns a PDone)

This message was sent by Atlassian JIRA

View raw message