我想使用 Google Cloud Dataflow 创建会话窗口，如 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 -> 307 -> 140我的问题是，如果 70 个数据流失败会发生什么？我认为在第 70 秒之前收到的 3 条消息已经被确认到 Pub/Sub，因此它们不会被重新传递。
当 Dataflow 重新启动时，它是否会以某种方式恢复带有键 7 的窗口状态，以便在 120 秒时它可以生成一对
7 -> 1407 -> 60还有一个相关问题 - 如果我取消数据流作业并开始一个新作业，我想新作业将不会具有上一个作业的状态。有没有办法把状态转移到新的工作上？
Cloud Dataflow 透明地处理故障。例如。它只会在处理消息并持久提交结果后才会在 Cloud Pubsub 中“确认”消息。如果数据流进程失败（我假设您指的是工作 JVM 崩溃，然后它会自动重新启动，而不是整个作业完全失败），重新启动时它将连接到 Pubsub再次，所有未确认的消息将被重新传递和重新处理，包括分组到窗口等。窗口状态也会在失败时持久保留，因此在这种情况下它应该产生
7 -> 140如果您对这种持久性的实现感兴趣，请参阅 Millwheel 论文 - 它早于 Dataflow，但 Dataflow 在流式运行器中使用相同的持久性层。
Dataflow 中没有面向用户的恢复机制，因为编程模型将您与处理故障的必要性隔离开来，并且运行程序负责所有必要的恢复；可见失败的唯一方式是通过记录可以多次处理这一事实，即，如果您在 DoFn 中执行任何副作用，这些副作用必须是幂等的。
目前作业之间发生状态转移的唯一情况是在管道更新操作期间。
我可以补充一下，除了 jkff 提供的功能之外，数据流还支持快照。如果作业失败，您可以对状态进行快照，这样您就可以启动 Dataflow 作业的新版本，而不会丢失状态。更多详细信息请参见：数据流快照