Apache Beam Java作业引入侧输入后PubSub消息丢失问题

嘿，你遇到的这个问题在Beam 2.x早期版本的Dataflow作业里其实挺典型的——加了Singleton侧输入就丢消息，去掉就正常，而且丢的数量还不固定。结合你的代码和场景，我帮你梳理下核心原因和可行的解决办法：

核心原因：Singleton侧输入的就绪时机与全局窗口的冲突 #

你的侧输入是用GenerateSequence生成的小数据集，然后通过Count.globally()转成SingletonView。这里的问题在于：

• Count.globally()默认绑定全局窗口，而全局窗口的触发规则是只有当整个PCollection完全处理完毕后才会输出结果。
• 主输入是PubSub的消息流，哪怕你一次性写入1500万条，Dataflow依然会把它当作无限流处理。

在分布式环境下，主输入的消息可能比侧输入的全局窗口结果先到达worker。如果worker在处理主消息时，侧输入的Singleton数据还没同步过来，旧版本的Beam可能会直接丢弃这些等待侧输入的元素（或者缓冲时出现异常）。另外，当作业自动缩放、worker重启时，新启动的worker可能无法获取到已经生成的Singleton侧输入，导致后续处理的消息丢失。

可行的解决办法 #

1. 给侧输入加个小窗口，确保及时触发输出 #

把侧输入的全局窗口改成固定小窗口，配合触发条件让它快速生成并持续可用，这样worker能及时获取到侧输入数据：

PCollectionView<Long> sideInput = p
 .apply(GenerateSequence.from(0).to(10))
 .apply(Window.<Long>into(FixedWindows.of(Duration.standardMinutes(1)))
        .triggering(AfterWatermark.pastEndOfWindow())
        .discardingFiredPanes())
 .apply(Count.globally())
 .apply(View.asSingleton());

这个改动会让侧输入在1分钟窗口结束后立即输出结果，哪怕后续有新worker启动，也能通过窗口输出同步到侧输入数据。

2. 换成IterableView替代SingletonView #

有时候SingletonView在分布式同步上容易出边界问题，换成View.asIterable()可以规避这类问题：

PCollectionView<Iterable<Long>> sideInput = p
 .apply(GenerateSequence.from(0).to(10))
 .apply(Count.globally())
 .apply(View.asIterable());

然后在ParDo里取第一个元素就行：

@ProcessElement
public void processElement(ProcessContext c) {
 Long count = c.sideInput(sideInput).iterator().next();
 c.output(c.element());
}

3. 升级Beam SDK版本 #

你用的2.2.0是2018年的老版本，后续Beam已经修复了大量侧输入、Dataflow执行相关的bug。建议直接升级到较新的稳定版本（比如2.40.0及以上），很多类似的消息丢失问题在新版本里已经被彻底解决了。

4. 排查PubSub订阅的ACK超时 #

虽然可能性较低，但也可以检查下你的PubSub订阅ACK超时时间。如果worker因为等待侧输入导致ACK超时，PubSub会重发消息，但如果你的作业没处理好重复消息，可能会出现统计上的偏差。不过你的情况是消息数量减少，所以这个优先级可以放低。

验证建议 #

你可以先试试前两个方案，看是否还会丢消息。如果问题依旧，升级SDK版本应该能解决大部分历史遗留问题。另外，在Dataflow监控里可以看下侧输入的处理进度和未完成元素数，确认侧输入是不是在主输入处理前就已经就绪了。

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