Flink中的Watermark是什么原理？它有什么用？

Flink中的Watermark是什么？它有什么用？

本文旨在理解，不谈代码。如有谬误，感谢指正。

附上官方文档链接

在流计算中事件的发生时间(Event time)和处理时间(processing time)是两个不同的概念。Flink假设数据到达是乱序的，这是著名流计算模型DataFlow的一个基本假设，也符合我们在分布式系统中的常识。简单地说，就是出于网络延迟等原因，来自不同地方的数据到达算子并被处理的时间（processing time）顺序与数据产生时的时间的（event time）顺序不同。这就会为我们做事件时间的窗口统计（event-time windowing）带来一些麻烦。

我们来假想一个场景。我们在收银台采集客户进入排队区的时间，并根据一段时间内进入排队区的客户数量，来决定接下来的一段时间在收银台配置多少员工收银（是的，这不是个好办法:P）。比如，之前十分钟共有10个人排队，接下来十分钟就只配置1个员工。之前有20个人排队，接下来10分钟就配置2个员工。我们在排队区装了两个传感器作为数据源，各自负责不同的范围（假设顾客不会同时触发两个传感器）。每当一个顾客进入其中一个的感应范围，就产生一条携带当前时间的数据（event time）。这些数据会被发送给一个计数的算子。乱序假设意味着如果一个客人在7:00开始排队(event time)并触发传感器A，另一个客人在7:30开始排队并触发传感器B，则7:30的这条数据可能要比7:00的数据更早到达算子并被处理(processing time)。一个可能的场景是：传感器A在发送7:00的数据之前出现了网络故障，所以它暂时将数据缓存起来。网络在B的7:30的数据被算子收到之后才恢复，这时A才将7:00的数据发出去。从另一个角度看乱序问题，我们会发现当算子看到7:30的数据时，它并不能确定之后会不会收到比7:30更早的数据。

假如我们要统计7:00-7:10这个时间窗口内有多少客人在排队，那我们要什么时候进行最终的统计才能确保数据的准确性呢？显然，我们统计的越晚，数据准确的可能性就越大（乱序的数据陆陆续续的都来了）。但是，如果7:00-7:10有很多人排队，急需增加收银员，我们在9:00才去统计，那等我们统计完并且决定增派人手的时候，排队的顾客早就结完账了，我们的程序就失去了意义。所以，在流计算中我们经常要在准确性和时效性之间做出取舍。我们可能会决定说，过了7:11，没到的数据就不统计了，我们就依据当前算子已有的数据决定配置多少收银员。如果真的有7:00-7:10的数据在7:11之后到达算子，我们再去订正统计结果（但是这个时候，决策已经做出了）。

DataFlow模型中使用了“Watermark”的概念来对应我们上述的场景，这个概念也被实现在Flink中。我们在流计算中把数据流类比为水流。watermark（水位线）表示当前的event time到了什么时候。这个类比非常形象，给算子输入数据流就像是在往水槽里灌水，在当前水位线以下的水肯定都是之前流进来的。在flink中，watermark也会像数据一样传输给下游。上面的例子中，我们决定在7:11统计7:00-7:10这个窗口并做出决策，也就是说我们觉得：“一分钟之内，新产生的数据一般能到达算子”，或者我们认为“7:11之后，7:00-7:10窗口中的数据将失去价值”，又或者是这二者之间的权衡。总之，两个数据源会各自不断地发出时间戳为一分钟之前的watermark。比如在7:10的时候发出7:09的watermark、在7:11的时候，发出带有7:10时间戳的watermark。而当算子收到两个数据源的watermark，安全起见会取两者中更早的那一个作为最终的watermark。当最终的watermark更新到7:10时，算子就明白了：“可以统计7:10之前的窗口数据了”。

顺带一提，我们可以对这些迟到的数据（比watermark标记的时间戳更早，但比watermark到达算子更晚的数据）进行特殊的处理。我们可以设置一个最大容忍时间（Flink默认是0，即直接丢弃），在这段时间内的迟到数据还是会被算入window里面，并且使新的window结果被重新发送。如果超过可容忍的时间，它依然会被丢弃。除了更新window和丢弃，我们还可以将迟到数据写入日志，用作日后处理历史数据时获取精准的结果。这都取决于应用的具体需求。

简单地说，flink中的watermark是为了让我们能够权衡event-time windowing的结果的准确性和时效性的手段。准确性和时效性的矛盾源自与数据的乱序问题。