虽然在找理由，但是没有时间总结了关于flink的知识点，终于下定了决心。 之后，我集中精力总结了flink的主题。 想想还是从watermark开始。 本文谈谈个人对watermark的理解。 如果有什么不合适的地方，欢迎讨论。 一开始我对Flink上的watermark有点困惑，但随着时间的推移，它沉淀了下来，源代码中断了，我读了起来。 稍微清楚一点。 我从几个概念说起。
1、时间属性Flink公式有三种时间类型。 Event Time (事件时间)、Processing Time (处理时间)、Ingestion Time (摄取时间)、摄取时间)在字面上很容易理解，所以再叙述一次其中的一个。
事件时间:一般来说，我们提供的事件时间通常是数据的原始创建时间，表示事件发生的时间。 事件时间必须在数据的体系结构中成为有数据的列。
处理时间:系统处理事件的本地系统时间。
摄入时间链接系统中事件进入的时间概念上介于事件时间和蒂姆处理之间，内部摄取时间和事件时间非常相似，但具有自动时间戳分配和自动水印生成功能。
谈论这三个时间主要是为了引出watemark。 因为，在很多场合，事件发生的时间事件时间是我们的业务所关心的。 在事件时间计算的基础上，采用某种策略，无论是采用实时的流媒体数据，还是采用历史数据，结果始终都是为了更生动地刻画事件时间与事件流入系统(这里指Flink )之间的关系。 其中的数字表示某个事件的发生时间。
在实时流计算中，可以通过从一个元素处理一个元素来实时处理。 但是，一些基于Event Time的APP应用要求处理的准确性，并且必须进行缓存。 因为不知道第一个事件例如5到达时，后面的事件是否比当前事件早发生，所以至少在第二个事件到达之前必须决定是否输出第一个事件的计算结果，这会导致延迟。
但是，在第二个事件3到达后，有没有比事件3发生的事件更早的事件？ 要继续等缓存吗？ 如果等的话，要等多久？ 因此，需要保证不等待的机制策略来触发当前缓存数据的计算和输出。
那么，现在的计算已经计算出来并输出了，如果更早发生的事件晚到了，怎么办？ 如上图所示，假设在事件9中触发计算并输出了结果。 但是，下面的活动8到了。 我们考虑了两种处理策略。 1、将事件8添加到上次缓存数据并重新计算输出； 2 )处置)不计算第二种策略处置)不计算处理。 第一个策略需要上次的缓存数据。 在这里又要面对一两个问题。 1、上次缓存数据计算后不能清除缓存； 2 )缓存保留多久？ 这是因为，如果继续保留缓存，则会出现系统整体内存压力增加等问题。
带着这些问题，我们进入了Flink。 Flink的watermark机制和lateness的概念对于上述问题得到了很好的全面解读。
注：本文主要论述Flink使用事件时间，因为Flink的缺省实时属性为处理时间。 需要经由Flink的接口env.setstreamtimecharacteristic (timecharacteristic.evee ristic ) 2、水印原理水印是事件时间通常，一条记录中的字段表示该记录发生的时间。 例如，基于事件时间的数据包含timestamp类型的字段rowtime，例如1543903383 (2018-12-041433600336003 )，并且策略是偏移3s
1543903383-3000=1543900383 (2018-12-041433600336000 )
此数据水印时间的含义： timestamp小于1543900383 (2018-12-041433600336000 )的数据全部到达。
2.1、在窗口触发条件下，对于数据乱序问题的处理机制是watermark window，那么window应该在什么时候触发呢？
基于Event Time的事件处理，Flink的默认事件触发条件如下：
对于出单和正常数据
1 ) watermark时间戳=窗口结束时间
2 )在window上发生了事件。
2 )如果late element包含过多的数据(设置了lateness选项，默认值为0 ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )。
1 )事件时间警告的时间戳
2.2、图解水印
mark对于lateness选项我们先不考虑，后面再再提及。
我们设置一个偏移为5秒的watermark策略，大小为10秒的窗口，为了能更好的理解watermark，我们作如下类比，数据发生的时间空间为A时间空间，watermark的时间空间为B时间空间，则B时间空间总比A时间空间晚5秒发生。
如上图，矩形小框代表窗口大小，大小为10秒，Flink默认会根据选择的时间（这里是Event Time）分配窗口。假设数据发生的时间rowtime从0开始，则预先分配的窗口即使[0,10），[10,20]，[20,30]，[30,40] ......
A时间轴上的时刻是一定的，同样B时间轴上的时刻也是一定的，B空间时间轴上的时刻相对A时刻轴上的时刻总是晚5秒。在同一时间坐标系S下，假设S时间坐标和A时间一样，则A时间轴上的时刻在S坐标系下时间值不变，但B时间轴上的时刻在S时间坐标系下时间值都变“大” 5s了。即在第一个窗口[0,10]，如果一个记录中rowtime为10s的数据在S坐标系下9s到达了，但是其watemark其实是10-5 = 5s，还没有到达第一个窗口的end Time，故不会触发窗口计算；如果一个记录中rowtime为8s的数据在S坐标系下12s到达了，但其watermark其实是8-5=3s小于之前的watermark，故此时不更新watermark(一般情况下)，watermark的时间戳仍然是5秒，也没有达到第一个窗口的触发条件；如果一个记录中rowtime为12s的数据在S坐标系下13s到达了，其watemark其实是12-5 = 7 > 5，更新watermark的时间戳为7秒，但是也没有达到一个窗口的触发条件；如果一个记录中rowtime为15s的数据到达了，其watemark其实是15 -5 = 10s，达到了触发条件 ，大于window endTime，故窗口此时触发计算，如果后面再有rowtime<10s的数据到达，将会被丢弃(没有设置latness选项)。
这样看是不是感觉计算”延迟了5秒”，确实，计算延迟了，但是计算的延迟是针对设置的时间属性延迟的，这里是EVENTTIME，和系统时间没有关系。
2.3、Late Elements某些元素有可能在watermark（t）发生之后，也会出现更多的时间戳t'<= t的元素。上文我们提到，默认情况下，当watermark> = Window EndTime后，这些晚到的元素将会被丢弃。但是现实业务处理中，我们又不希望丢弃这些元素，如果设置的watermark太大，数据积压又会导致系统性能下降。考虑到这一点，Flink允许为窗口指定一个最大延迟时间，这个最大延迟时间即是窗口触发计算后允许多长时间窗口的数据才能被删除，默认值为0。即当该窗口触发计算后，在最大延迟时间内，再有属于该窗口内的元素到达将会重新触发计算。
假设Flink设置的watermark允许延迟的策略为t1秒，设置的late Elements的lateness值为t2秒，窗口首次触发的的系统时间为t(假设已经转化为秒)，则这些late Elements到达的系统时间如果在[t, t+t2)时间内，将会再次触发计算。