我正在使用apacheflink1.9和standart检查点/保存点机制来实现fs。我的问题是：如果作业的代码被更改了，从保存点恢复作业的正确方法是什么？例如，在重构之后，我重命名了几个类，之后我就不能从旧的检查点恢复。我丢失了我的数据，想问-在这种情况下我能做什么？所有运算符都有uid和name
von4xj4u1#
简而言之：这要看情况。至于更详细的解释，如果只对类进行了重新排序和重命名，显然只要uid没有更改，那么通常不应该是问题。至于重构，它实际上可能会影响状态的存储方式，因此可能会阻止恢复状态。在这种情况下，可以使用参数 --allowNonRestoredState ，它应该允许从保存点还原可用状态并启动干净的状态。请记住，这可能不会恢复所有状态。一般来说，在操作符运行后不应该真正重构它们，因为这样可以有效地防止从保存点进行恢复。值得注意的是，如果您使用的是sql，则可能无法从保存点还原，请参阅flink-6966问题。我假设您处理的是保存点而不是外部化的检查点，否则就没有什么需要考虑的了，尤其是在更改并行性时。
--allowNonRestoredState
2ledvvac2#
似乎您的状态不能被视为pojo（pojo：遵循特定bean模式的类）。当用户定义的数据类型不能被识别为pojo类型时，它必须作为generictype处理并用kryo序列化。目前，在flink中，模式演化只支持pojo和avro类型。因此，如果您关心状态的模式演化，那么当前建议始终对状态数据类型使用pojo或avro。一些文件供参考：https://ci.apache.org/projects/flink/flink-docs-stable/dev/types_serialization.htmlhttpshttp://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/schema\u evolution.html
2条答案
按热度按时间von4xj4u1#
简而言之：这要看情况。
至于更详细的解释，如果只对类进行了重新排序和重命名，显然只要uid没有更改，那么通常不应该是问题。至于重构，它实际上可能会影响状态的存储方式，因此可能会阻止恢复状态。在这种情况下，可以使用参数
--allowNonRestoredState，它应该允许从保存点还原可用状态并启动干净的状态。请记住，这可能不会恢复所有状态。一般来说，在操作符运行后不应该真正重构它们，因为这样可以有效地防止从保存点进行恢复。值得注意的是，如果您使用的是sql，则可能无法从保存点还原，请参阅flink-6966问题。
我假设您处理的是保存点而不是外部化的检查点，否则就没有什么需要考虑的了，尤其是在更改并行性时。
2ledvvac2#
似乎您的状态不能被视为pojo（pojo：遵循特定bean模式的类）。当用户定义的数据类型不能被识别为pojo类型时，它必须作为generictype处理并用kryo序列化。目前，在flink中，模式演化只支持pojo和avro类型。因此，如果您关心状态的模式演化，那么当前建议始终对状态数据类型使用pojo或avro。
一些文件供参考：https://ci.apache.org/projects/flink/flink-docs-stable/dev/types_serialization.htmlhttpshttp://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/schema\u evolution.html