不可拆分大文件引发的数据倾斜
- 原因: 选择了不可切分的压缩算法 如: 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 选择使用其它方案