数据流作业卡住并且没有从 PubSub 读取消息

Question

我有一个数据流作业，它从 3 个 PubSub 主题中读取 JSON，将它们合并为一个，应用一些转换并保存到 BigQuery。

我正在使用具有以下配置的 GlobalWindow。

.apply(Window.<PubsubMessage>into(new GlobalWindows()).triggering(AfterWatermark.pastEndOfWindow()
                            .withEarlyFirings(AfterFirst.of(AfterPane.elementCountAtLeast(20000),
                                    AfterProcessingTime.pastFirstElementInPane().plusDelayOf(durations))))
                            .discardingFiredPanes());

作业正在使用以下配置运行

Max Workers : 20
Disk Size: 10GB
Machine Type : n1-standard-4
Autoscaling Algo: Throughput Based

我面临的问题是，在处理了几条消息（大约 80k）之后，作业停止从 PubSub 读取消息。其中一个主题中积压了近 1000 万条消息，但数据流作业没有读取消息或自动缩放。

我还检查了每个工作人员的 CPU 使用率，并且在初始爆发后也徘徊在个位数。

我已尝试更改机器类型和最大工作人员配置，但似乎没有任何效果。

我应该如何解决这个问题？

Answer 1

我怀疑窗口函数是罪魁祸首。 GlobalWindow 不适合流式作业（由于使用了 PubSub，我认为这项作业是），因为在所有元素都存在之前它不会触发窗口，这在流式上下文中永远不会发生。

在您的情况下，看起来窗口会提前触发一次，当它达到该元素计数或持续时间时，但之后窗口将卡住等待所有元素最终到达。检查是否是这种情况的快速解决方法是将早期触发包装在Repeatedly.forever 触发器中，如下所示：

withEarlyFirings(
    Repeatedly.forever(
        AfterFirst.of(
            AfterPane.elementCountAtLeast(20000),
            AfterProcessingTime.pastFirstElementInPane().plusDelayOf(durations)))))

这应该允许早期触发重复触发，防止窗口卡住。

但是，对于更持久的解决方案，我建议不要在流式传输管道中使用 GlobalWindow。使用基于元素计数的早期触发的固定时间窗口会给您相同的行为，但不会有卡住的风险。