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及时流计较平台架构演进

（编辑：湖南网）

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