Hi Rex,
sorry for replying so late. Yes, your summary should be correct.
In many cases this processing time stress on restore is the reason why
people select event time eventually. But if that is fine for your use
case, that's great.
Regards,
Timo
On 05.02.21 06:26, Rex Fenley wrote:
So if
So if I'm reading this correctly, on checkpoint restore, if current machine
time / proc time > checkpointed window proc time, the window will fire
immediately with all the data it had aggregated. If current machine time <
window proc time, the window will just continue where it left off until it
hi
As far as I know, we support ROW_NUMBER in SQL that could give you
sequence number.
Regarding window semantics, the processing time only determines when to
trigger the evaluation (also mentioned here [1]). A timer is registered
for the next evaluation. The window content and next timer is part
We need to aggregate in precisely row order. Is there a safe way to do
this? Maybe with some sort of row time sequence number?
As written in another email, we're currently doing the following set of
operations
val compactedUserDocsStream = userDocsStream
.window(TumblingProcessingTimeWindows.of(Ti
Hi Rex,
processing-time gives you no alignment of operators across nodes. Each
operation works with its local machine clock that might be interrupted
by the OS, Java garbage collector, etc. It is always a best effort timing.
Regards,
Timo
On 27.01.21 18:16, Rex Fenley wrote:
Hello,
I'm lo
Hello,
I'm looking at ways to deduplicate data and found [1], but does proctime
get committed with operators? How does this work against clock skew on
different machines?
Thanks
[1]
https://ci.apache.org/projects/flink/flink-docs-release-1.11/dev/table/sql/queries.html#deduplication
--
Rex Fe
