数据倾斜的主要表现形式
- reducer 阶段一直卡在99.9%，但是一直不能结束。
- 大量数据进入某个或者某几个reducer中处理，远远超过正常的reducer。
- 某几个container出现OOM。
数据倾斜的原因
- 数据倾斜通常伴随着 shuffle 过程。
- 数据的运算通常涉及到 group by、count distinct、join 等操作，这些操作一般会触发 shuffle，一旦触发，就会有大量的数据被拉到不同的节点上。
- 业务本身造成（比如对某一两件商品进行打折后，统计商品维度的购买量、pv等，很显然，此时打折商品的数据量会较大）。
解决方案
非业务相关数据倾斜
- count distinct 会只有一个reducer 。此时可以先进行group by 然后在外层进行count。
select count(distinct userid) from default.user;
=========>
select count(userid) from (select userid from default.user group by userid) a;
- 包含很多无用数据，比如 null、0 等在数据计算汇总时无需用到的数据，可以在统计时先对这些数据进行过滤，然后再进行数据统计计算。
select count(distinct userid) from default.user;
=========>
select count(userid) from (select userid from default.user where userid is not null group by userid) a;
- 两阶段聚合, 数据预处理，包含某些造成数据倾斜，但是必须计算其中的的数据，可以对其进行拼接处理。比如随机数+列值。
- mapjoin，将join操作提前到map端进行。
map join 不会发生 shuffle，因此不会产生数据倾斜的情况。
- hive.groupby.skewindata=true，发生数据倾斜时进行负载均衡，此时会产生两个 job ，第一个 job 的map解决随机分到不同的 reducer，此时具有相同key的数据会被分到不同的reducer中进行处理，第二个job时，再进行全局的数据处理。
- 设置map端输出、中间结果压缩。
- 增加 reducer 个数，set hive.reducer.tasks=
业务层面进行优化
- 比如上面的打折商品的例子中，可以对这两件商品单独进行count，最后再关联其他的商品即可。
总结
- 数据倾斜在大数据数据处理中会经常遇到，合理避免数据倾斜问题，可以有效提升数据的处理效率。尤其对于业务人员来讲，在编写需要的 sql 时处处考虑数据倾斜问题，不仅可以提高自己 sql 的执行速度，还可以为平台资源减轻压力。
