Spark核心原理与调优实战：RDD/DAG、OOM与数据倾斜-代码聚汇网

Spark核心原理与调优实战：RDD/DAG、OOM与数据倾斜

知乎科技·2026-09-03·阅读 22 GEO检测（免费）

SparkRDDDAG

|难度：普通|阅读约 47 分钟

去年帮忙调了一个跑了四十分钟还跑不完的离线ETL任务，换成Spark重写之后，九分钟出头就跑完了。盯着Spark UI上密密麻麻的Stage记录，我突然觉得有必要把Spark的核心原理好好写一遍——因为网上能找到的资料大多是概念堆砌，真到了要解释“为什么快”“为什么OOM”“为什么Stage卡住”的时候，很多人根本说不清。这篇不打算写成面面俱到的完整教材，而是从原理出发，把RDD/DAG/Stage、Spark SQL的优化机制、集群部署和日常排错串起来，顺便带上我这些年实际踩过的坑，适合刚学Spark的初学者，也适合准备面试的人当复习提纲。

1. 在讲原理之前，先回答一个问题：Spark到底为什么快

1.1 MapReduce给大家留的阴影：每算一步，都要把中间结果写一遍磁盘

讲Spark之前，得先回忆一下Hadoop MapReduce时代什么样。单次WordCount还好说，但一旦遇到K-means、PageRank、协同过滤这类迭代式算法，每一轮迭代都要把中间结果落到HDFS上，下一轮再重新读回来。一次迭代的map结果要写磁盘，shuffle的数据要写磁盘，reduce输出还要写一份。这种做法可靠性极好，但速度是真慢，IO开销几乎成了所有计算任务的瓶颈。当时团队里跑一个三层的机器学习实验，一半时间都消耗在等待MapReduce任务的写入和复制上，改参数调优基本靠等。

我印象最深的是，每次调整完模型参数重新跑任务，中间部分都要重新落盘、重新读。磁盘IO成了整个数据链路的常量开销，CPU反而一直在等数据。这种“每一步都存盘”的设计在容错上有它的道理，但对于数据挖掘、图计算这类需要反复迭代的场景，代价实在太大。

1.2 Spark的设计思路：能不落盘就不落盘

Spark核心贡献在于把计算模型从“每一步都落盘”改成“尽可能在内存里完成全链路”。它定义了一套RDD（弹性分布式数据集）抽象，用DAG（有向无环图）把完整计算过程描述出来；同一个RDD被多个算子使用时，可以复用内存缓存，迭代计算时不再需要反复写HDFS。除此之外，Spark还有两个关键设计：

惰性求值：transform算子不会立刻执行，只是记录血缘关系，遇到action算子才真正触发任务。
基于内存的shuffle机制：Map阶段的输出优先留在内存，只有内存放不下时才溢写磁盘。

把这两个机制结合到一起，结果就是：大多数离线批处理任务直接比MapReduce快一个数量级，在有缓存和复用场景里提升更夸张。比如我前面说的那个ETL任务，原来MapReduce每轮迭代都要把中间表写一遍，Spark把中间结果直接放在内存里，后面几轮复用同一份RDD缓存，整个计算链路的IO开销一下子降下来了。

1.3 Spark到底是什么，以及它的适用边界

很多人刚接触时会搞混几个概念。Spark本质是一个通用分布式计算引擎，不是存储系统，也不负责资源管理（除非用Standalone模式跑）。它默认可以读取HDFS、S3、本地文件，也可以读取各种数据库，但它本身不存数据。它提供的核心能力包括：

批处理：RDD/DataFrame的离线ETL；
交互式查询：通过Spark SQL对结构化数据做即时分析；
流处理：Structured Streaming，用批处理的方式处理流式数据；
图计算：GraphX；
机器学习：MLlib。

现在Spark 3.x已经是大数据领域默认的引擎之一，很多公司的数据平台把Spark当作执行引擎，上层用Hive、Flink跑任务时也经常会看到Spark的调度和执行。搞清楚它的原理，对你理解整个大数据生态也特别有帮助。不过也要注意边界：Spark不适合做低延迟的在线查询（在线场景用ClickHouse、Doris这类OLAP引擎更合适），也不适合做毫秒级的事件驱动流处理（那是Flink的主场）。Spark的定位始终是“大规模并行计算”，这句话理解了，选型时就不会跑偏。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. RDD、DAG与Spark执行链路：从提交到Stage划分的完整过程

2.1 RDD的三层身份：数据集合、计算模型、容错凭证

RDD全称是Resilient Distributed Dataset，这个名字里每个词都有意义。Resilient指的是容错能力强，通过血缘关系可以重算丢失的partition；Distributed说明它是分布式的，数据被划分到多个partition上，分布在多个Executor中；Dataset表示它代表一个数据集合。它同时承担三个角色：

数据容器：持有分区信息和依赖关系；
算子载体：map、filter、flatMap这些转换操作都作用在RDD上；
容错凭证：记录血缘（lineage），某个分区丢了可以直接根据血缘重算。

我记得第一次看RDD源码的时候，最困惑的是为什么RDD允许重复读。后来才意识到，正是这种不变性和可重算性，让Spark不需要在每个阶段都做数据备份，天然适合数据量大、节点可能故障的分布式环境。一个RDD一旦创建，它表达的数据转换关系就是固定的；数据丢了不是从备份恢复，而是顺着血缘重新算一遍，这才叫“弹性”。

2.2 行动算子触发的调度流程

RDD的惰性求值是Spark执行模型里最容易被忽略的设计。写一遍map、filter，任务不会立即执行，只是往DAG上加了节点和边；只有遇到collect、count、saveAsTextFile这类action时，才会上报DAGScheduler，开始真正的调度。

调度过程大致是：

SparkContext向Driver申请执行环境；
DAGScheduler解析整个DAG，根据宽依赖切分Stage；
每个Stage内部生成一组Task，TaskScheduler把Task分发到Executor；
Executor端启动TaskRunner，执行具体计算逻辑；
最终结果回传Driver（或直接写入外部存储）。

这里有个常见误解：Stage是“一批算子”，而不是“一个算子”。一个Stage里可能包含多个连续的窄依赖算子，比如rdd.map(...).filter(...).map(...)，只要中间没有宽依赖，就都归并在同一个Stage里，这样可以减少任务调度开销。新手最容易犯的错误是以为每写一个算子就会生成一个Stage，其实不是，Stage的边界只看shuffle。

2.3 宽依赖和窄依赖：为什么Stage划分的边界一定是shuffle

窄依赖是指父RDD的每个partition最多被子RDD的一个partition使用，典型算子是map、filter、union；宽依赖是指父RDD的每个partition可能被子RDD的多个partition使用，典型算子是groupByKey、reduceByKey、join（非广播）。宽依赖必须发生shuffle，也就是跨节点传输数据，因此是Stage划分的自然边界。

这里我用WordCount给大家画一条完整链路（画在脑子里就行）：

textFile读取HDFS得到HadoopRDD；
flatMap压平，得到FlatMappedRDD；
map成(word, 1)，得到MappedRDD；
reduceByKey聚合，触发shuffle，分成第一个Stage和第二个Stage；
第二个Stage跑完，最后执行collect。

reduceByKey之前的flatMap和map都属于第一个Stage，因为它们都依赖上游同一个partition一一映射，不需要网络传输。分组聚合来了之后，同一个单词可能分布在不同节点，必须shuffle到同一个Executor上做合并，所以这里划界。说白了，shuffle就是“数据重新洗牌”，只要发生了洗牌，前后两段就必须拆开变成两个Stage，因为上游算完才能决定下游的数据往哪儿送。

2.4 决定任务并行度的关键：partition、task和executor的关系

执行过程中，并行度不是由RDD自身决定的，而是由partition数量和可用Executor核心数共同决定。每个partition对应一个task；task是运行在Executor上的最小计算单元。如果输入有100个partition，而集群只有10个executor，每个executor只有1个core，那么真正能同时运行的task只有10个，剩下90个排队。这也就是为什么很多人会在Spark UI里看到大量task状态是“队列中”，并行度上不去，任务整体跑不快。

我一般会先查看stage的输入数据量，再结合每个executor的可执行内存和core数来设置合适的并行度。比如一个stage输入200GB，目标每个task处理256MB，那么partition大概需要800个左右。直接设置spark.default.parallelism或spark.sql.shuffle.partitions到这个数量级，比让系统默认值“碰运气”稳定得多。并行度设太低，节点资源利用不满；设太高，task调度本身会成为瓶颈，日志和Shuffle文件碎片也会暴增。这个平衡需要看实际任务反复调，没有通吃所有场景的固定值。

3. Spark SQL和外部数据源：DataFrame优化、Redis接入与达梦适配

3.1 DataFrame为什么比RDD好用：Catalyst优化器的三板斧

RDD的函数式编程虽然灵活，但最大的问题是：引擎不知道你在算什么。Spark SQL引入的DataFrame/Dataset先把“你要算什么”以schema形式描述出来，再用Catalyst优化器来优化执行计划。最典型的优化包括：

谓词下推：把where过滤条件下推到数据源端，减少读入数据量；
列裁剪：只读取SQL里需要的列，避免全量读；
常量折叠：把表达式里能用常量算的预先算好；
Join重排：通过统计信息自动调整join顺序。

执行前还能做WholeStageCodegen，把整条pipeline编译成一段Java字节码，减少虚函数调用和内存开销。RDD API写同样的逻辑，代码可能看着差不多，但执行性能往往差好几倍。所以现在大家写Spark任务基本都用Spark SQL或DataFrame API，用RDD的场景多半是基础教程或处理极端非结构化数据。

我的个人习惯是：能用SQL表达的绝不用算子慢慢拼。SQL的可读性好，优化器能做更多自动优化；而且团队里其他人接手时，看SQL比看一堆Lambda表达式容易得多。这里不是说RDD没用，而是你要清楚它的定位——灵活兜底，而不是默认选择。

3.2 用Spark SQL玩转Redis：一个实际可跑的案例

Redis和Spark的联动在很多实时离线一体的场景里非常常见。比如一个用户画像任务，主数据在HDFS，需要在加工过程中查询某个用户最近活跃状态，而这个状态存在Redis里。基本做法是在executor里直接初始化Redis客户端，在mapPartition或DataFrame的UDF里查询。更规范的做法是使用spark-redis这类第三方连接器，把整个Redis数据源映射成DataFrame。

这里我给大家展示一个典型的Spark读取Redis Hash的例子（以Scala为例）：

scala复制import org.apache.spark.sql.SparkSession
import com.redislabs.provider.redis._

val spark = SparkSession.builder()
  .appName("SparkReadRedis")
  .config("spark.redis.host", "10.0.0.5")
  .config("spark.redis.port", "6379")
  .config("spark.redis.auth", "yourpassword")
  .getOrCreate()

val df = spark.read.format("org.apache.spark.sql.redis")
  .option("table", "user_profile")
  .load()
df.show(false)

要注意的是，spark-redis的table概念对应Redis里的一个key前缀或hash结构，它会扫描匹配的key。生产环境里建议把Redis数据按哈希槽进行分片，并且控制扫描粒度，否则全量scan会给Redis实例带来比较大的压力。另一种常见的连法是不用连接器，直接用Jedis在Executor端逐条查询：这种方式灵活，但要防止并发太高把Redis连接数打满，通常要做连接池。

3.3 达梦数据库与Spark的适配集成：走JDBC这条老路其实最稳

搜索热词里专门有“达梦数据库与Apache Spark的适配集成”，这个需求在政企、金融场景里很常见。达梦（DM）是国内用得比较多的关系型数据库，和Spark集成的核心路径就是JDBC。

基本写法如下：

scala复制val jdbcDF = spark.read
  .format("jdbc")
  .option("url", "jdbc:dm://10.0.1.10:5236")
  .option("dbtable", "dmuser.t_user")
  .option("user", "test_user")
  .option("password", "******")
  .option("driver", "dm.jdbc.driver.DmDriver")
  .load()

jdbcDF.createOrReplaceTempView("t_user")
spark.sql("select city, count(*) as cnt from t_user group by city").show()

实际适配中，最容易踩的几个坑分别是：

JDBC驱动版本：DM提供不同版本的JDBC驱动，要和你的Spark版本、JDK版本匹配，优先用较新版本；
数据量限制：如果全表几十亿行，直接用jdbc读全表必然很慢。推荐加分区条件，比如按主键或日期字段拆成多个range分区并发读取；
建表写入时的“主键冲突”：Spark JDBC写入默认是追加模式，如果目标表已有相同主键，DM会抛异常。要么先清理目标表，要么用自定义保存逻辑；
方言适配：Spark的JdbcDialect默认没有DM方言，部分数据类型（如DM的DECIMAL/NUMBER）可能需要手动处理。通常做法是自定义一个JdbcDialect子类并注册。

3.4 大数据量写入外部系统：三个经典坑

Spark SQL处理完数据后，最容易出问题的是写数据阶段，典型的有三种：

小文件问题：spark.sql.shuffle.partitions设置过大或动态分区太多，导致输出几十万个小文件。后续数据读取和NameNode内存都扛不住。我习惯在写HDFS前，用coalesce或repartition控制输出分区数，并合理设置每个文件大小（比如200MB-500MB一个）。
重复写入：任务失败后重试，写入外部存储时可能产生重复数据。写入HDFS建议先写临时目录，成功后再rename；写入关系型数据库建议在写入前用目标表的唯一键做去重（或先delete再insert）。
类型精度：Spark侧Numeric类型精度和DM、Oracle等数据库不一致时，写入可能报“数字溢出”或“精度丢失”。最好在写入前显式对字段做cast。

这三个坑我在生产环境里全都碰到过。尤其是小文件问题，第一版任务跑完，下游Hive查询直接把NameNode搞到告警，排查下来发现是shuffle partitions设成2000，而实际输出只有1GB，每个文件几十KB。从那以后，凡是要落地的任务，我都会在写之前检查一遍预计的输出文件大小和分区数，宁可多一点task开销，也不要留下一堆没法读的小文件。

4. 集群部署路线：从单机安装到DGX GPU加速

4.1 本地单机部署：最小可用的Spark环境

没有集群也能先学起来。本机部署Spark的步骤其实很简单：

安装JDK 8或JDK 11（Spark 3.x推荐JDK 8/11/17，具体看发行版）；
下载Spark二进制包，比如spark-3.5.0-bin-hadoop3，解压到/opt/spark；
配置环境变量：

bash复制export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export SPARK_HOME=/opt/spark
export PATH=$SPARK_HOME/bin:$PATH

启动本地模式测试：

bash复制spark-shell --master local[*]

看到spark-shell的欢迎信息后，跑一个最简单的WordCount：

scala复制sc.textFile("file:///tmp/test.txt")
  .flatMap(_.split(" "))
  .map((_, 1))
  .reduceByKey(_ + _)
  .collect()

本地模式在调试逻辑时特别方便，但要注意：local[*]模式下所有计算都跑在一个进程里，没有分布式环境，性能指标不具备参考意义。本地模式适合验证代码逻辑、熟悉API、调试数据结果，但不适合拿来做性能测试。如果你想在上面做效果验证，记得数据量别太大，否则本机内存很容易被打满。

4.2 三节点Standalone集群搭建：最直接的理解方式

生产环境里用Spark，一般要么用YARN要么用K8s。但从学习角度，我建议先搭一个三节点Standalone集群，因为角色最简单，原理最直观。

假设三台机器：master节点做Driver和Master，两台worker节点分别做Executor。

搭建步骤：

将spark二进制包分发到所有节点，配置相同环境的JAVA_HOME；
在master节点编辑conf/spark-env.sh：

bash复制export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export SPARK_MASTER_HOST=192.168.1.10
export SPARK_MASTER_PORT=7077

编辑conf/workers文件，写入两个worker节点的IP：

code复制192.168.1.11
192.168.1.12

启动集群：

bash复制$SPARK_HOME/sbin/start-all.sh

在master节点访问http://192.168.1.10:8080，应该能看到两个worker已注册。

提交任务时：

bash复制spark-submit --master spark://192.168.1.10:7077 \
  --executor-memory 8G --executor-cores 4 \
  your-job.jar

Standalone模式下，Master负责资源的粗粒度分配：一个应用先申请固定数量的Executor，一旦申请到，整个运行期间一直占用。优点是稳定、好排查；缺点是资源利用率不如YARN的细粒度调度灵活。所以生产环境很多公司会选择YARN作为统一资源调度层。

4.3 DGX Spark是什么：GPU环境下的Spark使用

热词里出现了“DGX Spark部署Qwen3.8 Flash Next”这类内容，很多人会问这是不是一个新的框架。其实DGX Spark是面向AI数据处理场景推出的软硬件一体化平台，可以理解为“GPU机箱 + 预配置的Spark发行版 + RAPIDS加速插件”。常规Spark任务都在CPU上跑，而DGX Spark利用RAPIDS把部分计算（比如shuffle、SQL算子、特征工程）搬到CUDA GPU上，实现大幅加速。部署方式上，DGX Spark一般提供完整的Docker镜像和Kubernetes支持，可以把Spark Master、Driver、Executor都跑在GPU节点上。

如果你在一个NVIDIA DGX或类似GPU集群上部署Spark，核心步骤通常是：

安装NVIDIA驱动、CUDA、Docker等底层环境；
启动包含Spark和RAPIDS的镜像（镜像里通常预装了适配好版本的Spark）；
配置GPU资源：spark.executor.resource.gpu.amount=1，以及对应的resource file；
提交任务时开启RAPIDS加速器，指定gpu模块；
对于像Qwen3.8 Flash这类小型模型，可以结合Spark的向量化UDF或TensorFlow/PyTorch推理，把大规模推理任务批量跑起来。

这玩意的最大价值在于：以前做大规模机器学习推理或特征工程，要单独搭一套Flink/Spark + GPU的底层框架，而DGX Spark帮你在出厂时就把适配和性能优化做完，你只需要关注业务逻辑。我自己试下来，如果任务里join、groupBy特别多，从CPU Spark迁移到GPU Spark收益最大；如果任务基本是简单扫描和过滤，迁移收益就有限。

4.4 部署完成后的冒烟验证和配置检查

集群搭好后，建议按顺序做这几件事：

先查4040端口有没有Spark UI，能看到Stage和Executor信息；
跑一个简单的pi计算任务：

bash复制spark-submit --class org.apache.spark.examples.SparkPi \
  $SPARK_HOME/examples/jars/spark-examples_2.12-3.5.0.jar 100

检查UI里的Total Executor Cores是否等于你配置的总核数；
跑一个1GB左右的dataframe聚合任务，观察Shuffle read/write耗时是否正常。

我在部署时几乎每次都会遇到配置不一致问题：比如某个worker没装Java、或者JAVA_HOME路径和master不一样，导致worker启动失败。排查时优先看worker节点日志：$SPARK_HOME/logs/spark--org.apache.spark.deploy.worker-.out。这个日志通常会把失败原因写得明明白白。如果worker一直注册不上，用telnet命令测一下7077端口的连通性，基本能定位。

5. 稳定运行的关键：OOM、数据倾斜和Spark调优实战

5.1 OOM到底是怎么发生的：Executor内存模型拆解

Spark OOM是最常见的线上问题，也是面试必问。要真正解决它，先要看Executor可用内存的内部划分。

Spark 1.6引入了Unified Memory Manager，把Executor内存分为三块：

Execution Memory：给shuffle、join、aggregation等执行阶段使用；
Storage Memory：给RDD缓存和广播变量使用；
User Memory：给用户对象、UDF、Spark内部元数据等使用。

默认情况下，spark.memory.fraction=0.6，意思是Executor堆内存的60%分给执行+存储；执行和存储之间用spark.memory.storageFraction（默认0.5）动态调整，可以互相抢占。剩下的0.4留给用户代码和系统开销。

因此遇到Executor OOM时，不是简单地“把内存从4G改成8G”就完事。你要先判断是哪个区爆了：

如果报java.lang.OutOfMemoryError: Java heap space且出现在shuffle阶段，大概率是Execution Memory不够，考虑提高executor内存，或减少并发task数；
如果报Direct buffer memory，可能是堆外内存不够，调整spark.memory.offHeap.enabled和spark.memory.offHeap.size；
如果是Driver OOM，往往是因为collect结果太大，或者广播变量太大。记住：能不collect就不collect，需要小结果集时要确保数据量可控。

还有一个容易被忽略的点：同一个Executor上并发跑多个task时，每个task都会占用执行内存，如果某个task特别大，会把整个Executor的内存吃完。这时候调低spark.executor.cores，减少并发task数，反而比单纯加内存更有效。

5.2 数据倾斜：任务长尾的第一大元凶

数据倾斜的症状很典型：某个stage几百个task，其中大部分几秒跑完，但一两个task卡住跑了几十分钟，最终整体失败或超时。本质是shuffle时key分布不均，导致某些partition的数据量巨大。

常见的解决思路有以下几种：

加盐（salting）两阶段聚合：把key加上随机前缀，先做局部聚合，再去掉前缀做全局聚合。适合groupByKey这类聚合场景；
广播join：如果小表很小（几百MB以内），用broadcast join把大表和小表进行map端join，完全没有shuffle；
增大shuffle分区数：如果是因为partition数太少导致单个task数据过多，适当增大spark.sql.shuffle.partitions；
单独处理热点key：先统计热点key，把它们单独拎出来处理，避免影响整个job。

这里给一个加盐两阶段聚合的伪代码示例：

scala复制val saltedRDD = df.withColumn("salt", rand() * 100)
  .withColumn("salted_key", concat(col("sale_key"), lit("-"), col("salt").cast("int")))

val firstAgg = saltedRDD.groupBy("salted_key").agg(sum("amount").as("amount"))
val finalAgg = firstAgg.withColumn("real_key", regexp_extract(col("salted_key"), "(.*)-\\d+", 1))
  .groupBy("real_key").agg(sum("amount").as("amount"))

加盐的粒度要控制好：盐的个数太少，热点key还是集中；盐的个数太多，shuffle量成倍增加。一般我会先分析热点key的倾斜程度，倾斜特别严重的key单独处理，轻微倾斜的全局加盐。这个方案不是银弹，但确实是处理聚合倾斜最常用、成本最低的方案。

5.3 一套稳定运行的基础调优配置

调优没有银弹，但下面这组配置是我在多个生产任务里验证过、相对稳健的起点：

配置项	推荐值	作用
spark.sql.adaptive.enabled	true	动态调整shuffle分区、合并小分区
spark.sql.shuffle.partitions	200~1000（按数据量）	控制shuffle分区数
spark.sql.adaptive.coalescePartitions.enabled	true	减小不必要的分区数
spark.executor.memory	8G~16G	视单任务数据量而定
spark.executor.cores	2~4	每个Executor的CPU核数
spark.dynamicAllocation.enabled	true	动态回收空闲Executor
spark.sql.broadcastTimeout	600~1200	防止大广播超时
spark.sql.files.maxPartitionBytes	256MB~512MB	控制读文件时单个分区大小

这里的核心思路是尽量打开自适应执行（AQE）。Spark 3.x的AQE会根据运行时的真实统计数据自动做分区合并、join策略切换、倾斜join优化，比手工拍配置靠谱很多。建议先开AQE观察一段时间，再根据UI里的shuffle数据和task耗时做微调。我自己已经把AQE当作所有新任务的默认配置了，只要日志和数据源没有特殊要求，基本不会关。

5.4 排查问题的标准流程：从Spark UI到Executor日志

遇到Spark任务跑不动或报错，推荐按下面顺序排查：

打开Spark UI的Stage页面，看哪个Stage耗时最久；
点进这个Stage，看Executor Tab里每个task的shuffle read/write量、GC时间；
看有没有task反复失败。如果失败集中在少数几个Executor，优先怀疑数据倾斜或节点故障；
看Driver日志和Executor日志，Executor日志里一般会有完整的异常栈；
用Event Timeline看task调度是否有严重等待，如果有，可能是资源不足或网络问题；
如果SQL任务，先在SQL Tab里看物理执行计划，确认是否走了BroadcastJoin，有没有出现异常的SortMergeJoin。

这套流程看起来简单，但很多人实际排查时会跳过第一步，直接从日志翻起。结果在几千行日志里翻了半天，最后才发现问题只出在某一个task上。先看UI的聚合数据，再定位到具体的executor和task，效率高得多。尤其是Spark 3.x的UI，每个stage的shuffle read和write都有柱状图，一眼就能看出是否有task的数据量大得异常。

6. 面试常客：这些Spark原理题，值得你提前把逻辑捋清

6.1 宽依赖和窄依赖的区别，以及为什么它决定Stage划分

这是面试里Spark原理题的第一问，考察的是你是否真正理解了执行调度的本质。窄依赖（map、filter、union）不需要网络数据传输，子RDD的每个分区可以立刻在父分区所在节点上继续算；宽依赖（reduceByKey、groupByKey、join）需要跨节点传输数据，也就是shuffle。

Stage的划分策略就是“遇到宽依赖就断开”：一个Stage内部全是窄依赖，可以连续执行；Stage之间由宽依赖的shuffle连接。因为shuffle开销最大，也是整个任务最可能出问题的地方，所以无论是DAGScheduler划分、Spark UI查看瓶颈，还是调优，都要优先关注宽依赖。

6.2 Spark为什么不选择checkpoint而选择血统来容错

在分布式环境里，节点失效是常态。MapReduce的容错方式是中间结果落盘，节点挂了直接从磁盘恢复；Spark选择记录每个RDD的血缘，一旦某个分区的数据在计算过程中丢失，就根据血缘关系重新计算这个分区。这样做的优势在于：

重算只针对丢失的partition，不必重新计算整个job；
内存计算+血缘重算，大部分情况下比重放磁盘要快；
不需要定期checkpoint的开销。

但血统也有局限：DAG特别长的时候，越靠后的RDD重算代价越大。因此Spark还支持RDD.checkpoint()，遇到非常长的血缘时可以把中间结果持久化，截断血缘。实际项目中，一个DAG里有几百个算子的情况并不罕见，血缘太长时重算代价确实会失控，这时候一个checkpoint往往能把风险降下来。

6.3 Spark SQL 3.0之后为什么默认启用AQE

AQE全称Adaptive Query Execution，它的核心是“边执行边优化”。传统静态执行计划根据输入大小和统计信息事先定好，如果统计不准，执行计划就可能跑偏。AQE在shuffle之后获取真实的输出数据大小，再动态调整后续执行计划，包括：

自动合并shuffle后的小分区，减少task数量；
自动把SortMergeJoin转换为BroadcastJoin，当某侧数据实际很小时；
自动处理数据倾斜，把倾斜的分区分裂成多个子分区。

面试时如果能把AQE的三种优化机制说清楚，再举一个自己实际遇到的案例，基本就过关了。我通常拿生产环境里一张大表join小表的例子来讲：静态计划因为没识别出小表，走了SortMergeJoin，开了AQE之后自动改成BroadcastJoin，整个任务从二十分钟缩到三分钟。

6.4 Spark和MapReduce的本质区别是什么

这个问题问的不是简单对比表，而是考察洞察。除了计算模型（内存 vs 磁盘）、API语义（DAG vs MapReduce两阶段）之外，最本质的区别是：MapReduce把整个数据处理定义为map和reduce两个阶段，中间依赖分布式文件系统保存中间状态；Spark则用DAG把整个计算流程定义为一份“血缘图”，可以灵活调度、缓存复用，并且不必每次把中间结果写到外部存储。这种设计带来的连锁反应，就是Spark在迭代计算、交互式查询和机器学习场景里占据绝对优势。

6.5 面试中容易被追问的隐藏细节

真正有经验的面试官，问完基础题后一定会追问下面的细节：

reduceByKey和groupByKey的区别：reduceByKey会先在map端做combine，数据量小很多，性能通常会更好；
为什么join要注意大小表顺序：静态优化器会根据数据量选择BroadcastJoin或SortMergeJoin，但统计不准时可能选错，AQE能在运行中纠正；
Spark的Shuffle和MapReduce的Shuffle有什么区别：Spark的shuffle输出更依赖内存，且可以选择是否进行排序，MapReduce默认排序。

我自己的复习方法是把WordCount的完整执行链路在纸上画三遍：第一次画RDD的转换图，第二次画DAG和Stage划分，第三次标注每个节点的内存和磁盘IO。画完这三次，Spark核心原理基本就串成体系了，很多零散知识点会自动归位。等你真正能把一条执行链路里每个环节的输入、输出、内存/磁盘行为讲清楚，再回头去看那些OOM报错和Stage卡顿，思路会清晰很多。