什么是数据倾斜?

数据倾斜问题是分布式架构的重要难题,它破坏了MPP架构中各个节点对等的要求,导致单节点(倾斜节点)所存储或者计算的数据量远大于其他节点,所以会造成以下危害: 存储上的倾斜会严重限制系统容量,在系统容量不饱和的情况下,由于单节点倾斜的限制,使得整个系统容量无法继续增长。

FLINK中,如何定位数据倾斜?

1、进入flink-webUI界面

flink 只写全量 不写增量 flink的shuffle_数据库

 

2、哪类算子易出现数据倾斜?

 

flink 只写全量 不写增量 flink的shuffle_flink_02

 3、为什么keyedProcess易出现数据倾斜?

        1)非KeyProcess的分区策略(默认shuffle 或 forward):


        rebalance(以轮循方式均匀地分布到下一个操作)         shuffle(输出元素均匀随机地打乱到下一个操作)


                forward(并行分区传输到下一个操作算子)

                rescale(如果上游操作的并行度为2,而下游操作的并行度为4,那么一个上游操作将把元素分配给两个下游操作,而另一个上游操作将分配给另外两个下游操作)

                global 输出值都转到下一个处理操作符的第一个实例

        2)如果非KeyedProcess的默认分区策略不满足需求,还可以调用partitionCustom自定义分区。

        3)keyProcess的分区策略:

                KeyGroupRangeAssignment的assignToKeyGroup 这个api决定的分区策略。

                简而言之:你的key,经过hash再hash之后,除以分区数取余得到数据的分区号。

                所以如果你的key本身分布就不是均匀的,那么大概率会出现倾斜问题。

4、数据倾斜现象(选择keyStream算子,查看subTasks,观察数据量是否均匀)

flink 只写全量 不写增量 flink的shuffle_big data_03

 5、优化方案

        1)keyProcess的分区数选择为质数,因为质数取余更均匀。

        2)key再针对细分(没有key状态计算的场景可以如此用,如果是key状态计算,比如某类商品的windowCount,要么容忍倾斜,要么细分状态后再用算子聚合状态计算)

               比如数据为: 

                    

        Tuple3.of("a","东京","m")

        Tuple3.of("a","东京1","m1")       

        Tuple3.of("a","东京","m2")

        Tuple3.of("a","东京1","m")   

        Tuple3.of("b","东京1","m1")

        Tuple3.of("b","东京","m2")  

如果你选择的key是tuple.f1,那么出来两个分区,分区数据量分别为 4和2。但是如果选择为tuple.f1+tuple.f2 那么分区数据量分别为:2,2,1,1。数据倾斜便没有那么严重。

6、进阶解决方案:

其实我们没有必要生成的key一定是数据本身的key,例如第五步的例子,即使你采取第二种解决方案,出来的key也是(a,"东京")这种样式,但如果你在生成key的时候,把这类key转换为指定范围内的数字(前提是没有key状态计算,只是保证同类key顺序执行你的process),例如:

flink 只写全量 不写增量 flink的shuffle_flink 只写全量 不写增量_04

 这样你的key相对而已,就是在一个可控的范围内,比如范围是1-1000,而你的分区数是127,这种情况下,分区相对而言会均匀很多。

当然,最优!最优的解决方案,是你按权重去对key进行分配,这种方案需要你对key的权重比较了解,再针对性使用例如switch这种方式去给对应的权重数据分配指定的key。