2
时间窗口的每一次计算都是由watermark触发的。flink对于event的处理，只负责判断其所含的时间戳该进入哪个桶。
3
-2
2
flink解决迟到/乱序数据的三种方法： *事件时间语义下使用watermark---source算子后调用assignTimestampsAndWatermarks *延迟窗口关闭---timeWindow算子后调用allowedLateness *使用侧输出流---timeWindow算子后(紧接着allowedLateness)调用sideOutputLateData
4
5
6
8
68
.......
1
7
3
一个时间窗口的本质是一个桶，区间大小是左闭右开
谈谈对 watermark 的理解： 由于 flink 是分布式计算框架且各节点的处理性能和网络速度不一致，会导致数据从上游节点往下游分发的时候出现乱序的现象。而 watermark 正是 flink 在设计中通过允许一定程度上的延迟来解决数据乱序问题的。 注意，watermark 是基于 EventTime机制的，ProcessingTime 没有所谓的水位线。 flink 认为在水位线之前的事件都按时到达了，然后根据水位线触发时间窗口的计算。也就是说事件时间机制下的TimeWindow的触发/关闭是由 watermark 决定的。 watermark 用来让程序自己平衡延迟和结果正确性。
*该watermark表示在这第5s之span style=\"font-size: inherit;\
65
watermark的特点： *watermark 与数据的时间戳相关。 *watermark 必须单调递增，以确保任务的事件时间时钟在向前推进，而不是在后退。 *watermark 是一条特殊的数据记录，通过周期性和非周期性生成。程序可以分别实现接口AssignerWithPeriodicWatermarks和AssignerWithPunctuatedWatermarks。例子详见代码类 CustomerSourceDisorderByEventTime 和 CustomerSourceDisorderWithWaterMark
eventwatermark
watermark在任务之间的传递： 由于flink是分布式框架，任务具有并行度，每个subtask的上下游均有可能有多个任务线程。 subtask接收到上游发送的多个watermark后，由于木桶短板效应，会取多个watermark之中最小的那个作为自己的水位线，然后再向下游广播这个watermark。（如果两次的watermark值相同，则flink会节省资源，不会向下游进行广播。）
事 件 流
