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