我想使用Google Cloud Dataflow创建会话窗口，如dataflow model paper中所述。我想将未绑定的数据发送到Pub / Sub，然后以流方式在Cloud Dataflow中读取它。我想使用具有大超时（30分钟到120分钟）的会话窗口。
我的问题是：
1）如果数据流程失败会怎样？
2）我是否丢失了尚未超时的Windows中存储的所有数据？
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对？ / p>
也是一个相关的问题 - 如果我取消数据流作业并开始一个新作业，我想新的作业将没有上一个作业的状态。有没有办法将州转移到新工作？
答案 0 :(得分：3)
Cloud Dataflow透明地处理故障。例如。只有在处理完结果并且结果持久的情况下，它才会在Cloud Pubsub中“确认”消息。如果数据流进程失败（我假设您指的是工作者JVM的崩溃，然后将自动重新启动，而不是完成整个作业的失败），重新启动时它将再次连接到Pubsub，所有非acked消息将被重新传递和重新处理，包括分组到窗口等。窗口状态也可以在故障中持久保留，因此在这种情况下它应该产生7 -> 140。
如果您对此持久性的实现感兴趣，请参阅Millwheel paper - 它早于Dataflow，但Dataflow在流媒体运行器中使用相同的持久层。
Dataflow中没有面向用户的恢复机制，因为编程模型将您与处理故障的必要性隔离开来，并且跑步者负责所有必要的恢复;失败可见的唯一方法是通过记录可以多次处理的事实，即如果你在DoFn中执行任何副作用，这些副作用必须是幂等的。
目前唯一一种在工作之间进行状态转移的情况是pipeline update operation。