WaterMark 实战
- [1.WaterMark 触发详解](#1.WaterMark 触发详解)
- 2.实际案例
1.WaterMark 触发详解
例如,现在我们有了一个 [12:00:00-12:00:10)
的时间窗口,现在事件如下图所示顺序 A、B、C、D、E、F ... 到达。
在未设置 WaterMark 的情况下,当元素 C 到达的时候,便会触发窗口 [12:00:00-12:00:10)
进行计算,因为 C 元素的时间已经满足大于等于窗口 [12:00:00-12:00:10)
的结束时间 12:00:10
了。
此时呢,该窗口中仅会有 A、B 两个元素,如果从事件时间划分来讲,D、F 应也属于窗口 [12:00:00-12:00:10)
内的元素,但是由于 C 提前到来(D、F 延迟了)触发了计算,因 Flink 时间窗口的生命周期限制,[12:00:00-12:00:10)
这个窗口,再也不会打开。
其最后将导致 D、F 再无可归属窗口,D、F 因此成了无用数据,最终会被抛弃掉!
当我们引入了 WaterMark 水印机制,设置了延迟时间后,事件时间窗口的触发时机由事件时间决定变为了由 WaterMark 决定
比如我们现在设置了窗口允许数据最大延迟时间为 5s
。
- A 数据到达:WaterMark =
max{12:00:01} - 5
=11:59:56
< 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,不会触发计算。 - B 数据到达:WaterMark =
max{12:00:05,12:00:01} - 5
=12:00:0
< 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,不会触发计算。 - C 数据到达:WaterMark =
max{12:00:11,12:00:05,12:00:01} - 5
=12:00:06
< 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,不会触发计算。 - D 数据到达:WaterMark =
max{12:00:08,12:00:11,12:00:05,12:00:01} - 5
=12:00:06
< 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,不会触发计算。 - ...... 直到
某一个事件时间 - 5
>= 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,才会触发窗口[12:00:00-12:00:10)
计算! - G 数据据到达:WaterMark =
max{12:00:15,12:00:09,12:00:08,12:00:11,12:00:05,12:00:01} - 5
=12:00:10
= 窗口[12:00:00-12:00:10)
的结束时间12:00:10
,此时窗口[12:00:00-12:00:10)
的归属元素有 A、B、D、F,窗口存在元素,会触发计算!!!!
- 1️⃣ WaterMark 只是决定了窗口的触发时机,并非可以改变元素归属的窗口(事件应归属的窗口是由事件本身的事件时间决定的),例如上方元素 C、G,虽然根据设置的延迟时间可能触发窗口
[12:00:00-12:00:10)
计算,但其本身时间不归属于窗口之内,因为窗口[12:00:00-12:00:10)
中永远不会有 >=12:00:10
的元素存在。- 2️⃣ WaterMark 可以在一定程度上解决事件乱序问题,但严重的乱序问题依然无法解决!
例如,在事件 G 后又来了事件 H(乱序比较严重!!因为前边元素都 12:00:15
了,自己反而才 12:00:07
)。如果设置的允许最大延迟时间为 5s
,元素 G 依然满足触发窗口 [12:00:00-12:00:10)
计算销毁,后来的元素 H 便再无可归属的时间窗口了,所以 H 仍然会丢失!!
基于这种情况,如果想避免 H 数据丢失怎么办呢?我们可以让 G 无法触发窗口 [12:00:00-12:00:10)
就行,即允许延迟时间再设置大一点,比如允许延迟 10s
... 延迟 10s
后,至少有了事件时间为 12:00:20
的事件到来才会触发计算了,这样 H 就不会丢了。但如此设置,又避免不了更延迟的数据,比如延迟了 20s
的数据,所以说,WaterMark 只能在一定程度上解决乱序问题!!
当然以上情况,我们可以结合侧位输出来收集更为延迟的数据,避免延迟数据丢失(这个后边会讲),但是!事件时间延迟,主要问题在生产端!如果真要解决这个问题,应该从生产事件的生产端入手,而非极力依托于计算框架!!
2.实际案例
我们定义一个 10s
的滚动窗口,且允许数据最大延迟为 5s
。
sql
CREATE TABLE user_income (
income INT,
times TIMESTAMP(3),
WATERMARK FOR times AS times - INTERVAL '5' SECOND
) WITH (
'connector' = 'filesystem',
'path' = 'input/sales04.csv',
'format' = 'csv'
);
CREATE TABLE output (
win_start TIMESTAMP(3),
win_end TIMESTAMP(3),
hour_income BIGINT
) WITH (
'connector' = 'print'
);
INSERT INTO output
SELECT
TUMBLE_START(times,INTERVAL '10' SECOND),
TUMBLE_END(times,INTERVAL '10' SECOND),
SUM(income)
FROM user_income
GROUP BY TUMBLE(times,INTERVAL '10' SECOND);
构造测试数据
sql
10,2021-05-27 22:12:53
10,2021-05-27 22:12:58
10,2021-05-27 22:13:04 -- 不会触发窗口 [2021-05-27 22:12:50, 2021-05-27 22:13:00) 的计算
10,2021-05-27 22:13:03 -- 不会触发窗口 [2021-05-27 22:12:50, 2021-05-27 22:13:00) 的计算
10,2021-05-27 22:12:58
10,2021-05-27 22:13:03 -- 不会触发窗口 [2021-05-27 22:12:50, 2021-05-27 22:13:00) 的计算
10,2021-05-27 22:12:52
10,2021-05-27 22:12:52
10,2021-05-27 22:12:58
10,2021-05-27 22:13:05 -- 将会触发窗口 [2021-05-27 22:12:50, 2021-05-27 22:13:00) 的计算
10,2021-05-27 22:12:59 -- 该条数据所属窗口已经触发了计算,该条数据将会被抛弃
10,2021-05-27 22:13:19 -- 将会触发窗口 [2021-05-27 22:13:00, 2021-05-27 22:13:10) 的计算
运行结果如下: