我在Google Dataflow中使用Beam KafkaIO源代码运行工作，并且无法找到一种简单的方法来在作业重启期间保留补偿（作业更新选项不够，我需要重新启动作业）
比较Beam的KafkaIO与PubSubIO（或准确比较PubsubCheckpoint与KafkaCheckpointMark）我可以看到检查点持久性未在KafkaIO中实现（KafkaCheckpointMark.finalizeCheckpoint方法为空），而它在PubsubCheckpoint中实现.finalizeCheckpoint对PubSub做出确认。
这是否意味着我无法以最小的努力可靠地管理Kafka工作重启的补偿？
到目前为止我考虑的选项：
实现我自己的逻辑以保持偏移 - 听起来很复杂，我在Scala中使用Beam而不是Scio。
除此之外什么都不会导致重新启动作业时出现很多重复项（主题有30天的保留期）。
启用自动提交，但这会导致邮件丢失，甚至更糟。
答案 0 :(得分：3)
有两个选项：在KafkaIO中启用commitOffsetsInFinalize()或者在Kafka使用者配置中交替启用自动提交。请注意，尽管commitOffsetsInFinalize()与在Beam中处理的内容更加同步，而不是Kafka的自动提交，但它并不能在一次处理时提供强有力的保证。想象一下两阶段管道，Dataflow在第一阶段之后完成Kafka读卡器，而无需等待第二阶段完成。如果此时从头开始重新启动管道，则不会处理第一阶段完成的记录，但是第二阶段尚未处理。 PubsubIO的问题也不例外。
Regd选项（2）：您可以将KafkaIO配置为从特定时间戳开始读取（假设Kafka服务器支持它（版本10+））。但是看起来没有比启用auto_commit更好的了。
那就是说，KafkaIO应该支持最终确定。可能比启用auto_commit（需要考虑频率等）更简单。我们还没有很多用户要求它。如果可以，请在user@beam.apache.org上提及。
[更新：我正在PR 4481添加对向KafkaCheckpointMark提交偏移的支持