我刚刚读到flink作业的最大并行度（由setmaxpallelism定义）不能在不丢失状态的情况下更改。这让我有点吃惊，不难想象这样一个场景：一个人开始运行一个作业，却发现负载最终比预期的要大10倍（或者代码的效率低于预期），从而产生了提高并行性的愿望。
我找不到很多原因，除了一些关键群体的参考。我在这里找到了最具体的说法：
缩放作业时，最大并行度不能更改，因为它会破坏键到键组的Map。
然而，这仍然给我留下了问题：
为什么很难/不可能让作业改变其最大平行度？
基于上述情况，我们想到了以下概念解决方案：
在状态中，跟踪上次使用的最大并行度
启动作业时，请指示所需的最大并行度
假设两个设置都是已知的，那么应该可以推断Map需要如何更改以保持最初的有效性。
如果需要，可以使用新的maxparallelism基于旧状态定义新状态，以“适应”新作业。
我并不是说这个概念上的解决方案是理想的，或者说它的实现是微不足道的。我只是想知道是否有更多的非常严格的性质，最大的并行性。并试图理解这是否仅仅是一个“这种灵活性尚未实现”或“这与flink的本质大相径庭，人们不应该想要它”的问题。
1条答案
按热度按时间jtjikinw1#
每一个密钥都被分配给一个密钥组，方法是计算一个密钥的散列值，该散列值乘以密钥组的数目。因此，更改键组的数目会影响将键分配给键组。每个任务管理器负责一个或多个键组，因此键组的数量与最大并行度相同。
更改这个数字之所以痛苦，是因为它被有效地烘焙到状态快照（检查点和保存点）中。这些快照按密钥组编制索引，以便在系统启动时，每个任务管理器可以有效地加载它们所需的状态。
内存中的数据结构会随着键组数量的增加而显著增加，这就是为什么max parallelism不会默认为某个相当大的值（默认值是128）。
如果需要更改密钥组的数量，或者在状态后端之间迁移，可以使用状态处理器api重写状态快照。