Thanks!
On Tue, Jan 12, 2021 at 1:56 AM Yuan Mei wrote:
>
>> It sounds like any state which does not have some form of uniqueness
>> could end up being incorrect.
>>
>> at least once usually works if the use case can tolerate a certain level
> of duplication or the computation is idempotent.
>
>
>
>
> It sounds like any state which does not have some form of uniqueness could
> end up being incorrect.
>
> at least once usually works if the use case can tolerate a certain level
of duplication or the computation is idempotent.
> Specifically in my case, all rows passing through the executio
Thanks for the info.
It sounds like any state which does not have some form of uniqueness could
end up being incorrect.
Specifically in my case, all rows passing through the execution graph have
unique ids. However, any operator from groupby foreign_key then sum/count
could end up with an inconsi
Hey Rex,
You probably will find the link below helpful; it explains how
at-least-once (does not have alignment) is different
from exactly-once(needs alignment). It also explains how the
alignment phase is skipped in the at-least-once mode.
https://ci.apache.org/projects/flink/flink-docs-release-1
Hello,
We're using the TableAPI and want to optimize for checkpoint alignment
times. We received some advice to possibly use at-least-once. I'd like to
understand how checkpointing works in at-least-once mode so I understand
the caveats and can evaluate whether or not that will work for us.
Thank
