云数据流故障恢复

Question

我想使用 Google Cloud Dataflow 创建会话窗口，如数据流模型论文中所述。我想将未绑定的数据发送到 Pub/Sub，然后以流式传输方式在 Cloud Dataflow 中读取它。我想使用具有较长超时时间（30 分钟到 120 分钟）的会话窗口。

我的问题是：

1）如果数据流过程失败会发生什么？

2）我是否会丢失存储在窗口中尚未超时的所有数据？

3）Dataflow提供哪些恢复机制？

例子：

假设我有一个超时时间为 30 分钟的会话窗口，它会触发每分钟的处理时间并进行累积。假设该值是一个整数，我只是将窗口中的所有值相加。假设这些键值对来自 Pub/Sub：

7 -> 10 (at time 0 seconds)
7 -> 20 (at time 30 seconds)
7 -> 50 (at time 65 seconds)
7 -> 60 (at time 75 seconds)

我想在 60 秒的时候窗口会触发并且会产生一7 -> 30对。我还假设在 120 秒时窗口会再次触发，并且会产生一7 -> 140对，因为它是通过累积触发的。

我的问题是，如果 70 个数据流失败会发生什么？我认为在第 70 秒之前收到的 3 条消息已经被确认到 Pub/Sub，因此它们不会被重新传递。

当Dataflow重新启动时，它是否会以某种方式恢复带有密钥7的窗口的状态，以便在120秒时它可以生成一7 -> 140对，或者它只会生成一7 -> 60对？

还有一个相关的问题 - 如果我取消数据流作业并开始一个新的作业，我想新的作业将不会具有上一个作业的状态。有没有办法将状态转移到新的工作上？

Answer 1

Cloud Dataflow 透明地处理故障。例如，只有在处理完消息并持久提交结果后，它才会在 Cloud Pubsub 中“确认”消息。如果 Dataflow 进程失败（我假设您指的是工作 JVM 崩溃，然后它会自动重新启动，而不是整个作业完全失败），重新启动时它将再次连接到 Pubsub 并所有未确认的消息都将被重新传递和重新处理，包括分组到窗口等。窗口状态也会在失败时持久保留，因此在这种情况下它应该生成7 -> 140.

如果您对这种持久性的实现感兴趣，请参阅Millwheel 论文- 它早于 Dataflow，但 Dataflow 在流式处理运行器中使用相同的持久性层。

Dataflow 中没有面向用户的恢复机制，因为编程模型将您与处理故障的必要性隔离开来，并且运行程序负责所有必要的恢复；失败可见的唯一方式是通过记录可以多次处理这一事实，即如果您在 DoFn 中执行任何副作用，这些副作用必须是幂等的。

目前，作业之间发生状态转移的唯一情况是在管道更新操作期间。