最近在做大数据量的实时数据迁移, 频繁使用到了keyby hash去均衡数据, 但是却发现subtask执行的数据量不是很均衡, 导致checkpoint频繁超时, 于是开始寻找解决方法.
问题背景
使用keyby进行分区, 自定义KeySelector
, 进行hash%并行度
来进行分区, 比如使用的并行度是8, 最后会得到分区key
0, 1, 2, 3, 4, 5, 6, 7
run起项目后, 打开监视后台, 发现8个subtask中有一个task没有数据, 另一个task会有双倍的数据.
原因
原因很简单, 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)
重启之后分配不均的问题解决.
終わり。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。