数据倾斜常见的解决方案

不可拆分大文件引发的数据倾斜

• 原因： 选择了不可切分的压缩算法 如： Snappy 、Gzip 导致根据key 聚合后的文件过大 reduce处理时只能一次性读入该文件 导致某个task 费时
• 解决方案： 使用Lzo 压缩算法 (支持文件split ） 如果使得Lzo 进行文件split 需要对文创建index 或者使用Bzip2 压缩算法

不同数据类型进行关联时引发的数据倾斜

• 倾斜原因： 由于表进行join时默认使用hash 对join 的key 进行分配 ，如果使用不同类型的key 进行join 导致非int 类型的key 分配的同一个reduce 中
• 解决方案： 统一使用相同类型的key 进行join

  SELECT *
  FROM  table_a a
 LEFT JOIN  table_b  b ON a.id = CAST(b.id AS string);

脏数据（大量null）导致的数据倾斜

• 倾斜原因： 相互join的两个表的join字段有null 值 key 的hash 会被拉到同一个reduce中
• 解决方案： 现将null值的数据不参与join 然后在进行union all 操作 或者是将null的数据随机赋值将其分散到不同的reduce 当中

类似Driver端的全局动作算子 比如：collect_list

• 这种方式使用和group by 分组的解决方案效果不大 反而增加了磁盘和网络I/O
• 解决方案： 增加reduce 的内存

两阶段聚合（局部聚合+全局聚合）

• 使用场景： 对聚合类的shuffle 比较适合 对 join类的shuffle 选择使用其它方案