【Spark】Spark的两种核心Shuffle工作原理详解

如果觉得这篇文章对您有帮助,别忘了点赞、分享或关注哦!您的一点小小支持,不仅能帮助更多人找到有价值的内容,还能鼓励我持续分享更多精彩的技术文章。感谢您的支持,让我们一起在技术的世界中不断进步!

Spark 的shuffle机制

一、Spark ShuffleManager 发展历程

  • Spark 1.1.0 之前
    • 在 Spark 1.1.0 之前,Spark 使用 BlockStoreShuffleFetcher 来处理 Shuffle 操作。这个实现主要依赖于直接从 BlockManager 获取 Shuffle 数据,并通过网络进行交换。
  • Spark 1.1.x(默认使用 HashShuffleManager)
    • HashShuffleManager 使用哈希算法将数据划分到不同的分区。在进行 Shuffle 操作时,Spark 会为每个键计算一个哈希值,然后根据该值将数据分配到相应的分区。
  • Spark 1.2.x 及以后版本(默认使用 SortShuffleManager)
  • Spark 2.0.x 及以后版本(不在使用HashShuffleManager,默认使用 SortShuffleManager)

二、HashShuffleManager 原理

假设:每个 Executor 只有1个CPU core,也就是说,无论这个 Executor 上分配多少个 task

线程,同一时间都只能执行一个 task 线程。

  • 未经优化的HashShuffleManager工作原理

1.Shuffle Write 阶段

  • 将每个task处理的数据按照key进行hash算法,从而将相同key都写入同一个磁盘文件,而每一个磁盘文件都只属于下游stage的一个task,在数据写入磁盘之前,会现将数据写入内存缓冲区中,当内存缓冲区填满以后,才会溢写到磁盘文件中去。
  • 下一个stage的task有多少个,当前stage的每个task就要创建多少分磁盘文件,比如当前stage有20个task,总共有4个Executor,每个Executor执行5个task,下一个stage总共有40个task,那么每个Executor上就要创建200个磁盘文件,所有Executor会创建800个磁盘文件,由此可见,未经过优化的shuffle write操作所产生的磁盘文件数据是惊人的。

2. Shuffle Read 阶段

  • 将上一个stage的计算结果中所有相同的key,从各个节点上通过网络都拉取到自己所在的节点上,然后按照key进行聚合或连接等操作。
  • 由于shuffle write阶段,map task给下游stage的每个reduce task都创建了一个磁盘文件,因此shuffle read阶段,每个reduce task只要从上游stage的所有map task所在节点上拉取属于自己的那个磁盘文件即可。
  • shuffle read的拉取过程是一边拉取一边聚合的,每个shuffle read task都有一个自己的buffer缓冲,每次只能拉取与buffer缓冲相同大小的数据,然后在内存中进行聚合等操作,聚合完一批数据,再拉取下一批,以此类推,直接所有数据拉取完,并得到最终结果。
  • 优化后的HashShuffleManager工作原理

为了优化 HashShuffleManager ,可以启用参数 spark.shuffle.consolidateFiles,该参数的默认值为 false,启用后设置为 true,可以启动优化机制。

开启优化机制后的效果:

1.Shuffle Write 阶段

  • 在 shuffle write 过程中,task就不是为下游stage的每个task创建一个磁盘文件了,此时会出现shuffleFileGroup的概念,每个shuffleFileGroup会对应一批磁盘文件,磁盘文件的数量与下游stage的task数量是相同的。
  • 一个Executor上有多少个 CPU core,就可以并行执行多少个task。而第一批并行执行的每个task都会创建一个 shuffleFileGroup,并将数据写入对应的磁盘文件内。
  • 当执行下一批task时,下一批task就会复用之前已有的 shuffleFileGroup,包括其中的磁盘文件。
  • consolidate 机制允许不同的task复用同一批磁盘文件,这样就可以有效将多个task的磁盘文件进行一定程度上的合并,从而大幅度减少磁盘文件的数量,进而提升 shuffle write 的性能。
  • 比如当前stage有20个task,总共有4个Executor,每个Executor执行5个task,下一个stage总共有40个task,那么每个Executor上就要创建40个磁盘文件,所有Executor会创建160个磁盘文件,由此可见,优化后shuffle write操作所产生的磁盘文件较优化前明显减少。

2. Shuffle Read 阶段

  • 由于shuffle write阶段,每个Executor仅为下游每个reduce task创建一个磁盘文件,在shuffle read阶段,每个reduce task只要从上游stage的所有map task所在节点上拉取属于自己的那个磁盘文件即可。

三、SortShuffleManager 原理

SortShuffleManager 的运行机制主要分成两种,一种是普通运行机制,另一种是bypass运行机制。 当 shuffle

read task 的数量小于等于 spark.shuffle.sort.bypassMergeThreshold参数(默认为

200)的值且不是聚合类的shuffle算子时,就会启用 bypass 机制。

  • 普通运行机制的SortShuffleManager工作原理
  • 在该模式下,数据会先写入一个内存数据结构中,此时根据不同的 shuffle 算子, 可能选用不同的数据结构。如果是 reduceByKey 这种聚合类的 shuffle 算子,那么会 选用 Map 数据结构,一边通过 Map 进行聚合,一边写入内存;如果是join 这种普通的 shuffle 算子,那么会选用 Array 数据结构,直接写入内存。接着,每写一条数据进入内存数据结构之后,就会判断一下,是否达到了某个临界阈值。如果达到临界阈值的话,那么就会尝试将内存数据结构中的数据溢写到磁盘,然后清空内存数据结构。在溢写到磁盘文件之前,会先根据 key 对内存数据结构中已有的数据进行排序。 排序过后,会分批将数据写入磁盘文件。默认的 batch 数量是10000 条,也就是说,排序好的数据,会以每批 1 万条数据的形式分批写入磁盘文件。写入磁盘文件是通 过 Java 的BufferedOutputStream 实现的。BufferedOutputStream 是 Java的缓冲输出流,首先会将数据缓冲在内存中,当内存缓冲填满之后再一次写入磁盘文件中,这样可以减少磁盘 IO 次数,提升性能。
  • 一个 task 将所有数据写入内存数据结构的过程中,会发生多次磁盘溢写操作, 也就会产生多个临时文件。最后会将之前所有的临时磁盘文件都进行合并,这就是 merge 过程,此时会将之前所有临时磁盘文件中的数据读取出来,然后依次写入最 终的磁盘文件之中。此外,由于一个 task就只对应一个磁盘文件,也就意味着该 task 为下游 stage 的 task 准备的数据都在这一个文件中,因此还会单独写一份索引文件,其中标识了下游各个 task 的数据在文件中的 start offset 与 end offset。
  • SortShuffleManager 由于有一个磁盘文件 merge 的过程,因此大大减少了文件数量。比如第一个 stage 有 20 个 task,总共有 4 个 Executor,每个 Executor 执行 5 个 task,而第二个 stage 有 40 个 task。由于每个 task 最终只有一个磁盘文件,因此 此时每个 Executor 上只有 5 个磁盘文件,所有 Executor 只有
    20 个磁盘文件。
  • bypass运行机制的SortShuffleManager工作原理
  • 每个 task 会为每个下游 task 都创建一个临时磁盘文件,并将数据按 key进行 hash 然后根据 key 的 hash 值,将 key 写入对应的磁盘文件之中。当然,写入磁盘文件时也是先写入内存缓冲,缓冲写满之后再溢写到磁盘文件的。最后,同样会将所有临时磁盘文件都合并成一个磁盘文件,并创建一个单独的索引文件。
  • 该过程的磁盘写机制其实跟未经优化的 HashShuffleManager 是一模一样的,因为都要创建数量惊人的磁盘文件,只是在最后会做一个磁盘文件的合并而已。因此 少量的最终磁盘文件,也让该机制相对未经优化的 HashShuffleManager 来说,shuffle read 的性能会更好。
  • 而该机制与普通 SortShuffleManager 运行机制的不同在于:第一,磁盘写机制 不同;第二,不会进行排序。也就是说,启用该机制的最大好处在于,shuffle write
    过程中,不需要进行数据的排序操作,也就节省掉了这部分的性能开销。
相关推荐
AAA小肥杨13 分钟前
基于k8s的Python的分布式深度学习训练平台搭建简单实践
人工智能·分布式·python·ai·kubernetes·gpu
爬山算法3 小时前
Redis(73)如何处理Redis分布式锁的死锁问题?
数据库·redis·分布式
IT小哥哥呀4 小时前
电池制造行业数字化实施
大数据·制造·智能制造·数字化·mom·电池·信息化
Xi xi xi4 小时前
苏州唯理科技近期也正式发布了国内首款神经腕带产品
大数据·人工智能·经验分享·科技
yumgpkpm4 小时前
华为鲲鹏 Aarch64 环境下多 Oracle 、mysql数据库汇聚到Cloudera CDP7.3操作指南
大数据·数据库·mysql·华为·oracle·kafka·cloudera
祈祷苍天赐我java之术5 小时前
Redis 数据类型与使用场景
java·开发语言·前端·redis·分布式·spring·bootstrap
UMI赋能企业5 小时前
制造业流程自动化提升生产力的全面分析
大数据·人工智能
TDengine (老段)6 小时前
TDengine 数学函数 FLOOR 用户手册
大数据·数据库·物联网·时序数据库·iot·tdengine·涛思数据
猫林老师7 小时前
HarmonyOS线程模型与性能优化实战
数据库·分布式·harmonyos
派可数据BI可视化8 小时前
商业智能BI 浅谈数据孤岛和数据分析的发展
大数据·数据库·数据仓库·信息可视化·数据挖掘·数据分析