1.概述
60-300-022-使用-延迟数据-Flink中allowedLateness详细介绍
Flink对于乱序数据怎么办呢？
方案就是 watermark。
watermark，直译为水位线，就是元素可以迟到多久才去关闭窗口。例如一个窗口是[0-5),，watermark允许最多延迟3s，那么一个6s的事件，它的watermark就应该是3，一个7s的watermark是4，这两个都落在窗口中
在flink流处理的Source中或者处理window之前，都可以通过调用assignTimestampsAndWatermarks来指定如何从消息中获得当前事件时间和获得当前事件的watermark。可以直接扩展几个预定义的类实现。默认watermark是0，也即watermark时间等于事件时间。watermark不是对每一条数据都会生成的，默认配置每200ms生成一次，可以通过env.getConfig().setAutoWatermarkInterval()配置产生间隔。
此外，flink还允许在流处理window后设定allow lateness来指定一个最晚的时间，没有超过这个最晚时间，window还是未销毁，可以触发计算。（默认的lateness也是0）
2. 那么watermark和lateness区别在哪里呢？
这个主要是配合trigger的行为，默认的EventTimeTrigger，之前的元素是不触发window计算的，在watermark达到window end的时候，会触发一次window计算；之后的每一个迟到的元素进入窗口，都会触发一次window计算。所以watermark是保证大部分元素的时间落在windowend+watermark的区间内，减少window计算的触发次数。如果是其他trigger方式，watermark的意义不大。窗口触发计算时，会将窗口数据传给后续的处理过程处理。
很多地方把概念会搞混：
- 事件时间
<窗口end+watermark大小，元素落在窗口内 - flink返回的watermark时间=
事件时间-watermark大小 - watermark时间
<窗口end，元素落在窗口内
如上所述，EventTimeTrigger等一些默认的trigger，在watermark时间达到window end之前是不会触发的，如果事件有一段时间暂停了没有新元素，或者窗口期很长，则导致一直没有触发计算获得结果，延迟比较大，这时候可以使用ContinuousProcessingTimeTrigger。
对于延迟的数据，也可以定时可以把它揪出来处理。通过对WindowedStream设置sideOutputLateData，之后从WindowedStream处理的结果SingleOutputStreamOperator的getSideOutput(OutputTag)方法得到被丢弃的数据（这个是需要定时任务去处理）
只有所有的线程的最小watermark都满足watermark 时间 >= window_end_time时，触发历史窗才会执行。