Apache Flink中Watermark、Window、State三者的关系

最新推荐文章于 2025-03-07 18:15:42 发布

Quan.S

最新推荐文章于 2025-03-07 18:15:42 发布

阅读量2.4k

点赞数 3

分类专栏： Flink 文章标签： flink window watermark state 源码

本文链接：https://blog.csdn.net/xianzhen376/article/details/90415350

版权

本文探讨Apache Flink中的Watermark、Window和State的关系。Watermark是触发time window的时间依据，用于处理数据乱序问题；Window提供数据切分机制，与Watermark结合应对时间不一致；State则记录中间状态，对数据恢复至关重要。文中通过源码分析，解释了Window和Watermark基于key的工作原理，以及它们与State的关联。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

Watermark、Window和State是Apache Flink的三个高光名词，也是大家在实际应用中利器。

Watermark致力于解决数据的乱序和延迟问题；
Window尽心尽力提供各种数据切分机制；
State勤勤恳恳记录中间状态，并在数据恢复等场景承担着重要的角色。

这三个算得上是Flink的模范标兵。大家有想过三者之间的关系么，咱们从几个问题来探讨吧。

理想三问

Watermark和Window的关系？
Window和Watermark是基于key的么?
Window和State的关系？

下文主要是从上面三个点予以说明。源码版本1.6.1

Watermark和Window的关系

这个问题，Flink初学者的一个必然思考。官网已经予以了非常详尽的解释，如果鸡蛋里挑骨头，那就是英文对广大底层劳动人民不够友好，说的不够直接。能用最简单的语言去说清楚么？尝试下：watermark是触发time window的时间依据。

具体来说，Window可以为流提供分段处理机制， Watermark则主要应对数据时间乱序问题。在实际应用中，数据源往往很多个且时钟无法严格同步，数据汇集过程中传输的距离和速度也必然不同，在上游多节点处理过程中的处理速度也有差异，这些因素使得event time的乱序基本是一个必然现象。这样也可以理解Watermark对非time window类的操作没有什么意义。

下面代码是element处理过程中判断是否要触发窗口计算的逻辑，从中就可以看出Window和Watermark在代码层面的关联关系：

//From EventTimeTrigger.java
@Override
public TriggerResult onElement(Object element, long timestamp, TimeWindow window, TriggerContext ctx) throws Exception {
   
	if (window.maxTimestamp() <= ctx.getCurrentWatermark()) {
   
		// if the watermark is already past the window fire immediately
		// 触发窗口计算
		return TriggerResult.FIRE;
	} else {
   
		// 继续，不触发窗口计算
		ctx.registerEventTimeTimer(window.maxTimestamp());
		return TriggerResult.CONTINUE;
	}
}