mapred任务性能优化本质上就是和shuffle搏斗-hive hadoop spark

hive中解决数据倾斜的思路

1.由key为null值造成的倾斜，将空置变成字符串加随机数

2.由group by造成的倾斜，map端聚合

set hive.groupby.skewindata=true；

hive.groupby.mapaggr.checkinterval = 100000 (默认)

hive.map.aggr.hash.min.reduction=0.5(默认)

3.控制reduce节点上的数据规模

set hive.optimize.skewjoin = true;  — 优化歪斜：true

set hive.skewjoin.key = skew_key_threshold （default = 100000）— 歪斜键阈值，数据行数

行数超过阈值的reduce节点上就不再接收新数据，map端发送到其他reduce节点上去

下面是设置单个reduce节点上最大数据规模，也可以设置reduce节点个数，根本目的和上面是一样的，不要让单台reduce上有太多数据

set hive.exec.reducers.bytes.per.reducer = 1000000000（10的9次方字节是1G）— 字节数.单个.reducer

set mapred.reduce.tasks=800;

从这么长时间学习hadoop spark hive来看，性能调优问题的思路都一样

本质上就是和shuffle搏斗，以及解决数据倾斜问题（shuffle涉及到io和网络传输）

都是在reduceByKey或者hive中group by中造成的

解决的思路主要是下面几点：

1.减少shuffle次数

用broadcast+filter或者hive中的mapjoin来代替两个大表直接join

2.减小shuffle数据规模

比如使用reduceByKey代替groupByKey，先在map端聚合一次减小数据规模

比如在join和union之前先去重

比如在reduceByKey之前先用filter把rdd的规模过滤到最小

3.解决数据倾斜问题

map端是各个节点处理自己节点上的数据，不涉及数据倾斜

主要是由于key的集中分布导致过多的局部key被发送到个别的reduce节点上，导致个别节点上的reduceByKey极慢，大家都在等着他

表现也很明显，很多reduce节点都完成了，就他一个完不了

hive上数据倾斜解决思路

首先明确涉及到reduce算子的地方才会有shuflle，才会有数据倾斜，对应的hive算子就是group by/sort by/distinct

下面就是个总体思路，具体的参数调节都在上面写了

(1)map端进行combine

(2)设置单个reduce上的最大数据规模，或者增大reduce任务个数

spark上解决数据倾斜思路

第一种思路

1.先在key上添加随机数，注意这个随机数是介于0-task个数之间的随机整数，不是真的一个32位随机数，那样会导致每个key都成唯一的了，reduceByKey就没有意义了

2.汇总

3.去掉随机数继续汇总

第二种思路

使用自定义partitioner

第三种思路

在map端combine，先合并一次减少数据量

第四种思路

reduceByKey之前进行手动重分区