具有巨大状态的Flink恢复/重启作业
我正在K8上运行flink cluster，状态约为1TB。
我面临的问题之一是获取保存点并恢复作业。现在，这些更新有时是简单的代码更新，而不是并行性更改。但是获取保存点然后用旧状态恢复新作业的时间相当长。
是否有方法对作业进行就地更新，以使本地状态和作业ID不发生更改，从而避免执行保存点恢复所需的时间？
共有1个答案
在许多情况下，您可以使用保留的（外部化的）检查点，而不是保存点。这是可行的，但以下情况除外：
- 使用未对齐的检查点重新缩放（此限制将消失；请参阅FLINK-17979）
- 有涉及状态的作业拓扑更改
- 需要状态迁移的类型发生了变化
您可能会发现拓扑更改和状态迁移在某些情况下会起作用，但这并不能保证。
对于RocksDB上的大型状态，您需要使用增量检查点。完整的检查点和保存点需要很长时间，但增量检查点要快得多。
如果您确实想重新扩展，增加RocksDB可用的线程数是有益的，更像这样：
state.backend.rocksdb.checkpoint.transfer.thread.num: 8
state.backend.rocksdb.thread.num: 8
-
我们正在运行一个Flink集群来计算历史上数TB的流式数据。数据计算有一个巨大的状态，我们使用键控状态-RocksDb后端的值和映射状态。在工作计算的某个时候，工作绩效开始下降，输入和输出率下降到几乎为0。此时，可以在日志中看到诸如“与Taskmanager通信X超时错误”之类的异常情况，但作业甚至在之前就已被破坏。 我想我们面临的问题是RocksDb的磁盘后端。随着作业状态的增长，需要更频繁地访
-
我使用Apache Flink 1.9和标准检查点/保存点机制来FS。 我的问题是：如果作业的代码发生了更改，从保存点恢复作业的正确方法是什么？例如，在重构之后，我重命名了几个类，之后我无法从旧的检查点恢复。 我丢失了我的数据，想问-在这种情况下我能做些什么？ 所有运算符都有uid和name
-
我想使用Rocksdb状态后端在Flink中保持大约2TB的状态。我将使用增量检查点，因此它将大大减少检查点时间。 但我有时不得不更改代码，例如重新缩放、错误修复、添加新的过滤器/映射、添加新的源/汇等。 所有这些都会影响作业拓扑。当状态发生任何变化时，我可以再次引导状态。但其他时候，引导状态可能很困难，因为这意味着我浪费时间。 在这种情况下，我必须采取一个保存点来重新开始我的工作。当作业运行时，
-
我将微服务实现为事件源聚合，而事件源聚合又被实现为Flink FlatMapFunction。在基本设置中，聚合从两个kafka主题读取事件和命令。然后，它将新事件写入第一个主题并处理第三个主题的结果。因此，Kafka充当事件存储。希望这张图能有所帮助： 由于Kafka没有选中点，因此命令可能会被重放两次，而且输出事件似乎也可以在主题中写入两次。 在重复消息的情况下如何恢复状态？聚合是否可以知道其
-
状态的保存与恢复 操作流程 为了状态的保存与恢复，我们可以先用栈上的一小段空间来把需要保存的全部通用寄存器和 CSR 寄存器保存在栈上，保存完之后在跳转到 Rust 编写的中断处理函数；而对于恢复，则直接把备份在栈上的内容写回寄存器。由于涉及到了寄存器级别的操作，我们需要用汇编来实现。 而对于如何保存在栈上，我们可以直接令 sp 栈寄存器直接减去相应需要开辟的大小，然后依次放在栈上。需要注意的是，
-
在绘画的时候，经常会有这种情况，本来正在用绿色笔画，突然需要用红色笔画几笔，但画完了之后又要换成绿色笔。如果是在现实中作画，可以把笔蘸上不同的墨水，画了之后又蘸上之前的墨水，或者准备几只笔，要用哪只就选哪只。 在Canvas中也可以这样，不过Canvas中的画笔永远只有一只。所以，如果要更换画笔的颜色，就需要保存和恢复状态。状态其实就是画布当前属性的一个快照，包括： 图形的属性值，如strokeS