Spark Structured Streaming使用连续触发器搭配Kafka sink时offset异常

根因说明 #

你遇到的是Spark 3.0.x版本连续触发器对接Kafka的已知兼容性bug：

• 连续处理模式的Kafka消费者逻辑和默认微批模式独立实现，3.0.x版本对空Kafka分区的偏移量处理存在逻辑缺陷：当分区的LEO（最新偏移量）等于配置的起始偏移量时（空分区场景下LEO为0，startingOffsets=latest对应的偏移量也为0），代码会错误判定为偏移量越界，强制回滚到最早偏移量，随后又发现最早偏移量等于LEO、无可用数据，就抛出了你看到的数据丢失警告。
• 日志中KafkaDataConsumer is not running in UninterruptibleThread的警告，同样是3.0.x连续处理模式的已知问题：连续处理的执行线程未适配Kafka消费者的中断要求，极端场景下可能出现消费者假死。

可行解决方案 #

优先级1：升级Spark版本 #

将Spark版本升级到3.1.0及以上即可彻底解决该问题。偏移量处理的缺陷已在版本迭代中修复，升级后空分区场景下连续触发器可以正常识别latest偏移量，不会触发越界报错，同时也修复了线程模型的警告问题。

优先级2：临时规避方案（无法升级版本时使用） #

给所有Kafka输入分区预先写入1条测试数据，再启动连续处理任务。只要每个分区的LEO大于0，就能避开空分区的判定bug，任务启动后可正常消费后续新写入的业务数据。

优先级3：自定义改造（有二次开发能力时使用） #

如果不能接受预写入数据，可以自定义Kafka源的连续处理逻辑，修改空分区的偏移量校验规则，跳过LEO等于起始偏移量场景的异常判定。

额外注意事项 #

• 连续处理模式目前仅支持投影、过滤这类简单无状态算子，若后续需要使用聚合、关联、窗口等有状态操作，连续模式本身不支持，仍需切换回微批模式。
• 官方宣传的毫秒级延迟仅在无背压、数据量平稳的场景下可实现，若业务存在明显的数据峰值，连续模式的稳定性反而不如调优后的微批模式（可将微批间隔调整到100ms左右平衡延迟和稳定性）。

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