Flink - 在保存点启动期间使用操作员的延迟启动答案

【问题标题】：Flink - Lazy start with operators working during savepoint startupFlink - 在保存点启动期间使用操作员的延迟启动
【发布时间】：2021-07-14 22:03:28
【问题描述】：

我正在使用带有 RocksDBStateBackend 的 Apache Flink，并且在使用保存点重新启动作业时遇到了一些麻烦。

显然，状态再次准备好需要一些时间，但即使状态尚未准备好，来自 Kafka 的 DataStreams 似乎正在四处移动数据，这会导致一些无效的缺失，因为状态尚未准备好但是对于我的KeyedProcessFunction。

这是预期的行为吗？我在文档中找不到任何内容，显然也没有相关配置。

对我们来说，理想的状态是在移动任何数据之前完全准备好查询状态。

例如，这表明在部署期间，estimate_num_keys 指标正在缓慢增加。

但是，如果我们查看操作员的应用程序计数器，他们会在那个“热身阶段”工作。

我在这里找到了一些讨论 Apache flink: Lazy load from save point for RocksDB backend，建议使用外部检查点。

我会调查一下，但目前，我们的状态不是太大（~150 GB），所以我不确定这是否是唯一的尝试途径。

【问题讨论】：

【解决方案1】：

从保存点启动使用 RocksDB 的 Flink 作业是一项昂贵的操作，因为必须首先将所有状态从保存点加载到新的 RocksDB 实例中。另一方面，如果您使用保留的增量检查点，那么 RocksDB 可以直接使用该检查点中的 SST 文件，从而加快启动时间。

但是，虽然从保存点开始很昂贵是正常的，但这不应该导致任何错误或丢失数据。

【讨论】：

谢谢。我觉得我们有一些数据丢失。错误与状态尚未准备好有关，但操作员已被触发。另一方面，这有点难以证明，因为我们的条目有 TTL，但它们并不太激进，每个保存点之后都会加载与以前相同或更多的键，并慢慢减少保存的条目. （我正在使用 Flink 1.11.2 并正在考虑迁移到 1.13）。无论如何，现在保留和使用外部化检查点似乎非常顺利。
Hook：有点害怕保存点升级到 1.13。我可以跨版本使用检查点恢复吗？文档似乎引导我通过保存点路径停止。
我不确定你看到了什么，但是在状态恢复之前没有数据可以移动。
在 Flink 升级中重新使用保留的检查点来迁移状态：共识是这应该适用于从 Flink 1.11 升级到 1.13，但这是有风险的。不能保证这不会丢失数据，也没有测试。