SparkCore杂记二

最新推荐文章于 2025-08-13 22:50:12 发布

pucheung

最新推荐文章于 2025-08-13 22:50:12 发布

阅读量332

点赞数 2

CC 4.0 BY-SA版权

分类专栏： spark 文章标签： spark spark shuffle spark持久化

本文链接：https://blog.youkuaiyun.com/u013516966/article/details/78481730

spark 专栏收录该内容

14 篇文章

订阅专栏

本文深入探讨Spark的shuffle过程，包括shuffle write与shuffle read，以及数据倾斜问题。同时，文章详细介绍了RDD的持久化机制，如不同级别的持久化策略、缓存与淘汰策略，并讨论了如何选择合适的持久化方案以优化性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这篇博客主要讲解Spark中任务shuffle与persistence, 首先来说说shuffle洗牌，学过hadoop的同学应该都了解mapreduce,每一个mapreduce任务都要经过一次shuffle，简单的理解shuffle就是根据key将数据进行重新分布，这个过程会发生文件IO/网络IO,是比较耗性能的一个操作，并且还有可能产生数据倾斜，简单说一下数据倾斜指每个任务中分配的数据不均匀，一些任务数据量很少执行时间很短，一些数量很多执行时间很长，解决数据倾斜就是尽可能的使每个任务的数据量分布均匀，shuffle包括shuffle write与shuffler read过程，shuffle write将数据按照一定的规则组织写入到内存中，当内存达到一定上限就会写入到磁盘中，shuffle过程通常会产生大量的磁盘文件，shuffle read 指每个task到磁盘文件读取相应的文件，会读取一部分到内存中进行处理，然后读取继续进行处理。Spark中shuffle同样也指数据重分布，在spark中执行reduceByKey/join/groupByKey/repartition等算子操作就会执行shuffle，shuffle过程中key的式如何分布的在上节已经讲到过，主要有HashPartitioner(默认)、RangePartitioner来控制，HashPartitioner会将相同的key分布到同一个分区中，相同key的记录会在同一个分区中执行聚合操作，Spark中shuffle包括两种类型：hash/sort ，二者最主要的区别就是产生中间文件数量的多少，hash类型shuffle中每一个task都会产生下一个stage中task个数的文件数量，经过优化过后的hash shuffle 每一个core(执行多批task) 会产生下一个stage中task个数的文件数量, 而sort 类型的shuffle每个task只有一个磁盘文件与索引文件，索引文件会索引数据文件中数据对应下一个stage的每一个task,从spark1.2开始已经开始使用sort类型的shuffle。由于shuffle是一个比较号性能的算子操作，所以我们应该尽量少使用或者使用比较高性能的算子，使用reduceByKey代替groupBkKey,reduceByKey会在map段进行预聚合操作，而groupByKey不会，这样会减少IO的数据量，使用map+broadcast 代替join ,只适合broadcast 较小的数据量，由于join会产生shuffle ,但是map+broadcast是不会产生shuffle的。

RDD的persistence持久化，在实际中是经常使用的，对于多次使用或者需要checkpoint的RDD通常都是需要进行持久化的，当需要再次使用时直接从内存或者磁盘中获取即可，将会对性能有很大的提升，RDD是分区，那么持久化也就是分区执行，每个分区将会被持久在它所在的Executor中，spark中对RDD提供的多种持久化方案：内存（MEMORY_ONLY）、内存与磁盘（MEMORY_AND_DISK）等，直接参考官方文档即可，对于仅仅使用内存级别的持久化需要注意你的内存是否足够大，使用序列化机制可以节约空间但是带来的问题就是对CPU的消耗增加，该不该序列化需要经过实际测试得出，如果想提升容错机制，提供了持久化两份的机制，另外还支持OFF_HEAP 持久化，使用堆外内存就不用担心GC的影响。使用rdd.cache()或者rdd.persist(MEMORY_ONLY)来进行持久化，只有在执行action之后持久化在开始执行，那说明持久化跟transformations一样是lazy的，rdd.cache()是rdd.persist(MEMORY_ONLY)的用法，只缓存在内存中，如果一个RDD已经经过持久化，那么你将不能再次对其持久化，除非手动执行rdd.unpersist()方法清除持久化数据之后，否则就会报错。RDD是存在与executor中的storage Memory中的，一个Executor的所有RDD都是存在该区域中的，每个RDD在该区域都会有一个唯一的id,作为该RDD的标识符，当有RDD需要持久化，就会尝试性从该区域中获取一定的缓存空间，如果空间足够那么就会缓存，如果空间不足够那么它就会将该区域的与其具有相同缓存级别的数据并且最近最少使用的eveit掉，eveit对于仅仅只是内存级别将会被清除（如果再次需要使用这个被清除的RDD，通过rddId查询没找到，那么就要重新计算，所以仅仅内存持久化方案要慎用）对于内存与磁盘级别的将会被写入磁盘，该区域是一个LinkHashMap的一个结构，RDD的清除策略是LRU(最近最少使用)。综上RDD的清除策略有两种：1.手动执行rdd.unpersist() 2. 自动LRU策略。提一下：rdd在执行shuffle过程中，会自动将中间的产生的数据进行持久化，为了避免节点执行任务失败重新计算，这也是对性的提升。对RDD持久化方案的选择，其实就是对cpu与内存的一种抉择，MEMORY_ONLY当然是一种最快任务执行方案，但是我们还是需要结合实际机器的cpu、内存来考虑，我经常使用的持久化方案是：MEMORY_AND_DISK_SER ，理由：1 . 序列化节约内存空间，因为线上的集群不仅仅跑spark任务，还有hive/impala/solr/hbase等，内存对于我们来说是比较珍贵的 2. 该RDD被清除到磁盘中，当再洗需要使用也不需要重新计算，直接从磁盘中获取即可。