大数据----“数据倾斜”的问题
0.7862018.11.13 11:21:28字数 897阅读 4,411
一、Hadoop中的数据倾斜:
什么是数据倾斜?(见下图)
简单来说数据倾斜就是数据的key 的分化严重不均,造成一部分数据很多,一部分数据很少的局面。
举个 word count 的入门例子: 它的map 阶段就是形成 (“aaa”,1)的形式,然后在reduce 阶段进行 value 相加,得出 “aaa” 出现的次数。若进行 word count 的文本有100G,其中 80G 全部是 “aaa” 剩下 20G 是其余单词,那就会形成 80G 的数据量交给一个 reduce 进行相加,其余 20G 根据 key 不同分散到不同 reduce 进行相加的情况。如此就造成了数据倾斜,临床反应就是 reduce 跑到 99%然后一直在原地等着 那80G 的reduce 跑完。
这里如果详细的看日志或者和监控界面的话会发现:
有一个多几个reduce卡住
各种container报错OOM
读写的数据量极大,至少远远超过其它正常的reduce
伴随着数据倾斜,会出现任务被kill等各种诡异的表现。
二、导致的原因分为几种情况:
1.单个值有大量记录
单个值有大量记录, 这种值的所有纪录已经超过了分配给reduce 的内存,无论你怎么样分区这种情况都不会改变. 当然这种情况的限制也非常明显, 1.内存的限制存在,2.可能会对集群其他任务的运行产生不稳定的影响.
解决方法:(1)增加reduce 的jvm内存(效果可能不好)
或者(2)在 key 上面做文章,在 map 阶段将造成倾斜的key 先分成多组,例如 aaa 这个 key,map 时随机在 aaa 后面加上 1,2,3,4 这四个数字之一,把 key 先分成四组,先进行一次运算,之后再恢复 key 进行最终运算。
(在MapReduce/spark,该方法常用)
2.唯一值较多
唯一值较多,单个唯一值的记录数不会超过分配给reduce 的内存. 如果发生了偶尔的数据倾斜情况,增加reduce 个数可以缓解偶然情况下的某些reduce 不小心分配了多个较多记录数的情况.
解决办法: 增加reduce 个数
3.以上两种都无效的情况
一个固定的组合重新定义
解决办法:自定义partitioner
4.从业务和数据上解决数据倾斜
我们能通过设计的角度尝试解决它。
(1)有损的方法:
找到异常数据,比如ip为0的数据,过滤掉
(2)无损的方法:
对分布不均匀的数据,单独计算
先对key做一层hash,先将数据打散让它的并行度变大,再汇集
(3)数据预处理;
5.平台的优化方法
1.join 操作中,使用 map join 在 map 端就先进行 join ,免得到reduce 时卡住;
2.能先进行 group 操作的时候先进行 group 操作,把 key 先进行一次 reduce,之后再进行 count 或者 distinct count 操作;
3. 设置map端输出、中间结果压缩;
标签:map,aaa,reduce,key,倾斜,数据 From: https://blog.51cto.com/u_11908275/6405180