Hi,
Very thanks Wenlong for the update! Also +1 for the proposal~
Best,
Yun Gao
--
From:Yun Gao
Send Time:2021 Nov. 23 (Tue.) 16:09
To:dev
Subject:Re: [DISCUSS] Improve the name and structure of job vertex and operator
name
ave a separate index field for the JobVertex, the index would be
> > presented in the UI / thread name and some critical logs, while we still
> > leave users to have full control of the operator names?
> >
> > Best,
> > Yun
> >
> >
> > --
------
> From:Aitozi
> Send Time:2021 Nov. 22 (Mon.) 00:01
> To:dev
> Subject:Re: [DISCUSS] Improve the name and structure of job vertex and
> operator name for job
>
> Hi Wenlong
>
> I think it's a nice work, big +1 for it (non-binding).
>
> Thanks to Yun Tang f
ll control of the operator names?
Best,
Yun
--
From:Aitozi
Send Time:2021 Nov. 22 (Mon.) 00:01
To:dev
Subject:Re: [DISCUSS] Improve the name and structure of job vertex and operator
name for job
Hi Wenlong
I think it's a nice wo
Hi Wenlong
I think it's a nice work, big +1 for it (non-binding).
Thanks to Yun Tang for mention our internal version improvements on vertex
name display.
I think add a "[vertex-x]" prefix can tell people the information about the
vertex sequence. The vertex-id and node-id are at different
+1 for the FLIP. We have met the problem that a long name stuck the metric
collection for SQL jobs.
wenlong.lwl 于2021年11月19日周五 下午10:29写道：
> hi, yun,
> Thanks for the suggestion, but I am not sure whether we need such a prefix
> or not, because the log has included vertex id, when the name is
hi, yun,
Thanks for the suggestion, but I am not sure whether we need such a prefix
or not, because the log has included vertex id, when the name is concise
enough, we can get the vertex id easily.
Does anyone have some comments on this?
Best,
Wenlong Lyu
On Thu, 18 Nov 2021 at 19:03, Yun Tang
Hi Wenlong,
Thanks for bringing up this discussion and I believe many guys have ever
suffered from the long and unreadable operator name for long time.
I have another suggestion which inspired by Aitozi, that we could add some hint
to tell the vertex index. Such as make the pipeline from
Hi Wenlong, I'm fine with the config options.
Best,
Godfrey
wenlong.lwl 于2021年11月17日周三 下午3:13写道：
>
> Hi Chesney and Konstantin,
> thanks for your feedback, I have added a section about How we support set
> description at DataStream API in the doc.
>
>
> Bests,
> Wenlong
>
> On Tue, 16 Nov 2021
Hi Chesney and Konstantin,
thanks for your feedback, I have added a section about How we support set
description at DataStream API in the doc.
Bests,
Wenlong
On Tue, 16 Nov 2021 at 21:05, Konstantin Knauf wrote:
> Hi everyone,
>
> Thanks for starting this discussion. I am in favor of solving
Hi everyone,
Thanks for starting this discussion. I am in favor of solving this for
DataStream and Table API at the same time, using the same configuration
keys. IMO we shouldn't introduce any additional fragmentation if we can
avoid it.
Cheers,
Konstantin
On Tue, Nov 16, 2021 at 1:50 PM
hi, Chesney, we focus on sql first because the operator and topology of sql
jobs are generated by the engine, raising most of the problems in naming,
not only because the name is long but also because the topology can be more
complex than DataStream.
The case in Datastream is much better, most of
Why should this be specific to the table API? The datastream API has
similar issues with long operator names (like windowing).
On 16/11/2021 11:22, wenlong.lwl wrote:
Thanks Godfrey for the suggestion.
Regarding 1, how about table.optimizer.simplify-operator-name-enabled,
which means that we
Thanks Godfrey for the suggestion.
Regarding 1, how about table.optimizer.simplify-operator-name-enabled,
which means that we would simplify the name of operator and keep the
details in description only.
"table.optimizer.operator-name.description-enabled" can not describe what
it means I think.
Thanks for creating this FLIP Wenlong.
The FLIP already looks pretty solid, I think the config options can be
improved a little:
1) about table.optimizer.separate-name-and-description, I think
"operator-name" should be considered in the option,
how about
Hi, all, FYI the FLIP doc has been created ：
https://cwiki.apache.org/confluence/display/FLINK/FLIP-195%3A+Improve+the+name+and+structure+of+vertex+and+operator+name+for+sql+job
Best,
Wenlong
On Mon, 15 Nov 2021 at 11:41, wenlong.lwl wrote:
> Hi all,
> Thanks for the feedback, It seems that
Hi all,
Thanks for the feedback, It seems that the proposal is accepted by all of
you guys. I will prepare a formal FLIP document and then go ahead to the
vote stage.
If any one has any other comments or suggestions, please let me know,
thanks.
Best,
Wenlong
On Fri, 12 Nov 2021 at 05:54, Neng Lu
+1 (non-binding)
This change will really help to ease developer life.
On Thu, Nov 11, 2021 at 6:33 AM Guowei Ma wrote:
> +1
> This would be very helpful for our debugging online job.
>
> Best,
> Guowei
>
>
> On Thu, Nov 11, 2021 at 8:03 PM Yuepeng Pan wrote:
>
> > +1. It's useful to understand
+1
This would be very helpful for our debugging online job.
Best,
Guowei
On Thu, Nov 11, 2021 at 8:03 PM Yuepeng Pan wrote:
> +1. It's useful to understand the job topology.
> Looking forward to this feature.
> Best,
> Yuepeng Pan.
>
>
>
>
>
>
> At 2021-11-11 19:44:44, "Yangze Guo" wrote:
>
+1. It's useful to understand the job topology.
Looking forward to this feature.
Best,
Yuepeng Pan.
At 2021-11-11 19:44:44, "Yangze Guo" wrote:
>+1. That's gonna help a lot for debugging.
>
>Best,
>Yangze Guo
>
>On Thu, Nov 11, 2021 at 7:37 PM Till Rohrmann wrote:
>>
>> This improvement
+1. That's gonna help a lot for debugging.
Best,
Yangze Guo
On Thu, Nov 11, 2021 at 7:37 PM Till Rohrmann wrote:
>
> This improvement looks like it makes the life of our users a lot easier
> when it comes to understanding logs and reading the UI. Hence +1.
>
> Cheers,
> Till
>
> On Thu, Nov 11,
This improvement looks like it makes the life of our users a lot easier
when it comes to understanding logs and reading the UI. Hence +1.
Cheers,
Till
On Thu, Nov 11, 2021 at 11:59 AM JING ZHANG wrote:
> Big +1.
>
> This is a problem frequently encountered in our production platform, look
>
Big +1.
This is a problem frequently encountered in our production platform, look
forward to this improvement.
Best,
Jing Zhang
Martijn Visser 于2021年11月11日周四 下午6:26写道：
> +1. Looks much better now
>
> On Thu, 11 Nov 2021 at 11:07, godfrey he wrote:
>
> > Thanks for driving this, this
+1. Looks much better now
On Thu, 11 Nov 2021 at 11:07, godfrey he wrote:
> Thanks for driving this, this improvement solves a long-complained
> problem, +1
>
> Best,
> Godfrey
>
> Jark Wu 于2021年11月11日周四 下午5:40写道：
> >
> > +1 for this. It looks much more clear and structured.
> >
> > Best,
> >
Thanks for driving this, this improvement solves a long-complained problem, +1
Best,
Godfrey
Jark Wu 于2021年11月11日周四 下午5:40写道：
>
> +1 for this. It looks much more clear and structured.
>
> Best,
> Jark
>
> On Thu, 11 Nov 2021 at 17:23, Chesnay Schepler wrote:
>
> > I'm generally in favor of it,
+1 for this. It looks much more clear and structured.
Best,
Jark
On Thu, 11 Nov 2021 at 17:23, Chesnay Schepler wrote:
> I'm generally in favor of it, and there are already tickets that
> proposed a dedicated operator/vertex description:
>
> https://issues.apache.org/jira/browse/FLINK-20388
>
I'm generally in favor of it, and there are already tickets that
proposed a dedicated operator/vertex description:
https://issues.apache.org/jira/browse/FLINK-20388
https://issues.apache.org/jira/browse/FLINK-21858
On 11/11/2021 10:02, wenlong.lwl wrote:
Hi, all, I would like to start a
Hi, all, I would like to start a discussion about an improvement on name
and structure of job vertex name, mainly to improve experience of debugging
and analyzing sql job at runtime.
the main proposed changes including:
1. separate description and name for operator, so that we can have detailed
28 matches
Mail list logo
