Apache Beam：固定触发器 Window
Apache Beam: Trigger for Fixed Window
根据 following 文档，如果您没有明确指定触发器，您将获得如下所述的行为：
If unspecified, the default behavior is to trigger first when the
watermark passes the end of the window, and then trigger again every
time there is late arriving data.
FixedWindow 是否也存在这种行为？例如，您假设 fixed window 应该有一个默认触发器，即在水印通过 window 结束后重复触发，并丢弃所有迟到的数据，除非迟到的数据被明确处理。另外，在源代码的哪个位置我可以看到触发器的定义，例如 FixedWindow 对象？
最好的入门文档是 triggers, and windows 的指南（并从那里点击链接）。特别是，它说，即使每次延迟数据到达时都会触发默认触发器，但在默认配置中它仍然有效地只触发一次，丢弃延迟数据：
if you are using both the default windowing configuration and the
default trigger, the default trigger emits exactly once, and late data
is discarded. This is because the default windowing configuration has
an allowed lateness value of 0. See the Handling Late Data section for
information about modifying this behavior.
详情
Beam 中的窗口概念通常包含一些内容，包括分配 windows、处理触发器、处理延迟数据和其他一些内容。然而，这些事情是分开分配和处理的。从这里开始很快就会变得混乱。
如何将元素分配给 window 由 WindowFn、see here. For example FixedWindows: link 处理。它基本上是那里唯一发生的事情（几乎）。分配 window 是根据事件时间戳（有点）对元素进行分组的特例。您可以认为逻辑类似于根据时间戳手动为元素分配自定义键，然后应用 GroupByKey。
触发是一个相关但独立的概念。触发器（大致）只是谓词，指示何时允许跑步者发出 window 到目前为止累积的数据（source). I think this is the closest thing to the original design doc for triggers: https://s.apache.org/beam-triggers
延迟是配置的另一个相关部分，它也有些独立 (link)。即使触发器可能允许运行器永远发出所有迟到的数据，管道也可以设置为不允许任何迟到的数据（这是默认行为），或者只允许在某些有限时间内迟到的数据。这会导致上述默认触发行为。是的，这令人困惑。如果可以，请避免使用任何复杂的触发和延迟，它可能不会像您预期的那样工作。
所以window 类只处理分组逻辑，即什么样的元素有相同的分组键。这些 类 不关心您何时要发出累积的结果。这取决于您的业务逻辑，例如你可能想要处理新到达的元素，或者你可能想要丢弃它们，它不是 window 的一部分。这意味着 FixedWindows 或其他 windows 没有特殊触发器，您可以将任何触发器与任何 window 一起使用（即使逻辑上某些特定触发器在某些 window).
Default trigger 就是这样，只是默认设置的东西。如果它不适合您的需要，您应该分配自己的触发器。它可能不会，除了一些基本用例。
更新
An example 如何使用 FixedWindows 触发器。
根据 following 文档，如果您没有明确指定触发器，您将获得如下所述的行为：
If unspecified, the default behavior is to trigger first when the watermark passes the end of the window, and then trigger again every time there is late arriving data.
FixedWindow 是否也存在这种行为？例如，您假设 fixed window 应该有一个默认触发器，即在水印通过 window 结束后重复触发，并丢弃所有迟到的数据，除非迟到的数据被明确处理。另外，在源代码的哪个位置我可以看到触发器的定义，例如 FixedWindow 对象？
最好的入门文档是 triggers, and windows 的指南（并从那里点击链接）。特别是，它说，即使每次延迟数据到达时都会触发默认触发器，但在默认配置中它仍然有效地只触发一次，丢弃延迟数据：
if you are using both the default windowing configuration and the default trigger, the default trigger emits exactly once, and late data is discarded. This is because the default windowing configuration has an allowed lateness value of 0. See the Handling Late Data section for information about modifying this behavior.
详情
Beam 中的窗口概念通常包含一些内容，包括分配 windows、处理触发器、处理延迟数据和其他一些内容。然而，这些事情是分开分配和处理的。从这里开始很快就会变得混乱。
如何将元素分配给 window 由 WindowFn、see here. For example FixedWindows: link 处理。它基本上是那里唯一发生的事情（几乎）。分配 window 是根据事件时间戳（有点）对元素进行分组的特例。您可以认为逻辑类似于根据时间戳手动为元素分配自定义键，然后应用 GroupByKey。
触发是一个相关但独立的概念。触发器（大致）只是谓词，指示何时允许跑步者发出 window 到目前为止累积的数据（source). I think this is the closest thing to the original design doc for triggers: https://s.apache.org/beam-triggers
延迟是配置的另一个相关部分，它也有些独立 (link)。即使触发器可能允许运行器永远发出所有迟到的数据，管道也可以设置为不允许任何迟到的数据（这是默认行为），或者只允许在某些有限时间内迟到的数据。这会导致上述默认触发行为。是的，这令人困惑。如果可以，请避免使用任何复杂的触发和延迟，它可能不会像您预期的那样工作。
所以window 类只处理分组逻辑，即什么样的元素有相同的分组键。这些 类 不关心您何时要发出累积的结果。这取决于您的业务逻辑，例如你可能想要处理新到达的元素，或者你可能想要丢弃它们，它不是 window 的一部分。这意味着 FixedWindows 或其他 windows 没有特殊触发器，您可以将任何触发器与任何 window 一起使用（即使逻辑上某些特定触发器在某些 window).
Default trigger 就是这样，只是默认设置的东西。如果它不适合您的需要，您应该分配自己的触发器。它可能不会，除了一些基本用例。
更新
An example 如何使用 FixedWindows 触发器。