为什么 Apache Flink 需要 Watermarks 来进行事件时间处理？

Question

有人可以正确解释事件时间戳和水印。我从文档中理解它，但不是很清楚。现实生活中的例子或外行定义会有所帮助。另外，如果可以的话，请举一个例子（连同一些可以解释它的代码片段）。提前致谢

Answer 1

这是一个示例，说明了我们为什么需要水印，以及它们是如何工作的。

在这个例子中，我们有一个带时间戳的事件流，这些事件的到达顺序有点乱，如下所示。显示的数字是事件时间时间戳，指示这些事件实际发生的时间。第一个到达的事件发生在时间 4，然后是更早发生的事件，在时间 2，依此类推：

··· 23 19 22 24 21 14 17 13 12 15 9 11 7 2 4 ?

现在想象我们正在尝试创建一个流排序器。这是一个应用程序，它在流到达时处理每个事件，并发出一个包含相同事件的新流，但按时间戳排序。

一些观察：

(1) 我们的流排序器看到的第一个元素是 4，但我们不能立即将它作为排序流的第一个元素释放。它可能已经无序到达，并且可能还有更早的事件到达。事实上，我们对这个流的未来有了一些上帝般的知识，我们可以看到我们的流排序器应该至少等到 2 到达才能产生任何结果。

结论：一些缓冲和一些延迟是必要的。

(2) 如果我们做错了，我们可能会永远等待。首先，我们的应用程序看到了时间 4 的事件，然后是时间 2 的事件。时间戳小于 2 的事件会到达吗？也许。也许不吧。我们可以永远等待，永远不会看到 1。

结论：最终我们必须勇敢地发出 2 作为排序流的开始。

(3) 然后我们需要某种策略来定义对于任何给定的带时间戳的事件，何时停止等待较早事件的到来。

这正是水印所做的——它们定义了何时停止等待较早的事件。

Flink 中的事件时间处理依赖于水印生成器，该水印生成器将特殊的时间戳元素插入到流中，称为水印。

我们的流排序器什么时候应该停止等待，并推出 2 以启动排序流？当水印以 2 或更大的时间戳到达时。

(4) 我们可以想象不同的策略来决定如何生成水印。

我们知道每个事件都会在一些延迟之后到达，并且这些延迟各不相同，因此有些事件比其他事件延迟得更多。一种简单的方法是假设这些延迟受到某个最大延迟的限制。Flink 将此策略称为有界无序水印。很容易想象更复杂的水印方法，但对于许多应用程序来说，固定延迟就足够了。

如果你想构建一个像流排序器这样的应用程序，FlinkProcessFunction是正确的构建块。它提供对事件时间计时器的访问（即，根据水印的到达触发的回调），并具有用于管理缓冲事件所需的状态的钩子，直到轮到它们被发送到下游为止。