Flink学习笔记-窗口触发和乱序处理

通常来讲，由于各种原因，包含但不限于网络、背压，外部系统因素等，事件数据往往不能够及时传输到Flink系统中进行计算，因此，在开启EventTime的前提下，flink提供了一种依据watermark机制结合window来实现对乱序数据的处理的方式。

Flink窗口函数触发机制

• 首先，flink窗口函数的时间是按照自然时间划分的，如下

timeWindow(Time.seconds(10))

上诉代码的含义是窗口大小是十秒，也就是说按照自然时间划分的话，会将一分钟时间切成六份，每份十秒，且区间为半开半闭。

• 然后在数据流转到window算子的过程中，系统会根据事件的EventTime，将数据划分到属于它的窗口（window）中。例如：当前数据的EventTime是2019-06-23 12:00:01 ，那么这个事件会被分配到 [ 2019-06-23 12:00:00, 2019-06-23 12:00:10) 这个区间
• 具体的触发需要满足规则如下：（1）窗口中有数据 （2）窗口中不存在数据EventTime大于watermark时间（3）watermark >=window_end_time，当水位线真正大于window_end_time 时才会真正触发计算
• 关于什么是window_end_time：在window区间内可以认为有两个基本的概念window_start_time和window_end_time，顾名思义，window_start_time代表的是区间的起始时间，而window_end_time代表的是window时间区间的结束时间。以上诉[ 2019-06-23 12:00:00, 2019-06-23 12:00:10) 区间为例，那么12:00:00就是window_start_time，12:00:10就是window_end_time。

out-of-order数据处理

• 关于Flink的乱序处理，实际上可以简单理解为配置的EventTime和watermark的差值就是系统能容忍的事件最长迟到时间。
• 一定范围内的乱序数据可以被flink的数据乱序处理机制解决掉，但是如果事件乱序太多，“迟到”太多，则flink的机制无法保证数据计算的正确性。正常情况下，如果maxOutOfOrderness设置合理，不会产生太多“迟到”事件，我们假设maxOutOfOrderness为10秒，window算子时间区间为3秒，此刻水位线为14:30:22 ，也就是说最新数据为14:30:32，如果有一条乱序数据（迟到9秒，eventtime为14:30:23）进入，那么此刻水位线不改变，且会将这条数据放到区间 为[ 14:30:21, 14:30:24)的window中， 而此刻watermark（14:30:22）< window end time（14:30:24），因此不触发计算。也就是说目前为止，迟到9秒的数据都可以被分配到正确的window中且被正确处理，但是一旦超过10秒并且是大量数据均超过10秒，事件时间超过10秒说明此事件时间等同于水位线，如果此刻刚好水位线大于等于window end time那么第一条超过10秒的late element就会直接触发window计算，后边的late element到来只会来一条触发一次，所以推导出 对于late element太多的数据而言，watermark时间 > Event Time会直接触发window计算，可能会影响计算的准确性。
• 何为事件“迟到”太多？无非就是Flink的maxOutOfOrderness设置太小（使用BoundedOutOfOrdernessTimestampExtractor前提下），而实际业务中因为各种原因导致数据延迟时间总是大于设置的maxOutOfOrderness，可以推断此刻的watermark已经上升到了一定的程度，足够大于late element的window end time，因而导致，来一条late element就触发一次window。