Dataflow Pub/Sub IO吞吐量为零及GroupIntoBatches异常排查求助

云原生阿岚

2026-7-22

问题背景

我搭建了一个流式系统，由Dataflow消费Pub/Sub主题消息，最终写入PostgreSQL数据库。从Pub/Sub接收的单条消息会先被批处理为数组，再插入PostgreSQL，批处理逻辑使用了GroupIntoBatches（底层包含有状态DoFn）。

Dataflow流水线流程

该流水线已稳定运行3-4个月，近期通过独立系统向PostgreSQL批量回填历史数据后，全流水线数据新鲜度下降。虽推测是数据库过载引发背压导致处理变慢（最大设置2个工作节点），但需要严谨解释原因。

回填任务启动约1小时后，源端Pub/Sub IO输出量变为零，即Pub/Sub源停止读取消息，且Pub/Sub订阅统计显示未确认消息在此期间开始堆积，原因是什么？（需严谨解释）
（注：此期间确有消息发布至Pub/Sub，已通过Pub/Sub发送和发布统计确认）
在约6点-8点期间GroupIntoBatches PTransform无输入元素，但6:10和6:45仍有输出元素。这似乎意味着该PTransform中累积了此前的输入集合，等待处理的间隔却达1小时，与设置的max_buffering_duration_secs=1秒差异极大，这是为何？
（注：另有展示“各阶段待处理计时器”和“各阶段已处理计时器”的图表，其中紫色和蓝绿色线条代表包含GroupIntoBatches的融合步骤）

问题解答

这是端到端背压传递至源端的典型表现，完整逻辑链如下：

独立系统批量回填PostgreSQL时，数据库的写入IO、事务日志（WAL）同步、锁竞争等资源被占满，导致Dataflow的PostgreSQL写入步骤出现阻塞——每个批量插入请求的耗时从正常毫秒级飙升至数十秒甚至更久。
由于GroupIntoBatches和写入步骤处于同一个融合步骤（融合步骤2），且使用了常量键，所有消息的批处理和写入逻辑都被绑定到同一个工作节点的同一个线程中（Dataflow的键控处理会将相同键的元素分配到同一个处理单元）。写入阻塞会直接导致这个线程无法处理新的批处理输出，进而让GroupIntoBatches的缓冲区无法释放。
当GroupIntoBatches的有状态缓冲区无法释放时，会向上游传递背压：融合步骤2的过滤、键分配逻辑会因下游阻塞而暂停接收上游数据，最终传递到融合步骤1的PubsubSourceIO。
Dataflow的Pub/Sub源实现会根据下游处理能力动态调整拉取速率，当下游完全阻塞时，源端会停止拉取新消息；已拉取但未处理完成的消息会留在Pub/Sub的未确认队列中，导致堆积。

这里的关键是常量键导致的单线程瓶颈：即使扩容到2个工作节点，由于所有元素都使用同一个键，批处理和写入逻辑只能在一个节点上执行，另一个节点无法分担负载，进一步加剧了背压的传递效率。

这同样是下游阻塞引发的背压传递到有状态DoFn导致的，具体解释：

GroupIntoBatches的max_buffering_duration_secs=1秒是指当缓冲区未满时，等待1秒后触发批处理输出，但这个逻辑的前提是下游处理单元能够及时接收并处理该批次。
当下游的PostgreSQL写入步骤阻塞时，GroupIntoBatches的输出队列会被占满，DoFn无法将已完成的批次发送到下游，只能将已缓冲的元素保留在状态中。
直到下游的写入操作偶尔完成（比如回填任务出现短暂的资源空闲窗口），GroupIntoBatches才会将积压的批次输出，这就导致了“无输入但有输出”的现象——输出的是之前阻塞期间累积的批次，等待间隔完全由下游的阻塞时长决定，和配置的1秒无关。
结合“各阶段待处理计时器”图表来看，包含GroupIntoBatches的融合步骤待处理计时器持续走高，说明该步骤的处理任务一直处于排队等待状态，进一步验证了下游阻塞导致的批处理输出延迟。

内容的提问来源于stack exchange，提问作者leech