Hi Yuval, Thanks for pointing that out. Yes, metrics names would also be affected. The need sounds reasonable, we could create a JIRA and give a detailed description of the requirements.
cc @godfrey @Kurt to provide more user perspective, they may be interested in the feature. Best, JING ZHANG Yuval Itzchakov <yuva...@gmail.com> 于2021年7月29日周四 上午12:49写道： > Hi Jing, > > An additional challenge with the current Table API / SQL approach for > iperator naming is that it makes it very hard to export metrics, i.e. to > track watermarks with Prometheus, when operator names are not assignable by > the user. > > On Wed, Jul 28, 2021, 13:11 JING ZHANG <beyond1...@gmail.com> wrote: > >> Hi Clemens, >> >> This feature is temporarily not supported. >> Your needs sounds reasonable, you could create a JIRA ticket. >> >> Now operator name contains a lot of detailed information, it has >> advantages and disadvantages. >> When we need troubleshoot problems, detailed information could help us to >> know what operator is doing. >> But too long message would cause problem for log system and visual >> display in frontend. >> Maybe it's better to shorten the operator name if it is too long. And >> there is a way to query the complete name of a given operator which help us >> to troubleshoot problems. >> >> Best, >> JING ZHANG >> >> Clemens Valiente <clemens.valie...@grab.com> 于2021年7月28日周三 下午12:16写道： >> >>> Is it possible to rename execution stages from the Table API? Right now >>> the entire select transformation appears in plaintext in the task name so >>> the log entries from ExecutionGraph are over 10,000 characters long and the >>> log files are incredibly difficult to read. >>> for example a simple selected field shows up as >>> Calc(select=[(((_UTF-16LE'code = ' POSITION (FLAG(BOTH) TRIM _UTF-16LE' >>> ' TRIM ((((FLAG(BOTH) TRIM _UTF-16LE' ' TRIM extraInfo.loginRequestID) = >>> _UTF-16LE'') OR ((FLAG(BOTH) TRIM _UTF-16LE' ' TRIM >>> extraInfo.loginRequestID) = _UTF-16LE'None')) CASE null:VARCHAR(2147483647) >>> CHARACTER SET "UTF-16LE" CASE extraInfo.loginRequestID))) = 1) CASE >>> null:VARCHAR(2147483647) CHARACTER SET "UTF-16LE" CASE ((((FLAG(BOTH) TRIM >>> _UTF-16LE' ' TRIM extraInfo.loginRequestID) = _UTF-16LE'') OR ((FLAG(BOTH) >>> TRIM _UTF-16LE' ' TRIM extraInfo.loginRequestID) = _UTF-16LE'None')) CASE >>> null:VARCHAR(2147483647) CHARACTER SET "UTF-16LE" CASE >>> extraInfo.loginRequestID)) AS loginRequestId >>> and we have about a dozen of those, and they're all printed out for >>> every single log line. >>> Is there any way of shortening this without having to suppress these log >>> lines completely? >>> >>> Best Regards >>> Clemens >>> >>> >>> By communicating with Grab Inc and/or its subsidiaries, associate >>> companies and jointly controlled entities (“Grab Group”), you are deemed to >>> have consented to the processing of your personal data as set out in the >>> Privacy Notice which can be viewed at https://grab.com/privacy/ >>> >>> This email contains confidential information and is only for the >>> intended recipient(s). If you are not the intended recipient(s), please do >>> not disseminate, distribute or copy this email Please notify Grab Group >>> immediately if you have received this by mistake and delete this email from >>> your system. Email transmission cannot be guaranteed to be secure or >>> error-free as any information therein could be intercepted, corrupted, >>> lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do >>> not accept liability for any errors or omissions in the contents of this >>> email arises as a result of email transmission. All intellectual property >>> rights in this email and attachments therein shall remain vested in Grab >>> Group, unless otherwise provided by law. >>> >>
