spark调优之数据倾斜

spark调优之数据倾斜

问题出现的原因
数据倾斜的表现
数据倾斜的表现
遇到这种方式问题莫慌看思路
问题:数据倾斜会导致数据溢出,可能是其中的某个task分配了大量的数据,运行出错,导致数据倾斜,数据溢出.
1.方案一:聚合源数据
只针对常见的聚合操作的情况
2.方案二:使用过滤的方法
只针对只使用部分数据的情况
3.方案三:提高task的并行度的方法
数据量大且数据任务多的程序慎用
4.方案四:使用随机key方式
groupByKey、reduceByKey 比较适合使用这种方式
5.方案五:将reduce join转换为map join
适合小表的内存可以存在集群的内存的时候

spark调优之数据倾斜

问题:数据倾斜会导致数据溢出,可能是其中的某个task分配了大量的数据,运行出错,导致数据倾斜,数据溢出.

问题出现的原因

当我们在集群跑任务的时候,同一个key的values,一定是分配到一个reduce task中处理的,
当我们执行多个key对应的values,例如总共是100万个数量,其中一个key对应了了90万条数据,
两个key对应了1万条数据,剩下的key平分了剩下的9万条数据,这种情况下就会产生数据倾斜,
平分9万的key执行完花了1分钟,执行1万的两个key执行了10分钟,执行90万数据的那个key就
会执行10290=1800分钟=30个小时=1天多,
大家可以发现数据倾斜就是一个杀手,会不会杀了你但是会用时间拖死你!
数据倾斜的表现

1.你用client模式执行的时候,task运行成功的日志跳的异常的慢,一个task要执行一个小时夸
慢,像小牛拉大车一样,但是数据至少还能跑.
2.报错 
(1)OOM(OutOfMenory) 数据溢出,
(2)task failed(任务失败),task lost(任务迷失),resubmitting task(任务重启)反复执行几次都跑不通,最终因为(longtime)任务超时而挂掉,
程序因为数据倾斜引发的一系列异常,最终程序挂掉!

遇到这种方式问题莫慌看思路

解决思路:
1.根据log信息去定位出现数据倾斜的原因,首要原因就是因为shuffle,某个task承担了绝大多数的任务,
那哪些地方会产生shuffle呢?groupByKey、countByKey、reduceByKey、join一般就是这几个算子不老实,
2.log一般会报是在你的哪一行的代码,导致了OOM异常,或者看看是执行到了第几个stage(阶段)
哪一个stage(阶段)生成的task特别慢,就用你的肉眼去对代码进行stage(阶段)划分看看到底哪里发生了数据倾斜.

1.方案一:聚合源数据
只针对常见的聚合操作的情况

思路:
说白了我们要处理的数据仓库就是hive中的一堆表,这一堆表储存在hdfs(分布是存储系统)中我们一般就是凌晨跑
昨天一天所产生的数据,这些数据发生了数据倾斜,我们首要的看日志,肉眼分析阶段,肉眼分析是不是groupByKey,
reduceByKey等函数在聚合过程中产生的shuffle次数过多导致的数据倾斜,聚合数据源,就是提前聚合,找一种没有
sheffle的方式提前聚合,然后再切分还原数据本真,类似先列转行(伪转)聚合合理逃避sheffle,然后再map行转
列(伪转)恢复数据的本真!
1.另外在数据还没有进入spark之前,写一个hive的sql脚本,将value值提前合并,那么就可以直接对数据进行map操作,不需要groupby操作了就没有了shuffle了 就不会有数据倾斜的问题了
2.增大数据的粒度 就是减少了value的数据量 这样也可以有效的减少数据倾斜的问题

2.方案二:使用过滤的方法
只针对只使用部分数据的情况

根据业务的需求 过滤掉不重要的数据

3.方案三:提高task的并行度的方法
数据量大且数据任务多的程序慎用

增加task的数量,减少每个task执行的数据量
增加并行度的数量 每个task的数据就会有所减少  这种方法治标不治本  有可能会避免内存溢出的情况
但数据倾斜的问题还在  就会造成有的task运行快 有的运行慢  浪费整体时间

4.方案四:使用随机key打散方式
groupByKey、reduceByKey 比较适合使用这种方式

在第一轮聚合的时候将同一组的key打散,加上前缀后缀等  
然后在局部聚合时恢复key,最后在全局聚合

5.方案五:将reduce join转换为map join
适合小表的内存可以存在集群的内存的时候

(1)如果有两个RDD join 其中一个Rdd数据较小时  可以将这个小的RDD广播出去  这样再进行map就不会产生shuffle  就不会有数据倾斜
(2)如果数据都很大的情况 内存放不下时  不能采用广播的情况