Looks like https://beam.apache.org/documentation/runners/capability-matrix/
needs
to be updated? since there seems to be support for spark structured
streaming?
On Tue, Jan 28, 2020 at 1:47 PM Connell O'Callaghan
wrote:
> Well done thank you Udi!!!
>
> On Tue, Jan 28, 2020 at 11:47 AM Ankur Goen
No Spark Structured Streaming support yet?
On Thu, Dec 13, 2018 at 7:53 PM Connell O'Callaghan
wrote:
> Excellent thank you Chamikara and all who contributed to this release!!!
>
> On Thu, Dec 13, 2018 at 7:42 PM Chamikara Jayalath
> wrote:
>
>> The Apache Beam team is pleased to announce the r
aming has started and it
> might
> make it into the next release.
>
> On 14.12.18 07:00, kant kodali wrote:
> > No Spark Structured Streaming support yet?
> >
> > On Thu, Dec 13, 2018 at 7:53 PM Connell O'Callaghan > <mailto:conne...@google.com>> wrot
Great! Does this version include Spark Structured Streaming?
On Mon, Feb 18, 2019 at 3:23 AM Matt Casters wrote:
> Hi Beam-ers,
>
> Congratulations on the release!
> I did a quick upgrade and tried to run my test ETL jobs on Direct & Flink
> runners with great success.
> DataFlow however is thro
Staying behind doesn't imply one is better than the other and I didn't mean
that in any way but I fail to see how an abstraction framework like Beam
can stay ahead of the underlying execution engines?
For example, If a new feature is added into the underlying execution engine
that doesn't fit the
ving constantly. I
> don't see Beam as following the features of any engine, but rather coming
> up with new needed data processing abstractions and figuring out how to
> efficiently implement them on top of various architectures.
> >>
> >> Kenn
> >>
>
;>>> dependent on Beam and cannot afford to re-write their pipelines in
>> >>>>> Spark/Flink from scratch, they would realize that Beam does not give
>> >>>>> access to some of the capabilities of the free engines that they may
>> >>>>> req
implementation. And everything is moving constantly. I
> don't see Beam as following the features of any engine, but rather coming
> up with new needed data processing abstractions and figuring out how to
> efficiently implement them on top of various architectures.
>
> Kenn
&
t;> are today). so its always a moving target.
>>
>> Any scaleable data processing problem you might have that can't be solved
>> by Spark, Flink or DataFlow is pretty obscure don't you think?
>>
>> Great discussion :-)
>>
>> Cheers,
>> M
Work in progress
while the execution engine had the support since 2 years at very least.
On Mon, May 6, 2019 at 12:24 PM kant kodali wrote:
>
>
> On Mon, May 6, 2019 at 12:09 PM Juan Carlos Garcia
> wrote:
>
>> As everyone has pointed out there will be a small
10 matches
Mail list logo
