Flink数据倾斜以及解决之道

什么是数据倾斜？

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

FLINK中，如何定位数据倾斜？

1、进入flink-webUI界面

 

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

 

 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，观察数据量是否均匀）

 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），例如：

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

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