一、数据倾斜的常见类型
（1）不可拆分大文件引发的数据倾斜
不可分割的压缩格式：GZIP，如果该压缩文件很大，map就要花费很多时间进行读取，尽量采用bzip和zip等支持分割的压缩算法
（2）NULL值或热点值
随机数填充打散
热点值join使用skewjoin参数
（3）多维聚合引发数据膨胀
rollup cube等，如果map端聚合得不好，map端输出得数据量将会很大
hive.new.job.grouping.set.cardinality可对任务进行拆解
（4）中间结果无法削减
例如collect_list，同时key又有倾斜
解决这类问题最直接得方式时调整reduce执行得内存大小
（5）两个hive数据表连接发生数据倾斜
hive处理方式是启用两个作业，一个作业处理没有倾斜得数据，第二个作业将倾斜得数据存到分布式缓存中，分发到各个map任务所在的节点，进行mapjoin。
二、各类数据倾斜特征及解决方法
（1）NULL值/热点值/空值
这是最常见的造成数据倾斜的情况，能够在stage中看到各分位处理的数据量有较大不同，找到stage中DAG图的id，前往SQL界面，找到对应的过程，然后对对应表中的数据进行探查，确认是否存在热点值或者较多的空值。
发生倾斜时的stage界面
可以给这个值进行一个替换，比如替换成uid，或者给他加一个随机值rand()*-10000进行打散，这个不要在on上面操作，可能会造成谓词下推失效。优化后，尽可能让每个任务读取的数据量接近。
均匀的stage界面
（2）两个hive数据表连接发生数据倾斜
去找到等待时常比较久的stage，通常stage序号存在先后顺序，等待比较久的stage序号前，对执行时间较长的stage进行排查。
大小表连接
小表如果体量较小，在连接时采用的方式是boardcastjoin，这里用的是sortmergejoin，可以显示地指定需要mapjoin的表
select /*+ mapjoin(b)*/
b.xxx
from
xxxx a
join
xxxx b
（3）多维聚合引发数据膨胀
多维聚合引起数据膨胀，这是一个小表rollup了四个维度后发生的膨胀，有一个expand的过程。
image.png
除了第一部分说到的参数，把一些多维计算交给olap引擎去计算也是一种思路。
（4）中间结果无法削减
拆解任务，尽可能让key打散。
关注过程中报出的OOM错误 Exit status: 143，可适当调大executor的大小
（5）关于文件的情况
https://blog.csdn.net/carolzhang8406/article/details/77944044
文件大小可能还是需要进入集群进行查看。
文件的数量可以用读表stage起的task个数进行估算，通常每个task会处理一个文件。
大文件造成的map读取数据本地化需要对文件格式进行修改
小文件太多造成的HDFS通信、MAP个数等方面的压力可以进行合并
（6）上游文件分布不均匀
如果在SQL界面发现运行时长很长的stage就是最顶部，开始读取数据的步骤，并且发现每个任务读取写入的数据不太均匀，说明上游表本身可能存储得不太均匀。
image.png
这个在上游落表的时候，可以distribute by某个值进行处理。
（7）multi-distinct
数据量大了就不建议这么做了，也会造成数据膨胀，可以看看https://tech.meituan.com/2014/02/12/hive-sql-to-mapreduce.html
multi-distinct
由于每一个去重值都要在key里多n行（看去重对象滤出来的行数），比如这里面<1001(聚合值),0(占位),1(去重指标1)>，<1001(聚合值),1,1101(去重指标2)> 2个指标就是2n行，m个去重指标就是mn行，数据量会成倍增长。
还是上面那个38行的表，同时count distinct了四个值，count(distinct a) count(distinct b) count(distinct c) count(distinct d)翻了4倍
image.png
网友评论