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之前进行手动重分区