s for your proposal, Look good to me overall, +1
>
>Best,
>Ron
>
>
>> -原始邮件-
>> 发件人: Xuyang
>> 发送时间:2024-08-14 15:20:59 (星期三)
>> 收件人: dev@flink.apache.org
>> 主题: Re:Re: Re: Re:Re: [DISCUSS] FLIP-473: Introduce New SQL Operators Based
>> o
Hi, Xuyang
Thanks for your proposal, Look good to me overall, +1
Best,
Ron
> -原始邮件-
> 发件人: Xuyang
> 发送时间:2024-08-14 15:20:59 (星期三)
> 收件人: dev@flink.apache.org
> 主题: Re:Re: Re: Re:Re: [DISCUSS] FLIP-473: Introduce New SQL Operators Based
> on Asynchronous State
Hi, Feng. Thank you for your feedback.
I completely agree that these tests are crucial. I have updated the Roadmap
section of
the FLIP to include plans for harness tests and IT tests for data correctness,
state
compatibility tests, and performance regression tests.
Regarding the usage of th
Hi, Xuyang
Thank you for initiating this FLIP. I believe this is a significant feature
for the future of Flink SQL, but I also share concerns about the
maintenance costs related to the correctness, state compatibility, and
performance of the two implementations.
I fully support ensuring state comp
Hi, David. Thank you for your review. Let me address your questions:
>1. Is there a way to enforce this as an invariant during build time,
>perhaps through a generic test framework that switches between the sync and
>async versions of all operators and verifies checkpoint compatibility?
Yes, we n
Hi Xuyang,
Thank you for looking into this—great work! The overall direction seems
solid. I have two minor questions:
In theory, the implementation of AsyncStateOperator and SyncStateOperator
> differs only in their state handling. Their state schemas, business logic,
> and other aspects remain t
Hi, everyone.
I have updated the FLIP. Here are the newly added sections:
In theory, the implementation of AsyncStateOperator and SyncStateOperator
differs only in their state handling.
Their state schemas, business logic, and others are the same. Therefore, within
the same Flink version,
Hi, Zakelly.
You’re right. This is another advantage of choosing the where two sets of
operators share the same execution node. In this approach, users can utilize
the compiled plan and adjust the config 'table.exec.async-state.enabled',
providing them with the flexibility to switch between asy
Hi Xuyang,
Thanks for driving this! I'm happy to see operator implementation on top of
the async state. Overall it looks good, I have one minor question:
It seems the only difference between the new operator implementation and
the original one is the way of state accessing. Does this mean the sta
Hi devs,
I'd like to initiate a discussion about FLIP-473: Introduce New SQL Operators
Based on Asynchronous State APIs[1].
FLIP-424[2] has introduced an asynchronous state architecture to mitigate I/O
bottlenecks in Flink by offloading state
access to separate threads from the main thread
10 matches
Mail list logo
