并行流中的 Watermark
Watermark
在源函数处或源函数之后直接生成。源函数的每个并行子任务通常独立生成其水印。这些水印定义了该特定并行源处的事件时间。
随着 Watermark
在流媒体程序中的流动,它们会提前到达其到达的 Operator
的 Event Time
。每当 Operator
提前其事件时间时,都会为其后续 Operator
在下游生成新的 Watermark
。
一些运算符消费多个输入流;例如,并集 union
、键控 keyBy(…)
或分区 partition(…)
函数的运算符。这样的 Operator
的当前事件时间是其输入流的事件时间中的最小值。随着其输入流更新其事件时间,Operator
也将更新。
下图显示了流过并行流的事件和 Watermark
的示例,Operator
跟踪事件时间。(并行流用的不多,这里留个坑吧,待之后用到再来补=-=)
延迟的元素
某些元素可能会违反 Watermark
条件,这意味着即使在发生 Watermark(t)
之后,也会出现更多时间戳为 t'<= t
的元素。实际上,在许多现实世界的设置中,某些元素可以任意延迟,从而无法指定某个事件时间戳记的所有元素都将发生的时间。此外,即使可以限制延迟,通常也不希望将 Watermark
延迟太多,因为这会导致事件时间窗的评估延迟过多。
由于这个原因,流式传输程序可能会明确期望某些延迟元素。延迟元素是指系统的事件时间时钟(由 Watermark
指示)在经过延迟元素时间戳之后的时间到达的元素。有关如何在事件时间窗口中使用延迟元素的更多信息,请参见允许延迟。
Watermark 实际使用例子
- Generating Timestamps / Watermarks
- Flink Watermark 机制浅析
看了这两篇文章后,能对 Watermark
的设置有个基础的了解,在实际场景中,需要评估下面两者:定期 Watermark
或标点 Watermark
,了解两者差别后才使用。
总结
本篇主要讲了三种时间类型:Processing Time
、Event Time
和 Ingestion Time
,了解了它们所发生的位置,三者的使用差别,以及 Watermark
与 事件时间 Event Time
的关系,可以使用 Watermark
来解决乱序的事件流,请参考实际使用例子的链接,调整算法来达到你所需要解决的实际场景~
以及本篇时间 Time
的介绍有点“太干”,学起来有点费力,如有其它学习建议或文章不对之处,请与我联系~
项目地址
https://github.com/Vip-Augus/flink-learning-note
git clone https://github.com/Vip-Augus/flink-learning-note
参考资料
- Event Time
- Flink 从 0 到 1 学习 —— Flink 中几种 Time 详解
- Flink Watermark 机制浅析
- Flink 小贴士 (3): 轻松理解 Watermark
- Generating Timestamps / Watermarks
- 允许延迟