数据流管道在执行 GroupBy 之前等待来自所有流的元素答案

【问题标题】：Dataflow pipeline waits for elements from all streams before performing GroupBy数据流管道在执行 GroupBy 之前等待来自所有流的元素
【发布时间】：2017-02-13 16:07:58
【问题描述】：

我们正在运行一个处理多个输入流的 Dataflow 作业。其中一些是高流量的，其中一些很少通过消息。我们将所有流与包含与所有元素相关的信息的“共享”流连接起来。这是管道的简化示例：

我注意到该作业不会产生任何输出，直到两个流都包含一些流量。

例如，假设Stream 1 获得了稳定的流量，而Stream 2 在一段时间内没有产生任何消息。这次，作业的 DAG 将显示在 GroupByKey 步骤中累积的元素，但不会传播任何内容。我还可以看到 Flatten PCollections 步骤显示图表左侧的输入元素，而不是右侧的输入元素。这在处理同一作业中的高流量和低流量流时会产生问题，因为它会导致输出延迟与Stream 2 获取消息所需的时间一样多。

我不确定观察结果是否正确，但我想问一下 Flatten/GroupByKey 的一般工作原理是否如此，如果是这样，我们看到的问题是否可以通过另一种构建管道的方式来避免.

（示例 JobID：2017-02-10_06_48_01-14191266875301315728）

【问题讨论】：

您在该步骤中使用了什么样的窗口和触发方式？即使没有来自流的元素，您也应该能够配置您的窗口/触发器以工作。
@Pablo FixedWindows 和 Sessions 使用默认触发器和第二种情况的 30 分钟间隔持续时间。据我所知，我可以添加一个触发器，该触发器使用处理时间或添加的元素数量过早触发，但我想避免这种情况，因为这意味着某些会话将不完整（30 分钟的不活动可能不会已经过去）当窗格被触发时。

标签： google-cloud-platform google-cloud-dataflow

【解决方案1】：

如group-by-key 的文档中所述，默认行为是等待窗口内的所有数据到达——这是确保下游结果正确性所必需的。

根据您要执行的操作，您可以使用triggers 来提前输出聚合。

您也可以使用慢流作为side-input 来处理快流。

如果您仍然卡住，如果您能更详细地描述流的内容以及您如何尝试使用它们，将会有所帮助，因为更详细的答案取决于目标。

【讨论】：

这是否意味着如果其中一个流不产生任何数量的元素，GroupByKey 将等到每个流至少有一个元素才能知道它需要关闭Session?确切的用例是我正在尝试实现一个用户会话，我在其中跟踪大量消息类型（点击、页面浏览等）的用户活动。一些会话可能包含所有流的元素（例如，用户单击了某物并查看了一个页面），但有些可能没有。
这项工作现在正在消耗大约 20 个不同的流，其中一部分有资格成为“慢”或根本不传播元素。我认为使用侧输入可能不是要走的路，因为它可能是那些无法交付或速度缓慢的流中的任何一个。我也在考虑配置错误的情况：假设由于某种原因，我的订阅中的一个由于配置错误而无法传递消息，或者消息可能不再传播给它。这是否意味着管道将无限期地保留会话窗口？
实际行为取决于上游源如何跟踪水印。例如，如果没有数据到达，PubSub 源将允许水印前进到当前时间。但是，CoGroupByKey 步骤需要等到所有上游源的水印都超过了固定窗口的末尾，等等。