为什么一个flink job的maxparallelism不能更新而不丢失状态？
Why can the maxparallelism of a flink job not be updated without losing state?
我刚读到 Flink 作业的最大并行度（由 setMaxParallelism 定义）不能在不丢失状态的情况下更改。这让我有点吃惊，不难想象开始 运行 一项工作的场景，却发现负载最终比预期大 10 倍（或者代码的效率低于预期） ) 导致希望增加并行性。
除了对关键组的一些引用之外，我找不到很多原因。我找到的最有形的说法 here:
The max parallelism mustn't change when scaling the job, because it would destroy the mapping of keys to key groups.
然而，这仍然给我留下了问题：
为什么要hard/impossible让作业改变其最大并行度？
基于以上，我想到了以下概念性解决方案：
- 在该状态下，跟踪最后使用的最大并行度
- 开始作业时，指明所需的最大并行度
- 鉴于这两个设置都是已知的，应该可以推断出映射最初需要如何更改才能保持有效。
- 如果需要，可以根据具有新最大并行度的旧状态定义新状态，'fit' 新作业。
我并不是说这个概念性解决方案是理想的，或者实施起来很简单。我只是想知道最大并行度的非常严格的性质是否还有更多。并试图了解这只是 'this flexibility is not implemented yet' 还是 'this goes so much against the nature of Flink that one should not want it'.
的问题
通过以密钥组的数量为模计算密钥的散列，将每个密钥分配给恰好一个密钥组。因此，更改键组的数量会影响键到键组的分配。每个任务管理器负责一个或多个键组，因此键组的数量与最大并行度相同。
这个数字很难改变的原因是它被有效地烘焙到状态快照（检查点和保存点）中。这些快照按键组索引，因此在系统启动时，每个任务管理器都可以有效地加载它们需要的状态。
内存中的数据结构会随着键组数量的增加而显着增加，这就是为什么最大并行度不会默认为某个相当大的值（默认值为 128）的原因。
如果您需要更改密钥组的数量，或在状态后端之间迁移，State Processor API 可用于重写状态快照。
我刚读到 Flink 作业的最大并行度（由 setMaxParallelism 定义）不能在不丢失状态的情况下更改。这让我有点吃惊，不难想象开始 运行 一项工作的场景，却发现负载最终比预期大 10 倍（或者代码的效率低于预期） ) 导致希望增加并行性。
除了对关键组的一些引用之外，我找不到很多原因。我找到的最有形的说法 here:
The max parallelism mustn't change when scaling the job, because it would destroy the mapping of keys to key groups.
然而，这仍然给我留下了问题：
为什么要hard/impossible让作业改变其最大并行度？
基于以上，我想到了以下概念性解决方案：
- 在该状态下，跟踪最后使用的最大并行度
- 开始作业时，指明所需的最大并行度
- 鉴于这两个设置都是已知的，应该可以推断出映射最初需要如何更改才能保持有效。
- 如果需要，可以根据具有新最大并行度的旧状态定义新状态，'fit' 新作业。
我并不是说这个概念性解决方案是理想的，或者实施起来很简单。我只是想知道最大并行度的非常严格的性质是否还有更多。并试图了解这只是 'this flexibility is not implemented yet' 还是 'this goes so much against the nature of Flink that one should not want it'.
的问题通过以密钥组的数量为模计算密钥的散列，将每个密钥分配给恰好一个密钥组。因此，更改键组的数量会影响键到键组的分配。每个任务管理器负责一个或多个键组，因此键组的数量与最大并行度相同。
这个数字很难改变的原因是它被有效地烘焙到状态快照（检查点和保存点）中。这些快照按键组索引，因此在系统启动时，每个任务管理器都可以有效地加载它们需要的状态。
内存中的数据结构会随着键组数量的增加而显着增加，这就是为什么最大并行度不会默认为某个相当大的值（默认值为 128）的原因。
如果您需要更改密钥组的数量，或在状态后端之间迁移，State Processor API 可用于重写状态快照。