beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Kirpichov (JIRA)" <>
Subject [jira] [Closed] (BEAM-73) IO design pattern: Decouple Parsers and Coders
Date Wed, 29 Mar 2017 18:30:41 GMT


Eugene Kirpichov closed BEAM-73.
    Resolution: Duplicate

The only remaining instance of this is in KafkaIO, handled by BEAM-1573.

> IO design pattern: Decouple Parsers and Coders
> ----------------------------------------------
>                 Key: BEAM-73
>                 URL:
>             Project: Beam
>          Issue Type: New Feature
>          Components: sdk-java-core
>            Reporter: Daniel Halperin
>            Priority: Minor
>              Labels: backward-incompatible
>             Fix For: First stable release
> Many Sources can be thought of as providing a byte[] payload -- e.g. TextIO bytes between
newlines, or PubSubIO messages. Therefore, we originally suggested a Coder as the thing to
use to decode these byte[] into T (what I'll call Parsing).
> Consider the case of a text file of integers.
> 123\n
> 456\n
> ...
> We want a PCollection<Integer> out, so we can use TextualIntegerCoder with TextIO.Read.
However, that Coder will get propagated as the default coder for that PCollection (and may
be used in downstream DoFns). This seem bad as, once the data is parsed, we probably want
to use VarIntCoder or another Coder that is more CPU- and Space-efficient.
> Another design pattern is
>     TextIO.Read() -> MapElements<String, Integer> (lambda s : Integer.parseInt(s))
> This has better behavior, but now we go from byte[] to String to Integer rather than
directly from byte[] to Integer.
> The solution seems to be to explicitly add Parser and Coder abstractions.

This message was sent by Atlassian JIRA

View raw message