Spark面试真题卷三深度拆解：Stage划分、Shuffle机制与调优实战

1. Spark面试真题卷三的整体拆解思路

1.1 为什么面试真题要按“卷”来刷

很多人准备大数据面试的时候喜欢东一榔头西一棒子，今天看两篇博客，明天刷几道八股，结果上了考场发现题目稍微换个问法就懵了。我自己的经验是，按“卷”来刷真题是最接近真实面试节奏的方式。所谓“卷三”，意味着前面已经有两套题打底，这一卷的定位通常是从基础概念往调优和源码理解过渡，难度比前两卷高一个台阶，考察点也更偏向“你有没有真正在生产环境里跑过Spark”。

这一卷的核心价值在于：它不再满足于你背出“RDD是弹性分布式数据集”这种定义，而是会追问你“一个Stage为什么会被切分成两个TaskSet”“Shuffle Write的三种方式在什么场景下选哪种”。换句话说，卷三筛的是能干活的人，不是能背书的人。适合已经有一到两年Spark使用经验、准备跳槽或者想系统梳理知识体系的同学参考，纯小白看这一卷会有点吃力，建议先把卷一卷二的基础打牢。

1.2 卷三的考察重心分布

从历年真题的规律来看，卷三的题目大致可以分成四个板块，我按出现频率和分值权重做了个粗略统计：

这个分布说明一件事：卷三的重心在“调优”和“Shuffle”，这两块加起来超过一半。为什么？因为这两块是生产环境里最容易出问题、也最能体现一个人实战水平的地方。面试官问数据倾斜，不是想听你背“加随机前缀”这五个字，而是想听你说清楚“什么情况下加前缀有效、什么情况下加了反而更糟”。

1.3 答题的底层逻辑：先定位再展开

我在带新人的时候反复强调一个答题框架：先定位问题域，再展开技术细节，最后落到实操取舍。举个例子，面试官问“Spark内存模型怎么划分的”，低分回答是直接背“Execution Memory和Storage Memory”，高分回答是先说“这要看你用的是哪种内存管理模式，1.6之后统一成UnifiedMemoryManager，但静态管理和统一管理的区别在于……”，然后再说“统一管理下两者可以互相借用，但借用的规则是……”，最后补一句“实际调优时我一般会关注spark.memory.fraction这个参数，因为……”。

这个框架的好处是，它让面试官看到你的知识是有层次的，不是一堆散点。卷三的题目尤其吃这套，因为很多题本身就是开放式的，比如“你们生产环境Spark怎么调优的”，这种题没有标准答案，考的就是你的组织能力和实战沉淀。

2. 运行架构与调度机制的核心考点

2.1 Stage划分：宽依赖是那条分界线

Stage划分是卷三的必考题，几乎每套卷子都会出现。核心就一句话：遇到宽依赖就切Stage。但面试官不会只让你说这一句，他会追问“为什么宽依赖要切”“窄依赖为什么不切”。

先说原理。Spark的DAG调度器在提交作业时，会从最后一个RDD往前回溯，遇到窄依赖就把当前RDD归到同一个Stage里，遇到宽依赖就断开，前一个Stage作为后一个Stage的输入。这么做的根本原因是宽依赖意味着数据需要跨分区重新分布，也就是要发生Shuffle，而Shuffle是需要落盘和网络传输的，必须等父Stage全部算完才能开始。窄依赖则是分区内的一对一或一对多转换，可以流水线式地在同一个Task里连续执行，不需要等待。

这里有个容易踩的坑：很多人以为“窄依赖一定不Shuffle”，这话对，但反过来“不Shuffle一定是窄依赖”就不对了。比如repartition是宽依赖，coalesce在shuffle=false时是窄依赖，但coalesce如果设了shuffle=true就变成宽依赖了。面试时如果被问到coalesce和repartition的区别，一定要把shuffle参数这个点带出来，这是加分项。

提示：回答Stage划分时，最好能顺手画出（口述）一个简单的DAG例子，比如sc.textFile().flatMap().map().reduceByKey().map().saveAsTextFile()，说清楚哪里切了一刀、切完有几个Stage、每个Stage有几个Task。这种具象化的表达比干背定义强十倍。

2.2 Task调度：从Driver到Executor的完整链路

Stage切完之后，每个Stage会生成一批Task，这些Task怎么被分配到Executor上执行，是卷三爱考的第二个点。完整链路大致是：DAGScheduler把Stage提交给TaskScheduler，TaskScheduler按照调度策略（FIFO或FAIR）把Task放进调度池，然后通过SchedulerBackend与集群管理器通信，最终把Task发到Executor的线程池里跑。

这里有几个细节值得展开。第一，Task的本地性级别有五种：PROCESS_LOCAL、NODE_LOCAL、NO_PREF、RACK_LOCAL、ANY。Spark会优先把Task调度到数据所在的节点，但如果等不到，会在一个超时时间（spark.locality.wait，默认3秒）后降级到更宽松的级别。这个参数调优时经常被忽略，实际上在数据本地性差的集群里，适当调大它能显著减少网络传输。

第二，FAIR调度模式下有个spark.scheduler.pool的概念，可以把不同优先级的作业放进不同的池子，池子之间按权重分配资源。生产环境如果有多个团队共用一个集群，这个配置几乎是必调的，否则一个跑批作业就能把交互式查询的资源全占光。

第三，推测执行（speculative execution）默认是关的，但在长尾Task特别严重的场景下打开它（spark.speculation=true）能救命。不过要注意，推测执行对写操作不友好，如果你的Task里有幂等性没保证的写外部存储逻辑，开了反而会写重复数据。

2.3 内存模型：统一管理下的借用规则

Spark 1.6之后默认使用统一内存管理（UnifiedMemoryManager），把堆内内存分成三块：Reserved Memory（固定300MB，存Spark内部对象）、User Memory（剩余部分的(1 - spark.memory.fraction)）、Spark Memory（剩余部分的spark.memory.fraction，默认0.6）。Spark Memory内部又分Execution和Storage两块，两者共享一个池子，可以互相借用。

借用的规则是重点：Execution可以抢占Storage，但Storage不能抢占Execution。也就是说，当Execution内存不够时，它会驱逐Storage里缓存的Block（如果这些Block的存储级别允许驱逐的话，比如MEMORY_ONLY可以，MEMORY_AND_DISK会落盘）。反过来，Storage需要内存时只能等Execution释放。这个不对称设计的原因是Shuffle和Join这类操作对内存的即时需求更刚性，缓存丢了可以重算，但Shuffle数据丢了代价更大。

实际调优时，spark.memory.fraction和spark.memory.storageFraction这两个参数要配合着看。如果作业缓存需求大（比如反复查同一份维表），可以适当调大storageFraction；如果Shuffle密集，就保持默认或者调小storageFraction，给Execution多留空间。我见过有团队把storageFraction调到0.8，结果Shuffle频繁spill，作业反而慢了，这就是没理解借用规则的单向性。

3. Shuffle机制：卷三的高频深水区

3.1 Shuffle Write的三种方式怎么选

Shuffle Write是卷三区分度最高的考点之一。Spark发展到现在，Shuffle Write主要有三种实现：BypassMergeSortShuffleWriter、SortShuffleWriter、UnsafeShuffleWriter。面试官问这个，通常是想看你知不知道它们各自的适用条件。

BypassMergeSortShuffleWriter的触发条件是：分区数小于等于spark.shuffle.sort.bypassMergeThreshold（默认200），且没有map端聚合。它的做法是每个分区写一个临时文件，最后合并成一个文件加一个索引文件。优点是省去了排序开销，缺点是分区多的时候会同时打开大量文件句柄，容易把文件描述符耗尽。

SortShuffleWriter是默认方式，先按分区ID排序，再按key排序（如果需要聚合的话），最后合并成单个数据文件加索引文件。它的通用性最好，但排序有开销。

UnsafeShuffleWriter依赖Tungsten的内存管理，用二进制方式操作数据，速度快，但限制条件多：不能有map端聚合、序列化器要支持relocation、分区数不能超过2的24次方。满足条件时它是性能最好的选择。

实际选型时，我的经验是不要手动去指定Writer，让Spark自己根据条件选就行，但你要知道当前作业走的是哪条路径，因为排查Shuffle问题时这个信息很关键。比如你发现作业在map端就OOM了，一看是BypassMergeSort且分区数接近200，那大概率是文件句柄和缓冲区的问题，调小bypassMergeThreshold或者改用SortShuffle就能缓解。

3.2 Shuffle Read的拉取与聚合

Shuffle Read端，每个Reducer Task会通过BlockStoreShuffleReader去各个Mapper节点拉取属于自己的分区数据。拉取过程是先远程后本地，远程数据通过Netty传输，本地数据直接读文件。拉回来之后如果下游需要聚合（比如reduceByKey），会在读的过程中用ExternalAppendOnlyMap做聚合，内存不够就spill到磁盘。

这里有个关键参数spark.reducer.maxSizeInFlight（默认48MB），控制每次远程拉取的最大数据量。调大它能减少网络往返次数，但会增加Reducer端的内存压力。在带宽充足但延迟高的跨机房场景下，适当调大这个值效果明显；反过来如果Reducer频繁GC，就该调小它。

还有一个容易被忽略的点：Shuffle Read的拉取是并发的，并发数由spark.shuffle.io.maxRetries和线程池大小控制。如果某个Mapper节点挂了或者响应慢，Reducer会重试拉取，重试次数用完还拉不到就报FetchFailedException。排查这类问题时，先看是不是某个Executor负载过高导致响应慢，再看网络是否有丢包，最后才怀疑数据本身。

3.3 Shuffle文件合并与清理

Shuffle产生的临时文件如果不及时清理，会把磁盘撑爆。Spark提供了spark.shuffle.service.enabled（外部Shuffle服务）来解决这个问题：开启后，Executor在空闲时不会立即删除Shuffle文件，而是交给一个独立的ShuffleService进程管理，这样即使Executor被回收，下游Stage还能拉到数据。这个机制在动态资源分配场景下几乎是必须的，否则Executor一缩容，正在跑的Stage就拉不到Shuffle数据了。

文件清理的时机由spark.shuffle.service.removeShuffle和spark.cleaner.ttx等参数控制。我踩过的一个坑是：开了外部Shuffle服务但没配好清理策略，结果Shuffle文件在磁盘上堆了好几天，把节点磁盘写满了。后来加了定时清理脚本，并且把spark.shuffle.service.removeShuffle设为true，让服务在作业结束后主动删文件，问题才解决。

4. 数据倾斜与OOM的排查实录

4.1 数据倾斜的识别与分级处理

数据倾斜是卷三的“压轴题”，几乎每套卷子都有。面试官问“遇到数据倾斜怎么办”，如果你上来就说“加随机前缀”，基本就凉了一半，因为这说明你只会背方案，不会判断场景。

正确的思路是先识别、再分级、后选方案。识别的方法很简单：看Spark UI里Stage的Task执行时间分布，如果少数几个Task的Shuffle Read Size远大于其他Task（比如中位数是10MB，某几个是2GB），那就是倾斜了。也可以在代码里采样key的分布，rdd.map(k => (k, 1)).reduceByKey(_+_).sortBy(_._2, false).take(10)，看看Top key是不是特别集中。

分级处理的意思是，倾斜程度不同，方案也不同：

• 轻度倾斜（个别key数据量是平均值的几倍）：调大spark.sql.shuffle.partitions或者repartition增加分区数，把数据打散就行。
• 中度倾斜（个别key是平均值的几十倍）：对热点key加随机前缀做两阶段聚合，先局部聚合再全局聚合。
• 重度倾斜（个别key占了总量的一大半）：加前缀也没用，因为前缀数量有限，得考虑把热点key单独抽出来处理，或者用mapSideCombine在map端先做聚合减少传输量。

注意：加随机前缀不是万能的。如果热点key本身的数据量就超过了单个Task能处理的上限，加前缀只会把一个大Task拆成几个中等Task，总量没变，还是可能OOM。这时候要考虑的是业务层面能不能过滤或预聚合，技术手段只是兜底。

4.2 OOM的三种典型场景与对策

OOM在卷三里通常以“你遇到过哪些OOM，怎么解决的”这种开放题出现。我总结下来，Spark的OOM大致分三类：

第一类是Driver端OOM，常见于collect()把大量数据拉到Driver，或者broadcast的变量太大。对策是避免collect大结果集，broadcast变量超过spark.broadcast.blockSize限制时改用分布式缓存。

第二类是Executor端堆内OOM，原因是单个Task处理的数据量超过了Execution Memory能承受的范围。对策包括：调大spark.executor.memory、减少每个Task处理的数据量（增加分区数）、检查是否有大对象在Task里被反复创建（比如在map里new一个很大的集合）。

第三类是堆外OOM，报错信息里带“Direct buffer memory”或“Metaspace”。堆外OOM通常是Netty传输或Tungsten的off-heap使用超限，调spark.executor.memoryOverhead能缓解；Metaspace OOM则是类加载太多，常见于动态生成代码的场景（比如大量UDF），调spark.executor.extraJavaOptions里的-XX:MaxMetaspaceSize。

4.3 GC调优的实操切入点

GC问题在卷三里通常作为OOM的延伸出现。Spark作业的GC调优，核心是减少Full GC的频率和时长。切入点有三个：

第一，用G1替换CMS。Spark 2.x默认还是CMS（老版本），3.x开始倾向G1。G1在大堆（超过4GB）场景下停顿更可控，配置方式是-XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=35。

第二，控制对象创建速率。GC频繁往往是因为Task里创建了太多短命对象，比如在map里频繁字符串拼接、频繁装箱拆箱。用mapPartitions替代map能减少函数调用开销，用基本类型数组替代List能减少对象头开销。

第三，调整堆内比例。年轻代太小会导致对象过早晋升到老年代，触发Full GC。一般建议年轻代占堆的1/3到1/2，通过-XX:NewRatio或-XX:NewSize控制。我实测过一个ETL作业，把NewRatio从2调到1之后，Full GC从每小时好几次降到几乎不出现，作业耗时降了将近20%。

5. 源码级问题的应对策略

5.1 DAGScheduler的作业提交链路

卷三偶尔会出源码题，最常见的是“一个Action触发后，底层发生了什么”。完整的链路是：Action算子调用sc.runJob()，runJob把任务交给DAGScheduler的submitJob，DAGScheduler创建JobWaiter并生成一个JobSubmitted事件放进事件队列，事件循环线程取出事件后调用handleJobSubmitted，在里面做Stage划分（createResultStage），然后递归提交父Stage（submitStage），直到最前面的Stage没有父依赖，就通过submitMissingTasks生成TaskSet交给TaskScheduler。

这条链路面试时不需要一字不差地背，但关键节点要说对：Action → runJob → DAGScheduler.submitJob → 事件队列 → handleJobSubmitted → createResultStage → submitStage递归 → submitMissingTasks → TaskScheduler。能说清楚“Stage是从后往前划分、Task是从前往后提交”这个方向感，基本就过关了。

5.2 Executor与Driver的通信机制

另一个源码考点是Executor和Driver之间怎么通信。Spark的网络通信层经历了从Akka到Netty RPC的演进，现在（2.x之后）统一用Netty。Driver端有RpcEndpoint（比如DAGScheduler本身就是一个Endpoint），Executor端注册后会定期发送心跳（spark.executor.heartbeatInterval，默认10秒），心跳里带Task的运行状态和累加器更新。

如果心跳超时（spark.network.timeout，默认120秒），Driver会认为Executor失联，把上面的Task标记为失败并重新调度。这个机制解释了为什么有时候作业会莫名其妙重跑Task——不是代码有问题，是GC停顿太长导致心跳没发出去。所以调GC不只是为了快，也是为了别让心跳超时引发误判。

提示：源码题答不上来不要硬编。诚实说“这块我了解大致链路，具体到某个方法的实现细节我记不太清，但我可以讲讲我的理解”，比胡编一个错误的方法名要好得多。面试官更看重你的分析思路，而不是记忆力。

6. 我踩过的坑和几条实在建议

6.1 别把“调参”当成调优的全部

我刚开始做Spark调优的时候，特别喜欢翻参数表，看到哪个参数觉得有用就往上加，结果作业越调越慢。后来才明白，调优的第一步永远是看Spark UI，找到瓶颈在哪，是CPU打满、内存不够、还是IO等待。参数只是手段，不是目的。比如你发现Stage的Shuffle Read耗时占了70%，那该动的是分区策略和倾斜处理，而不是去调GC参数。

6.2 面试时“我不知道”比“我瞎说”值钱

卷三的题目有些确实偏深，比如问到某个具体版本的源码实现细节，没看过就是没看过。这时候与其硬编一个答案，不如说“这个点我确实没深入研究过，但基于我对Spark整体架构的理解，我猜测可能是……”。面试官通常会给台阶，顺着你的猜测往下聊，反而能聊出你的思维过程。我见过太多候选人因为瞎编被追问到崩盘，其实老老实实说不会，换个角度展示理解，分数不会低。

6.3 真题要“做”不要“看”

最后说个刷题的方法论。很多人刷面试真题就是看一遍答案，觉得“哦，原来是这样”，然后就过了。我的建议是每道题都自己先写一遍答案，再对照参考答案找差距。尤其是调优类题目，自己写的时候会发现很多细节说不清楚，比如“加随机前缀”具体怎么加、加完之后怎么去前缀、两阶段聚合的代码长什么样。这些细节才是面试官真正想听的，光看答案永远学不会。

我在实际带人的过程中发现，能把卷三的题目用自己的话讲清楚、并且能举出生产环境例子的同学，面试通过率明显高出一截。原因很简单：卷三考的不是知识量，是知识的组织方式和实战转化能力。你把每个考点都当成一个真实问题去拆解，自然就能答到点子上。