rWsmhrgnt05RI>
>
> Best
> Yun Tang
> From: Piotr Nowojski mailto:pi...@ververica.com>>
> Sent: Thursday, January 9, 2020 23:27
> To: dev mailto:dev@flink.apache.org>>
> Subject: Re: [DISCUSS] Add N-Ary Stream Operator
>
> Hi,
>
> I have started
From: Piotr Nowojski
Sent: Thursday, January 9, 2020 23:27
To: dev
Subject: Re: [DISCUSS] Add N-Ary Stream Operator
Hi,
I have started a vote on this topic [1], please cast your +1 or -1 there :)
Also I assigned FLIP-92 number to this design doc.
Piotrek
[1]
http://apache
Hi,
I have started a vote on this topic [1], please cast your +1 or -1 there :)
Also I assigned FLIP-92 number to this design doc.
Piotrek
[1]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-FLIP-92-Add-N-Ary-Stream-Operator-in-Flink-td36539.html
Hi Piotr,
Sorry for the misunderstanding, chaining does work with multiple output
right now, I mean, it's also a very important feature, and it should work
with N-ary selectable input operators.
We all think that providing N-ary selectable input operator is a very
important thing, it makes
Hi,
Thanks for the clarifications Jingsong. Indeed, if chaining doesn’t work with
multiple output right now (doesn’t it?), that’s also a good future story.
Re Kurt:
I think this pattern could be easily handled if those two joins are implemented
as a single 3 input operator, that internally is
Kurt mentioned a very interesting thing,
If we want to better performance to read simultaneously, To this pattern:
We need to control not only the read order of inputs, but also the outputs
of endInput.
In this case, HashAggregate can only call its real endInput after the input
of build2 is
During implementing n-ary input operator in table, please keep
this pattern in mind:
Build1 ---+
|
+---> HshJoin1 --—> HashAgg ---+
| |
Probe1 ---+ +---> HashJoin2
Hi Piotr,
> a) two input operator X -> one input operator Y -> one input operator Z
(ALLOWED)
> b) n input operator X -> one input operator Y -> one input operator Z
(ALLOWED)
> c) two input operator X -> one input operator Y -> two input operator Z
(NOT ALLOWED as a single chain)
NOT ALLOWED to
Hi Jingsong,
Thanks for the feedback :)
Could you clarify a little bit what do you mean by your wished use cases?
> There are a large number jobs (in production environment) that their
> TwoInputOperators that can be chained. We used to only watch the last
> ten tasks transmit data through
Hi Piotr,
Huge +1 for N-Ary Stream Operator.
And I love this Golden Shovel award very much!
There are a large number jobs (in production environment) that their
TwoInputOperators that can be chained. We used to only watch the last
ten tasks transmit data through disk and network, which could
Hi,
First and foremost I would like to nominate myself to the Golden Shovel award
for digging out this topic:
Secondly, I would like to discuss coming back to this particular idea of
implementing N-Ary Stream Operator. This time motivation doesn’t come from the
Side Inputs, but to
Hi,
yes, I see operators of this style as very much an internal thing. You are
probably talking about use cases for OneInputOperator and TwoInputOperator
where users have a very specific need and require access the the low-level
details such as watermarks, state and timers to get stuff done. Maybe
Hey,
Some initial feedback from side:
I think this a very important problem to deal with as a lot of applications
depend on it. I like the proposed runtime model and that is probably the
good way to handle this task, it is very clean what is happening.
My main concern is how to handle this from
Hi Team,
I'm currently thinking about how we can bring the broadcast set/broadcast
input feature form the DataSet API to the DataStream API. I think this
would be a valuable addition since it would enable use cases that join
streams with constant (or slowly changing) side information.
For this
14 matches
Mail list logo
