Piotr Pawlaczek
07/21/2023, 10:19 AMCURRENT_WATERMARK() function works in Flink SQL.
Let’s say I have a source table:
create table source (
symbol STRING,
ts TIMESTAMP,
WATERMARK FOR ts AS ts - INTERVAL '1' MINUTE
)
WITH (
….kafka connection properties….
);
Now I have some windows aggregation:
CREATE VIEW windows_1m AS (
select symbol, count(*), window_start, window_end
from TABLE(TUMBLE(TABLE source, DESCRIPTOR(ts), INTERVAL '1' MINUTE))
GROUP by symbol, window_start, window_end
)
But I would like also to identify late events, so I take:
CREATE VIEW events_with_current_watermark AS (
select *, CURRENT_WATERMARK(ts)
from source
);
Now I insert both my windows_1m and events_with_current_watermark into jdbc DB.
Let’s say my DB tables look like:
windows_1m:
symbol|count |window_start |window_end |
------+--------------------------+-------------------+
s1 |1 |2023-07-20 07:04:00|2023-07-20 07:05:00|
events_with_current_watermark:
symbol|ts |current_watermark |
------+-----------------------+-----------------------+
s1 |2023-07-20 07:04:01.429|2023-07-20 07:04:16.612|
so in my DB in events_with_current_watermark table the event seems to be late (ts < current_watermark)
however 1 minute window was created and contains this particular event (so while processing it wasn’t late?)
I’m quite confused, could it be that saving events_with_current_watermark to DB was after processing windows (windows_1m) and CURRENT_WATERMARK(ts) returned different values corresponding to different points in time?Martijn Visser
07/21/2023, 11:57 AMMartijn Visser
07/21/2023, 11:59 AMPiotr Pawlaczek
07/21/2023, 1:00 PMCURRENT_WATERMARK() function.
shouldn’t CURRENT_WATERMARK() return the same, deterministic value at every stage of processing?
in the above example we see event that was processed within allowed out of orderness (and put into window) but at the same time source data with current_watermark value attached suggests it was a late event and should be ignored.
isn’t it contradictive?Martijn Visser
07/21/2023, 1:16 PMPiotr Pawlaczek
07/21/2023, 2:05 PMevents_with_current_watermark) uses different watermark for current_watermark column? so in other words current_watermark() value doesn’t correspond to given event but to the current ts in source?Piotr Pawlaczek
07/21/2023, 2:06 PMPiotr Pawlaczek
07/21/2023, 2:11 PMcurrent_watermark() function in the same time doesn’t guarantee the returned timestamp will be equal?
that would be even fine since the watermark changes dynamically depending on the values in source but with the setup above the difference between blue and red are sometimes > 1 minPiotr Pawlaczek
07/21/2023, 2:13 PMPiotr Pawlaczek
07/21/2023, 2:14 PMPiotr Pawlaczek
07/21/2023, 2:17 PMcreate table source (
symbol STRING,
ts TIMESTAMP,
WATERMARK FOR ts AS ts - INTERVAL '1' MINUTE
)
WITH (
….kafka connection properties….
);
create view events AS (
SELECT
symbol,
ts
FROM source where ts > CURRENT_WATERMARK(ts)
);
create view late_events AS (
SELECT
symbol,
ts
FROM source where ts <= CURRENT_WATERMARK(ts)
);
and then create windows based only on events table:
CREATE VIEW windows_1m AS (
select symbol, count(*), window_start, window_end
from TABLE(TUMBLE(TABLE events, DESCRIPTOR(ts), INTERVAL '1' MINUTE))
GROUP by symbol, window_start, window_end
)
is this aproach correct? 🔼