持续运行的Dataflow停发消息后无法写入/发布的原因咨询

这种情况我在维护长运行Dataflow管道时碰到过好几次，结合你的描述，下面几个方向值得重点排查：

1. 窗口触发与延迟容忍配置不合理 #

如果你的管道用了时间窗口（固定/滑动/会话），停发消息几小时后再恢复，很可能是窗口的触发逻辑卡住了：

• 要是用了会话窗口，停发时长超过了会话间隙，恢复后的新消息会开启新会话，但旧的会话窗口可能因为设置了过大的AllowedLateness（延迟容忍时间），一直处于打开状态占用资源，导致新窗口的处理被阻塞。
• 如果触发策略是仅在水印过了窗口结束时间才触发，停发期间水印停滞，恢复后水印虽然推进，但旧窗口可能还在等待迟到数据，而新数据的窗口又没满足触发条件（比如数据量太少）。
• 排查建议：检查管道的窗口配置，调小AllowedLateness（如果不需要太长的延迟容忍），或者给窗口加上早期触发（比如AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardMinutes(5))），确保即使数据量小也能及时输出。

2. BigQuery写入的批量缓冲阈值过高 #

Dataflow的BigQueryIO.Write默认是批量写入，会缓冲数据直到达到一定的行数、字节数或时间阈值才会提交写入请求：

• 如果你恢复后发送的消息量很少，可能还没达到批量阈值，导致数据一直卡在缓冲里，看起来没有输出。
• 要是你自定义了withBatchSizeRows、withBatchSizeBytes或者withTriggeringFrequency，阈值设置得太大（比如几小时），就会出现挂钟时间不断增加但无写入的情况。
• 排查建议：查看BQ写入的配置，降低批量阈值或触发频率，比如设置withTriggeringFrequency(Duration.standardMinutes(1))，同时在BQ的作业历史里查看是否有延迟的写入作业。

3. PubSub流控制与订阅积压问题 #

虽然输入数量显示增加，但Dataflow可能没有真正把消息传递到下游步骤：

• 订阅的maxOutstandingMessages或maxOutstandingBytes设置过小，导致Dataflow拉取消息后被流控制限制，无法传递给下游处理。
• 停发期间订阅可能积压了大量旧消息，恢复后新消息被旧消息阻塞，下游步骤一直在处理旧消息但你没察觉到（比如旧消息格式有问题但没报错）。
• 排查建议：查看PubSub订阅的监控指标（未确认消息数），调整流控制参数；在管道的PubSub拉取步骤后添加日志，确认消息是否被正确传递到下游。

4. Worker资源与状态异常 #

长时间空闲的worker可能出现资源回收或状态异常：

• 停发几小时后，worker的连接池（比如BQ、PubSub的连接）被回收，恢复发消息后需要重新建立连接，这个过程可能很慢甚至静默失败（日志没报错）。
• worker长时间运行出现内存泄漏，导致内存不足，处理速度急剧下降，看起来像是卡住了。
• 排查建议：查看Dataflow的worker监控（CPU、内存使用率），尝试重启管道（如果重启后恢复正常，基本可以确定是worker长时间运行的状态问题），检查worker的初始化日志是否有延迟。

5. 水印传递异常 #

虽然Web界面显示水印推进，但管道内部的水印可能在某个步骤没有正确传递：

• 自定义DoFn中没有正确处理时间戳，比如调用outputWithTimestamp时用了错误的时间，导致下游步骤的水印计算异常。
• 使用了SideInput，SideInput的窗口与主数据窗口不匹配，导致下游步骤的水印停滞。
• 排查建议：在每个关键步骤添加水印日志（比如输出context.timestamp()和context.watermark()），检查水印是否在所有步骤正常推进。

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