Apache Flink 漫谈系列 - Watermark

回过头来我们在看看Watermark机制如何解决上面的问题，上面的问题在于如何将迟来的EventTime 位11的元素正确处理。要解决这个问题我们还需要先了解一下EventTime window是如何触发的? EventTime window 计算条件是当Window计算的Timer时间戳 小于等于 当前系统的Watermak的时间戳时候进行计算。

• 当Watermark的时间戳等于Event中携带的EventTime时候，上面场景(Watermark=EventTime)的计算结果如下：

上面对应的DDL(Alibaba 企业版的Flink分支)定义如下：

CREATE TABLE source( 
..., 
Event_timeTimeStamp, 
WATERMARK wk1 FOR Event_time as withOffset(Event_time, 0) 
) with ( 
... 
); 

• 如果想正确处理迟来的数据可以定义Watermark生成策略为 Watermark = EventTime -5s， 如下：

上面对应的DDL(Alibaba 企业版的Flink分支)定义如下：

CREATE TABLE source( 
..., 
Event_timeTimeStamp, 
WATERMARK wk1 FOR Event_time as withOffset(Event_time, 5000) 
) with ( 
... 
); 

上面正确处理的根源是我们采取了 延迟触发 window 计算 的方式正确处理了 Late Event. 与此同时，我们发现window的延时触发计算，也导致了下游的LATENCY变大，本例子中下游得到window的结果就延迟了5s。

多流的Watermark处理

在实际的流计算中往往一个job中会处理多个Source的数据，对Source的数据进行GroupBy分组，那么来自不同Source的相同key值会shuffle到同一个处理节点，并携带各自的Watermark，Apache Flink内部要保证Watermark要保持单调递增，多个Source的Watermark汇聚到一起时候可能不是单调自增的，这样的情况Apache Flink内部是如何处理的呢?如下图所示：

Apache Flink内部实现每一个边上只能有一个递增的Watermark， 当出现多流携带Eventtime汇聚到一起(GroupBy or Union)时候，Apache Flink会选择所有流入的Eventtime中最小的一个向下游流出。从而保证watermark的单调递增和保证数据的完整性。如下图：

小结

本节以一个流计算常见的乱序问题介绍了Apache Flink如何利用Watermark机制来处理乱序问题。本篇内容在一定程度上也体现了EventTime Window中的Trigger机制依赖了Watermark(后续Window篇章会介绍)。Watermark机制是流计算中处理乱序，正确处理Late Event的核心手段。

作者孙金城，花名 金竹，目前就职于阿里巴巴，自2015年以来一直投入于基于Apache Flink的阿里巴巴计算平台Blink的设计研发工作。

【本文为51CTO专栏作者“金竹”原创稿件，转载请联系原作者】

【编辑推荐】

1. 流计算框架 Flink 与 Storm 的性能对比
2. Apache Flink 漫谈系列 - 概述
3. Apache Flink 漫谈系列 - 序
4. 如何实现秒级百万TPS？微博WAIC实时流计算平台架构演进

（编辑：好传媒网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!