You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by shuai xu <xu...@gmail.com> on 2025/04/08 01:57:46 UTC
[DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Hi devs,
I'd like to start a discussion on FLIP-519: Introduce async lookup key
ordered mode[1].
The Flink system currently supports both record-level ordered and
unordered output modes for asynchronous lookup joins. However, it does
not guarantee the processing order of records sharing the same key.
As highlighted in [2], there are two key requirements for enhancing
async io operations:
1. Ensuring the processing order of records with the same key is a
common requirement in DataStream.
2. Sequential processing of records sharing the same upsertKey when
performing lookup join in Flink SQL is essential for maintaining
correctness.
This optimization aims to balance correctness and performance for
stateful streaming workloads.Then the FLIP introduce a new operator
KeyedAsyncWaitOperator to supports the optimization. Besides, a new
option is added to control the behaviour avoid influencing existing
jobs.
please find more details in the FLIP wiki document[1]. Looking forward
to your feedback.
[1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
[2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
Best,
Xu Shuai
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by shuai xu <xu...@gmail.com>.
Hi, devs,
There haven’t been any further responses to this email over the past few days.
I'd like to initiate a vote on the current proposal[1] in the next few days. If
there are any concerns about this FLIP-519[1], I will gladly pause and make
necessary adjustments.
Best,
Xu Shuai
[1]https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
>
> Hi devs,
>
> I'd like to start a discussion on FLIP-519: Introduce async lookup key
> ordered mode[1].
>
> The Flink system currently supports both record-level ordered and
> unordered output modes for asynchronous lookup joins. However, it does
> not guarantee the processing order of records sharing the same key.
>
> As highlighted in [2], there are two key requirements for enhancing
> async io operations:
> 1. Ensuring the processing order of records with the same key is a
> common requirement in DataStream.
> 2. Sequential processing of records sharing the same upsertKey when
> performing lookup join in Flink SQL is essential for maintaining
> correctness.
>
> This optimization aims to balance correctness and performance for
> stateful streaming workloads.Then the FLIP introduce a new operator
> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
> option is added to control the behaviour avoid influencing existing
> jobs.
>
> please find more details in the FLIP wiki document[1]. Looking forward
> to your feedback.
>
> [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>
> Best,
> Xu Shuai
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by shuai xu <xu...@gmail.com>.
Hi Ron，
Thank you so much for your feedback and support on this proposal! I really appreciate you taking the time to review
it in detail.
You're absolutely right about the table's content. When table.exec.async-lookup.key-ordered-enabled=true and
table.exec.async-lookup.output-mode=ORDERED, the lookup join in key order should indeed be marked as "yes”
instead of "no". The current representation is a bit misleading and could cause confusion.
I'll update the FLIP to correct this point and ensure it accurately reflects the behavior.
Best,
Shuai
> 2025年4月25日 10:23，Ron Liu <ro...@gmail.com> 写道：
>
> Hi, Shuai
>
> Thanks for driving this proposal. The FLIP looks good to me overall, +1 for
> it.
>
> I have a small question about the table's contents. When
> 'table.exec.async-lookup.key-ordered-enabled=true' and
> 'table.exec.async-lookup.output-mode=ORDERD', the lookup join in key
> ordered should be 'yes', not 'no'.
> ORDERD is naturally guaranteed to be ordered, it just doesn't depend on the
> current implementation of this proposal, which is a bit confusing here.
>
>
> Best,
> Ron
>
> shuai xu <xu...@gmail.com> 于2025年4月18日周五 10:50写道：
>
>> Hi Xuyang,
>>
>>
>> Thanks for your response. Actually, ALLOW_UNORDERED is only enabled when
>> facing
>>
>> append-only streams for higher throughput. KEY_ORDERED is designed for
>> scenarios
>>
>> where upsert key exists. Its goal is to achieve higher performance
>> compared to the ORDERED
>>
>> mode while ensuring correctness is not compromised. In a word,
>> ALLOW_UNORDERED
>>
>> mode does works in the presence of an upsert key.
>>
>>
>> Aside from the literal difference in sequence, KEY_ORDER focuses on the
>> processing order,
>>
>> while ALLOW_UNORDERED pertains to the output order. In ALLOW_UNORDERED
>> mode,
>>
>> the processing order may be either ordered or unordered.
>>
>>
>> Best,
>> Xu Shuai
>>
>>> 2025年4月17日 14:53，Xuyang <xy...@163.com> 写道：
>>>
>>> Hi, Shuai.
>>>
>>> This is a valuable addition to the current AsyncLookupJoin, and I’m
>>>
>>> generally in favor of it.
>>>
>>>
>>>
>>>
>>> I have one question. Why do we need to introduce additional parameters
>>>
>>> to control KEY_ORDERED and ALLOW_UNORDERED? In other words,
>>>
>>> what scenarios require allowing users to perform completely unordered
>>>
>>> async lookup joins in the presence of an upsert key?
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best！
>>> Xuyang
>>>
>>>
>>>
>>>
>>>
>>> 在 2025-04-11 10:39:46，"shuai xu" <xu...@gmail.com> 写道：
>>>> Hi all,
>>>>
>>>> This FLIP will primarily focus on the implementation within the table
>> module. As for support in the DataStream API, it will be addressed in a
>> separate FLIP.
>>>>
>>>>> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
>>>>>
>>>>> Hi devs,
>>>>>
>>>>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
>>>>> ordered mode[1].
>>>>>
>>>>> The Flink system currently supports both record-level ordered and
>>>>> unordered output modes for asynchronous lookup joins. However, it does
>>>>> not guarantee the processing order of records sharing the same key.
>>>>>
>>>>> As highlighted in [2], there are two key requirements for enhancing
>>>>> async io operations:
>>>>> 1. Ensuring the processing order of records with the same key is a
>>>>> common requirement in DataStream.
>>>>> 2. Sequential processing of records sharing the same upsertKey when
>>>>> performing lookup join in Flink SQL is essential for maintaining
>>>>> correctness.
>>>>>
>>>>> This optimization aims to balance correctness and performance for
>>>>> stateful streaming workloads.Then the FLIP introduce a new operator
>>>>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
>>>>> option is added to control the behaviour avoid influencing existing
>>>>> jobs.
>>>>>
>>>>> please find more details in the FLIP wiki document[1]. Looking forward
>>>>> to your feedback.
>>>>>
>>>>> [1]
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
>>>>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>>>>>
>>>>> Best,
>>>>> Xu Shuai
>>
>>
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by Ron Liu <ro...@gmail.com>.
Hi, Shuai
Thanks for driving this proposal. The FLIP looks good to me overall, +1 for
it.
I have a small question about the table's contents. When
'table.exec.async-lookup.key-ordered-enabled=true' and
'table.exec.async-lookup.output-mode=ORDERD', the lookup join in key
ordered should be 'yes', not 'no'.
ORDERD is naturally guaranteed to be ordered, it just doesn't depend on the
current implementation of this proposal, which is a bit confusing here.
Best,
Ron
shuai xu <xu...@gmail.com> 于2025年4月18日周五 10:50写道：
> Hi Xuyang,
>
>
> Thanks for your response. Actually, ALLOW_UNORDERED is only enabled when
> facing
>
> append-only streams for higher throughput. KEY_ORDERED is designed for
> scenarios
>
> where upsert key exists. Its goal is to achieve higher performance
> compared to the ORDERED
>
> mode while ensuring correctness is not compromised. In a word,
> ALLOW_UNORDERED
>
> mode does works in the presence of an upsert key.
>
>
> Aside from the literal difference in sequence, KEY_ORDER focuses on the
> processing order,
>
> while ALLOW_UNORDERED pertains to the output order. In ALLOW_UNORDERED
> mode,
>
> the processing order may be either ordered or unordered.
>
>
> Best,
> Xu Shuai
>
> > 2025年4月17日 14:53，Xuyang <xy...@163.com> 写道：
> >
> > Hi, Shuai.
> >
> > This is a valuable addition to the current AsyncLookupJoin, and I’m
> >
> > generally in favor of it.
> >
> >
> >
> >
> > I have one question. Why do we need to introduce additional parameters
> >
> > to control KEY_ORDERED and ALLOW_UNORDERED? In other words,
> >
> > what scenarios require allowing users to perform completely unordered
> >
> > async lookup joins in the presence of an upsert key?
> >
> >
> >
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > 在 2025-04-11 10:39:46，"shuai xu" <xu...@gmail.com> 写道：
> >> Hi all,
> >>
> >> This FLIP will primarily focus on the implementation within the table
> module. As for support in the DataStream API, it will be addressed in a
> separate FLIP.
> >>
> >>> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
> >>>
> >>> Hi devs,
> >>>
> >>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
> >>> ordered mode[1].
> >>>
> >>> The Flink system currently supports both record-level ordered and
> >>> unordered output modes for asynchronous lookup joins. However, it does
> >>> not guarantee the processing order of records sharing the same key.
> >>>
> >>> As highlighted in [2], there are two key requirements for enhancing
> >>> async io operations:
> >>> 1. Ensuring the processing order of records with the same key is a
> >>> common requirement in DataStream.
> >>> 2. Sequential processing of records sharing the same upsertKey when
> >>> performing lookup join in Flink SQL is essential for maintaining
> >>> correctness.
> >>>
> >>> This optimization aims to balance correctness and performance for
> >>> stateful streaming workloads.Then the FLIP introduce a new operator
> >>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
> >>> option is added to control the behaviour avoid influencing existing
> >>> jobs.
> >>>
> >>> please find more details in the FLIP wiki document[1]. Looking forward
> >>> to your feedback.
> >>>
> >>> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
> >>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
> >>>
> >>> Best,
> >>> Xu Shuai
>
>
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by shuai xu <xu...@gmail.com>.
Hi Xuyang,
Thanks for your response. Actually, ALLOW_UNORDERED is only enabled when facing
append-only streams for higher throughput. KEY_ORDERED is designed for scenarios
where upsert key exists. Its goal is to achieve higher performance compared to the ORDERED
mode while ensuring correctness is not compromised. In a word, ALLOW_UNORDERED
mode does works in the presence of an upsert key.
Aside from the literal difference in sequence, KEY_ORDER focuses on the processing order,
while ALLOW_UNORDERED pertains to the output order. In ALLOW_UNORDERED mode,
the processing order may be either ordered or unordered.
Best,
Xu Shuai
> 2025年4月17日 14:53，Xuyang <xy...@163.com> 写道：
>
> Hi, Shuai.
>
> This is a valuable addition to the current AsyncLookupJoin, and I’m
>
> generally in favor of it.
>
>
>
>
> I have one question. Why do we need to introduce additional parameters
>
> to control KEY_ORDERED and ALLOW_UNORDERED? In other words,
>
> what scenarios require allowing users to perform completely unordered
>
> async lookup joins in the presence of an upsert key?
>
>
>
>
> --
>
> Best！
> Xuyang
>
>
>
>
>
> 在 2025-04-11 10:39:46，"shuai xu" <xu...@gmail.com> 写道：
>> Hi all,
>>
>> This FLIP will primarily focus on the implementation within the table module. As for support in the DataStream API, it will be addressed in a separate FLIP.
>>
>>> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
>>>
>>> Hi devs,
>>>
>>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
>>> ordered mode[1].
>>>
>>> The Flink system currently supports both record-level ordered and
>>> unordered output modes for asynchronous lookup joins. However, it does
>>> not guarantee the processing order of records sharing the same key.
>>>
>>> As highlighted in [2], there are two key requirements for enhancing
>>> async io operations:
>>> 1. Ensuring the processing order of records with the same key is a
>>> common requirement in DataStream.
>>> 2. Sequential processing of records sharing the same upsertKey when
>>> performing lookup join in Flink SQL is essential for maintaining
>>> correctness.
>>>
>>> This optimization aims to balance correctness and performance for
>>> stateful streaming workloads.Then the FLIP introduce a new operator
>>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
>>> option is added to control the behaviour avoid influencing existing
>>> jobs.
>>>
>>> please find more details in the FLIP wiki document[1]. Looking forward
>>> to your feedback.
>>>
>>> [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
>>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>>>
>>> Best,
>>> Xu Shuai
Re:Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by Xuyang <xy...@163.com>.
Hi, Shuai.
This is a valuable addition to the current AsyncLookupJoin, and I’m
generally in favor of it.
I have one question. Why do we need to introduce additional parameters
to control KEY_ORDERED and ALLOW_UNORDERED? In other words,
what scenarios require allowing users to perform completely unordered
async lookup joins in the presence of an upsert key?
--
Best！
Xuyang
在 2025-04-11 10:39:46，"shuai xu" <xu...@gmail.com> 写道：
>Hi all,
>
>This FLIP will primarily focus on the implementation within the table module. As for support in the DataStream API, it will be addressed in a separate FLIP.
>
>> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
>>
>> Hi devs,
>>
>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
>> ordered mode[1].
>>
>> The Flink system currently supports both record-level ordered and
>> unordered output modes for asynchronous lookup joins. However, it does
>> not guarantee the processing order of records sharing the same key.
>>
>> As highlighted in [2], there are two key requirements for enhancing
>> async io operations:
>> 1. Ensuring the processing order of records with the same key is a
>> common requirement in DataStream.
>> 2. Sequential processing of records sharing the same upsertKey when
>> performing lookup join in Flink SQL is essential for maintaining
>> correctness.
>>
>> This optimization aims to balance correctness and performance for
>> stateful streaming workloads.Then the FLIP introduce a new operator
>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
>> option is added to control the behaviour avoid influencing existing
>> jobs.
>>
>> please find more details in the FLIP wiki document[1]. Looking forward
>> to your feedback.
>>
>> [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>>
>> Best,
>> Xu Shuai
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by shuai xu <xu...@gmail.com>.
Hi all,
This FLIP will primarily focus on the implementation within the table module. As for support in the DataStream API, it will be addressed in a separate FLIP.
> 2025年4月8日 09:57，shuai xu <xu...@gmail.com> 写道：
>
> Hi devs,
>
> I'd like to start a discussion on FLIP-519: Introduce async lookup key
> ordered mode[1].
>
> The Flink system currently supports both record-level ordered and
> unordered output modes for asynchronous lookup joins. However, it does
> not guarantee the processing order of records sharing the same key.
>
> As highlighted in [2], there are two key requirements for enhancing
> async io operations:
> 1. Ensuring the processing order of records with the same key is a
> common requirement in DataStream.
> 2. Sequential processing of records sharing the same upsertKey when
> performing lookup join in Flink SQL is essential for maintaining
> correctness.
>
> This optimization aims to balance correctness and performance for
> stateful streaming workloads.Then the FLIP introduce a new operator
> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
> option is added to control the behaviour avoid influencing existing
> jobs.
>
> please find more details in the FLIP wiki document[1]. Looking forward
> to your feedback.
>
> [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>
> Best,
> Xu Shuai
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by shuai xu <xu...@gmail.com>.
Hi Zakelly,
Thank you for your response and for taking responsibility for generalizing the functionality of the 'Asynchronous Execution Model' (AEC). As we discussed earlier, the subsequent work on FLIP will be based on operators that support AEC. If you need any further discussion, please feel free to reach out to me directly.
> 2025年4月10日 12:31，Zakelly Lan <za...@gmail.com> 写道：
>
> Hi all,
>
> I have also added a 'Follow up' section at the end of the FLIP-425[1]
> describing this.
>
> [1] https://cwiki.apache.org/confluence/x/S4p3EQ
>
>
> Best,
> Zakelly
>
> On Wed, Apr 9, 2025 at 12:42 PM Zakelly Lan <za...@gmail.com> wrote:
>
>> Thanks for driving this!
>>
>> +1 for the FLIP given there is a solid user case behind.
>>
>> Shuai and I had a discussion and we agree that `KeyedAsyncWaitOperator`
>> in current FLIP shares similar functionality with the `Asynchronous
>> Execution Model (AEC)` introduced in FLIP-425[1]. We think it is better to
>> generalize the AEC for all keyed ordered cases, not only for state access.
>> So I'd make this happen after the approval of this FLIP. Hope this helps
>> all the similar operators to implement.
>>
>> [1] https://cwiki.apache.org/confluence/x/S4p3EQ
>>
>>
>> Best,
>> Zakelly
>>
>> On Tue, Apr 8, 2025 at 10:00 AM shuai xu <xu...@gmail.com> wrote:
>>
>>> Hi devs,
>>>
>>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
>>> ordered mode[1].
>>>
>>> The Flink system currently supports both record-level ordered and
>>> unordered output modes for asynchronous lookup joins. However, it does
>>> not guarantee the processing order of records sharing the same key.
>>>
>>> As highlighted in [2], there are two key requirements for enhancing
>>> async io operations:
>>> 1. Ensuring the processing order of records with the same key is a
>>> common requirement in DataStream.
>>> 2. Sequential processing of records sharing the same upsertKey when
>>> performing lookup join in Flink SQL is essential for maintaining
>>> correctness.
>>>
>>> This optimization aims to balance correctness and performance for
>>> stateful streaming workloads.Then the FLIP introduce a new operator
>>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
>>> option is added to control the behaviour avoid influencing existing
>>> jobs.
>>>
>>> please find more details in the FLIP wiki document[1]. Looking forward
>>> to your feedback.
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
>>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>>>
>>> Best,
>>> Xu Shuai
>>>
>>
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by Zakelly Lan <za...@gmail.com>.
Hi all,
I have also added a 'Follow up' section at the end of the FLIP-425[1]
describing this.
[1] https://cwiki.apache.org/confluence/x/S4p3EQ
Best,
Zakelly
On Wed, Apr 9, 2025 at 12:42 PM Zakelly Lan <za...@gmail.com> wrote:
> Thanks for driving this!
>
> +1 for the FLIP given there is a solid user case behind.
>
> Shuai and I had a discussion and we agree that `KeyedAsyncWaitOperator`
> in current FLIP shares similar functionality with the `Asynchronous
> Execution Model (AEC)` introduced in FLIP-425[1]. We think it is better to
> generalize the AEC for all keyed ordered cases, not only for state access.
> So I'd make this happen after the approval of this FLIP. Hope this helps
> all the similar operators to implement.
>
> [1] https://cwiki.apache.org/confluence/x/S4p3EQ
>
>
> Best,
> Zakelly
>
> On Tue, Apr 8, 2025 at 10:00 AM shuai xu <xu...@gmail.com> wrote:
>
>> Hi devs,
>>
>> I'd like to start a discussion on FLIP-519: Introduce async lookup key
>> ordered mode[1].
>>
>> The Flink system currently supports both record-level ordered and
>> unordered output modes for asynchronous lookup joins. However, it does
>> not guarantee the processing order of records sharing the same key.
>>
>> As highlighted in [2], there are two key requirements for enhancing
>> async io operations:
>> 1. Ensuring the processing order of records with the same key is a
>> common requirement in DataStream.
>> 2. Sequential processing of records sharing the same upsertKey when
>> performing lookup join in Flink SQL is essential for maintaining
>> correctness.
>>
>> This optimization aims to balance correctness and performance for
>> stateful streaming workloads.Then the FLIP introduce a new operator
>> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
>> option is added to control the behaviour avoid influencing existing
>> jobs.
>>
>> please find more details in the FLIP wiki document[1]. Looking forward
>> to your feedback.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
>> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>>
>> Best,
>> Xu Shuai
>>
>
Re: [DISCUSS] FLIP-519: Introduce async lookup key ordered mode
Posted by Zakelly Lan <za...@gmail.com>.
Thanks for driving this!
+1 for the FLIP given there is a solid user case behind.
Shuai and I had a discussion and we agree that `KeyedAsyncWaitOperator` in
current FLIP shares similar functionality with the `Asynchronous Execution
Model (AEC)` introduced in FLIP-425[1]. We think it is better to generalize
the AEC for all keyed ordered cases, not only for state access. So I'd make
this happen after the approval of this FLIP. Hope this helps all the
similar operators to implement.
[1] https://cwiki.apache.org/confluence/x/S4p3EQ
Best,
Zakelly
On Tue, Apr 8, 2025 at 10:00 AM shuai xu <xu...@gmail.com> wrote:
> Hi devs,
>
> I'd like to start a discussion on FLIP-519: Introduce async lookup key
> ordered mode[1].
>
> The Flink system currently supports both record-level ordered and
> unordered output modes for asynchronous lookup joins. However, it does
> not guarantee the processing order of records sharing the same key.
>
> As highlighted in [2], there are two key requirements for enhancing
> async io operations:
> 1. Ensuring the processing order of records with the same key is a
> common requirement in DataStream.
> 2. Sequential processing of records sharing the same upsertKey when
> performing lookup join in Flink SQL is essential for maintaining
> correctness.
>
> This optimization aims to balance correctness and performance for
> stateful streaming workloads.Then the FLIP introduce a new operator
> KeyedAsyncWaitOperator to supports the optimization. Besides, a new
> option is added to control the behaviour avoid influencing existing
> jobs.
>
> please find more details in the FLIP wiki document[1]. Looking forward
> to your feedback.
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-519%3A++Introduce+async+lookup+key+ordered+mode
> [2] https://lists.apache.org/thread/wczzjhw8g0jcbs8lw2jhtrkw858cmx5n
>
> Best,
> Xu Shuai
>