:* Monday, May 01, 2017 12:56 PM
*To:* Newport, Billy [Tech]; 'user@flink.apache.org'
*Subject:* Re: Collector.collect
Oh you have multiple different output formats, missed that.
For the Batch API you are i believe correct, using a custom
output-format is the best solution.
In the Strea
, May 01, 2017 12:56 PM
To: Newport, Billy [Tech]; 'user@flink.apache.org'
Subject: Re: Collector.collect
Oh you have multiple different output formats, missed that.
For the Batch API you are i believe correct, using a custom output-format is
the best solution.
In the Streaming API the
17 10:41 AM
*To:* user@flink.apache.org
*Subject:* Re: Collector.collect
Hello,
@Billy, what prevented you from duplicating/splitting the record,
based on the bitmask, in a map function before the sink?
This shouldn't incur any serialization overhead if the sink is chained
to the map. T
approaches?
From: Chesnay Schepler [mailto:ches...@apache.org]
Sent: Monday, May 01, 2017 10:41 AM
To: user@flink.apache.org
Subject: Re: Collector.collect
Hello,
@Billy, what prevented you from duplicating/splitting the record, based on the
bitmask, in a map function before the sink?
This shouldn&#
Hello,
@Billy, what prevented you from duplicating/splitting the record, based
on the bitmask, in a map function before the sink?
This shouldn't incur any serialization overhead if the sink is chained
to the map. The emitted Tuple could also share the
GenericRecord; meaning you don't even have
We’ve done that but it’s very expensive from a serialization point of view when
writing the same record multiple times, each in a different tuple.
For example, we started with this:
.collect(new Tuplemailto:gaurav671...@gmail.com]
Sent: Saturday, April 29, 2017 4:32 AM
To: user@flink.apache.org
