转载自Jark's Blog,文末有详细信息。

当人们第一次使用 Flink 时,经常会对 watermark 感到困惑。但其实 watermark 并不复杂。让我们通过一个简单的例子来说明为什么我们需要 watermark,以及它的工作机制是什么样的。

在 Apache Flink 中使用 watermark 的 4 个理解

在下文中的例子中,我们有一个带有时间戳的事件流,但是由于某种原因它们并不是按顺序到达的。图中的数字代表事件发生的时间戳。第一个到达的事件发生在时间 4,然后它后面跟着的是发生在更早时间(时间 2)的事件,以此类推:

注意这是一个按照事件时间处理的例子,这意味着时间戳反映的是事件发生的时间,而不是处理事件的时间。事件时间(Event-Time)处理的强大之处在于,无论是在处理实时的数据还是重新处理历史的数据,基于事件时间创建的流计算应用都能保证结果是一样的。

注:可以访问 Apache Flink 文档,了解更多有关时间的概念,如 event-time, processing-time, ingestion-time。

现在假设我们正在尝试创建一个流计算排序算子。也就是处理一个乱序到达的事件流,并按照事件时间的顺序输出事件。

理解 #1:

数据流中的第一个元素的时间是 4,但是我们不能直接将它作为排序后数据流的第一个元素并输出它。因为数据是乱序到达的,也许有一个更早发生的数据还没有到达。事实上,我们能预见一些这个流的未来,也就是我们的排序算子至少要等到 2 这条数据的到达再输出结果。

有缓存,就必然有延迟。

理解 #2:

如果我们做错了,我们可能会永远等待下去。首先,我们的应用程序从看到时间 4 的数据,然后看到时间 2 的数据。是否会有一个比时间 2 更早的数据到达呢?也许会,也许不会。我们可以一直等下去,但可能永远看不到 1 。

最终,我们必须勇敢地输出 2 作为排序流的第一个结果。

理解 #3:

我们需要的是某种策略,它定义了对于任何带时间戳的事件流,何时停止等待更早数据的到来。

这正是 watermark 的作用,他们定义了何时不再等待更早的数据。

Flink 中的事件时间处理依赖于一种特殊的带时间戳的元素,成为 watermark,它们会由数据源或是 watermark 生成器插入数据流中。具有时间戳 t 的 watermark 可以被理解为断言了所有时间戳小于或等于 t 的事件都(在某种合理的概率上)已经到达了。

译注:此处原文是“小于”,译者认为应该是 “小于或等于”,因为 Flink 源码中采用的是 “小于或等于” 的机制。

何时我们的排序算子应该停止等待,然后将事件 2 作为首个元素输出?答案是当收到时间戳为 2(或更大)的 watermark 时。

理解 #4:

我们可以设想不同的策略来生成 watermark。

我们知道每个事件都会延迟一段时间才到达,而这些延迟差异会比较大,所以有些事件会比其他事件延迟更多。一种简单的方法是假设这些延迟不会超过某个最大值。Flink 把这种策略称作 “有界无序生成策略”(bounded-out-of-orderness)。当然也有很多更复杂的方式去生成 watermark,但是对于大多数应用来说,固定延迟的方式已经足够了。

如果想要构建一个类似排序的流应用,可以使用 Flink 的 ProcessFunction。它提供了对事件时间计时器(基于 watermark 触发回调)的访问,还提供了可以用来缓存数据的托管状态接口。

如果想要了解更多有关 Apache Flink 的 ProcessFunction 的实践案例,可以访问我的上一篇文章《Flink 零基础实战教程:如何计算实时热门商品》 了解如何使用 ProcessFunction 实现 TopN 功能。

标签: flink

添加新评论