我一直在阅读有关在读取流中的数据时DataFlow如何确认消息的信息。 基于答案here和here,DataFlow似乎按束“确认”消息,只要完成束,它就会“确认”其中的消息。
当管道中包含GroupByKey
时会发生混乱n。捆绑软件中的数据将保存到一个多区域存储桶中,并确认消息。然后想象整个区域都下降了。中间数据仍将存储在存储桶中(因为我们是多区域的)。
话虽这么说
请告知
答案 0 :(得分:3)
使用数据流和PubSubIO的当前实现,实现一次最少交付取决于可用的检查点状态。取消时,您必须始终耗尽管道;否则,检查点状态可能会丢失。如果整个区域都无法使用,而您又需要在另一个区域开始工作,那么我相信这等同于取消流水线而不会耗尽。
我们有几个简单的流数据流管道,它们可以从PubSub读取并写入PubSub,而无需调用GroupByKey,因此不涉及检查点状态,并且仅在将消息传递到输出主题后才对其进行确认。
我们还有其他从Pubsub读取并写入GCS或BigQuery的管道。 FileIO和BigQueryIO都包含几个GroupByKey操作,因此当检查点消息丢失时,我们很容易遭受数据丢失。我们曾几次遇到这些管道进入无法恢复的状态,需要取消的情况。在这些情况下,我们必须回填数据架构早期阶段的一部分数据。
在这一点上,Beam还没有提供一种用于延迟GroupByKey上的Pubsub邮件确认的解决方案,因此您需要接受这种风险并建立可从丢失的检查点状态中恢复的操作流程,或者通过下沉消息来解决问题到Beam之外的其他数据存储中。