根据following文档，如果没有明确指定触发器，则会出现以下行为：
如果未指定，则默认行为是在 水印通过窗口的末端，然后每次 时间是迟到的数据。
此行为对FixedWindow也适用吗？例如，您假定固定窗口应具有默认触发条件，该默认触发条件是在水印通过窗口结尾之后重复触发，并丢弃所有最新数据，除非明确处理了最新数据。另外，在源代码的哪里可以看到示例FixedWindow对象的触发器的定义？
答案 0 :(得分：2)
最开始的文档是triggers和windows的指南（以及从那里开始的链接）。特别是，它说，即使每次延迟数据到达时都会触发默认触发器，但在默认配置中，它仍然仅触发一次，丢弃延迟数据：
如果同时使用默认窗口配置和 默认触发器，默认触发器仅发出一次，而后期数据 被丢弃。这是因为默认的窗口配置具有 允许的延迟值为0。有关详细信息，请参见“处理延迟数据”部分。 有关修改此行为的信息。
详细信息
Beam中的窗口化概念通常包含几件事情，包括分配窗口，处理触发器，处理最新数据和其他一些东西。但是这些东西是分开分配和处理的。从这里开始，它很快变得令人困惑。
WindowFn，see here处理如何将元素分配给窗口。例如FixedWindows：link。基本上，这是唯一发生（几乎）发生的事情。分配窗口是根据事件时间戳记（kinda）对元素进行分组的一种特殊情况。您可以认为逻辑类似于基于时间戳为元素手动分配自定义键，然后应用GroupByKey。
触发是一个相关但独立的概念。触发器只是（大致）谓词，用于指示何时允许运行程序发出到目前为止在窗口中累积的数据（source）。我认为这是最接近原始设计文档的触发器：https://s.apache.org/beam-triggers
延迟是配置的另一个相关部分，该部分也有些分离（link）。即使触发器可能允许跑步者永远发出所有最新数据，也可以将管道设置为不允许任何最新数据（这是默认行为），或者仅允许在有限的时间内发布最新数据。这导致上述默认触发行为。是的，这令人困惑。如果可能的话，请避免使用任何复杂的触发和延迟，否则可能无法按预期工作。
因此，窗口类仅处理分组逻辑，即哪种元素具有相同的分组键。这些类不在乎您何时要发出累积的结果。这取决于您的业务逻辑，例如您可能要处理新到达的元素，或者可能要丢弃它们，它不是窗口的一部分。这意味着FixedWindows或其他窗口没有特殊的触发器，您可以在任何窗口中使用任何触发器（即使逻辑上某些特定的触发器在某些窗口的上下文中没有意义）。
Default trigger就是这样，它是默认设置。如果不符合您的需求，则应分配自己的触发器。除了一些基本用例之外，它可能不会。
更新
An example，介绍如何将FixedWindows与触发器配合使用。