Spark-优化解析

最新推荐文章于 2024-04-27 13:51:16 发布

thunder࿐

最新推荐文章于 2024-04-27 13:51:16 发布

阅读量1k

点赞数 1

分类专栏： spark spark优化解析文章标签： spark spark优化解析

本文链接：https://blog.csdn.net/u012116196/article/details/106469199

版权

spark 同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

spark优化解析

1 篇文章 0 订阅

订阅专栏

文章目录

小笔记
- spark的监控工具
- Spark的数据倾斜
第1章Spark性能优化
第2章Spark企业应用案例

小笔记

spark的监控工具

1、Spark Web UI Spark内置应用运行监控工具
提供了应用运行层面的主要信息(重要)
2、Ganglia
分析集群的使用状况和资源瓶颈
提供了集群的使用状况，资源瓶颈（重点）
3、Nmon
主机CPU、网络、磁盘、内存
单机，提供了单机信息
4、Jmeter系统实时性能监控工具
提供了单机的实时信息
5、Jprofile Java程序性能监控工具
提供了对应用程序开发和jvm监控（次重点）

Spark的数据倾斜

1、数据倾斜是什么?就是在shuffle过程中分配到下游的Task的数据量不平均，导致了每个Task处理的数据量和数据时间有很大差别，导致整个应用
的运行大大加长。

2、如何定位数据倾斜?
1、是不是有00m情况出现，-般是少数出现内存溢出的问题。
2、是不是应用运行时间差异很大，总体时间很长。
3、你需要了解你所处理的数据Key的分布情况，如果有些Key具有大量的条数，那么就要小心数据倾斜的问题。
4、一般需要通过Spark web UI和其他一-些监控方式中出现的异常来综合判断。
5、看看你的代码里面是否有一些导致Shuffle的算子出现。

3、数据倾斜的集中典型情况
数据源中的数据分布不均匀，Spark需要频繁交互
数据集中的不同Key由于分区方式，导致数据倾斜
JOIN操作中，一个数据集中的数据分布不均匀，另一个数据集较小
聚合操作中，数据集中的数据分布不均匀
JOIN操作中，两个数据集都比较大，其中只有几个Key的数据分布不均均
JOIN操作中，两个数据集都比较大，有很多Key的数据分布不均匀
数据集中少数几个key数据量很大，不重要，其他数据均均

1、你需要处理的数据倾斜问题就是要处理Shuffle后数据的分布是否均匀问题。
2、只要保证最后的结果是正确的，你可以采用任何方式来处理倾斜，只要保证在处理过程中不发生数据倾斜就可以。

4、数据倾斜的处理方法。
1、前台的J ava系统和Spark有很频繁的交互，这个时候如果Spark能够在最短的时间内处理数据，往往会给前端有非常好的体验。这个时候你可以
将数据倾斜的问题抛给数据源端,在数据源端进行数据倾斜的处理。这种方案没有真正处理数据倾斜问题。
实现应理:通过在Hive中对倾斜的数据进行预处理，以及在进行kafka数据分发时尽量进行平均分配。这种方案从根源上解诀了
数据倾斜，彻底避免了在Spark中执行huf1e类算子，那么肯定就不会有数据倾斜的问题了。
方案优点:实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。
方案缺点:治标不治本，Hive或者Kafka中还是会发生数据倾斜。
适用情况:在一些Java系统与 Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能
要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL,每天仅执行一次，只有那一次是比较慢的，而之后每次
Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。|
2、调整并行度:适合于有大量key由于分区算法或者分区数的问题，将key进行了不均匀分区，你可以通过调大或者调小分区数来试试是否有
效。
实现原理:增加sufle read task的数量，可以让原本分配给一-个task的多个key分配给多个task,从而让每个task处理比原来更少的
数据。
方案优点:实现起来比较简单，可以有效缓解和减轻数据倾斜的影响g
方案缺点:只是缓解了数据倾斜而己，没有彻底根除问题，根据实践经验来看，其效果有限。
实践经验:该方案通常无法彻底解决数据倾斜，因为如果出现- -些极端情况，比如某个key对应的数据量有100万，那么无论你
的task数量增加到多少，都无法处理。
3、通过自定义Parti tioner
适用场景:
大量不同的Key被分配到了相同的Task造成该Task数据量过大。
解决方案:
使用自定义的Partitioner实现类代替默认的HashPartitioner,尽量将所有不同的Key均匀分配到不同的Task中。
优势:
不影响原有的并行度设计。如果改变并行度，后续Stage的并行度也会默认改变，可能会影响后续Stage。
劣势:
适用场景有限，只能将不同Key分散开，对于同- -Key对应数据集非常大的场景不适用。_效果与调整并行度类似，只能缓解数据倾斜
而不能完全消除数据倾斜。而且需要根据数据特点自定义专用的Partitioner，不够灵活。
4、将Reduce Side Join转变为Map Side Join
方案适用场景:在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且joim操作中的一-个RDD或表的数据量比较
小(比如几百M)，比较适用此方案。(一个大，-个小)
方案实现原理:普通的join是会走shuffle过程的，而一旦shufte,就相当于会将相同key的数据拉取到一个sufle read task中再进行
join, 此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就
是map join,此时就不会发生sufle操作，也就不会发生数据倾斜。
方案优点:对join操作导致的数据倾斜，效果非常好，因为根本就不会发生sufte，,也就根本不会发生数据倾斜。
方案缺点:适用场景较少，因为这个方案只适用于- -个大表和一个小表的情况。
5、两阶段聚合(局部聚合+全局聚合)
适合于聚合操作，
方案适用场景:对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句.
进行分组聚合时，比较适用这种方案
方案实现原理:将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本.
被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接
着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。
方案优点: 对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数
据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。
方案缺点:仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还
得用其他的解决方案

6、通过分拆，为倾斜key添加随机前后缀
适用场景:两张表都比较大，无法使用Map则Join。其中一个RDD有少数几个Key的数据量过大，另外-一个
RDD的Key分布较为均匀。
解决方案:将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀，另外-一个RDD每条
数据分别与随机前缀结合形成新的RDD(笛卡尔积，相当于将其数据增到到原来的N倍，N即为随机前缀的总个
数)，然后将二者Join后去掉前缀。然后将不包含倾斜Key的剩余数据进行Join。最后将两次Join的结果集通过
union合并，即可得到全部Join结果。
优势:相对于Map侧Join，更能适应大数据集的Join。如果资源充足，倾斜部分数据集与非倾斜部分数据集
可并行进行，效率提升明显。且只针对倾斜部分的数据做数据扩展，增加的资源消耗有限。
劣势:如果倾斜Key非常多，则另一侧数据膨胀非常大，此方案不适用。而且此时对倾斜Key与非倾斜Key分
开处理，需要扫描数据集两遍，增加了开销。
注意:具有倾斜Key的RDD数据集中，key的数量比较少。

7、將傾斜Key添加1-N的随机前錣，并將被Join的数据集相座的ガ大N倍。( 需要将1-N数字添加到毎- - 条数
据上作カ前綴)
方案迺用切景:如果在迸行join操作吋，RDD中有大量的key尋致数据傾斜，那幺迸行分拆key也没什幺意乂。
方案突現思路:將亥RDD的毎条数据都打.上- -个n以内的随机前綴。同吋対男外- -个正常的RDD迸行折容，将毎条数据都折容
成n条数据，折容出来的毎条数据都依次打上- -个0~n的前綴。最后将兩个処理后的RDD迸行join即可。和上一-神方案是尽量只対少数
傾斜key対座的数据迸行特殊処理，由于処理辻程需要折容RDD，因此.上- -神方案折容RDD后対内存的占用并不大;而送一-神方案是
針対有大量傾斜key的情况，没法将部分key拆分出来迸行単独赴理，因此只能対整个RDD迸行数据抃容，対内存資源要求很高。
方案代点:対join炎型的数据傾斜基本都可以赴理，而且效果也相対比較昆著，性能提升效果非常不錯。
方案缺点:垓方案更多的是緩解数据傾斜，而不是砌底避免数据傾斜。而且需要対整个RDD迸行折容，対内存資源要求很高。
方案突践経驗:曽経幵友一个数据需求的吋候，岌現一个join尋致了数据傾斜。代化之前，作止的抗行吋向大約是60分中左
右;使用垓方案伉化之后，抉行吋囘縮短到1Q分狆左右，性能提升了6倍。

8、减少倾斜Key (存储倾斜Key, 但是倾斜Key对业务结果并没有太大的影响)
适用场景:如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的
key就对应10条数据，但是只有一-个key对应了100万数据，从而导致了数据倾斜。
方案优点:实现简单，而且效果也很好，可以完全规避掉数据倾斜。
.方案缺点:适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。
实践经验:在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然O0M了，追查之后发
现，是Hive表中的某一-个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几
个key之后，直接在程序中将那些key给过滤掉。

第1章Spark性能优化

1.1调优基本原则

1.1.1基本概念和原则

首先，要搞清楚Spark的几个基本概念和原则，否则系统的性能调优无从谈起：
在这里插入图片描述
每一台host上面可以并行N个worker，每一个worker下面可以并行M个executor，task们会被分配到executor上面去执行。Stage指的是一组并行运行的task，stage内部是不能出现shuffle的，因为shuffle的就像篱笆一样阻止了并行task的运行，遇到shuffle就意味着到了stage的边界。
CPU的core数量，每个executor可以占用一个或多个core，可以通过观察CPU的使用率变化来了解计算资源的使用情况，例如，很常见的一种浪费是一个executor占用了多个core，但是总的CPU使用率却不高（因为一个executor并不总能充分利用多核的能力），这个时候可以考虑让一个executor占用更少的core，同时worker下面增加更多的executor，或者一台host上面增加更多的worker来增加并行执行的executor的数量，从而增加CPU利用率。但是增加executor的时候需要考虑好内存消耗，因为一台机器的内存分配给越多的executor，每个executor的内存就越小，以致出现过多的数据spill over甚至out of memory的情况。
partition和parallelism，partition指的就是数据分片的数量，每一次task只能处理一个partition的数据，这个值太小了会导致每片数据量太大，导致内存压力，或者诸多executor的计算能力无法利用充分；但是如果太大了则会导致分片太多，执行效率降低。在执行action类型操作的时候（比如各种reduce操作），partition的数量会选择parent RDD中最大的那一个。而parallelism则指的是在RDD进行reduce类操作的时候，默认返回数据的paritition数量（而在进行map类操作的时候，partition数量通常取自parent RDD中较大的一个，而且也不会涉及shuffle，因此这个parallelism的参数没有影响）。所以说，这两个概念密切相关，都是涉及到数据分片的，作用方式其实是统一的。通过spark.default.parallelism可以设置默认的分片数量，而很多RDD的操作都可以指定一个partition参数来显式控制具体的分片数量。
看这样几个例子：
（1）实践中跑的Spark job，有的特别慢，查看CPU利用率很低，可以尝试减少每个executor占用CPU core的数量，增加并行的executor数量，同时配合增加分片，整体上增加了CPU的利用率，加快数据处理速度。
（2）发现某job很容易发生内存溢出，我们就增大分片数量，从而减少了每片数据的规模，同时还减少并行的executor数量，这样相同的内存资源分配给数量更少的executor，相当于增加了每个task的内存分配，这样运行速度可能慢了些，但是总比OOM强。
（3）数据量特别少，有大量的小文件生成，就减少文件分片，没必要创建那么多task，这种情况，如果只是最原始的input比较小，一般都能被注意到；但是，如果是在运算过程中，比如应用某个reduceBy或者某个filter以后，数据大量减少，这种低效情况就很少被留意到。
最后再补充一点，随着参数和配置的变化，性能的瓶颈是变化的，在分析问题的时候不要忘记。例如在每台机器上部署的executor数量增加的时候，性能一开始是增加的，同时也观察到CPU的平均使用率在增加；但是随着单台机器上的executor越来越多，性能下降了，因为随着executor的数量增加，被分配到每个executor的内存数量减小，在内存里直接操作的越来越少，spill over到磁盘上的数据越来越多，自然性能就变差了。
下面给这样一个直观的例子，当前总的cpu利用率并不高：
在这里插入图片描述
但是经过根据上述原则的的调整之后，可以显著发现cpu总利用率增加了：

其次，涉及性能调优我们经常要改配置，在Spark里面有三种常见的配置方式，虽然有些参数的配置是可以互相替代，但是作为最佳实践，还是需要遵循不同的情形下使用不同的配置：
1.设置环境变量，这种方式主要用于和环境、硬件相关的配置；
2.命令行参数，这种方式主要用于不同次的运行会发生变化的参数，用双横线开头；
3.代码里面（比如Scala）显式设置（SparkConf对象），这种配置通常是application级别的配置，一般不改变。
举一个配置的具体例子。slave、worker和executor之间的比例调整。我们经常需要调整并行的executor的数量，那么简单说有两种方式：
1.每个worker内始终跑一个executor，但是调整单台slave上并行的worker的数量。比如，SPARK_WORKER_INSTANCES可以设置每个slave的worker的数量，但是在改变这个参数的时候，比如改成2，一定要相应设置SPARK_WORKER_CORES的值，让每个worker使用原有一半的core，这样才能让两个worker一同工作；
2.每台slave内始终只部署一个worker，但是worker内部署多个executor。我们是在YARN框架下采用这个调整来实现executor数量改变的，一种典型办法是，一个host只跑一个worker，然后配置spark.executor.cores为host上CPU core的N分之一，同时也设置spark.executor.memory为host上分配给Spark计算内存的N分之一，这样这个host上就能够启动N个executor。
有的配置在不同的MR框架/工具下是不一样的，比如YARN下有的参数的默认取值就不同，这点需要注意。
明确这些基础的事情以后，再来一项一项看性能调优的要点。

1.1.2性能监控方式

在这里插入图片描述
Spark web ui 应用运行层面
Ganglia 集群层面
Nmon单机层面
Jmeter 单机层面的实时性能
Jprofile 应用开发层面

1.1.2.1 Spark Web UI

Spark提供了一些基本的Web监控页面，对于日常监控十分有用。
在这里插入图片描述
如果通过spark shell 进行一些操作

对于这个正在活动的窗口，在哪里看？

通过8080端口，这里有一个application，有一个kill，如果点击kill，前面对应的就会kill掉。
如果点击kill前面的应用

就会有一个Application Detail UI，然后点击这个Application Detail UI，就会跳到4040
在这里插入图片描述
这个时候能够看到，刚才执行了一个collect，然后点击这个任务

有他的DAG图等等

往下滑，点击collect

可以看到所有task运行的过程

网上滑，有一些增加的测量的工具

看一下上面的图中，有许多的job，什么是一个job？运行一次action
点击job
在这里插入图片描述
就会分成了很多stage，下面有stage的具体描述
选择某个具体的stage点进去

有整个stage的过程
往下滑

当前stage运行的所有的任务。
shuffle read size record

看其他的都是1538 1539这种，绿色的一下子很大，这很明显就是数据倾斜了

在这里插入图片描述
Environment是整个应用在执行的时候一些参数

Executos是当前应用所有的Executor

spark在优化的时候看就就是这些东西。

通过http://master:4040（默认端口是4040，可以通过spark.ui.port修改）我们可以获得运行中的程序信息：
（1）stages和tasks调度情况；
（2）RDD大小及内存使用；
（3）系统环境信息；
（4）正在执行的executor信息。
如果想当Spark应用退出后，仍可以获得历史Spark应用的stages和tasks执行信息，便于分析程序不明原因挂掉的情况。可以开启History Server。配置方法如下：
（1）

$SPARK_HOME/conf/spark-env.sh
export SPARK_HISTORY_OPTS="-Dspark.history.retainedApplications=50
Dspark.history.fs.logDirectory=hdfs://master01:9000/directory"

   
   
   
   1
2
3

说明：spark.history.retainedApplica-tions仅显示最近50个应用spark.history.fs.logDirectory：Spark History Server页面只展示该路径下的信息。
（2）$SPARK_HOME/conf/spark-defaults.conf
spark.eventLog.enabled true
spark.eventLog.dir hdfs://hadoop000:8020/directory #应用在运行过程中所有的信息均记录在该属性指定的路径下
spark.eventLog.compress true
（3）HistoryServer启动
$SPARK_HOMR/bin/start-histrory-server.sh
（4）HistoryServer停止
$SPARKHOMR/bin/stop−histrory−server.sh同时Executor的logs也是查看的一个出处：Standalone模式：SPARKHOMR/bin/stop−histrory−server.sh同时Executor的logs也是查看的一个出处：Standalone模式： SPARK_HOMR/bin/stop-histrory-server.sh同时Executor的logs也是查看的一个出处：Standalone模式：$ $S P A R K_{H} O M R / b i n / s t o p - h i s t r o r y - s e r v e r . s h 同时 E x e c u t o r 的 l o g s 也是查看的一个出处： S t a n d a l o n e 模式：$ SPARK_HOME/logs
YARN模式：在yarn-site.xml文件中配置了YARN日志的存放位置：yarn.nodemanager.log-dirs，或使用命令获取yarn logs -applicationId。
同时通过配置ganglia，可以分析集群的使用状况和资源瓶颈，但是默认情况下ganglia是未被打包的，需要在mvn编译时添加-Pspark-ganglia-lgpl，并修改配置文件$SPARK_HOME/conf/metrics.properties。

1.1.2.2 Ganglia

主要用于集群的监控，集群里面cpu、磁盘、io

nmon

1.1.2.2 其他监控工具

Nmon（http://www.ibm.com/developerworks/aix/library/au-analyze_aix/）
Nmon 输入：c：CPU n：网络 m：内存 d：磁盘
在这里插入图片描述
Jmeter（http://jmeter. apache.org/）
通常使用Jmeter做系统性能参数的实时展示，JMeter的安装非常简单，从官方网站上下载，解压之后即可使用。运行命令在%JMETER_HOME%/bin下，对于 Windows 用户，直接使用jmeter.bat。
启动jmeter：创建测试计划，设置线程组设置循环次数。
添加监听器：jp@gc - PerfMon Metrics Collector。
在这里插入图片描述
设置监听器：监听主机端口及监听内容，例如CPU。

启动监听：可以实时获得节点的CPU状态信息，从下图可看出CPU已出现瓶颈。

Jprofiler（很重要）

（http://www.ej-technologies.com/products/jprofiler/overview.html）
JProfiler是一个全功能的Java剖析工具（profiler），专用于分析J2SE和J2EE应用程式。它把CPU、线程和内存的剖析组合在一个强大的应用中。JProfiler的GUI可以更方便地找到性能瓶颈、抓住内存泄漏（memory leaks），并解决多线程的问题。例如分析哪个对象占用的内存比较多；哪个方法占用较大的CPU资源等；我们通常使用Jprofiler来监控Spark应用在local模式下运行时的性能瓶颈和内存泄漏情况。
在这里插入图片描述

1.1.3调优要点

在这里插入图片描述
数据倾斜是调优里面的最大项，如果数据倾斜了，再说程序开发、资源参数、shuffle参数就都没有用了。

1.1.3.1 内存调整要点

Memory Tuning，Java对象会占用原始数据2~5倍甚至更多的空间。最好的检测对象内存消耗的办法就是创建RDD，然后放到cache里面去，然后在UI上面看storage的变化。使用-XX:+UseCompressedOops选项可以压缩指针（8字节变成4字节）。在调用collect等API的时候也要小心—大块数据往内存拷贝的时候心里要清楚。内存要留一些给操作系统，比如20%，这里面也包括了OS的buffercache，如果预留得太少了，会见到这样的错误：
“Required executor memory (235520+23552 MB) is above the max threshold (241664MB) of this cluster! Please increase the value of ‘yarn.scheduler.maximum-allocation-mb’.
或者干脆就没有这样的错误，但是依然有因为内存不足导致的问题，有的会有警告，比如这个：
“16/01/13 23:54:48 WARN scheduler.TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory
有的时候连这样的日志都见不到，而是见到一些不清楚原因的executor丢失信息：
“Exception in thread “main” org.apache.spark.SparkException: Job aborted due to stage failure: Task 12 in stage 17.0 failed 4 times, most recent failure: Lost task 12.3 in stage 17.0 (TID 1257, ip-10-184-192-56.ec2.internal): ExecutorLostFailure (executor 79 lost)
Reduce Task的内存使用。在某些情况下reduce task特别消耗内存，比如当shuffle出现的时候，比如sortByKey、groupByKey、reduceByKey和join等，要在内存里面建立一个巨大的hash table。其中一个解决办法是增大level of parallelism，这样每个task的输入规模就相应减小。另外，注意shuffle的内存上限设置，有时候有足够的内存，但是shuffle内存不够的话，性能也是上不去的。我们在有大量数据join等操作的时候，shuffle的内存上限经常配置到executor的50%。
注意原始input的大小，有很多操作始终都是需要某类全集数据在内存里面完成的，那么并非拼命增加parallelism和partition的值就可以把内存占用减得非常小的。我们遇到过某些性能低下甚至OOM的问题，是改变这两个参数所难以缓解的。但是可以通过增加每台机器的内存，或者增加机器的数量都可以直接或间接增加内存总量来解决。
另外，有一些RDD的API，比如cache，persist，都会把数据强制放到内存里面，如果并不明确这样做带来的好处，就不要用它们。
内存优化有三个方面的考虑：对象所占用的内存，访问对象的消耗以及垃圾回收所占用的开销。

对象所占内存，优化数据结构
Spark 默认使用Java序列化对象，虽然Java对象的访问速度更快，但其占用的空间通常比其内部的属性数据大2-5倍。为了减少内存的使用，减少Java序列化后的额外开销，下面列举一些Spark官网提供的方法。
（1）使用对象数组以及原始类型（primitive type）数组以替代Java或者Scala集合类（collection class)。fastutil 库为原始数据类型提供了非常方便的集合类，且兼容Java标准类库。
（2）尽可能地避免采用含有指针的嵌套数据结构来保存小对象。
（3）考虑采用数字ID或者枚举类型以便替代String类型的主键。
（4）如果内存少于32GB，设置JVM参数-XX:+UseCom-pressedOops以便将8字节指针修改成4字节。与此同时，在Java 7或者更高版本，设置JVM参数-XX:+UseC-----ompressedStrings以便采用8比特来编码每一个ASCII字符。
内存回收
（1）获取内存统计信息：优化内存前需要了解集群的内存回收频率、内存回收耗费时间等信息，可以在spark-env.sh中设置SPARK_JAVA_OPTS=“-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps $ SPARK_JAVA_OPTS”来获取每一次内存回收的信息。
（2）优化缓存大小：默认情况Spark采用运行内存（spark.executor.memory）的60%来进行RDD缓存。这表明在任务执行期间，有40%的内存可以用来进行对象创建。如果任务运行速度变慢且JVM频繁进行内存回收，或者内存空间不足，那么降低缓存大小设置可以减少内存消耗，可以降低spark.storage.memoryFraction的大小。
频繁GC或者OOM
针对这种情况，首先要确定现象是发生在Driver端还是在Executor端，然后在分别处理。
Driver端：通常由于计算过大的结果集被回收到Driver端导致，需要调大Driver端的内存解决，或者进一步减少结果集的数量。
Executor端：
（1）以外部数据作为输入的Stage：这类Stage中出现GC通常是因为在Map侧进行map-side-combine时，由于group过多引起的。解决方法可以增加partition的数量（即task的数量）来减少每个task要处理的数据，来减少GC的可能性。
（2）以shuffle作为输入的Stage：这类Stage中出现GC的通常原因也是和shuffle有关，常见原因是某一个或多个group的数据过多，也就是所谓的数据倾斜，最简单的办法就是增加shuffle的task数量，比如在SparkSQL中设置SET spark.sql.shuffle.partitions=400，如果调大shuffle的task无法解决问题，说明你的数据倾斜很严重，某一个group的数据远远大于其他的group，需要你在业务逻辑上进行调整，预先针对较大的group做单独处理。

1.1.3.2 集群并行度调整要点

在Spark集群环境下，只有足够高的并行度才能使系统资源得到充分的利用，可以通过修改spark-env.sh来调整Executor的数量和使用资源，Standalone和YARN方式资源的调度管理是不同的。
在Standalone模式下:

每个节点使用的最大内存数：SPARK_WORKER_INSTANCES*SPARK_WORKER_MEMORY；
每个节点的最大并发task数：SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES。
在YARN模式下：
集群task并行度：SPARK_ EXECUTOR_INSTANCES* SPARK_EXECUTOR_CORES；
集群内存总量：(executor个数) * (SPARK_EXECUTOR_MEMORY+ spark.yarn.executor.memoryOverhead)
+(SPARK_DRIVER_MEMORY+spark.yarn.driver.memoryOverhead)。
重点强调：Spark对Executor和Driver额外添加堆内存大小，Executor端：由spark.yarn.executor.memoryOverhead设置，默认值executorMemory * 0.07与384的最大值。Driver端：由spark.yarn.driver.memoryOverhead设置，默认值driverMemory * 0.07与384的最大值。
通过调整上述参数，可以提高集群并行度，让系统同时执行的任务更多，那么对于相同的任务，并行度高了，可以减少轮询次数。举例说明：如果一个stage有100task，并行度为50，那么执行完这次任务，需要轮询两次才能完成，如果并行度为100，那么一次就可以了。
但是在资源相同的情况，并行度高了，相应的Executor内存就会减少，所以需要根据实际实况协调内存和core。此外，Spark能够非常有效的支持短时间任务（例如：200ms），因为会对所有的任务复用JVM，这样能减小任务启动的消耗，Standalone模式下，core可以允许1-2倍于物理core的数量进行超配。
Level of Parallelism。指定它以后，在进行reduce类型操作的时候，默认partition的数量就被指定了。这个参数在实际工程中通常是必不可少的，一般都要根据input和每个executor内存的大小来确定。设置level of parallelism或者属性spark.default.parallelism来改变并行级别，通常来说，每一个CPU核可以分配2~3个task。
CPU core的访问模式是共享还是独占。即CPU核是被同一host上的executor共享还是瓜分并独占。比如，一台机器上共有32个CPU core的资源，同时部署了两个executor，总内存是50G，那么一种方式是配置spark.executor.cores为16，spark.executor.memory为20G，这样由于内存的限制，这台机器上会部署两个executor，每个都使用20G内存，并且各使用“独占”的16个CPU core资源；而在内存资源不变的前提下，也可以让这两个executor“共享”这32个core。根据测试，独占模式的性能要略好与共享模式。
GC调优。打印GC信息：-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps。要记得默认60%的executor内存可以被用来作为RDD的缓存，因此只有40%的内存可以被用来作为对象创建的空间，这一点可以通过设置spark.storage.memoryFraction改变。如果有很多小对象创建，但是这些对象在不完全GC的过程中就可以回收，那么增大Eden区会有一定帮助。如果有任务从HDFS拷贝数据，内存消耗有一个简单的估算公式——比如HDFS的block size是64MB，工作区内有4个task拷贝数据，而解压缩一个block要增大3倍大小，那么估算内存消耗就是：4364MB。另外，还有一种情况：GC默认情况下有一个限制，默认是GC时间不能超过2%的CPU时间，但是如果大量对象创建（在Spark里很容易出现，代码模式就是一个RDD转下一个RDD），就会导致大量的GC时间，从而出现“OutOfMemoryError: GC overhead limit exceeded”，对于这个，可以通过设置-XX:-UseGCOverheadLimit关掉它。

1.1.3.3 序列化和传输

Data Serialization，默认使用的是Java Serialization，这个程序员最熟悉，但是性能、空间表现都比较差。还有一个选项是Kryo Serialization，更快，压缩率也更高，但是并非支持任意类的序列化。在Spark UI上能够看到序列化占用总时间开销的比例，如果这个比例高的话可以考虑优化内存使用和序列化。
Broadcasting Large Variables。在task使用静态大对象的时候，可以把它broadcast出去。Spark会打印序列化后的大小，通常来说如果它超过20KB就值得这么做。有一种常见情形是，一个大表join一个小表，把小表broadcast后，大表的数据就不需要在各个node之间疯跑，安安静静地呆在本地等小表broadcast过来就好了。
Data Locality。数据和代码要放到一起才能处理，通常代码总比数据要小一些，因此把代码送到各处会更快。Data Locality是数据和处理的代码在屋里空间上接近的程度：PROCESS_LOCAL（同一个JVM）、NODE_LOCAL（同一个node，比如数据在HDFS上，但是和代码在同一个node）、NO_PREF、RACK_LOCAL（不在同一个server，但在同一个机架）、ANY。当然优先级从高到低，但是如果在空闲的executor上面没有未处理数据了，那么就有两个选择：
（1）要么等如今繁忙的CPU闲下来处理尽可能“本地”的数据，
（2）要么就不等直接启动task去处理相对远程的数据。
默认当这种情况发生Spark会等一会儿（spark.locality），即策略（1），如果繁忙的CPU停不下来，就会执行策略（2）。
代码里对大对象的引用。在task里面引用大对象的时候要小心，因为它会随着task序列化到每个节点上去，引发性能问题。只要序列化的过程不抛出异常，引用对象序列化的问题事实上很少被人重视。如果，这个大对象确实是需要的，那么就不如干脆把它变成RDD好了。绝大多数时候，对于大对象的序列化行为，是不知不觉发生的，或者说是预期之外的，比如在我们的项目中有这样一段代码：

rdd.map(r => {
  println(BackfillTypeIndex)
})

   
   
   
   1
2
3

其实呢，它等价于这样：

rdd.map(r => {
  println(this.BackfillTypeIndex)
})

   
   
   
   1
2
3

不要小看了这个this，有时候它的序列化是非常大的开销。
对于这样的问题，一种最直接的解决方法就是：

val dereferencedVariable = this.BackfillTypeIndex
rdd.map(r => println(dereferencedVariable)) // "this" is not serialized 

   
   
   
   1
2

相关地，注解@transient用来标识某变量不要被序列化，这对于将大对象从序列化的陷阱中排除掉是很有用的。另外，注意class之间的继承层级关系，有时候一个小的case class可能来自一棵大树。

1.1.3.4 文件读写

文件存储和读取的优化。比如对于一些case而言，如果只需要某几列，使用rcfile和parquet这样的格式会大大减少文件读取成本。再有就是存储文件到S3上或者HDFS上，可以根据情况选择更合适的格式，比如压缩率更高的格式。另外，特别是对于shuffle特别多的情况，考虑留下一定量的额外内存给操作系统作为操作系统的buffer cache，比如总共50G的内存，JVM最多分配到40G多一点。
文件分片。比如在S3上面就支持文件以分片形式存放，后缀是partXX。使用coalesce方法来设置分成多少片，这个调整成并行级别或者其整数倍可以提高读写性能。但是太高太低都不好，太低了没法充分利用S3并行读写的能力，太高了则是小文件太多，预处理、合并、连接建立等等都是时间开销啊，读写还容易超过throttle。

1.1.3.5 任务调整要点

Spark的Speculation。通过设置spark.speculation等几个相关选项，可以让Spark在发现某些task执行特别慢的时候，可以在不等待完成的情况下被重新执行，最后相同的task只要有一个执行完了，那么最快执行完的那个结果就会被采纳。
减少Shuffle。其实Spark的计算往往很快，但是大量开销都花在网络和IO上面，而shuffle就是一个典型。举个例子，如果(k, v1) join (k, v2) => (k, v3)，那么，这种情况其实Spark是优化得非常好的，因为需要join的都在一个node的一个partition里面，join很快完成，结果也是在同一个node（这一系列操作可以被放在同一个stage里面）。但是如果数据结构被设计为(obj1) join (obj2) => (obj3)，而其中的join条件为obj1.column1 == obj2.column1，这个时候往往就被迫shuffle了，因为不再有同一个key使得数据在同一个node上的强保证。在一定要shuffle的情况下，尽可能减少shuffle前的数据规模，比如这个避免groupByKey的例子。下面这个比较的图片来自Spark Summit 2013的一个演讲，讲的是同一件事情：
在这里插入图片描述
Repartition。运算过程中数据量时大时小，选择合适的partition数量关系重大，如果太多partition就导致有很多小任务和空任务产生；如果太少则导致运算资源没法充分利用，必要时候可以使用repartition来调整，不过它也不是没有代价的，其中一个最主要代价就是shuffle。再有一个常见问题是数据大小差异太大，这种情况主要是数据的partition的key其实取值并不均匀造成的（默认使用HashPartitioner），需要改进这一点，比如重写hash算法。测试的时候想知道partition的数量可以调用rdd.partitions().size()获知。
Task时间分布。关注Spark UI，在Stage的详情页面上，可以看得到shuffle写的总开销，GC时间，当前方法栈，还有task的时间花费。如果你发现task的时间花费分布太散，就是说有的花费时间很长，有的很短，这就说明计算分布不均，需要重新审视数据分片、key的hash、task内部的计算逻辑等等，瓶颈出现在耗时长的task上面。
在这里插入图片描述
重用资源。有的资源申请开销巨大，而且往往相当有限，比如建立连接，可以考虑在partition建立的时候就创建好（比如使用mapPartition方法），这样对于每个partition内的每个元素的操作，就只要重用这个连接就好了，不需要重新建立连接。
同时Spark的任务数量是由stage中的起始的所有RDD的partition之和数量决定，所以需要了解每个RDD的partition的计算方法。以Spark应用从HDFS读取数据为例，HadoopRDD的partition切分方法完全继承于MapReduce中的FileInputFormat，具体的partition数量由HDFS的块大小、mapred.min.split.size的大小、文件的压缩方式等多个因素决定，详情需要参见FileInputFormat的代码。

1.1.3.6 开启推测机制

推测机制后，如果集群中，某一台机器的几个task特别慢，推测机制会将任务分配到其他机器执行，最后Spark会选取最快的作为最终结果。
在spark-default.conf 中添加：spark.speculation true
推测机制与以下几个参数有关：

spark.speculation.interval 100：检测周期，单位毫秒；
spark.speculation.quantile 0.75：完成task的百分比时启动推测；
spark.speculation.multiplier 1.5：比其他的慢多少倍时启动推测。

1.2数据倾斜优化

小笔记

在这里插入图片描述
主要发生在shuffle过程，对于整个stage来说，每一个stage里面数据都是在Executor的本地运行的，运行了一个阶段，接下来运行第二个阶段，不发生任何的网络输出，一旦遇到了shuffle，就会有大量的数据传输，因为网络是有瓶颈的，所以网络在传输的过程中，怎么能够保证传输到的下一个task都均匀的分到数据，如果均匀的分到数据，虽然shuffle过程比较慢，但是整个过程是可以接受的，但是如果shuffle后，某个task处理的数据突然增多，几倍几百倍，你会发现这个任务遥遥无期，怎么都结束不了，虽然其他任务都早早的结束了，但是就卡在这一个任务上，所以这个时候就需要一些操作去处理这件事。

注意上图中的最后一句话：一个经验结论是：一般情况下，OOM的原因是是数据倾斜

在这里插入图片描述
注意触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。要注意这些操作会引起shuffle，所以要注意保证下游的平均度

注意上面的红色字体：
某个task执行特别慢的情况
某个task莫名内存溢出的情况
查看导致数据倾斜的key的数据分布情况（在做数据处理的时候，必须是懂业务的，业务层面的意思是什么，因为大多数处理的是key value 的，所以key的数据分布情况要了解，因为在分区里面如何落到下一个分区，就会去控制这个key它的情况）

这些还是要依赖下面的页面工具进行排查

在这里插入图片描述
数据源中的数据，但是需要和上一次的应用频繁交互

缓解数据倾斜-避免数据源的数据倾斜

在这里插入图片描述
如果spark在连接数据源的时候，在数据源里面是数据倾斜的，如果直接用spark连接数据源，这个时候写的spark应用程序，对数据倾斜会造成很大影响

缓解数据倾斜-调整并行度

在这里插入图片描述
如上图，之前task1 要处理0 2 4 6 8等任务，task1只需要处理1 3 两个
这个时候把分区数增加到4，这个时候原来分区到task0上的数据，可能就分配到task2上，就会把原来集聚的数据打散。

一个验证调整并行度的小例子
通过sparkshell
在这里插入图片描述
当id<900000，当分区数为12的时候，如果当前的id对12取余，余数为八，都会分布到第八个分区上，后面的id生成一个随机数*50000

sourcRdd.map 转化成kv的rdd
执行完上面的，能够在spark前段看到三个job，分别对应上面的三个操作
在这里插入图片描述
点击count这个job，有stage，点击count这个stage

进入之后，发现除了第一行剩下的execution memory、shuffle等都比较小，这就是很典型的数据倾斜

发现都是差不多400多k
如果改为7

分片的数量减小了，虽然每个分片的数据量增多了，但是还是挺均匀的

缓解数据倾斜-自定义partitioner

在这里插入图片描述
通过自定义分区，实现了将不同的key分配到了不同的task
这里也有一个小例子。
直接使用上一个的数据

做了一个自定义的分区器：custerParttioner，复写了两个函数，第一个是numPartitions返回整个分区数，第二个getPartition，在getPartition中，如果id<900000，产生一个100以内的随机数对12取余，也就是把key原来的默认方式，通过自定义partitioner，然后把他改变了，通过这种方式把他强行分区到另外一个分区，因为对于分区运行来说，一个分区是运行成为一个task里面。
sc.textFile把数据加载一下。
加载完之后把上面的:past到类结束加载一下。
把原来的scourceRdd转化成key value的这种元组的结构
运行函数
在这里插入图片描述

在这里插入图片描述
看个count操作，点进去看这个count操作，发现相差不是很大

缓解数据倾斜-Reduce side Join 转变为Map side Join

在这里插入图片描述
适用于join操作，一个RDD比较大，一个RDD比较小，如果在比较大的RDD中，有数据倾斜的问题，如果这个时候在做join，无法避免的是相同的key会全部被被某一个task处理了，这个时候也无法避免的出现了数据倾斜的问题。这个时候有一种方案，就是广播变量的问题，就像下面的RDD2，这个RDD比较小，就可以使用广播小RDD全量数据+map算子这种方式来实现。也就是说把RDD2当做一个广播变量，其实就相当于一个常量，这个时候可以在任何一个task里面去读取全量数据，就像上图的右边部分，这个时候要做join，join其实就是相对应key他的一个连接，这个时候如果说在map里面，把相对应的key，同样在广播变量里面找到，然后手动的方式让他们倆撞在一块，这种方式就和原来的方式是一样的，一样的效果，即最终的结果是不变的。
这个其实整个join操作其实是在reduce端做的，通过这种方式可以避免join操作shuffle发生，这个时候join操作就会变成map操作。
小例子：

将每一个数据切分，把第一个id切分出来，然后把剩下的x就直接赋上了，转化过来之后，，这个时候把kvRdd又做了一个操作，如果kvRdd的第一个元素小于900001，这个时候返回元组900001，然后直接把value给返回，否则直接返回整个元组，这个相对于做什么操作呢？相对于把900001这些下面的这些id全部换成了900001，就是说他们的id是相同的，符合咱们这场景，也就是在RDD中有大量的key是相同的

做完kvRdd2之后，直接把他输出了，对每个元素转化成了一个string，然后输出到了hdfs上，大的数据文件就造好了，小的数据文件（kvRdd）做了一个filter，如果说变量大于900000，就把剩下的东西给留下，可以发现在剩下的东西里面有900001-1000000，对于900001这个id，上一个RDD里面(kvRdd2)是有很多的，这个时候直接把joinRdd2直接输出到small_data

然后实际执行一下上面的操作
在这里插入图片描述

然后看一下他们的大小

在这里插入图片描述

这个时候做一下join操作，
在这里插入图片描述

从DAG图中，能够看到做了join操作
进去查看，发现有很严重的数据倾斜，看前面的时间，发现有好几倍的时间变化

在这里插入图片描述

把rdd转化为了两个真正的rdd，这个时候sc.broadcast，因为对于smalljoin来说，直接用了一个广播变量，因为是广播变量，所以里面的参数应该是一个scala的集合，而不应该是rdd，就是把所有分散在其他节点上的rdd全都收集回来，因为基于这个前提就是比较小，所以收集到driver里面的时候，driver里面的内存其实是可以容纳的，如果在做这个操作的时候，driver内存溢出了，要么去调整driver的容量，要么就是因为数据集太大了

为了达到相同的效果，并没有用join操作，而是用的map操作，因为对于join来说就是要把相同key的相同数据组合到一块，所以在map里面对于每个数据来说返回了一个大的元组，这个元组里面这个key还是原来的key，后面返回了一个元组，这个元组就是join后的结果，把bigjoin的第二个元素放到key，后面的元素是直接从broadcastVar里面直接get的，取了broadcastVar当前的值，然后用了getOrElse，如果发现里面某些key是没有的，这边直接get就会报错，所以，直接用getElse这种方式，如果获得了，直接可以传入了key，然后获得value，或者为空""，然后直接count

在这里插入图片描述
可以看到这里的DAG图就没有分成三个，是因为把他归并掉了，把shuffle过程归并掉了，目前只是一个顺序执行的stage

首先这种顺序执行的，肯定要比shuffle快一点，因为他不走网络。
然后可以看到处理数据量还是比较频繁的

在这里插入图片描述

缓解数据倾斜-两阶段聚合（局部聚合+全局聚合）

在这里插入图片描述
如上图，左下角蓝色的部分，有很多的相同的key存在，这个时候两阶段聚合，适用于聚合类的操作，例如reduceByKey，group by等，因为bykey的时候就会把相同的key放到一个task下面，这个时候可以分成局部聚合和全局聚合，对于相同配置的属性，在key前面打上一个随机的前缀。比如hello，打n以内的前缀，对于hello这个东西，其实总体分成了n份，这个时候可以先做一次聚合，这个时候就变成了(1_hello,2) ，即完成了局部聚合，这个时候再统一做一个操作，把前面的前缀统一干掉，这个时候就成了(hello,2)这个时候，这个时候再进行全局聚合，最终生成了(hello,6)。
小例子
在这里插入图片描述
这里把sourceRdd转化成了kvRdd，kvRdd数据大于20000的，就把素有的id变成了20001，对于20000之下的都直接返回了。这个时候如果做了一个聚合操作，groupByKey.cout

这里发现分成了两个区，说明进行了shuffle操作，也就是说一旦看到有两个相邻的stage，一定发生了shuffle操作
在这里插入图片描述
查看数据的shuffle大小和duration的时间，都能看到问题。

在这里插入图片描述

如果key是20001，就在第一个值加上了一个随机的100的值，这个时候很容易把他去掉，因为对于这个20001来说，虽然是100，但是这个时候很容易把他去掉，因为对于20001来说，虽然是100，这个时候如果想去掉的时候，就把大于20001的数据全部换成20000，然后加上1就可以了这样就返回了原来的id，这里需要注意的是改变了id，之后一定可以再改变回来。
执行了count操作之后，查看前端
在这里插入图片描述
同样还是发生了shuffle操作，但是这个时候处理的数据量是比较平均的

缓解数据倾斜-为倾斜key增加随机前/后缀

在这里插入图片描述
适用的场景，两张表都比较大，无法始终map，只能适用join，其中一个，其中个RDD少数几个key的数据量过大，另外个RDD的key分布比较均匀。
如上图中的RDD1中的000，这三个，我们认为0这个key是数据量过大的，比如占到了60%，剩下的一些key，数据量比较小，而且分布比较均匀，对于这种情况，如果直接做RDD1和RDD2的join的话，势必会导致数据倾斜的问题，对于RDD1RDD2都非常大的情况，做一个拆分操作，就是把RDD1拆分，把key比较大的拆分开，对于这些key都加一个随机前缀，比如这里加了1-3 ，因为需要和RDD2聚合，这个时候其实已经把原来相同id的打散成了n分之一个，因为加了一些前缀，这个时候如果聚合的话，可以看到上图中的skewed part join里面的 name6就是RDD2中的name6，会把这部分数据也随机扩大n倍，只有name6随机扩大n倍之后，name1里面的10才能在name6中找到10，20才能在name6中找到20，30才能找到30。
剩下的RDD1中的1，2 和RDD2中的1，2还是按原来的装的
所以对于原来整个的join操作，分成了两个join操作，一个join操作是倾斜比较厉害的join，都加了一个随机前缀，然后变成了不倾斜的数据，另一个RDD，扩大了n倍，这样的结果就是有前缀的数据，这个时候需要把结果里面的前缀去掉，去掉之后，就是真正join后的数据了，最后把上面的结果和下面的结果做一次union连接，产出最后的数据集

缓解数据倾斜-随机前缀和扩容RDD进行join

在这里插入图片描述
之前的场景是虽然key的数据很大，但是key的个数是比较少的，对于如果rdd中有大量的key，导致的数据倾斜，比如有1000000条数据，有5000的key是四五百条数据，对于之前的例子就是，1000000条数据，倾斜的key就四五个，每一个都有几十万条数据。
这个时候的解决思路是对于每一条数据的key都打上一个n以内的前缀，然后另外一个RDD将每条数据都扩容成n条数据，然后依次打上0-n的前缀，这个时候说的是什么操作呢？
在这里插入图片描述
就是上面的哪种方法的红圈的部分，就是每一个相同的key都打上一个1-n的前缀，分割成n份，同样join的rdd增加n倍，为什么增加n倍？是为了迎合上面数据的扩展，比如上面的某一个数据变成了10，因为下面不知道上面的前缀变成了10，这个时候为了让下面的RDD里有一个数据能够和我匹配上，对于我的每条数据都要加n的前缀，所以需要形成n倍数据，就像上面的RDD 10 20 30 ，下面的name6只有0，这个时候需要10 20 30 key。
有了这个n倍数据之后，最后将两个RDD join，因为加了n的前缀，所以会被分成n份，不再出现大量数据倾斜的问题，这个方法适用的类型是比较广的，一般类型的join操作都可以解决，但是数据量特别大，原来被join的rdd，被打成了n份，对内存资源消耗比较高。

缓解数据倾斜-过滤少数倾斜key

在这里插入图片描述

1.2.1为何要处理数据倾斜（Data Skew）

什么是数据倾斜
对Spark/Hadoop这样的大数据系统来讲，数据量大并不可怕，可怕的是数据倾斜。
何谓数据倾斜？数据倾斜指的是，并行处理的数据集中，某一部分（如Spark或Kafka的一个Partition）的数据显著多于其它部分，从而使得该部分的处理速度成为整个数据集处理的瓶颈。
如果数据倾斜没有解决，完全没有可能进行性能调优，其他所有的调优手段都是一个笑话。数据倾斜是最能体现一个spark大数据工程师水平的性能调优问题。
数据倾斜如果能够解决的话，代表对spark运行机制了如指掌。
数据倾斜俩大直接致命后果。
1 数据倾斜直接会导致一种情况：Out Of Memory。
2 运行速度慢,特别慢，非常慢，极端的慢，不可接受的慢。
在这里插入图片描述
我们以100亿条数据为列子。
个别Task(80亿条数据的那个Task)处理过度大量数据。导致拖慢了整个Job的执行时间。这可能导致该Task所在的机器OOM,或者运行速度非常慢。
数据倾斜是如何造成的
在Shuffle阶段。同样Key的数据条数太多了。导致了某个key(上图中的80亿条)所在的Task数据量太大了。远远超过其他Task所处理的数据量。
而这样的场景太常见了。二八定律可以证实这种场景。
搞定数据倾斜需要：
1 搞定shuffle
2 搞定业务场景
3 搞定 cpu core的使用情况
4 搞定OOM的根本原因等。
所以搞定了数据倾斜需要对至少以上的原理了如指掌。所以搞定数据倾斜是关键中的关键。
一个经验结论是：一般情况下，OOM的原因都是数据倾斜。某个task任务数据量太大，GC的压力就很大。这比不了Kafka,因为kafka的内存是不经过JVM的。是基于Linux内核的Page.
数据倾斜的原理很简单：在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。此时如果某个key对应的数据量特别大的话，就会发生数据倾斜。比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了；但是个别task可能分配到了100万数据，要运行一两个小时。因此，整个Spark作业的运行进度是由运行时间最长的那个task决定的。
因此出现数据倾斜的时候，Spark作业看起来会运行得非常缓慢，甚至可能因为某个task处理的数据量过大导致内存溢出。
下图就是一个很清晰的例子：hello这个key，在三个节点上对应了总共7条数据，这些数据都会被拉取到同一个task中进行处理；而world和you这两个key分别才对应1条数据，所以另外两个task只要分别处理1条数据即可。此时第一个task的运行时间可能是另外两个task的7倍，而整个stage的运行速度也由运行最慢的那个task所决定。
在这里插入图片描述
由于同一个Stage内的所有Task执行相同的计算，在排除不同计算节点计算能力差异的前提下，不同Task之间耗时的差异主要由该Task所处理的数据量决定。

1.2.2如何定位导致数据倾斜的代码

数据倾斜只会发生在shuffle过程中。这里给大家罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。出现数据倾斜时，可能就是你的代码中使用了这些算子中的某一个所导致的。
某个task执行特别慢的情况
首先要看的，就是数据倾斜发生在第几个stage中。
可以通过Spark Web UI来查看当前运行到了第几个stage,看一下当前这个stage各个task分配的数据量，从而进一步确定是不是task分配的数据不均匀导致了数据倾斜。
比如下图中，倒数第三列显示了每个task的运行时间。明显可以看到，有的task运行特别快，只需要几秒钟就可以运行完；而有的task运行特别慢，需要几分钟才能运行完，此时单从运行时间上看就已经能够确定发生数据倾斜了。此外，倒数第一列显示了每个task处理的数据量，明显可以看到，运行时间特别短的task只需要处理几百KB的数据即可，而运行时间特别长的task需要处理几千KB的数据，处理的数据量差了10倍。此时更加能够确定是发生了数据倾斜。
在这里插入图片描述
知道数据倾斜发生在哪一个stage之后，接着我们就需要根据stage划分原理，推算出来发生倾斜的那个stage对应代码中的哪一部分，这部分代码中肯定会有一个shuffle类算子。精准推算stage与代码的对应关系，这里介绍一个相对简单实用的推算方法：只要看到Spark代码中出现了一个shuffle类算子或者是Spark SQL的SQL语句中出现了会导致shuffle的语句（比如group by语句），那么就可以判定，以那个地方为界限划分出了前后两个stage。
这里我们就以Spark最基础的入门程序——单词计数来举例，如何用最简单的方法大致推算出一个stage对应的代码。如下示例，在整个代码中，只有一个reduceByKey是会发生shuffle的算子，因此就可以认为，以这个算子为界限，会划分出前后两个stage。
stage0，主要是执行从textFile到map操作，以及执行shuffle write操作。shuffle write操作，我们可以简单理解为对pairs RDD中的数据进行分区操作，每个task处理的数据中，相同的key会写入同一个磁盘文件内。
stage1，主要是执行从reduceByKey到collect操作，stage1的各个task一开始运行，就会首先执行shuffle read操作。执行shuffle read操作的task，会从stage0的各个task所在节点拉取属于自己处理的那些key，然后对同一个key进行全局性的聚合或join等操作，在这里就是对key的value值进行累加。stage1在执行完reduceByKey算子之后，就计算出了最终的wordCounts RDD，然后会执行collect算子，将所有数据拉取到Driver上，供我们遍历和打印输出。

val conf = new SparkConf()
val sc = new SparkContext(conf)
val lines = sc.textFile("hdfs://...")
val words = lines.flatMap(_.split(" "))
val pairs = words.map((_, 1))
val wordCounts = pairs.reduceByKey(_ + _)
wordCounts.collect().foreach(println(_))

   
   
   
   1
2
3
4
5
6
7

通过对单词计数程序的分析，希望能够让大家了解最基本的stage划分的原理，以及stage划分后shuffle操作是如何在两个stage的边界处执行的。然后我们就知道如何快速定位出发生数据倾斜的stage对应代码的哪一个部分了。比如我们在Spark Web UI或者本地log中发现，stage1的某几个task执行得特别慢，判定stage1出现了数据倾斜，那么就可以回到代码中定位出stage1主要包括了reduceByKey这个shuffle类算子，此时基本就可以确定是由reduceByKey算子导致的数据倾斜问题。比如某个单词出现了100万次，其他单词才出现10次，那么stage1的某个task就要处理100万数据，整个stage的速度就会被这个task拖慢。
某个task莫名其妙内存溢出的情况
这种情况下去定位出问题的代码就比较容易了。我们建议直接看yarn-client模式下本地log的异常栈，或者是通过YARN查看yarn-cluster模式下的log中的异常栈。一般来说，通过异常栈信息就可以定位到你的代码中哪一行发生了内存溢出。然后在那行代码附近找找，一般也会有shuffle类算子，此时很可能就是这个算子导致了数据倾斜。
但是大家要注意的是，不能单纯靠偶然的内存溢出就判定发生了数据倾斜。因为自己编写的代码的bug，以及偶然出现的数据异常，也可能会导致内存溢出。因此还是要按照上面所讲的方法，通过Spark Web UI查看报错的那个stage的各个task的运行时间以及分配的数据量，才能确定是否是由于数据倾斜才导致了这次内存溢出。
查看导致数据倾斜的key的数据分布情况
知道了数据倾斜发生在哪里之后，通常需要分析一下那个执行了shuffle操作并且导致了数据倾斜的RDD/Hive表，查看一下其中key的分布情况。这主要是为之后选择哪一种技术方案提供依据。针对不同的key分布与不同的shuffle算子组合起来的各种情况，可能需要选择不同的技术方案来解决。
此时根据你执行操作的情况不同，可以有很多种查看key分布的方式：
如果是Spark SQL中的group by、join语句导致的数据倾斜，那么就查询一下SQL中使用的表的key分布情况。
如果是对Spark RDD执行shuffle算子导致的数据倾斜，那么可以在Spark作业中加入查看key分布的代码，比如RDD.countByKey()。然后对统计出来的各个key出现的次数，collect/take到客户端打印一下，就可以看到key的分布情况。
举例来说，对于上面所说的单词计数程序，如果确定了是stage1的reduceByKey算子导致了数据倾斜，那么就应该看看进行reduceByKey操作的RDD中的key分布情况，在这个例子中指的就是pairs RDD。如下示例，我们可以先对pairs采样10%的样本数据，然后使用countByKey算子统计出每个key出现的次数，最后在客户端遍历和打印样本数据中各个key的出现次数。

val sampledPairs = pairs.sample(false, 0.1)
val sampledWordCounts = sampledPairs.countByKey()
sampledWordCounts.foreach(println(_))

   
   
   
   1
2
3

1.2.3如何缓解/消除数据倾斜

1.2.3.1 尽量避免数据源的数据倾斜

比如数据源是Kafka：
以Spark Stream通过DirectStream方式读取Kafka数据为例。由于Kafka的每一个Partition对应Spark的一个Task（Partition），所以Kafka内相关Topic的各Partition之间数据是否平衡，直接决定Spark处理该数据时是否会产生数据倾斜。
Kafka某一Topic内消息在不同Partition之间的分布，主要由Producer端所使用的Partition实现类决定。如果使用随机Partitioner，则每条消息会随机发送到一个Partition中，从而从概率上来讲，各Partition间的数据会达到平衡。此时源Stage（直接读取Kafka数据的Stage）不会产生数据倾斜。
但很多时候，业务场景可能会要求将具备同一特征的数据顺序消费，此时就需要将具有相同特征的数据放于同一个Partition中。一个典型的场景是，需要将同一个用户相关的PV信息置于同一个Partition中。此时，如果产生了数据倾斜，则需要通过其它方式处理。
比如数据源是Hive：
导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀（比如某个key对应了100万数据，其他key才对应了10条数据），而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。
方案实现思路：此时可以评估一下，是否可以通过Hive来进行数据预处理（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），然后在Spark作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。
方案实现原理：这种方案从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。但是这里也要提醒一下大家，这种方式属于治标不治本。因为毕竟数据本身就存在分布不均匀的问题，所以Hive ETL中进行group by或者join等shuffle操作时，还是会出现数据倾斜，导致Hive ETL的速度很慢。我们只是把数据倾斜的发生提前到了Hive ETL中，避免Spark程序发生数据倾斜而已。
方案优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。
方案缺点：治标不治本，Hive ETL中还是会发生数据倾斜。
方案实践经验：在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。
项目实践经验：在美团·点评的交互式用户行为分析系统中使用了这种方案，该系统主要是允许用户通过Java Web系统提交数据分析统计任务，后端通过Java提交Spark作业进行数据分析统计。要求Spark作业速度必须要快，尽量在10分钟以内，否则速度太慢，用户体验会很差。所以我们将有些Spark作业的shuffle操作提前到了Hive ETL中，从而让Spark直接使用预处理的Hive中间表，尽可能地减少Spark的shuffle操作，大幅度提升了性能，将部分作业的性能提升了6倍以上。

1.2.3.2 调整并行度分散同一个Task的不同Key

方案适用场景：如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜最简单的一种方案。
方案实现思路：在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量。对于Spark SQL中的shuffle类语句，比如group by、join等，需要设置一个参数，即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，该值默认是200，对于很多场景来说都有点过小。
方案实现原理：增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。具体原理如下图所示。
方案优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。
方案缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。
方案实践经验：该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，这个对应着100万数据的key肯定还是会分配到一个task中去处理，因此注定还是会发生数据倾斜的。所以这种方案只能说是在发现数据倾斜时尝试使用的第一种手段，尝试去用最简单的方法缓解数据倾斜而已，或者是和其他方案结合起来使用。

原理
Spark在做Shuffle时，默认使用HashPartitioner（非Hash Shuffle）对数据进行分区。如果并行度设置的不合适，可能造成大量不相同的Key对应的数据被分配到了同一个Task上，造成该Task所处理的数据远大于其它Task，从而造成数据倾斜。
如果调整Shuffle时的并行度，使得原本被分配到同一Task的不同Key发配到不同Task上处理，则可降低原Task所需处理的数据量，从而缓解数据倾斜问题造成的短板效应。
在这里插入图片描述
案例
现有一张测试数据集，内有100万条数据，每条数据有一个唯一的id值。现通过一些处理，使得id为90万之下的所有数据对12取模后余数为8（即在Shuffle并行度为12时该数据集全部被HashPartition分配到第8个Task），其它数据集id不变，从而使得id大于90万的数据在Shuffle时可被均匀分配到所有Task中，而id小于90万的数据全部分配到同一个Task中。处理过程如下

scala> val sourceRdd = sc.textFile("hdfs://master01:9000/source_index")
sourceRdd: org.apache.spark.rdd.RDD[String] = hdfs://master01:9000/source_index MapPartitionsRDD[1] at textFile at <console>:24

scala> case class brower(id:Int, time:Long, uid:String, keyword:String, url_rank:Int, click_num:Int, click_url:String) extends Serializable
defined class brower

scala> val ds = sourceRdd.map(_.split("\t")).map(attr => brower(attr(0).toInt, attr(1).toLong, attr(2), attr(3), attr(4).toInt, attr(5).toInt, attr(6))).toDS
ds: org.apache.spark.sql.Dataset[brower] = [id: int, time: bigint … 5 more fields]

scala> ds.createOrReplaceTempView(“sourceTable”)

scala> val newSource = spark.sql(“SELECT CASE WHEN id < 900000 THEN (8 + (CAST (RAND() * 50000 AS bigint)) * 12 ) ELSE id END, time, uid, keyword, url_rank, click_num, click_url FROM sourceTable”)
newSource: org.apache.spark.sql.DataFrame = [CASE WHEN (id < 900000) THEN (CAST(8 AS BIGINT) + (CAST((rand(-5486683549522524104) CAST(50000 AS DOUBLE)) AS BIGINT) CAST(12 AS BIGINT))) ELSE CAST(id AS BIGINT) END: bigint, time: bigint … 5 more fields]

scala> newSource.rdd.map(_.mkString("\t")).saveAsTextFile(“hdfs://master01:9000/test_data”)

通过上述处理，一份可能造成后续数据倾斜的测试数据即以准备好。接下来，使用Spark读取该测试数据，并通过groupByKey(12)对id分组处理，且Shuffle并行度为12。代码如下

scala> val sourceRdd = sc.textFile("hdfs://master01:9000/test_data/p*")
sourceRdd: org.apache.spark.rdd.RDD[String] = hdfs://master01:9000/test_data/p* MapPartitionsRDD[1] at textFile at <console>:24

scala> val kvRdd = sourceRdd.map(x =>{ val parm=x.split("\t");(parm(0).trim().toInt,parm(1).trim()) })
kvRdd: org.apache.spark.rdd.RDD[(Int, String)] = MapPartitionsRDD[2] at map at <console>:26

scala> kvRdd.groupByKey(12).count
res0: Long = 150000

scala> :quit

本次实验所使用集群节点数为3，每个节点可被Yarn使用的CPU核数为3，内存为2GB。在Spark-shell中进行提交
GroupBy Stage的Task状态如下图所示，Task 8处理的记录数为90万，远大于（9倍于）其它11个Task处理的10万记录。而Task 8所耗费的时间为1秒，远高于其它11个Task的平均时间。整个Stage的时间也为1秒，该时间主要由最慢的Task 8决定。数据之间处理的比例最大为105倍。
在这里插入图片描述
在这种情况下，可以通过调整Shuffle并行度，使得原来被分配到同一个Task（即该例中的Task 8）的不同Key分配到不同Task，从而降低Task 8所需处理的数据量，缓解数据倾斜。
通过groupByKey(17)将Shuffle并行度调整为17，重新提交到Spark。新的Job的GroupBy Stage所有Task状态如下图所示。

scala> val sourceRdd = sc.textFile("hdfs://master01:9000/test_data/p*")
sourceRdd: org.apache.spark.rdd.RDD[String] = hdfs://master01:9000/test_data/p* MapPartitionsRDD[1] at textFile at <console>:24

scala> val kvRdd = sourceRdd.map(x =>{ val parm=x.split("\t");(parm(0).trim().toInt,parm(1).trim()) })
kvRdd: org.apache.spark.rdd.RDD[(Int, String)] = MapPartitionsRDD[2] at map at <console>:26

scala> kvRdd.groupByKey(17).count
res0: Long = 150000

scala> :quit

在这里插入图片描述
从上图可知，相比以上次一计算，目前每一个计算的数据都比较平均，数据之间的最大比例基本为1:1，总体时间降到了0.8秒。
在这种场景下，调整并行度，并不意味着一定要增加并行度，也可能是减小并行度。如果通过groupByKey(7)将Shuffle并行度调整为7，重新提交到Spark。新Job的GroupBy Stage的所有Task状态如下图所示。
在这里插入图片描述
从上图可见，处理记录数都比较平均。
总结
适用场景
大量不同的Key被分配到了相同的Task造成该Task数据量过大。
解决方案
调整并行度。一般是增大并行度，但有时如本例减小并行度也可达到效果。
优势
实现简单，可在需要Shuffle的操作算子上直接设置并行度或者使用spark.default.parallelism设置。如果是Spark SQL，还可通过SET spark.sql.shuffle.partitions=[num_tasks]设置并行度。可用最小的代价解决问题。一般如果出现数据倾斜，都可以通过这种方法先试验几次，如果问题未解决，再尝试其它方法。
劣势
适用场景少，只能将分配到同一Task的不同Key分散开，但对于同一Key倾斜严重的情况该方法并不适用。并且该方法一般只能缓解数据倾斜，没有彻底消除问题。从实践经验来看，其效果一般。

1.2.3.3 自定义Partitioner

原理
使用自定义的Partitioner（默认为HashPartitioner），将原本被分配到同一个Task的不同Key分配到不同Task。
案例
以上述数据集为例，继续将并发度设置为12，但是在groupByKey算子上，使用自定义的

Partitioner（实现如下）

class CustomerPartitioner(numParts:Int) extends org.apache.spark.Partitioner {

//覆盖分区数
override def numPartitions: Int = numParts

//覆盖分区号获取函数
override def getPartition(key: Any): Int = {
val id: Int = key.toString.toInt
if (id <= 900000)
return new java.util.Random().nextInt(100) % 12
else
return id % 12
}
}

执行如下代码：

scala> :paste
// Entering paste mode (ctrl-D to finish)
class CustomerPartitioner(numParts:Int) extends org.apache.spark.Partitioner {
  //覆盖分区数
  override def numPartitions: Int = numParts
  //覆盖分区号获取函数
  override def getPartition(key: Any): Int = {
    val id: Int = key.toString.toInt
    if (id <= 900000)
      return new java.util.Random().nextInt(100) % 12
    else
      return id % 12
  }
}
// Exiting paste mode, now interpreting.
defined class CustomerPartitioner
scala> val sourceRdd = sc.textFile("hdfs://master01:9000/test_data/p*")
sourceRdd: org.apache.spark.rdd.RDD[String] = hdfs://master01:9000/test_data/p* MapPartitionsRDD[1] at textFile at <console>:24

scala> val kvRdd = sourceRdd.map(x =>{ val parm=x.split("\t");(parm(0).trim().toInt,parm(1).trim()) })
kvRdd: org.apache.spark.rdd.RDD[(Int, String)] = MapPartitionsRDD[2] at map at <console>:26

scala> kvRdd.groupByKey(new CustomerPartitioner(12)).count
res0: Long = 565312

scala> :quit

由下图可见，使用自定义Partition后，各Task所处理的数据集大小相当。
在这里插入图片描述
总结
适用场景
大量不同的Key被分配到了相同的Task造成该Task数据量过大。
解决方案
使用自定义的Partitioner实现类代替默认的HashPartitioner，尽量将所有不同的Key均匀分配到不同的Task中。
优势
不影响原有的并行度设计。如果改变并行度，后续Stage的并行度也会默认改变，可能会影响后续Stage。
劣势
适用场景有限，只能将不同Key分散开，对于同一Key对应数据集非常大的场景不适用。效果与调整并行度类似，只能缓解数据倾斜而不能完全消除数据倾斜。而且需要根据数据特点自定义专用的Partitioner，不够灵活。

1.2.3.4 将Reduce side Join转变为Map side Join

方案适用场景：在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M或者一两G），比较适用此方案。
方案实现思路：不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。
方案实现原理：普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。具体原理如下图所示。
在这里插入图片描述
方案优点：对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。
方案缺点：适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。毕竟我们需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果我们广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。
通过Spark的Broadcast机制，将Reduce侧Join转化为Map侧Join，避免Shuffle从而完全消除Shuffle带来的数据倾斜。

案例
通过如下SQL创建一张具有倾斜Key且总记录数为1.5亿的大表test。

INSERT OVERWRITE TABLE test
  SELECT CAST(CASE WHEN id < 980000000 THEN (95000000 + (CAST (RAND() * 4 AS INT) + 1) * 48 )
  ELSE CAST(id/10 AS INT) END AS STRING),
name
FROM student_external
  WHERE id BETWEEN 900000000 AND 1050000000;

 
 
 
 1
2
3
4
5
6

使用如下SQL创建一张数据分布均匀且总记录数为50万的小表test_new。

INSERT OVERWRITE TABLE test_new
  SELECT CAST(CAST(id/10 AS INT) AS STRING),
name
FROM student_delta_external
  WHERE id BETWEEN 950000000 AND 950500000;

 
 
 
 1
2
3
4
5

直接通过Spark Thrift Server提交如下SQL将表test与表test_new进行Join并将Join结果存于表test_join中。
在这里插入图片描述

INSERT OVERWRITE TABLE test_join
  SELECT test_new.id, test_new.name
FROM test
  JOIN test_new
  ON test.id = test_new.id;

 
 
 
 1
2
3
4
5

该SQL对应的DAG如下图所示。从该图可见，该执行过程总共分为三个Stage，前两个用于从Hive中读取数据，同时二者进行Shuffle，通过最后一个Stage进行Join并将结果写入表test_join中。
从下图可见，最近Join Stage各Task处理的数据倾斜严重，处理数据量最大的Task耗时7.1分钟，远高于其它无数据倾斜的Task约2s秒的耗时。
在这里插入图片描述
接下来，尝试通过Broadcast实现Map侧Join。实现Map侧Join的方法，并非直接通过CACHE TABLE test_new将小表test_new进行cache。现通过如下SQL进行Join。

CACHE TABLE test_new;
INSERT OVERWRITE TABLE test_join
  SELECT test_new.id, test_new.name
FROM test
  JOIN test_new
  ON test.id = test_new.id;

 
 
 
 1
2
3
4
5
6

通过如下DAG图可见，该操作仍分为三个Stage，且仍然有Shuffle存在，唯一不同的是，小表的读取不再直接扫描Hive表，而是扫描内存中缓存的表。
在这里插入图片描述
并且数据倾斜仍然存在。如下图所示，最慢的Task耗时为7.1分钟，远高于其它Task的约2秒。

正确的使用Broadcast实现Map侧Join的方式是，通过SET spark.sql.autoBroadcastJoinThreshold=104857600;将Broadcast的阈值设置得足够大。
再次通过如下SQL进行Join。

SET spark.sql.autoBroadcastJoinThreshold=104857600;
INSERT OVERWRITE TABLE test_join
  SELECT test_new.id, test_new.name
FROM test
  JOIN test_new
  ON test.id = test_new.id;

 
 
 
 1
2
3
4
5
6

通过如下DAG图可见，该方案只包含一个Stage。
在这里插入图片描述
并且从下图可见，各Task耗时相当，无明显数据倾斜现象。并且总耗时为1.5分钟，远低于Reduce侧Join的7.3分钟。

总结
适用场景
参与Join的一边数据集足够小，可被加载进Driver并通过Broadcast方法广播到各个Executor中。
优势
避免了Shuffle，彻底消除了数据倾斜产生的条件，可极大提升性能。
劣势
要求参与Join的一侧数据集足够小，并且主要适用于Join的场景，不适合聚合的场景，适用条件有限。

1.2.3.5 两阶段聚合（局部聚合+全局聚合）

方案适用场景：对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。
方案实现思路：这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。接着对打上随机数后的数据，执行reduceByKey等聚合操作，进行局部聚合，那么局部聚合结果，就会变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。
方案实现原理：将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。
方案优点：对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。
方案缺点：仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。
在这里插入图片描述

// 第一步，给RDD中的每个key都打上一个随机前缀。
JavaPairRDD<String, Long> randomPrefixRdd = rdd.mapToPair(
  new PairFunction<Tuple2<Long,Long>, String, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<String, Long> call(Tuple2<Long, Long> tuple)
    throws Exception {
      Random random = new Random();
      int prefix = random.nextInt(10);
      return new Tuple2<String, Long>(prefix + "_" + tuple._1, tuple._2);
    }
  });
// 第二步，对打上随机前缀的key进行局部聚合。
JavaPairRDD<String, Long> localAggrRdd = randomPrefixRdd.reduceByKey(
  new Function2<Long, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Long call(Long v1, Long v2) throws Exception {
      return v1 + v2;
    }
  });
// 第三步，去除RDD中每个key的随机前缀。
JavaPairRDD<Long, Long> removedRandomPrefixRdd = localAggrRdd.mapToPair(
  new PairFunction<Tuple2<String,Long>, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<Long, Long> call(Tuple2<String, Long> tuple)
    throws Exception {
      long originalKey = Long.valueOf(tuple._1.split("_")[1]);
      return new Tuple2<Long, Long>(originalKey, tuple._2);
    }
  });
// 第四步，对去除了随机前缀的RDD进行全局聚合。
JavaPairRDD<Long, Long> globalAggrRdd = removedRandomPrefixRdd.reduceByKey(
  new Function2<Long, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Long call(Long v1, Long v2) throws Exception {
      return v1 + v2;
    }
  });

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

1.2.3.6 为skew的key增加随机前/后缀

原理
为数据量特别大的Key增加随机前/后缀，使得原来Key相同的数据变为Key不相同的数据，从而使倾斜的数据集分散到不同的Task中，彻底解决数据倾斜问题。Join另一侧的数据中，与倾斜Key对应的部分数据，与随机前缀集作笛卡尔乘积，从而保证无论数据倾斜侧倾斜Key如何加前缀，都能与之正常Join。
在这里插入图片描述
案例
通过如下SQL，将id为9亿到9.08亿共800万条数据的id转为9500048或者9500096，其它数据的id除以100取整。从而该数据集中，id为9500048和9500096的数据各400万，其它id对应的数据记录数均为100条。这些数据存于名为test的表中。
对于另外一张小表test_new，取出50万条数据，并将id（递增且唯一）除以100取整，使得所有id都对应100条数据。

NSERT OVERWRITE TABLE test
  SELECT CAST(CASE WHEN id < 908000000 THEN (9500000 + (CAST (RAND() * 2 AS INT) + 1) * 48 )
  ELSE CAST(id/100 AS INT) END AS STRING),
name
FROM student_external
  WHERE id BETWEEN 900000000 AND 1050000000;
INSERT OVERWRITE TABLE test_new
  SELECT CAST(CAST(id/100 AS INT) AS STRING),
name
FROM student_delta_external
  WHERE id BETWEEN 950000000 AND 950500000;

 
 
 
 1
2
3
4
5
6
7
8
9
10
11

通过如下代码，读取test表对应的文件夹内的数据并转换为JavaPairRDD存于leftRDD中，同样读取test表对应的数据存于rightRDD中。通过RDD的join算子对leftRDD与rightRDD进行Join，并指定并行度为48。

public class SparkDataSkew{
  public static void main(String[] args) {
    SparkConf sparkConf = new SparkConf();
    sparkConf.setAppName("DemoSparkDataFrameWithSkewedBigTableDirect");
    sparkConf.set("spark.default.parallelism", parallelism + "");
    JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf);
    JavaPairRDD<String, String> leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    JavaPairRDD<String, String> rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    leftRDD.join(rightRDD, parallelism)
      .mapToPair((Tuple2<String, Tuple2<String, String>> tuple) -> new Tuple2<String, String>(tuple._1(), tuple._2()._2()))
      .foreachPartition((Iterator<Tuple2<String, String>> iterator) -> {
        AtomicInteger atomicInteger = new AtomicInteger();
        iterator.forEachRemaining((Tuple2<String, String> tuple) -> atomicInteger.incrementAndGet());
      });
    javaSparkContext.stop();
    javaSparkContext.close();
  }
}

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

从下图可看出，整个Join耗时1分54秒，其中Join Stage耗时1.7分钟。
在这里插入图片描述
通过分析Join Stage的所有Task可知，在其它Task所处理记录数为192.71万的同时Task 32的处理的记录数为992.72万，故它耗时为1.7分钟，远高于其它Task的约10秒。这与上文准备数据集时，将id为9500048为9500096对应的数据量设置非常大，其它id对应的数据集非常均匀相符合。

现通过如下操作，实现倾斜Key的分散处理
将leftRDD中倾斜的key（即9500048与9500096）对应的数据单独过滤出来，且加上1到24的随机前缀，并将前缀与原数据用逗号分隔（以方便之后去掉前缀）形成单独的leftSkewRDD
将rightRDD中倾斜key对应的数据抽取出来，并通过flatMap操作将该数据集中每条数据均转换为24条数据（每条分别加上1到24的随机前缀），形成单独的rightSkewRDD
将leftSkewRDD与rightSkewRDD进行Join，并将并行度设置为48，且在Join过程中将随机前缀去掉，得到倾斜数据集的Join结果skewedJoinRDD
将leftRDD中不包含倾斜Key的数据抽取出来作为单独的leftUnSkewRDD
对leftUnSkewRDD与原始的rightRDD进行Join，并行度也设置为48，得到Join结果unskewedJoinRDD
通过union算子将skewedJoinRDD与unskewedJoinRDD进行合并，从而得到完整的Join结果集
具体实现代码如下

public class SparkDataSkew{
  public static void main(String[] args) {
    int parallelism = 48;
    SparkConf sparkConf = new SparkConf();
    sparkConf.setAppName("SolveDataSkewWithRandomPrefix");
    sparkConf.set("spark.default.parallelism", parallelism + "");
    JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf);
    JavaPairRDD<String, String> leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    JavaPairRDD<String, String> rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    String[] skewedKeyArray = new String[]{"9500048", "9500096"};
    Set<String> skewedKeySet = new HashSet<String>();
    List<String> addList = new ArrayList<String>();
    for(int i = 1; i <=24; i++) {
      addList.add(i + "");
    }
    for(String key : skewedKeyArray) {
      skewedKeySet.add(key);
    }
    Broadcast<Set<String>> skewedKeys = javaSparkContext.broadcast(skewedKeySet);
    Broadcast<List<String>> addListKeys = javaSparkContext.broadcast(addList);
    JavaPairRDD<String, String> leftSkewRDD = leftRDD
      .filter((Tuple2<String, String> tuple) -> skewedKeys.value().contains(tuple._1()))
      .mapToPair((Tuple2<String, String> tuple) -> new Tuple2<String, String>((new Random().nextInt(24) + 1) + "," + tuple._1(), tuple._2()));
    JavaPairRDD<String, String> rightSkewRDD = rightRDD.filter((Tuple2<String, String> tuple) -> skewedKeys.value().contains(tuple._1()))
      .flatMapToPair((Tuple2<String, String> tuple) -> addListKeys.value().stream()
        .map((String i) -> new Tuple2<String, String>( i + "," + tuple._1(), tuple._2()))
        .collect(Collectors.toList())
        .iterator()
      );
    JavaPairRDD<String, String> skewedJoinRDD = leftSkewRDD
      .join(rightSkewRDD, parallelism)
      .mapToPair((Tuple2<String, Tuple2<String, String>> tuple) -> new Tuple2<String, String>(tuple._1().split(",")[1], tuple._2()._2()));
    JavaPairRDD<String, String> leftUnSkewRDD = leftRDD.filter((Tuple2<String, String> tuple) -> !skewedKeys.value().contains(tuple._1()));
    JavaPairRDD<String, String> unskewedJoinRDD = leftUnSkewRDD.join(rightRDD, parallelism).mapToPair((Tuple2<String, Tuple2<String, String>> tuple) -> new Tuple2<String, String>(tuple._1(), tuple._2()._2()));
    skewedJoinRDD.union(unskewedJoinRDD).foreachPartition((Iterator<Tuple2<String, String>> iterator) -> {
      AtomicInteger atomicInteger = new AtomicInteger();
      iterator.forEachRemaining((Tuple2<String, String> tuple) -> atomicInteger.incrementAndGet());
    });
    javaSparkContext.stop();
    javaSparkContext.close();
  }
}

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

从下图可看出，整个Join耗时58秒，其中Join Stage耗时33秒。
在这里插入图片描述
通过分析Join Stage的所有Task可知
由于Join分倾斜数据集Join和非倾斜数据集Join，而各Join的并行度均为48，故总的并行度为96
由于提交任务时，设置的Executor个数为4，每个Executor的core数为12，故可用Core数为48，所以前48个Task同时启动（其Launch时间相同），后48个Task的启动时间各不相同（等待前面的Task结束才开始）
由于倾斜Key被加上随机前缀，原本相同的Key变为不同的Key，被分散到不同的Task处理，故在所有Task中，未发现所处理数据集明显高于其它Task的情况
在这里插入图片描述
实际上，由于倾斜Key与非倾斜Key的操作完全独立，可并行进行。而本实验受限于可用总核数为48，可同时运行的总Task数为48，故而该方案只是将总耗时减少一半（效率提升一倍）。如果资源充足，可并发执行Task数增多，该方案的优势将更为明显。在实际项目中，该方案往往可提升数倍至10倍的效率。
总结
适用场景
两张表都比较大，无法使用Map则Join。其中一个RDD有少数几个Key的数据量过大，另外一个RDD的Key分布较为均匀。
解决方案
将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀，另外一个RDD每条数据分别与随机前缀结合形成新的RDD（相当于将其数据增到到原来的N倍，N即为随机前缀的总个数），然后将二者Join并去掉前缀。然后将不包含倾斜Key的剩余数据进行Join。最后将两次Join的结果集通过union合并，即可得到全部Join结果。
优势
相对于Map则Join，更能适应大数据集的Join。如果资源充足，倾斜部分数据集与非倾斜部分数据集可并行进行，效率提升明显。且只针对倾斜部分的数据做数据扩展，增加的资源消耗有限。
劣势
如果倾斜Key非常多，则另一侧数据膨胀非常大，此方案不适用。而且此时对倾斜Key与非倾斜Key分开处理，需要扫描数据集两遍，增加了开销。

1.2.3.7 使用随机前缀和扩容RDD进行join

方案适用场景：如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义，此时就只能使用最后一种方案来解决问题了。
方案实现思路：
该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。
然后将该RDD的每条数据都打上一个n以内的随机前缀。
同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。
最后将两个处理后的RDD进行join即可。
方案实现原理：将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。该方案与“解决方案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。
方案优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。
方案缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。
方案实践经验：曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

// 首先将其中一个key分布相对较为均匀的RDD膨胀100倍。
JavaPairRDD<String, Row> expandedRDD = rdd1.flatMapToPair(
  new PairFlatMapFunction<Tuple2<Long,Row>, String, Row>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Iterable<Tuple2<String, Row>> call(Tuple2<Long, Row> tuple)
    throws Exception {
      List<Tuple2<String, Row>> list = new ArrayList<Tuple2<String, Row>>();
      for(int i = 0; i < 100; i++) {
        list.add(new Tuple2<String, Row>(0 + "_" + tuple._1, tuple._2));
      }
      return list;
    }
  });
// 其次，将另一个有数据倾斜key的RDD，每条数据都打上100以内的随机前缀。
JavaPairRDD<String, String> mappedRDD = rdd2.mapToPair(
  new PairFunction<Tuple2<Long,String>, String, String>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<String, String> call(Tuple2<Long, String> tuple)
    throws Exception {
      Random random = new Random();
      int prefix = random.nextInt(100);
      return new Tuple2<String, String>(prefix + "_" + tuple._1, tuple._2);
    }
  });
// 将两个处理后的RDD进行join即可。
JavaPairRDD<String, Tuple2<String, Row>> joinedRDD = mappedRDD.join(expandedRDD);

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

1.2.3.8 大表随机添加N种随机前缀，小表扩大N倍

原理
如果出现数据倾斜的Key比较多，上一种方法将这些大量的倾斜Key分拆出来，意义不大。此时更适合直接对存在数据倾斜的数据集全部加上随机前缀，然后对另外一个不存在严重数据倾斜的数据集整体与随机前缀集作笛卡尔乘积（即将数据量扩大N倍）。

案例
这里给出示例代码，读者可参考上文中分拆出少数倾斜Key添加随机前缀的方法，自行测试。

public class SparkDataSkew {
  public static void main(String[] args) {
    SparkConf sparkConf = new SparkConf();
    sparkConf.setAppName("ResolveDataSkewWithNAndRandom");
    sparkConf.set("spark.default.parallelism", parallelism + "");
    JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf);
    JavaPairRDD<String, String> leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    JavaPairRDD<String, String> rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/")
      .mapToPair((String row) -> {
        String[] str = row.split(",");
        return new Tuple2<String, String>(str[0], str[1]);
      });
    List<String> addList = new ArrayList<String>();
    for(int i = 1; i <=48; i++) {
      addList.add(i + "");
    }
    Broadcast<List<String>> addListKeys = javaSparkContext.broadcast(addList);
    JavaPairRDD<String, String> leftRandomRDD = leftRDD.mapToPair((Tuple2<String, String> tuple) -> new Tuple2<String, String>(new Random().nextInt(48) + "," + tuple._1(), tuple._2()));
    JavaPairRDD<String, String> rightNewRDD = rightRDD
      .flatMapToPair((Tuple2<String, String> tuple) -> addListKeys.value().stream()
        .map((String i) -> new Tuple2<String, String>( i + "," + tuple._1(), tuple._2()))
        .collect(Collectors.toList())
        .iterator()
      );
    JavaPairRDD<String, String> joinRDD = leftRandomRDD
      .join(rightNewRDD, parallelism)
      .mapToPair((Tuple2<String, Tuple2<String, String>> tuple) -> new Tuple2<String, String>(tuple._1().split(",")[1], tuple._2()._2()));
    joinRDD.foreachPartition((Iterator<Tuple2<String, String>> iterator) -> {
      AtomicInteger atomicInteger = new AtomicInteger();
      iterator.forEachRemaining((Tuple2<String, String> tuple) -> atomicInteger.incrementAndGet());
    });
    javaSparkContext.stop();
    javaSparkContext.close();
  }
}

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

总结
适用场景
一个数据集存在的倾斜Key比较多，另外一个数据集数据分布比较均匀。
优势
对大部分场景都适用，效果不错。
劣势
需要将一个数据集整体扩大N倍，会增加资源消耗。
总结
对于数据倾斜，并无一个统一的一劳永逸的方法。更多的时候，是结合数据特点（数据集大小，倾斜Key的多少等）综合使用上文所述的多种方法。

1.2.3.9 采样倾斜key并分拆join操作

方案适用场景：两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五”，那么此时可以看一下两个RDD/Hive表中的key分布情况。如果出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。
方案实现思路：
对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个key的数量，计算出来数据量最大的是哪几个key。
然后将这几个key对应的数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key都打上n以内的随机数作为前缀，而不会导致倾斜的大部分key形成另外一个RDD。
接着将需要join的另一个RDD，也过滤出来那几个倾斜key对应的数据并形成一个单独的RDD，将每条数据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀，不会导致倾斜的大部分key也形成另外一个RDD。
再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打散成n份，分散到多个task中去进行join了。
而另外两个普通的RDD就照常join即可。
最后将两次join的结果使用union算子合并起来即可，就是最终的join结果。
方案实现原理：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。具体原理见下图。
方案优点：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，采用该方式可以用最有效的方式打散key进行join。而且只需要针对少数倾斜key对应的数据进行扩容n倍，不需要对全量数据进行扩容。避免了占用过多内存。
方案缺点：如果导致倾斜的key特别多的话，比如成千上万个key都导致数据倾斜，那么这种方式也不适合。
在这里插入图片描述

// 首先从包含了少数几个导致数据倾斜key的rdd1中，采样10%的样本数据。
JavaPairRDD<Long, String> sampledRDD = rdd1.sample(false, 0.1);
// 对样本数据RDD统计出每个key的出现次数，并按出现次数降序排序。
// 对降序排序后的数据，取出top 1或者top 100的数据，也就是key最多的前n个数据。
// 具体取出多少个数据量最多的key，由大家自己决定，我们这里就取1个作为示范。
JavaPairRDD<Long, Long> mappedSampledRDD = sampledRDD.mapToPair(
  new PairFunction<Tuple2<Long,String>, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<Long, Long> call(Tuple2<Long, String> tuple)
    throws Exception {
      return new Tuple2<Long, Long>(tuple._1, 1L);
    }
  });
JavaPairRDD<Long, Long> countedSampledRDD = mappedSampledRDD.reduceByKey(
  new Function2<Long, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Long call(Long v1, Long v2) throws Exception {
      return v1 + v2;
    }
  });
JavaPairRDD<Long, Long> reversedSampledRDD = countedSampledRDD.mapToPair(
  new PairFunction<Tuple2<Long,Long>, Long, Long>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<Long, Long> call(Tuple2<Long, Long> tuple)
    throws Exception {
      return new Tuple2<Long, Long>(tuple._2, tuple._1);
    }
  });
final Long skewedUserid = reversedSampledRDD.sortByKey(false).take(1).get(0)._2;
// 从rdd1中分拆出导致数据倾斜的key，形成独立的RDD。
JavaPairRDD<Long, String> skewedRDD = rdd1.filter(
  new Function<Tuple2<Long,String>, Boolean>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Boolean call(Tuple2<Long, String> tuple) throws Exception {
      return tuple._1.equals(skewedUserid);
    }
  });
// 从rdd1中分拆出不导致数据倾斜的普通key，形成独立的RDD。
JavaPairRDD<Long, String> commonRDD = rdd1.filter(
  new Function<Tuple2<Long,String>, Boolean>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Boolean call(Tuple2<Long, String> tuple) throws Exception {
      return !tuple._1.equals(skewedUserid);
    }
  });
// rdd2，就是那个所有key的分布相对较为均匀的rdd。
// 这里将rdd2中，前面获取到的key对应的数据，过滤出来，分拆成单独的rdd，并对rdd中的数据使用flatMap算子都扩容100倍。
// 对扩容的每条数据，都打上0～100的前缀。
JavaPairRDD<String, Row> skewedRdd2 = rdd2.filter(
  new Function<Tuple2<Long,Row>, Boolean>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Boolean call(Tuple2<Long, Row> tuple) throws Exception {
      return tuple._1.equals(skewedUserid);
    }
  }).flatMapToPair(new PairFlatMapFunction<Tuple2<Long,Row>, String, Row>() {
  private static final long serialVersionUID = 1L;
  @Override
  public Iterable<Tuple2<String, Row>> call(
    Tuple2<Long, Row> tuple) throws Exception {
    Random random = new Random();
    List<Tuple2<String, Row>> list = new ArrayList<Tuple2<String, Row>>();
    for(int i = 0; i < 100; i++) {
      list.add(new Tuple2<String, Row>(i + "_" + tuple._1, tuple._2));
    }
    return list;
  }
});
// 将rdd1中分拆出来的导致倾斜的key的独立rdd，每条数据都打上100以内的随机前缀。
// 然后将这个rdd1中分拆出来的独立rdd，与上面rdd2中分拆出来的独立rdd，进行join。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD1 = skewedRDD.mapToPair(
  new PairFunction<Tuple2<Long,String>, String, String>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<String, String> call(Tuple2<Long, String> tuple)
    throws Exception {
      Random random = new Random();
      int prefix = random.nextInt(100);
      return new Tuple2<String, String>(prefix + "_" + tuple._1, tuple._2);
    }
  })
  .join(skewedUserid2infoRDD)
  .mapToPair(new PairFunction<Tuple2<String,Tuple2<String,Row>>, Long, Tuple2<String, Row>>() {
    private static final long serialVersionUID = 1L;
    @Override
    public Tuple2<Long, Tuple2<String, Row>> call(
      Tuple2<String, Tuple2<String, Row>> tuple)
    throws Exception {
      long key = Long.valueOf(tuple._1.split("_")[1]);
      return new Tuple2<Long, Tuple2<String, Row>>(key, tuple._2);
    }
  });
// 将rdd1中分拆出来的包含普通key的独立rdd，直接与rdd2进行join。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD2 = commonRDD.join(rdd2);
// 将倾斜key join后的结果与普通key join后的结果，uinon起来。
// 就是最终的join结果。
JavaPairRDD<Long, Tuple2<String, Row>> joinedRDD = joinedRDD1.union(joinedRDD2);

 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93