白眉大叔 hive 怎么解决数据倾斜？
（1）group by
注：group by 优于 distinct group
情形：group by 维度过小，某值的数量过多
后果：处理某值的 reduce 非常耗时
解决方式：采用 sum() group by 的方式来替换 count(distinct)完成计算
（2）count(distinct)
情形：某特殊值过多
后果：处理此特殊值的 reduce 耗时；只有一个 reduce 任务
解决方式：count distinct 时，将值为空的情况单独处理，比如可以直接过滤空值的行，
在最后结果中加 1。如果还有其他计算，需要进行 group by，可以先将值为空的记录单独
处理，再和其他计算结果进行 union
（3）不同数据类型关联产生数据倾斜
情形：比如用户表中 user_id 字段为 int，log 表中 user_id 字段既有 string 类型也有 int
类型。当按照 user_id 进行两个表的 Join 操作时。
后果：处理此特殊值的 reduce 耗时；只有一个 reduce 任务默认的 Hash 操作会按 int 型
的 id 来进行分配，这样会导致所有 string 类型 id 的记录都分配到一个 Reducer 中。
解决方式：把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
4）开启数据倾斜时负载均衡
set hive.groupby.skewindata=true;
思想：就是先随机分发并处理，再按照 key group by 来分发处理。
操作：当选项设定为 true，生成的查询计划会有两个 MRJob。
第一个 MRJob 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 GroupBy Key 有可能被分发到不同的Reduce 中，从而达到负载均衡的目的；
第二个 MRJob 再根据预处理的数据结果按照 GroupBy Key 分布到 Reduce 中（这个过程可以保证相同的原始 GroupBy Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
总结：它使计算变成了两个 mapreduce，先在第一个中在 shuffle 过程 partition 时随机给key 打标记，使每个 key 随机均匀分布到各个 reduce 上计算，但是这样只能完成部分计算，因为相同 key 没有分配到相同 reduce 上。所以需要第二次的 mapreduce,这次就回归正常 shuffle,但是数据分布不均匀的问题在第一次 mapreduce 已经有了很大的改善，因此基本解决数据倾斜。因为大量计算已经在第一次 mr 中随机分布到各个节点完成。
（5）控制空值分布
将为空的 key 转变为字符串加随机数或纯随机数，将因空值而造成倾斜的数据分不到多个Reducer。
注：对于异常值如果不需要的话，最好是提前在 where 条件里过滤掉，这样可以使计算量大大减少
欢迎来撩 ： 汇总all
