1、问题描述
在计算数据的时候,数据的分散度不够,不均匀,导致大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,导致整个计算过程过慢。 常见场景有:
Hive的数据倾斜,一般都发生在Sql中Group和On上,而且和数据逻辑绑定比较深。Spark Streaming程序在运行的时候,我们一般不会分配特别多的内存,因此一旦在这个过程中出现一些数据倾斜,就十分容易造成OOM。
2、产生原因
数据运算的时候会设计到count distinct、group by、join等操作,这些都会触发Shuffle动作,一旦触发,所有相同key的值就会拉到一个或几个节点上,就容易发生单点问题。
数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。比如就说订单场景,在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。然后我们要统计不同城市的订单情况,这样做group操作,可能直接就数据倾斜了。
3、解决方案
1、思维导向
A.业务逻辑,从业务逻辑的层面上来优化数据倾斜,比如单独对这两个销量大的城市来做count,最后和其它城市做整合
B.程序层面,在Hive中经常遇到count(distinct)操作,这样会导致最终只有一个reduce,可以先group 再包一层count
C.调参方面,Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题
2、从业务和数据上解决数据倾斜
很多数据倾斜都是在数据的使用上造成的,前面提到的“从数据角度来理解数据倾斜”和“从业务计角度来理解数据倾斜”中的例子,其实都是数据分布不均匀的类型,这种情况和计算平台无关,我们能通过设计的角度尝试解决它。
- 有损的方法:找到异常数据,比如ip为0的数据,过滤掉
- 无损的方法:对分布不均匀的数据,单独计算
- 数据预处理:将数据打散让它的并行度变大,再汇集(比如按 多个字段组合 分区,加新增字段+随机值)
A、hadoop
- map join方式
- count distinct的操作,先转成group,再count
- hive.groupby.skewindata=true
- left join的使用
- 设置map端输出、中间结果压缩。
B、Spark
- map join方式
- 设置RDD压缩
- 合理设置driver的内存
- Spark Sql中的优化和Hive类似
数据倾斜的问题是很大的,如何处理数据倾斜是一个长期的过程,而千亿级别的数据还会有更多的难点,不仅仅是数据倾斜的问题。