1.概述

转载：flink keyby 在 subtask 中分配不均的研究

最近在做大数据量的实时数据迁移, 频繁使用到了keyby hash去均衡数据, 但是却发现subtask执行的数据量不是很均衡, 导致checkpoint频繁超时, 于是开始寻找解决方法.

2. 问题背景

使用keyby进行分区, 自定义KeySelector, 进行hash%并行度来进行分区, 比如使用的并行度是8, 最后会得到分区key

0, 1, 2, 3, 4, 5, 6, 7

run起项目后, 打开监视后台, 发现8个subtask中有一个task没有数据, 另一个task会有双倍的数据.

3.原因

详细参考官方文档

原因很简单, flink无法预估你会有多少key, 所以会基于最大并行度(默认128)进行一个key分组, 在这个范围内的才会分配到task中.

以下是相关代码

public static int computeKeyGroupForKeyHash(int keyHash, int maxParallelism) {
    return MathUtils.murmurHash(keyHash) % maxParallelism;
}

那么我们对上面自己的key, 去运行这段代码, 会得到以下结果

0 86
1 54
2 27
3 33
4 4
5 79
6 19
7 115

我们是8个并行, 相当于每个subtask占有16个key, 会得到以下分组:

0~15    4
16~31   19   27
32~47   33
48~63   54
64~79   79
80~95   86
96~111  
112~127 115

会发现有个分区确实获得了两个key, 而一个分区轮空.

解

将6换成murmurhash后在 96~111 中的key, 比如 6666(hash为106)

重启之后分配不均的问题解决.