Flink之Watermark

1.乱序问题

流处理从事件产生，到流经source，再到operator，中间是有一个过程和时间的，虽然大部分情况下，流到operator的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、分布式等原因，导致乱序的产生，所谓乱序，就是指Flink接收到的事件的先后顺序不是严格按照事件的Event Time顺序排列的。

一旦出现乱序，如果只根据eventTime决定window的运行，我们不能明确数据是否全部到位，但又不能无限期的等下去，此时必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了，这个特别的机制，就是Watermark。

例如：某App会记录用户的所有点击行为，并回传日志（在网络不好的情况下，先保存在本地，延后回传）。A用户在11:02对App进行操作，B用户在11:03对App进行操作，但是A用户的网络不太稳定，回传日志延迟了，导致我们在服务端先接受到B用户11:03的消息，然后再接受到A用户11:02的消息，消息乱序了。

2.什么是Watermark

Watermark是Apache Flink提出的一种用来解决乱序、延迟数据等情况的解决方案。

它是建立在事件时间上的一个概念，用来刻画数据流的完整性。如果按照处理时间来衡量事件，一切都是有序的、完美的，自然而然也就不需要Watermark了。换句话说事件时间带来了乱序的问题，而Watermark就是用来解决乱序问题。所谓的乱序，其实就是有事件延迟了，对于延迟的元素，我们不可能无限期的等下去，必须要有一种机制来保证一个特定的时间后，必须触发Window进行计算。这个特别的机制,就是Watermark,它告诉了算子延迟到达的消息不应该再被接收。

watermrk具体特点如下：

  • Watermark是一种衡量Event Time进展的机制。
  • Watermark是用于处理乱序事件的，通常用Watermark机制结合window来实现。
  • 数据流中的Watermark用于表示timestamp小于Watermark的数据，都已经到达了，因此，window的执行也是由Watermark触发的。
  • Watermark可以理解成一个延迟触发机制，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的maxEventTime，然后认定eventTime小于maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。
  • watermark 用来让程序自己平衡延迟和结果正确性。

3.Watermark原理

Watermark会携带一个单调递增的时间戳t，Watermark(t)表示所有时间戳不大于t的数据都已经到来了，未来小于等于t的数据不会再来，因此可以放心地触发和销毁窗口了。

当Flink,接收到数据时，会按照一定的规则去生成Watermark，这条Watermark就等于当前所有到达数据中的maExertT me"-延N时长，也就定说，Watermark是基于数据携带的时间戳生成的，一旦Watermark比当前未触发的窗口的停止时间要晚，那么就会触发相应窗口的执行。由于eventtime是由数据携带的，因此，如果运行过程中无法获取新的数据，那么没有被触发的窗口将永远都不被触发。

4.延迟数据处理机制

Watermark能够应对乱序的数据，但是真实世界中没法得到一个完美的 Watermark数值。要么没法获取到，要么耗费太大，因此实际工作中会近似 Watermark(t)之后，还有较小的概率接收到时间戳t之前的数据，在Flink中将这些数据定义为“late elements”，可以在Window中指定允许延迟的最大时间（默认为О)。

延迟事件是乱序事件的特例，和一般乱序事件不同的是它们的乱序程度超出了水位线( Watermark)的预计，导致窗口在它们到达之前已经关闭。

延迟事件出现时窗口已经关闭并产出了计算结果，对于此种情况处理的方法有3种:

  • 重新激活已经关闭的窗口并重新计算以修正结果。
  • 将延迟事件收集起来另外处理。
  • 将延迟事件视为错误消息并丢弃。

Flink默认的处理方式是第3种直接丢弃，其他两种方式分别使用Side Output和AllowedLateness。

  • Side Output机制：将延迟事件单独放入一个数据流分支，这会作为Window计算结果的副产品，以便用户获取并对其进行特殊处理。迟来的数据同样可以触发窗口，进行输出。
  • Allowed Lateness机制：允许用户设置一个允许的最大延迟时长。Flink会在窗口关闭后一直保存窗口的状态直至超过允许延迟时长，这期间的延迟事件不会被丢弃，而是默认会触发窗口重新计算。因为保存窗口状态需要额外内存，并且如果窗口计算使用了ProcessWindowFunction APl还可能使得每个延迟事件触发一次窗口的全量计算，代价比较大，所以允许延迟时长不宜设得太长，延迟事件也不宜过多。