Spark与Hadoop Shuffle机制对比：排序哲学、磁盘IO与OOM调优实践

1. 先厘清概念：为什么Shuffle这个词被Spark和Hadoop都用了

我在面试候选人的时候，经常问一个问题：“Spark的shuffle和Hadoop的shuffle，到底是不是一回事？”

相当多的人第一反应是：都是数据重分区嘛，总不能翻出花来。但真让他们说出个一二三，就开始含糊了。这不能全怪候选人，因为这俩东西名字一样，解决的问题也确实类似，但底层的设计哲学和执行路径差了十万八千里。如果你只是把它们当成同一个东西去理解，遇到实际问题——比如Spark作业莫名OOM、Hadoop任务卡在shuffle阶段——根本没法定位。

Shuffle这个词，直译是“洗牌”。在分布式的语境下，它指的就是数据在集群节点之间重新分布的过程。一个MapReduce任务，Map阶段处理完的数据分散在各节点上，接下来Reduce阶段需要把相同key的数据拉到一个节点处理，这一步就是shuffle。整个过程涉及磁盘读写、网络传输、排序归并，是大数据计算里最耗费资源、也最容易出问题的环节。

Hadoop MapReduce 从2004年论文里就把这套机制定义得很清楚，当年数据库界的大牛David DeWitt甚至说过一句名言：“We love shuffle”（我们爱shuffle），因为shuffle是分布式数据库和分布式计算框架绕不开的核心操作。

Spark之所以沿用shuffle这个词，并不是要从概念上跟Hadoop对齐，而是它面对的问题本质相同：DAG计算中，父RDD的数据经过map后，需要按照目标RDD的分区规则重新分布。既然底层问题一样，词就借过来了。但Spark对shuffle的实现，不是“Hadoop那套换个语言重写一遍”，而是针对内存计算和DAG迭代的场景做了彻底重设计。

这篇文章我就把两边掰开来聊，先讲Hadoop shuffer的完整链路，再讲Spark shuffle的演进和现状，最后给你一张能直接写进面试答案或设计方案里的对照表。

2. Hadoop MapReduce的Shuffle：一次写盘到底的硬派做法

Hadoop MapReduce的设计目标非常明确：跑超大规模批处理任务，数据量几十TB甚至PB级别，集群节点可能几百上千台，且节点宕机是常态。在这种前提下，它选择了最稳、最保守但绝对可靠的shuffle实现。

2.1 Map端：环形缓冲区、Spill与排序

Map端输出的结果并不是直接写到磁盘上送给Reduce的。MapTask启动之后，会先创建一个环形内存缓冲区（默认大小100MB，由mapreduce.task.io.sort.mb控制），Map的输出会以key、value、partitionId、offset等格式写入这个缓冲区。

当缓冲区的使用率达到阈值（默认80%，由mapreduce.map.sort.spill.percent控制），一个后台线程就会启动“Spill”（溢写）过程。这时候注意一个关键细节：在真正溢写之前，后台线程会把缓冲区里的数据按照partitionId和key做一次排序——这就是为什么Map端也一定要有排序，因为Hadoop的shuffle默认就是“sort-based shuffle”，后续Reduce拉取数据时，必须依赖每个Map输出片段是有序的这个前提。

排序完成后，数据会被写入本地磁盘，形成一个Spill文件。如果整个MapTask的输出量很大，可能会触发多次Spill，那么最终在MapTask结束前，还会把所有Spill文件做一次Merge，合并成一个有序的最终输出文件，同时生成一个索引文件来记录每个分区数据在文件中的偏移量。这里有个细节：合并时如果配置了Combiner，并且Spill文件数量超过阈值（默认3），会在Merge过程中执行Combiner，提前做一轮Map端局部聚合，减少网络传输的数据量。

2.2 Reduce端：拉取、归并与二次排序

ReduceTask启动后，会启动若干个Fetcher线程（默认5个）去各个MapTask节点拉取属于自己的分区数据。这个拉取过程不是一次性完成的——它一边拉取、一边往磁盘或内存中放，到达一定大小后就开始做归并排序。

这里的归并策略值得细说。Hadoop的Reduce端维护了一个MergeManager，它会选择优先把数据放进Heap（内存）里，如果内存不够，就走磁盘。归并的输入是多个有序片段，每次从所有片段中取出最小的那个key输出，这样最终全局就是有序的。整个过程和外部排序算法里的多路归并一模一样。

等所有数据拉取并归并完成后，Reduce端会做一个“最终合并”，把所有片段合成一个整体有序的数据流，然后按照key的分组边界，一组一组地喂给Reduce函数。Reducer的reduce()方法每接收到一个key，就能拿到这个key对应的所有value的迭代器，这就是整个Hadoop shuffle最核心的产出。

2.3 为什么Hadoop死磕“全量排序”

很多人不理解，为什么Hadoop的shuffle里到处都在排序。Map端排一次，Reduce端还要归并，这不是浪费性能吗？

答案在于，排序是Hadoop实现分布式的“最小公约数”。在Reduce端归并时，如果每个Map输出片段已经是局部有序的，整个归并过程就不需要建复杂的数据结构（比如哈希表），只需要做N路归并，算法简单且可控。对于PB级数据量的任务，一个简单的多路归并就能稳定地完成任务，维护成本极低。而且，Hadoop框架本身是面向“磁盘优先”设计的，在磁盘上进行有序归并的效率远高于随机读写。

所以说，Hadoop的shuffle是“以排序为核心”的shuffle。为了排序，Map端牺牲了一部分性能来做Spill和Merge，但换来了整体极高的稳定性。这个设计思想主导了Hadoop十年的生态，直到Spark改变了这套玩法。

2.4 Hadoop shuffle的短板在哪

Hadoop shuffle最大的问题，不是它做了排序，而是它把所有中间结果都写到了磁盘。Map端写一次本地磁盘，Reduce端拉过来又要写一次磁盘（或者至少走一遍内存和磁盘交互）。

这对早期的批处理任务来说不是致命伤，因为磁盘顺序读写的吞吐其实很高。但在需要迭代计算、交互式查询的场景下，Hadoop的表现就没法看了。一个简单的PageRank迭代，每一轮迭代都要把中间结果落一次盘，几十轮迭代下来，大部分时间都耗在磁盘IO上了。

3. Spark的Shuffle：从“谁都要Sort”到“能省就省”的进化

Spark的目标从一开始就和Hadoop不同：它要跑内存计算，要支持DAG迭代，要以更低的延迟处理中间结果。但不管是MapReduce还是Spark，shuffle本质上都是“跨节点数据重新分布”，而跨节点就意味着网络传输，就意味着数据不可能凭空转移——这是分布式计算绕不开的物理定律。

那Spark做了什么改变？一句话概括：能不排序就不排序，非不得已排序也要换种方式排。

3.1 Spark 1.x的Hash Shuffle：激进的去排序试验

Spark早期版本（1.1之前）用的是Hash Shuffle。它的逻辑非常直接：每个Map任务会根据下游Reduce（Spark里叫ShuffleMapStage中的Partition）数量，为每个分区生成一个文件。也就是说，一个大任务如果有100个Map任务、100个Reduce分区，就会产生100×100=10000个小文件。每个文件里存的就是这个Map任务分配给对应分区的数据，文件内部没有排序。

因为不需要排序，Map端不需要做Spill和Merge，内存消耗大幅减少。这个设计的本意是省掉排序的开销，但代价极其高昂——磁盘小文件爆炸。10000个文件意味着大量的文件句柄、低效的随机IO，以及糟糕的块管理。在超大集群上，光文件数就能把NameNode搞垮。

Spark 1.2引入了consolidation机制来缓解这个问题，也叫FileGroup，它把同一个Executor里的Map任务写出的文件合并成组。假设一个Executor有4个Core，可以同时跑4个Map任务，那这4个任务写给同一个Reduce分区的数据就放进同一个文件组，文件数量从M×R降为Core×R。但这只是治标，文件数量还是会随着Executor数、分区数的增长而膨胀。

3.2 从Sort Shuffle开始的统一方案

从Spark 1.1开始，Sort Shuffle被引入，并从Spark 2.0起完全取代了Hash Shuffle。之所以叫Sort Shuffle，是因为它借鉴了Hadoop的思路，Map端每个ShuffleMapTask产出的东西是一个按分区编号排好序、按分区索引可寻址的文件。

Spark的Sort Shuffle内部有三条具体路径：

• 普通Sort Shuffle（SortShuffleWriter）：Map端直接按partitionId和key排序，生成一个有序的Shuffle文件放在spark.local.dir下，同时生成一个.index索引文件，记录每个partition在shuffle文件中的偏移量。下游reduce端根据索引可以精准定位自己要的数据，不需要全文件读取。这种方式的排序是在内存里通过PartitionedAppendOnlyMap或ExternalSorter做的，如果内存不够会溢写到磁盘，但只有溢写时才落盘，内存够用时全程内存操作。

• Bypass机制：当spark.shuffle.sort.bypassMergeThreshold条件满足（默认阈值是200），即下游分区数小于等于200且不需要map端聚聚合时，Spark会走一条“除了排序什么都做”的捷径：Map端直接为每个分区写一个文件，最终合并成一个文件并生成索引。它没有排序，但生成了合并后的单文件，所以反而比Hash Shuffle的高IO模式好得多。这个机制的适用场景是分区数很少、Map端不需要排序的小任务。

• Tungsten Sort Shuffle（UnsafeShuffleWriter）：这是Spark 2.0之后与Tungsten工程结合的一种优化路径。它把Java对象序列化成二进制数据，直接在内存中以指针的形式做排序，大幅减少了GC压力。它也有要求：序列化器必须是Kryo或自定义的Unsafe序列化器，且Map端不能做聚合。在数据量大、key类型简单稳定时，这个路径能明显提升shuffle效率。

3.3 Reduce端读取：按索引精准拉取

ShuffleMapStage执行完之后，每个stage的结果就是一个Shuffle文件加索引文件。下游Stage的Reduce拉取数据时，不再像Hadoop那样需要把整个Map输出归并成完全有序的全量数据，它的做法是：

• 根据上游stage的分区号，通过索引文件定位到对应数据块的偏移；
• 通过网络用BlockStoreShuffleReader拉取需要的数据块；
• 拉取到的数据放入AppendOnlyMap或ExternalSorter做分区内的数据归并——如果下游需要的是聚合（group by key），那就直接基于哈希表做聚合，不需要全量排序。

这个设计直接体现了“能省就省”的哲学：如果下游只是做聚合，Spark用哈希表就够了，不会强迫你排序；只有当下游算子确实需要排序（比如sortByKey、repartitionAndSortWithinPartitions）时，才会真正走排序路径。

4. 一张表看清两者的根本差异

我在这里整理了一张比较表，方便你看完直接用来做面试答题框架或方案选型参考。

表里最关键的区别在“排序策略”和“磁盘IO”两行。Hadoop把排序当作“必须做的事”，Spark把排序当作“可选的事”。这两者的背后，是框架设计目标的不同：Hadoop要的是极端数据量下的确定性和可预测性；Spark要的是在内存足够时把计算拉满，把IO和GC降到最低。

另外，这个区别还直接关联到一个很常见的真实问题——“spark oom”。Spark作业的OOM很多都发生在shuffle阶段，尤其是Reduce端。因为Spark默认会把shuffle数据尽量保持在内存里做聚合，一旦某个分区key特别集中，AppendOnlyMap就会膨胀到撑爆内存。反观Hadoop，数据在到达Reduce函数之前大部分已经在磁盘上归并过了，根本不给OOM留机会。这是两个框架在内存模型上的巨大差别，也是很多做调优的人容易忽略的深层原因。

5. 两者之间的联系：同根同源的洗牌思想

虽然实现路径差别很大，但如果把它们放在同一条技术发展线上看，Spark并没有完全抛弃Hadoop的设计，它只是基于Hadoop的思想做了大量“减法”。

5.1 分区器（Partitioner）的继承

MapReduce里，Partitioner负责决定每个Map输出去往哪个Reduce任务。Spark把这个概念原封不动地拿了过来，HashPartitioner、RangePartitioner的职责和Hadoop的语义完全一致，只是实现语言和内部数据结构变了。在自定义分区器的时候，你在Hadoop上学的getPartition逻辑，放到Spark里仍然适用，只是要换一层API。

5.2 Combiner的思想就是Map端聚合

Hadoop的Combiner在Map端提前合并相同key的数据，减少写入和传输量。Spark把这一思想继承为mapSideCombine或者算子里面的reduceByKey等操作。在Sort Shuffle的排序路径中，Spark同样会在溢写时执行合并，降低落盘数据量。

5.3 Map端输出“先本地，后网络”的模型没变

无论哪套框架，shuffle都遵循一个铁律：Map阶段的输出必须先写到本节点存储（本地磁盘或本地存储系统），之后再由下游节点通过网络拉取。这个过程叫“shuffle write”和“shuffle read”。两种框架的shuffle事件都经历了同样的写与读两个阶段，只是内部的落盘策略不同。

5.4 归并机制的操作系统级别相似

Hadoop Reduce端的多路归并排序，和Spark Reduce端ExternalSorter用的外排序逻辑，底子上是同一套算法——内存优先，装不下就溢写，溢写后归并。区别只是Spark尽量把归并发生在内存里，Hadoop更倾向于在更早的时机就落盘。换句话说，Hadoop和Spark的shuffle在某些核心算法的轮廓上是重叠的，只是资源倾向与触发时机不同。

6. 从调优和面试看：怎么把区别转化为实战价值

知道两者区别不是为了背概念，而是要落到三件实际的事上：答面试题、定位问题、调优配置。我在这节里给你整理几个我认为最有实战价值的角度。

6.1 面试常考的三个隐藏考点

面试官问“Spark shuffle和Hadoop shuffle的区别”，表面上是考概念，实际上在考察三个层面：

• 第一层：你知不知道两边都要先写本地再网络传输。
• 第二层：你知不知道Hadoop强制全局排序、Spark依赖内存尽量不排序。
• 第三层：你能不能说清楚“为什么Spark敢不排序”以及“不排序的代价是什么”。

第三层是最加分的。Spark敢不排序，是因为下游Stage如果需要的是groupBy，它只需要一个聚合结构（哈希表）就够了，多路归并只是其中一种实现方式。代价是，如果下游算子确实需要排序，或者分区内数据分布极端不均，它的内存消耗会失控。所以，不排序是一把双刃剑。

6.2 针对Shuffle OOM的定位思路

结合热搜词里的“spark oom”，这里我再展开一下。我在实际调优中遇到的大多数shuffle OOM，都得先从两个方向排查：

• 第一，是Map端还是Reduce端？Map端OOM通常跟spark.shuffle.spill.compress、spark.shuffle.file.buffer、spark.reducer.maxSizeInFlight有关；Reduce端OOM则基本上是aggregation数据结构太大，直接调大spark.sql.shuffle.partitions或spark.default.parallelism，让每个分区的数据量变小。

• 第二，是不是数据倾斜？如果是某个key的数据集中在某个分区导致OOM，那么加内存、调分区数量都治标不治本。正确的做法是走数据倾斜的经典方案：加盐、自定义分区器按key分布做range分区、或者先做一层聚合再聚第二层。

这跟你面对Hadoop job时的排查路径差异很大。Hadoop的shuffle OOM（准确说应该是DFS不够、文件句柄不够）更多表现为任务失败或IO瓶颈，内存本身并不是它的主要痛点。理解这点之后，你去排查问题会快很多。

6.3 实际场景下的选型建议

如果你的计算场景是“必须做二次排序”“需要非常精确的全局有序输出”“数据规模大到内存成本不可控”，那么用Hadoop MapReduce仍然是一个稳妥的选择，毕竟它的shuffle天然就是为这种场景设计的。

但如果你要的是迭代计算、需要快速产出聚合结果、或者任务数据量可控且内存足够，那Spark是不二之选。在实际生产环境中，我见过很多团队为了“统一技术栈”，把原本跑在Spark上的逻辑硬拆成MapReduce写，结果反而更慢——因为MapReduce需要把shuffle彻底排序，而很多业务根本不需要全局排序，白白丢失了Spark内存计算的优势。

6.4 我对shuffle优化的一点个人体会

跑了很多年大数据作业，我越来越觉得，shuffle优化的段位不在“把参数调大调小”，而在于“能不能减少shuffle”。少一次shuffle，比任何参数优化都管用。Spark的DAG中，一个stage就是一个shuffle边界，你设计的计算逻辑如果有多个action反复触发shuffle，那不是调整内存能解决的。

比如，能用reduceByKey就别用groupByKey，前者在Map端做了combine，后者全量传输；能用broadcast join就避免大表和大表join的shuffle；能用repartitionAndSortWithinPartitions一次搞定重分区和排序，就不要先repartition再sort产生两次shuffle。这些经验其实和Hadoop时代的思路相差不大——“能不走网络就不走网络”，是大数据计算里永远有效的优化第一性原则。

写到这里，我想起刚入行时为了搞懂Hadoop的环形缓冲区，把代码翻来覆去看了好几遍。后来接触到Spark的shuffle时，才终于明白一个道理：框架的演进从来不是简单的代码重写，而是对相同问题给出不同目标下的不同解法。理解差异背后的“为什么”，比记住差异表格里的“是什么”重要得多。