SparkShuffle文件寻址以及Executor的内存管理

最新推荐文章于 2022-09-02 08:00:00 发布

Hello stupid

最新推荐文章于 2022-09-02 08:00:00 发布

阅读量285

点赞数

分类专栏： Spark 文章标签： Spark文件寻址以及Executor内存管理

本文链接：https://blog.csdn.net/kinganne/article/details/103061537

版权

Spark 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

SparkShuffle文件寻址

在说文件寻址的时候先介绍下面几个对象

MapOutPutTracker：管理磁盘文件的对象， MapOutPutTrackerMaster
MapOutPutTrackerWorker
BlockManager：块管理
BlockManagerMaster：
DiskStore:管理磁盘文件
MemoryStore：管理内存数据
BlockTransferService：负责拉取数据
BlockManagerSlave：
DiskStore:管理磁盘文件
MemoryStore：管理内存数据
BlockTransferService：负责拉取数据

在这里插入图片描述

当Map阶段处理完成之后，将map处理完数据落地磁盘的位置已一个mapStus对象通过MapOutPutTracker发送给MapOutPutTrackerMaster
reduce阶段MapOutPutTrackerWorker 会去获取文件的位置，然后通过BlockManagerSalve 去连接对方，拉取数据拉取的时候会开启5个线程，默认一次拉取的数据不超过48M，拉取到executor端的内存，不够会落地磁盘

如果内存为48M，拉取的数据量为50M，会发生ReduceOOM
解决方案
1.减少拉取的数量
2.增加Executor的内存

我们可以通过调节shuffle大小，解决OOM内存溢出问题

设置参数：
1.在代码中设置，硬编码问题
2.在spark-defaluts.conf中设置
3.最好在提交任务设置 ,./spark-submit --conf xxx = xxx

1.spark.reducer.maxSizeInFlight 默认值：48m 参数说明：该参数用于设置shuffle read task的buffer缓冲大小，而这个buffer缓冲决定了每次能够拉取多少数据。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如96m），
从而减少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。

2.spark.shuffle.io.maxRetries 重试次数默认值：3 参数说明：shuffle read task从shuffle write task所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，
是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败。
调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full
gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现，
对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数可以大幅度提升稳定性。 shuffle file not find
taskScheduler不负责重试task，由DAGScheduler负责重试stage

3.spark.shuffle.io.retryWait 默认值：5s 参数说明：具体解释同上，该参数代表了每次重试拉取数据的等待间隔，默认是5s。
调优建议：建议加大间隔时长（比如60s），以增加shuffle操作的稳定性。

4.spark.shuffle.sort.bypassMergeThreshold----针对SortShuffle 默认值：200 参数说明：当ShuffleManager为SortShuffleManager时，如果shuffle read
task的数量小于这个阈值（默认是200），则shuffle
write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，
但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。
调优建议：当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle
read task的数量。那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。
但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。