[
https://issues.apache.org/jira/browse/FLINK-29692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623481#comment-17623481
]
Benchao Li commented on FLINK-29692:
------------------------------------
{quote}'Early fire' would periodically sent intermediate result to downstream,
the frequency to send intermediate result is based on processing time, even
thought the window itself based on event time. It mixed up processing time
semantics with the time attribute of Window.
{quote}
I agree, it's not perfect.
{quote}If you need to retire window state and send intermediate result, how
about trying "[cumulate window
tvf|https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/dev/table/sql/queries/window-tvf/#cumulate]";
instead of 'early fire'?
{quote}
Cumulate window could cover most cases, except that it's semantic is different
from others (unbounded aggregate and window with early-fire's output semantic
is changelog for the same grouping key).
> Support early/late fires for Windowing TVFs
> -------------------------------------------
>
> Key: FLINK-29692
> URL: https://issues.apache.org/jira/browse/FLINK-29692
> Project: Flink
> Issue Type: New Feature
> Components: Table SQL / Planner
> Affects Versions: 1.15.2
> Reporter: Canope Nerda
> Priority: Major
>
> I have cases where I need to 1) output data as soon as possible and 2) handle
> late arriving data to achieve eventual correctness. In the logic, I need to
> do window deduplication which is based on Windowing TVFs and according to
> source code, early/late fires are not supported yet in Windowing TVFs.
> Actually 1) contradicts with 2). Without early/late fires, we had to
> compromise, either live with fresh incorrect data or tolerate excess latency
> for correctness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
