Hi guys
A DSL would be very welcomed, in particular if fluent.
Open question: did you study to implement Stream API (surely extending it
to have a BeamStream and a few more features like sides etc)? Would be very
natural and integrable easily anywhere and avoid a new API discovery.
Hazelcast
Hi David,
As JB noted, merging of these two projects is a great idea. If fact, some
of us have had those discussions in the past.
Legally, nothing particular is strictly necessary as the code seem to
already be Apache 2.0 licensed. We don't, however, want to be perceived as
making hostile forks,
This is an interesting point.
In the past, we've often just though about sequencing some action to take
place after the sink, in which case you can simply use the sink output as a
main input. However if you want to run a transform with another PCollection
as a main input, this doesn't work. And
Hi David,
Generally speaking, having different fluent DSL on top of the Beam SDK is great.
I would like to take a look on your wordcount examples to give you a complete
feedback. I like the idea and a fluent Java DSL is valuable.
Let's wait feedback from others. If we have a consensus, then
Hello,
First of all, thanks for the amazing work the Apache Beam community is
doing!
In 2014, we've started development of the runtime independent Java 8 API,
that helps us to create unified big-data processing flows. It has been used
as a core building block of Seznam.cz web crawler data