Spark对数据倾斜的八种处理方法
本文主要讲Spark针对数据倾斜的解决方案（来自数盟的一篇文章《数据倾斜是多么痛？spark作业/面试/调优必备秘籍》，见文末参考），但核心思想也可迁移到其它框架的使用上，部分需要看图更好理解（毕竟本文只是对其理解，相当于摘要，建议直接打开文末参考的连接）。
之前在做垃圾短信分类中，也遇到过OOM的问题，我的解决方案是使用RDD.randomSplit对RDD进行指定比例切分出多个subRDD，没有本文考虑地如此细致。
1. 什么是数据倾斜
数据倾斜是一种很常见的问题（依据二八定律），简单来说，比方WordCount中某个Key对应的数据量非常大的话，就会产生数据倾斜，导致两个后果：
OOM（单或少数的节点）；
拖慢整个Job执行时间（其他已经完成的节点都在等这个还在做的节点）。
2. 解决数据倾斜需要
搞定 Shuffle；
搞定业务场景；
搞定 CPU core 的使用情况；
搞定 OOM 的根本原因等：一般都因为数据倾斜（某task任务的数据量过大，GC压力大，和Kafka不同在于Kafka的内存不经过JVM，其基于Linux的Page）。
3. 导致Spark数据倾斜的本质
Shuffle时，需将各节点的相同key的数据拉取到某节点上的一个task来处理，若某个key对应的数据量很大就会发生数据倾斜。比方说大部分key对应10条数据，某key对应10万条，大部分task只会被分配10条数据，很快做完，个别task分配10万条数据，不仅运行时间长，且整个stage的作业时间由最慢的task决定。
数据倾斜只会发生在Shuffle过程，以下算法可能触发Shuffle操作：
distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。
4. 定位最慢的Task所处的源码位置
步骤一： 看数据倾斜发生在哪个stage（也就是看以上算子出现在哪个阶段）。yarn-client模式下查看本地log或Spark Web UI中当前运行的是哪个stage；yarn-cluster模式下，通过Spark Web UI查看运行到了哪个Stage。
主要看最慢的Stage各task分配的数据量，来确定是否是数据倾斜。
步骤二：根据Stage划分，推算倾斜发生的代码（必然有Shuffle类算子）。简单实用方法：只要看到shuffle类算子或Spark SQL的SQL语句会有Shuffle类的算子的句子，就可以该地方划分为前后两个Stage。（之前用Python的PySpark接口，Spark Web UI会查看task在源码中的行数，Java或者Scala虽没用过，但我想应该有）
5. 解决方案
方案一：使用Hive ETL预处理
场景：若Hive表中数据不均匀，且业务中会频繁用Spark对Hive表分析；
思路：用Hive对数据预处理（对key聚合等操作），原本是Spark对Hive的原表操作，现在就是对Hive预处理后的表操作；
原理：从根源解决了数据倾斜，规避了了Spark进行Shuffle类算子操作。但Hive ETL中进行聚合等操作会发生数据倾斜，只是把慢转移给了Hive ETL；
优点：方便，效果好，规避了Spark数据倾斜；
缺点：治标不治本，Hive ETL会数据倾斜。
方案二：过滤导致倾斜的key
场景：发生倾斜的key很少且不重要；
思路：对发生倾斜的key过滤掉。比方在Spark SQL中用where子句或filter过滤，若每次作业执行，需要动态判定可使用sample算子对RDD采样后取数据量最多的key过滤；
原理：对倾斜的key过滤后，这些key便不会参与后面的计算，从本质上消除数据倾斜；
优点：简单，效果明显；
缺点：适用场景少，实际中导致倾斜的key很多。
方案三：提高Shuffle操作并行度
场景：任何场景都可以，优先选择的最简单方案；
思路：对RDD操作的Shuffle算子传入一个参数，也就是设置Shuffle算子执行时的Shuffle read task数量。对于Spark SQL的Shuffle类语句（如group by，join）即spark.sql.shuffle.partitions，代表shuffle read task的并行度，默认值是200可修改；
原理：增大shuffle read task参数值，让每个task处理比原来更少的数据；
优点：简单，有效；
缺点：缓解的效果很有限。
方案四：两阶段聚合（局部聚合+全局聚合）
场景：对RDD进行reduceByKey等聚合类shuffle算子，SparkSQL的groupBy做分组聚合这两种情况
思路：首先通过map给每个key打上n以内的随机数的前缀并进行局部聚合，即(hello, 1) (hello, 1) (hello, 1) (hello, 1)变为(1_hello, 1) (1_hello, 1) (2_hello, 1)，并进行reduceByKey的局部聚合，然后再次map将key的前缀随机数去掉再次进行全局聚合；
原理：对原本相同的key进行随机数附加，变成不同key，让原本一个task处理的数据分摊到多个task做局部聚合，规避单task数据过量。之后再去随机前缀进行全局聚合；
优点：效果非常好（对聚合类Shuffle操作的倾斜问题）；
缺点：范围窄（仅适用于聚合类的Shuffle操作，join类的Shuffle还需其它方案）。
方案五：将reduce join转为map join
场景：对RDD或Spark SQL使用join类操作或语句，且join操作的RDD或表比较小（百兆或1,2G）；
思路：使用broadcast和map类算子实现join的功能替代原本的join，彻底规避shuffle。对较小RDD直接collect到内存，并创建broadcast变量；并对另外一个RDD执行map类算子，在该算子的函数中，从broadcast变量（collect出的较小RDD）与当前RDD中的每条数据依次比对key，相同的key执行你需要方式的join；
原理：若RDD较小，可采用广播小的RDD，并对大的RDD进行map，来实现与join同样的效果。简而言之，用broadcast-map代替join，规避join带来的shuffle（无Shuffle无倾斜）；
优点：效果很好（对join操作导致的倾斜），根治；
缺点：适用场景小（大表+小表），广播（driver和executor节点都会驻留小表数据）小表也耗内存。
方案六：采样倾斜key并分拆join操作
场景：两个较大的（无法采用方案五）RDD/Hive表进行join时，且一个RDD/Hive表中少数key数据量过大，另一个RDD/Hive表的key分布较均匀（RDD中两者之一有一个更倾斜）；
1. 对更倾斜rdd1进行采样（RDD.sample）并统计出数据量最大的几个key；
2. 对这几个倾斜的key从原本rdd1中拆出形成一个单独的rdd1_1，并打上0~n的随机数前缀，被拆分的原rdd1的另一部分（不包含倾斜key）又形成一个新rdd1_2；
3. 对rdd2过滤出rdd1倾斜的key，得到rdd2_1，并将其中每条数据扩n倍，对每条数据按顺序附加0~n的前缀，被拆分出key的rdd2也独立形成另一个rdd2_2；
【个人认为，这里扩了n倍，最后union完还需要将每个倾斜key对应的value减去(n-1)】
4. 将加了随机前缀的rdd1_1和rdd2_1进行join（此时原本倾斜的key被打散n份并被分散到更多的task中进行join）；
【个人认为，这里应该做两次join，两次join中间有一个map去前缀】
5. 另外两个普通的RDD（rdd1_2、rdd2_2）照常join；
6. 最后将两次join的结果用union结合得到最终的join结果。
原理：对join导致的倾斜是因为某几个key，可将原本RDD中的倾斜key拆分出原RDD得到新RDD，并以加随机前缀的方式打散n份做join，将倾斜key对应的大量数据分摊到更多task上来规避倾斜；
优点：前提是join导致的倾斜（某几个key倾斜），避免占用过多内存（只需对少数倾斜key扩容n倍）；
缺点：对过多倾斜key不适用。
方案七：用随机前缀和扩容RDD进行join
场景：RDD中有大量key导致倾斜；
思路：与方案六类似。
1. 查看RDD/Hive表中数据分布并找到造成倾斜的RDD/表；
2. 对倾斜RDD中的每条数据打上n以内的随机数前缀；
3. 对另外一个正常RDD的每条数据扩容n倍，扩容出的每条数据依次打上0到n的前缀；
4. 对处理后的两个RDD进行join。
原理：与方案六只有唯一不同在于这里对不倾斜RDD中所有数据进行扩大n倍，而不是找出倾斜key进行扩容（这是方案六）；
优点：对join类的数据倾斜都可处理，效果非常显著；
缺点：缓解，扩容需要大内存。
【个人认为，这里和方案六一样，也需要对扩容的key对应的value最后减去(n-1)，除非只需大小关系，对值没有要求】
方案八：多种方案组合
实际中，需综合着对业务全盘考虑，可先用方案一和二进行预处理，同时在需要Shuffle的操作提升Shuffle的并行度，最后针对数据分布选择后面方案中的一种或多种。实际中需要对数据和方案思路理解灵活应用。
数据倾斜是多么痛？spark作业/面试/调优必备秘籍
http://mp.weixin.qq.com/s?__biz=MzA4NjA4MTkzMw==&mid=&idx=1&sn=0b253fc2e1bbb&scene=1&srcid=07147NC7qNbqP5r5HjOlE9Gu#wechat_redirect
相关 [spark 数据 方法] 推荐：
Spark对数据倾斜的八种处理方法. 本文主要讲Spark针对数据倾斜的解决方案（来自数盟的一篇文章《数据倾斜是多么痛. spark作业/面试/调优必备秘籍》，见文末参考），但核心思想也可迁移到其它框架的使用上，部分需要看图更好理解（毕竟本文只是对其理解，相当于摘要，建议直接打开文末参考的连接）. 之前在做垃圾短信分类中，也遇到过OOM的问题，我的解决方案是使用RDD.randomSplit对RDD进行指定比例切分出多个subRDD，没有本文考虑地如此细致.
本文讲解Spark的结构化数据处理，主要包括：Spark SQL、DataFrame、Dataset以及Spark SQL服务等相关内容. 本文主要讲解Spark 1.6.x的结构化数据处理相关东东，但因Spark发展迅速(本文的写作时值Spark 1.6.2发布之际，并且Spark 2.0的预览版本也已发布许久)，因此请随时关注.
- CSDN博客综合推荐文章
UCL机器学习知识库：包括近300个不同大小和类型的数据集，可用于分类、回归、聚类 和推荐系统任务. 数据集列表位于：
http://archive.ics.uci.edu/ml/. Amazon AWS公开数据集：包含的通常是大型数据集，可通过Amazon S3访问. 这些数据 集包括人类 基因组项目 、 Common Crawl 网页语料 库、维基百 科数据和 Google Books Ngrams.
- IT瘾-geek
实用教程|Spark性能优化之道——解决Spark数据倾斜.
浏览次数：108. 为何要处理数据倾斜（Data Skew）. 对Spark/Hadoop这样的大数据系统来讲，数据量大并不可怕，可怕的是数据倾斜. 数据倾斜指的是，并行处理的数据集中，某一部分（如Spark或Kafka的一个Partition）的数据显著多于其它部分，从而使得该部分的处理速度成为整个数据集处理的瓶颈.
- CSDN博客架构设计推荐文章
Spark正在占据越来越多的大数据新闻的重要位置，除了性能优异，Spark到底具备了那些特性，让学术界和工业界对其充满了兴趣. 同时，Spark还处在快速发展的阶段，开发者和用户不得不解决不稳定和bug，Scala语言也有较高的学习门槛，这些也会成为Spark普及的障碍. 当然，尽管Spark提供了一栈式的大数据方案，但并不意味着他适合任何场景.
Spark是一个由加州大学伯克利分校（UC Berkeley AMP）开发的一个分布式数据快速分析项目. 它的核心技术是弹性分布式数据集(Resilient distributed datasets)，提供了比Hadoop更加丰富的MapReduce模型，可以快速在内存中对数据集进行多次迭代，来支持复杂的数据挖掘算法和图计算算法.
- leejun_2005的个人页面
数据平台在大部分公司都属于支撑性平台，做的不好立刻会被吐槽，这点和运维部门很像. 所以在技术选型上优先考虑现成的工具，快速出成果，没必要去担心有技术负担. 早期，我们走过弯路，认为没多少工作量，收集存储和计算都自己研发，发现是吃力不讨好. 去年上半年开始，我们全面拥抱开源工具，搭建自己的数据平台. 公司的主要数据来源是散落在各个业务服务器上的半结构化日志，比如系统日志、程序日志、访问日志、审计日志等.
- IT瘾-bigdata
随着在CDH平台上物联网(IoT)使用案例的不断增加，针对这些工作负载的安全性显得至关重要. 本篇博文对如何以安全的方式在Spark中使用来自Kafka的数据，以及针对物联网(IoT)使用案例的两个关键组件进行了说明. Cloudera Distribution of Apache Kafka 2.0.0版本(基于Apache Kafka 0.9.0)引入了一种新型的Kafka消费者API，可以允许消费者从安全的Kafka集群中读取数据.
- IT技术博客大学习
Facebook 经常使用数据驱动的分析方法来做决策. 在过去的几年，用户和产品的增长已经需要我们的分析工程师一次查询就要操作数十 TB 大小的数据集. 我们的一些批量分析执行在古老的
Hive 平台（ Apache Hive 由 Facebook 贡献于 2009 年）和
Corona 上——这是我们定制的 MapReduce 实现.
- IT瘾-bigdata
本文结合实例详细阐明了Spark数据倾斜的几种场景以及对应的解决方案，包括避免数据源倾斜，调整并行度，使用自定义Partitioner，使用Map侧Join代替Reduce侧Join，给倾斜Key加上随机前缀等. 为何要处理数据倾斜（Data Skew）. 对Spark/Hadoop这样的大数据系统来讲，数据量大并不可怕，可怕的是数据倾斜.
--> 坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：itarea.。hive大数据倾斜总结
我的图书馆
hive大数据倾斜总结
1数据倾斜的原因1.1操作：关键词情形后果Join其中一个表较小，但是key集中分发到某一个或几个Reduce上的数据远高于平均值大表与大表，但是分桶的判断字段0值或空值过多这些空值都由一个reduce处理，灰常慢group bygroup by 维度过小，某值的数量过多处理某值的reduce灰常耗时Count Distinct某特殊值过多处理此特殊值的reduce耗时1.2原因：1)、key分布不均匀2)、业务数据本身的特性3)、建表时考虑不周4)、某些SQL语句本身就有数据倾斜1.3表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。2数据倾斜的解决方案2.1参数调节：hive.map.aggr=trueMap 端部分聚合，相当于Combinerhive.groupby.skewindata=true有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。2.2 SQL语句调节：如何Join：关于驱动表的选取，选用join key分布最均匀的表作为驱动表做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。大小表Join：使用map join让小的维度表（1000条以下的记录条数） 先进内存。在map端完成reduce.大表Join大表：把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。count distinct大量相同特殊值count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union。group by维度过小：采用sum() group by的方式来替换count(distinct)完成计算。特殊情况特殊处理：在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。3典型的业务场景3.1空值产生的数据倾斜场景：如日志中，常会有信息丢失的问题，比如日志中的 user_id，如果取其中的 user_id 和 用户表中的user_id 关联，会碰到数据倾斜的问题。解决方法1：&user_id为空的不参与关联（红色字体为修改后）select * from log a join users b on a.user_id is not null and a.user_id = b.user_id union all select * from log a where a.user_id is null;&解决方法2&：赋与空值分新的key值select * from log a left outer join users b on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;&结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。3.2不同数据类型关联产生数据倾斜场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。解决方法：把数字类型转换成字符串类型select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string)&3.3小表不小不大，怎么用 map join 解决倾斜问题使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。&以下例子:select * from log a left outer join users b on a.user_id = b.user_id;&users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。解决方法：select /*+mapjoin(x)*/* from log a
left outer join (
/*+mapjoin(c)*/d.*
from ( select distinct user_id from log ) c
join users d
on c.user_id = d.user_id
on a.user_id = b.user_
假如，log里user_id有上百万个，这就又回到原来map join问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。4总结使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成&user_id,value&的key,value对，假如记录来自member,生成&user_id,value&的key,value对，进入reduce阶段。4、最终把a文件，把Stage3 reduce阶段输出的文件合并起写到hdfs。&如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：1、对于join，在判断小表不大于1G的情况下，使用map join2、对于group by或distinct，设定&hive.groupby.skewindata=true3、尽量使用上述的SQL语句调节进行优化&转自&http://www.tbdata.org/archives/2109
TA的最新馆藏
喜欢该文的人也喜欢& & & 数据倾斜是进行大数据计算时最经常遇到的问题之一。当我们在执行HiveQL或者运行MapReduce作业时候，如果遇到一直卡在map100%,reduce99%一般就是遇到了数据倾斜的问题。数据倾斜其实是进行分布式计算的时候，某些节点的计算能力比较强或者需要计算的数据比较少，早早执行完了，某些节点计算的能力较差或者由于此节点需要计算的数据比较多，导致出现其他节点的reduce阶段任务执行完成，但是这种节点的数据处理任务还没有执行完成。
　　在hive中产生数据倾斜的原因和解决方法：
　　1）group by,我使用Hive对数据做一些类型统计的时候遇到过某种类型的数据量特别多，而其他类型数据的数据量特别少。当按照类型进行group by的时候，会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合，而当其中每一组的数据量过大时，会出现其他组的计算已经完成而这里还没计算完成，其他节点的一直等待这个节点的任务执行完成，所以会看到一直map 100%& reduce 99%的情况。
　　解决方法：set hive.map.aggr=true
　　　　　　　set hive.groupby.skewindata=true
　　原理：hive.map.aggr=true 这个配置项代表是否在map端进行聚合
　　　　　hive.groupby.skwindata=true&当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
　　2）map和reduce优化。
　　　　1.当出现小文件过多，需要合并小文件。可以通过set hive.merge.mapfiles=true来解决。
&　　　& &2.单个文件大小稍稍大于配置的block块的大写，此时需要适当增加map的个数。解决方法：set mapred.map.tasks个数
　& &　　 3.文件大小适中，但map端计算量非常大，如select id,count(*),sum(case when...),sum(case when...)...需要增加map个数。解决方法：set mapred.map.tasks个数，set mapred.reduce.tasks个数
　　3）当HiveQL中包含count（distinct）时
& & & & &如果数据量非常大，执行如select a,count(distinct b)类型的SQL时，会出现数据倾斜的问题。
& & & & &解决方法：使用sum...group by代替。如select a,sum(1) from (select a, b from t group by a,b)
　　4）当遇到一个大表和一个小表进行join操作时。
　　& 解决方法：使用mapjoin 将小表加载到内存中。
　& 　如：select /*+ MAPJOIN(a) */&
& & 　　　　　　a.c1, b.c1 ,b.c2
　　　　　from a join b&
　　　　　where a.c1 = b.c1;&
　　5）遇到需要进行join的但是关联字段有数据为空，如表一的id需要和表二的id进行关联
　　& &解决方法1：id为空的不参与关联
　　　　比如：select * from log a&
　　　　　　join users b&
　　　　　　on a.id is not null and a.id = b.id&
　　　　　　　union all&
　　　　　　　select * from log a&
　　　　　　where a.&
　　　解决方法2：给空值分配随机的key值
　　　　　　如：select * from log a&
　　　　　　　　left outer join users b&
　　　　　　　　on&
　　　　　　　　case when a.user_id is null&
　　　　　　　　then concat(‘hive’,rand() )&
　　　　　　　　else a.user_id end = b.user_&
以上是在工作和学习中遇到的数据倾斜的情况，也希望各位能够提供更多的建议，后续遇到会更新补充。
阅读(...) 评论()没有更多推荐了，
不良信息举报
举报内容：
hive-数据倾斜解决详解
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！分享到微信朋友圈
打开微信，点击底部的“发现”，使用“扫一扫”即可将网页分享至朋友圈。
加载中 ...
(window.slotbydup=window.slotbydup || []).push({
id: '5010815',
container: s,
size: '805,85',
display: 'inlay-fix'
什么是数据倾斜?如何解决数据倾斜?
14:30 来源：网络大数据
相信很多接触MapReduce的朋友对 数据倾斜 这四个字并不陌生,那么究竟什么是数据倾斜?又该怎样解决这种该死的情况呢?
导读相信很多接触MapReduce的朋友对'倾斜'这四个字并不陌生,那么究竟什么是数据倾斜?又该怎样解决这种该死的情况呢?何为数据倾斜?在弄清什么是数据倾斜之前,我想让大家看看数据分布的概念:正常的数据分布理论上都是倾斜的，就是我们所说的20-80原理：80%的财富集中在20%的人手中, 80%的用户只使用20%的功能 , 20%的用户贡献了80%的访问量 , 不同的数据字段可能的数据倾斜一般有两种情况:一种是唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)一种是唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一数据倾斜:数据倾斜在MapReduce编程模型中十分常见,用最通俗易懂的话来说,数据倾斜无非就是大量的相同key被partition分配到一个分区里,造成了'一个人累死,其他人闲死'的情况,这种情况是我们不能接受的,这也违背了并行计算的初衷,首先一个节点要承受着巨大的压力,而其他节点计算完毕后要一直等待这个忙碌的节点,也拖累了整体的计算时间,可以说效率是十分低下的。解决方案:1.增加jvm内存,这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)),这种情况下,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。2.增加reduce的个数,这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一),我们知道,这种情况下,最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。3.自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。4.重新key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。5.使用combinner,combinner是在map阶段,reduce之前的一个中间阶段,在这个阶段可以选择性的把大量的相同key数据先进行一个合并,可以看做是local reduce,然后再交给reduce来处理,这样做的好处很多,即减轻了map端向reduce端发送的数据量(减轻了网络带宽),也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率),推荐使用这种方法。
本文来源：网络大数据责任编辑：KS002
本文仅代表作者个人观点，与本网站立场无关。云掌财经对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证，请读者仅作参考，并请自行核实相关内容。
48秒后自动更新
云掌财经产品下载专区
服务时间：8:30-18:00(工作日)
证券投顾咨询编号：ZX0125
云掌财经官方微信
(C)云掌财经&All Rights Reserved 版权所有&复制必究&皖ICP备号
本站郑重声明：云掌财经所有平台仅提供服务对接功能，所载文章、数据仅供参考，用户需独立做出投资决策，风险自担，投资有风险，选择需谨慎。