Apache Beam:触发固定窗口

dat*_*ser 1 google-cloud-dataflow apache-beam

根据以下文档,如果您没有明确指定触发器,您将获得如下描述的行为:

如果未指定,默认行为是在水印通过窗口末尾时首先触发,然后在每次有迟到数据时再次触发。

这种行为对于 FixedWindow 也是如此吗?例如,您会假设固定窗口应该具有在水印通过窗口结束后重复触发的默认触发器,并丢弃所有延迟数据,除非明确处理延迟数据。另外,在源代码中的何处可以看到触发器的定义,例如 FixedWindow 对象?

Ant*_*ton 6

最好的入门文档是triggerswindows指南(并遵循那里的链接)。特别是,它说,即使每次延迟数据到达时都会触发默认触发器,但在默认配置中,它仍然有效地只触发一次,丢弃延迟数据:

如果您同时使用默认窗口配置和默认触发器,则默认触发器只发出一次,并丢弃迟到的数据。这是因为默认窗口配置的允许延迟值为 0。有关修改此行为的信息,请参阅处理延迟数据部分。

细节

Beam 中的窗口概念通常包含很少的内容,包括分配窗口、处理触发器、处理延迟数据和其他一些事情。然而,这些事情是分开分配和处理的。从这里开始很快就会变得混乱。

元素如何分配给窗口由 a 处理WindowFn请参见此处。例如FixedWindows链接。它基本上是唯一发生在那里(几乎)的事情。分配窗口是根据事件时间戳(有点)对元素进行分组的一种特殊情况。您可以认为逻辑类似于根据时间戳手动为元素分配自定义键,然后应用GroupByKey.

触发是一个相关但独立的概念。触发器(粗略地)只是指示跑步者何时被允许发出迄今为止在窗口中累积的数据的谓词(来源)。我认为这是最接近触发器的原始设计文档的东西:https : //s.apache.org/beam-triggers

延迟是配置的另一个相关部分,它也有些独立(链接)。即使触发器可能允许运行器永远发出所有迟到的数据,管道也可以设置为不允许任何迟到的数据(这是默认行为),或者只在有限的时间内允许迟到的数据。这会导致上述默认触发行为。是的,这令人困惑。如果可以,请避免使用任何复杂的触发和延迟,它可能不会像您期望的那样工作。

所以窗口类只处理分组逻辑,即什么样的元素具有相同的分组键。这些类不关心您何时想要发出累积结果。这取决于您的业务逻辑,例如您可能想要处理新到达的元素,或者您可能想要丢弃它们,它不是窗口的一部分。这意味着没有针对FixedWindows或 其他窗口的特殊触发器,您可以对任何窗口使用任何触发器(即使逻辑上某些特定触发器在某些窗口的上下文中没有意义)。

默认触发器就是这样,默认设置的东西。如果它不适合您的需要,您应该分配自己的触发器。它可能不会,除了一些基本用例。

更新

如何使用FixedWindows触发器的示例