徐卓菲在跟 Spark 打交道之前，我一直用的是 Pandas 和 SQL 跑数。数据量一旦上了几十个 G，单机就开始卡死，动不动就要 split 成几十个小文件分批跑，流程又臭又长。真正让我下决心深入 Spark 的，是第一次在一台 8 核 16G 的普通服务器上，用 Spark 处理了大概 300G 的日志数据，整个过程只花了几分钟。那一刻我就明白了：大数据处理里，Spark 不是“可选项”，而是“必选项”。今天这篇内容，我想从一个实际落地使用的角度，完整聊聊 Spark 的技术原理、典型应用场景、集群部署的坑，以及我调优排查 OOM 和读取 Redis 数据时积累下来的经验。这篇文章不是带你读官方文档，而是把从安装到调优这一整条链路中，最容易被卡住的点掰开揉碎讲清楚。
标题里的【1.3】其实是一个学习序列的编号，如果你是零基础，按顺序读下来即可；如果你已经写过 Spark SQL，只是对性能优化和数据倾斜束手无策，那可以直接跳到性能和故障部分。我会刻意用“我实际跑过的配置和代码片段”来讲，而不是给一堆理论。
1. 从安装到集群搭建：Spark环境准备的完整流程
1.1 部署模式怎么选：local、Standalone 还是 YARN
很多人一上来就问“Spark 怎么安装”，但真正的问题是“装完之后你在什么模式下跑”。第一次接触 Spark 的时候，我也以为安装完就万事大吉，结果 Spark 的部署模式直接决定了后续代码怎么写、资源怎么申请、怎么管理集群，这一步理解不透彻，后面全是坑。
Spark 最常见的部署模式有三种：local 模式、Standalone 模式和 YARN 模式。
- local 模式：Spark 进程直接跑在本机的一个 JVM 里，主要用于本地开发调试和单元测试。不需要集群，也不需要额外启动任何服务。你把 spark 解压完，直接 spark-shell 进入的就是 local 模式。
- Standalone 模式：Spark 自带的简单集群调度器。由 Master 节点和 Worker 节点组成，你手动启动 Master，再在 Worker 节点上启动 Worker 进程。适合小团队、没有现成 Hadoop 集群、但需要多机分布式计算的场景。
- YARN 模式：把 Spark 作业提交给 Hadoop YARN 集群，由 YARN 统一分配 CPU 和内存。如果你的公司已经有 Hadoop 集群，或者你希望 Spark、MapReduce、Flink 共用一套资源池，那 YARN 模式是首选。
部署模式的核心决策逻辑，总结下来就是三问：是不是只有一台机器？是不是只要能跑通功能就行？公司有没有现成的资源调度框架？
如果只是为了学 Spark，直接在本地用 local[4] 就够了，没必要搭集群。如果是做数据清洗、ETL、报表统计，并且机器不多，三台以内，那我建议直接上 Standalone。而一旦涉及多团队共享数据平台、Job 并发多、需要统一资源管控，那 YARN 比 Standalone 稳得多。
1.2 Spark 安装详细步骤与最容易忽略的环境变量
我以 Linux 环境为例，给出最常用的安装步骤。如果你用 Mac 或 Windows，逻辑完全一样，只是路径不同。
第一步：确认 Java 版本。Spark 3.x 必须跑在 Java 8/11/17 上，推荐 Java 8 或者 Java 11。这一步太容易踩坑了，我见过有人装了 Java 17 然后来回换 Spark 版本，其实只要统一用 Java 8，什么都省了。
bash复制java -version
第二步：下载 Spark 安装包。去官网下载预编译好的二进制包，比如 spark-3.5.1-bin-hadoop3.tgz。注意下载的是“bin-hadoop3”的版本，它已经自带了 Hadoop 客户端依赖，不需要额外装 Hadoop 就能跑 Standalone 模式。
第三步：解压并配置环境变量。
bash复制tar -zxvf spark-3.5.1-bin-hadoop3.tgz -C /usr/local/
cd /usr/local/
mv spark-3.5.1-bin-hadoop3 spark
然后编辑 /etc/profile 或者 ~/.bashrc：
bash复制export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export SPARK_HOME=/usr/local/spark
export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin
这里容易忽略两个关键点。一个是 JAVA_HOME 必须显式写入 Spark 的 conf/spark-env.sh，否则启动 Worker 时可能会找不到 Java。很多教程根本不会提这个，但这恰恰是集群启动失败最常见的原因。另一个是 Spark 自带的 sbin 目录要加到 PATH 里，否则你输入 start-master.sh 会提示找不到命令。
1.3 Spark 集群搭建与节点启动验证过程
我以三台机器为例，假设三台机器的主机名分别是 node01、node02、node03。node01 作为 Master，三台都作为 Worker 节点。
配置好网络和 hostname 之后，进入 Spark 安装目录的 conf 目录，复制模板文件：
bash复制cd /usr/local/spark/conf
cp spark-env.sh.template spark-env.sh
cp workers.template workers
编辑 spark-env.sh，加入以下内容：
bash复制export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export SPARK_MASTER_HOST=node01
export SPARK_MASTER_PORT=7077
export SPARK_WORKER_CORES=8
export SPARK_WORKER_MEMORY=16g
export SPARK_DAEMON_MEMORY=2g
编辑 workers 文件，把 node01、node02、node03 每个节点一行写进去。注意不要留空行，也不要加 localhost，否则会把当前机器重复注册一遍。
一切就绪之后，在 node01 上执行：
bash复制start-master.sh
start-workers.sh
启动完成后，浏览器访问 http://node01:8080，就能看到 Master 的 Web UI，正常情况下列表里能看到三台 Worker 的状态、核数和内存信息。如果 Worker 没有出现在界面里，优先去看 $SPARK_HOME/logs 目录下的日志，我遇到过的 90% 的情况都是 java 路径没配好或者主机名解析失败。
如果想验证分布式计算是否真的生效，可以执行下面这个简单命令：
bash复制spark-shell --master spark://node01:7077
然后在 Scala 终端里执行：
scala复制sc.parallelize(1 to 100, 10).map(_ * 2).sum
如果你在 Web UI 上看到多个 Executor 参与了任务运行，说明集群已经通了。到这里，环境层面的链路就算跑通了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. RDD、DataFrame 和 Dataset：理解 Spark 核心计算模型的设计演进
2.1 RDD 为什么慢：惰性计算与重复计算的代价
环境搭好之后，下一步就是写数据处理逻辑。Spark 最核心的抽象是 RDD（弹性分布式数据集），但你会发现，大量网上教程的 RDD 代码写起来爽，真正跑性能就是不行。原因在哪里？因为 RDD 是惰性求值的，而且它只记录了“怎么从数据源算出来”的依赖关系，并不会主动帮你优化。
举个例子。你用 RDD 加载一个 1000 列的 CSV 文件，然后只用了第 1 列和第 2 列做聚合，RDD 在计算时会老老实实地把全部 1000 列都读一遍。它不会像 SQL 引擎那样做“列裁剪”。更麻烦的是，如果一个 RDD 被重复使用了两次，它上游依赖的所有转换流程都要重新执行一遍。
scala复制val rdd = sc.textFile("hdfs://logs/2025/")
val count = rdd.filter(line => line.contains("ERROR")).count()
val sample = rdd.filter(line => line.contains("ERROR")).take(10)
这段代码看起来逻辑没错，但 rdd 被遍历了两次，Spark 不会智能地缓存第一次的 filter 结果。生产环境里，这种写法轻则让任务时间翻倍，重则直接把集群跑挂。RDD 确实灵活，但对于绝大多数数据清洗和统计分析场景，它并不是最优解。
RDD 的核心价值是在于它提供了一套非常底层的 API，让你能控制分区、自定义函数、处理非结构化数据。这也是为什么 Spark 一直没有移除 RDD API，因为总有 5% 的场景需要这种底层操作。
2.2 DataFrame 背后的 Catalyst 优化器如何“替你省钱”
DataFrame 的出现，本质上是为了解决“开发效率低”和“执行性能差”这两个问题。DataFrame 可以理解成“带有 Schema 信息的分布式行集合”，它与 RDD 最大的区别是：DataFrame 知道每一列叫什么名字、是什么类型。正是这种“结构性信息”，让 Catalyst 优化器有了发挥的空间。
我一开始也觉得 DataFrame 无非是套了一层 Schema，性能提升不会太大。后来处理一个订单表的 Join 操作，RDD 版本跑了 7 分钟，换成 DataFrame 写法只跑了 1 分 20 秒，而且代码量少了不止一半。这个差距不是代码技巧带来的，而是 Catalyst 在物理执行前自动做了好几层优化。
Catalyst 优化器的工作流程大致分为四个阶段：
- Unresolved Logical Plan：从代码里解析出一个尚未校验的逻辑执行计划。
- Analyzed Logical Plan：通过 Catalog 校验表名、列名、数据类型。
- Optimized Logical Plan：应用谓词下推、列裁剪、常量折叠、Join 重排等优化规则。
- Physical Plan：把逻辑计划转换为物理执行计划，并选择具体的执行策略。
其中“谓词下推”和“列裁剪”在实际效果上最明显。谓词下推是指先过滤再计算，把过滤条件下推到数据源读取阶段；列裁剪是指只读取查询真正用到的列，尤其在读 Parquet 这类列式存储时效果显著。
scala复制val df = spark.read.parquet("/data/orders")
df.filter($"status" === "PAID")
.select("order_id", "amount")
.groupBy("order_id")
.sum("amount")
这段代码在 Catalyst 优化后，大概率只在扫描数据时读取 order_id、status、amount 三列，而且 status 过滤在读取阶段就开始生效了，而不是等全表加载完再过滤。这种底层优化逻辑对使用者完全是透明的，但如果你不理解它，你会在调优时找不到方向。
2.3 类型安全的 Dataset：什么时候我才会选它
Dataset 在 DataFrame 的基础上引入了强类型。DataFrame 是 Dataset[Row]，每一行都是 Row 类型，编译期无法检查列名是否正确；Dataset[T] 则是把每一行映射成自定义的 Java/Scala 对象，比如 Dataset[Order]，编码的时候 IDE 就能自动帮你检查类型。
但 Dataset 并不是免费的午餐。它需要 Encoder 来做序列化和反序列化，性能在复杂场景下并不一定比 DataFrame 快。业界目前的主流实践是：绝大多数业务场景用 DataFrame；如果你不仅需要类型安全，还需要对每条记录做复杂的函数式处理，比如嵌套的 map、flatMap 操作，那才适合用 Dataset。
我个人的经验是，在写偏底层的 ETL 逻辑时 Dataset 会严谨很多，但在做即席查询、报表统计时，DataFrame 的效率明显更高。顺带提一句，Python 的 PySpark 里 Dataset API 支持并不完善，所以 Python 用户基本只和 DataFrame 打交道。
3. 性能优化实战：从 Shuffle 到数据倾斜的排查与调优
3.1 Shuffle 是万恶之源：为什么性能问题大多出在宽依赖
Spark 应用跑得慢，十有八九和 Shuffle 有关。Shuffle 本质上是一份数据被重新分区到不同节点上的过程。在物理上它涉及：上游任务把计算结果写入本地磁盘，下游任务通过网络拉取这些中间结果。磁盘 I/O 和网络 I/O 同时被消耗，性能瓶颈基本不可避免。
从一个代码角度来看，触发 Shuffle 的算子通常包括 groupByKey、reduceByKey、join、distinct、repartition 等。它们都产生了“宽依赖”，也就是父 RDD 的同一个分区会被子 RDD 的多个分区使用。理解 Shuffle 的代价后，你就能解释为什么有些操作要尽量避免。
比如 groupByKey 与 reduceByKey 的区别。groupByKey 会把同一个 Key 对应的所有 Value 原封不动地 Shuffle 到下游，而 reduceByKey 会在 Shuffle 之前先在每个分区内做一次局部聚合，再把局部聚合结果 Shuffle 下去。数据量越大，“先在本地预聚合”带来的收益就越明显。
scala复制// 性能差
val counts = pairs.groupByKey().mapValues(_.sum)
// 性能好
val counts = pairs.reduceByKey(_ + _)
我第一次在使用超过 500G 的日志做关键词统计时，就是用了 groupByKey，结果任务跑了 40 分钟还没跑完，后来切成 reduceByKey，时间直接降到 8 分钟。原因就是网络传输的数据量减少了几十倍。
另外，Spark SQL 中执行 join 时也常遇到 Shuffle，尤其是两张表都很大时。这是因为相同 Key 的数据必须被分发到同一个 Executor 上才能完成匹配。如果一张大表和一张很小的维度表关联，经典的优化就是 Broadcast Join，也就是把小的维度表复制到每个 Executor 的本地内存中，避免全量 Shuffle。
scala复制val largeDf = spark.read.parquet("/data/orders")
val smallDf = spark.read.parquet("/data/dim_city")
val result = largeDf.join(smallDf.hint("broadcast"), Seq("city_id"))
在 Spark 3.x 中，当 smallDf 小于 spark.sql.autoBroadcastJoinThreshold（默认 10MB）时，系统会自动选择 Broadcast Join。这个参数在生产里可以根据 Executor 内存调整到 20MB 甚至 50MB，但要适度，毕竟广播表是常驻每个 Executor 的 JVM 堆内存里的，太大会直接引发 GC 频繁甚至 OOM。
3.2 数据倾斜排查：Key 分布不均匀导致的执行卡死
数据倾斜是比 Shuffle 更隐蔽的性能杀手。所谓数据倾斜，就是数据中的某个 Key 分布极度集中，导致大量数据都进入同一个 Task 处理，别的 Task 都跑完了，就这一个 Task 卡在那里跑几个小时。
最典型的场景发生在 groupBy、join 这类操作上。一句简单的 groupBy("city_id")，如果 80% 的数据都集中在某一个城市，那这个城市的 Task 就是整个作业的最短板。
排查步骤我一般这样走：
- 在 Spark Web UI 上查看 Stage 的任务耗时分布，如果有某个 Task 的输入数据量比其他 Task 大好几个数量级，基本可以判定倾斜。
- 定位触发倾斜的算子，通常是 groupBy、join、distinct。
- 对 Key 做采样统计，确认倾斜程度。可以使用如下思路：
scala复制df.groupBy("city_id").count().orderBy($"count".desc).show(10)
找出倾斜 Key 后，解决思路通常有两种。第一种是两阶段聚合，也就是“加盐”。先给每个 Key 加一个随机前缀，打散成多个子 Key，做第一轮局部聚合，再去掉前缀做第二轮聚合。
scala复制import org.apache.spark.sql.functions._
val salted = df.withColumn("salt", rand() * 10 cast "int")
.withColumn("salted_key", concat($"city_id", lit("_"), $"salt"))
val result = salted.groupBy("salted_key").agg(sum($"amount"))
.withColumn("city_id", split($"salted_key", "_")(0))
.groupBy("city_id").agg(sum($"amount"))
在 join 场景下，加盐稍微复杂一点，因为必须保证两张表对同一个 Key 都做相同的加盐逻辑。一般做法是：把大表的倾斜 Key 加上随机前缀，把对应的小表数据膨胀 N 倍，再做关联。要注意的是，这种方式要以控制膨胀倍数为前提，不能无限放大。
还有一类比较容易忽视的倾斜来源是 null。如果某个业务字段里 null 占比巨大，groupBy null 这种 Key 时会聚合成一个超大 Task。最简单的解决方式：把 null 处理为默认值或直接过滤掉。空字符串也是一样的道理，我遇到过数据里空字符串占 70%，整条链路卡在一个 Task 上，排查了整整一个下午，最后才发现问题不在 Join 逻辑，而在数据本身的质量。
3.3 缓存与持久化：哪些场景该用 cache，哪些场景根本不该用
很多初学者喜欢在 DataFrame 后面随手加一个 .cache()，以为这样能加速，其实大多数时候反而拖慢了任务。cache 只有在“同一个 DataFrame 会被多个 Action 重复使用”的情况下才有明显收益。否则，cache 本身也需要占用 Executor 内存，增加序列化和反序列化的开销，属于画蛇添足。
缓存级别上，最常用的是 StorageLevel.MEMORY_AND_DISK。Spark 先尝试把数据放入内存，如果内存不够，就把多出的部分写入本地磁盘，这样不会因为内存溢出而丢数据。如果数据是反复要用的核心中间结果，我会使用 cache() 并主动在作业结束后调用 unpersist()，否则它会一直驻留在 Executor 中，影响后续任务。
scala复制val cleanDf = df.filter($"amount" > 0).cache()
cleanDf.count()
cleanDf.groupBy("city_id").sum("amount").show()
cleanDf.unpersist()
此外，Spark 内存模型的动态占用机制也容易让人困惑。Spark 2.x 之后采用统一内存管理，存储内存和执行内存可以在一定约束下互相借用。也就是说 spark.memory.storageFraction 并不是一个“存储能用到的最大上限”，而是一个“预留值”。这导致很多人看到 Storage 内存不足，以为是缓存放太多，实际上可能是因为同一时刻执行内存把空间借走了。排查内存问题别只看 UI 上的 Storage Memory，要结合 Executor 的 GC 日志来判断。
3.4 内存模型与 Executor 参数：OOM 不只是“调大内存”那么简单
生产环境里最常遇到的错误就是 OOM。一看到 OOM，不少人的第一反应是把 spark.executor.memory 从 4g 调到 8g，但很多时候内存调大并没有用，甚至情况更糟。原因是 Executor 的 OOM 需要区分到底发生在 Driver 端还是 Executor 端，以及发生在哪个环节。
Executor 端的 OOM，常见于 Shuffle 或 Join 阶段。此时单个 Executor 需要处理的数据量太大，超过 JVM 堆内存。治理思路不是一味加内存，而是控制单个 Task 处理的数据量。可以优先调整 spark.sql.shuffle.partitions，该参数默认是 200，但并非越大越好。分区数太小，每个分区处理的数据太多；分区数太大，任务调度和文件写出开销急剧上升。经验值一般是根据 Shuffle 数据总量除以每个 Task 期望处理量来估算。假设某次 Shuffle 数据量在 200GB，希望单个 Task 处理不超过 500MB，分区数设置在 400 左右比较合理。
Driver 端 OOM 最常见的原因是 collect() 被滥用。collect() 会把所有结果拉回 Driver，如果结果集有几个 G，Driver 内存再多也白搭。正确做法是用 saveAsTable/写入外部存储，只把必要的聚合结果拉回。
代码里的另一个隐患是 DataFrame 的重复 Action 造成的大量重算。Spark 的惰性求值让很多人忘了每次 Action 都会重新执行完整血统，如果中间结果不 cache，多个 Action 会导致任务反复执行，内存压力成倍增长。所以，凡是跑 count、show、write 之前需要反复使用的中间结果集，都必须做持久化处理。
Off-Heap 内存也是很容易被忽略的一环。spark.memory.offHeap.enabled 默认是 false。如果你开启 off-heap，需要设置 spark.memory.offHeap.size，例如 2g。但不要指望 off-heap 能完全替代堆内内存，它主要解决的是堆内内存的 GC 压力，在序列化数据场景下有收益，但非序列化算子仍然使用堆内内存。总的来说，我建议从调整并行度、检查数据倾斜、减少重复计算着手，而不是一上来就调内存大小。
4. 实战案例分析：OOM 处理、Spark 读取 Redis 与集群资源评估
4.1 一个真实的 Executor OOM 排查过程与最终落地配置
我之前处理过一个真实需求：读取某业务表 400G 的 Parquet 文件，做 Join 后聚合写入结果表。集群是 10 台 16 核 64G 的 Worker。刚开始我按“经验”配置了资源，心想 64G 内存足够大了，结果任务在第三个 Stage 直接报 Executor Lost 和 OOM。
最初报错后，我第一时间把 executor.memory 提高到 24g，但效果很差，任务还是失败。这时候我意识到不能靠加内存解决了。我重新到 Spark Web UI 上看 Stage 详情，发现某个 Stage 的 Shuffle Read 数据量接近 100G，而该 Stage 又只有 200 个任务，意味着每个 Task 平均要处理 500MB 的 Shuffle 数据，单 Task 峰值甚至超过 1G。任务分配到的内存不仅要放这批数据，还要放聚合操作产生的中间对象，处理不下来是必然的。
最终我做的调整是：
- spark.sql.shuffle.partitions 从 200 调到 600
- spark.executor.memory 保持 16g，不盲目加大
- spark.executor.cores 设为 4，确保单 Executor 内并发数不太高
- spark.memory.offHeap.enabled 设为 false，减少额外的序列化开销
- 对部分中间结果集使用 MEMORY_AND_DISK 持久化，而不是纯 Memory
调整之后任务稳定通过，总耗时还比之前快了 30%。这让我深刻认识到，分配资源的核心逻辑是“让每个 Task 处理的数据量落在它能力范围内”，而不是把所有数据都塞进一个大内存 Executor。
4.2 Spark 读取 Redis 的正确姿势与一次性连接优化
很多业务会把实时特征或维度数据存在 Redis 中，然后用 Spark 批量读取。我在项目里就遇到过从 Spark 任务读取 Redis 数据反查维度的需求。最开始的代码很直接：用 foreachPartition 遍历每个分区的每条记录，然后为每条记录创建 Jedis 连接去 get 数据。结果数据量一大，Redis 根本扛不住，Spark 任务也大量超时。
问题出在连接创建太频繁。Jedis 实例不是线程安全的，但创建 Jedis 连接池的开销完全可以分摊到每个 Executor 而不是每条记录。调整后的方案是：在每个 Executor 分区内使用 JedisPool，每个分区只初始化一次池，然后批量获取数据。
scala复制df.foreachPartition { partition =>
val pool = new JedisPool(new JedisPoolConfig(), "redis-host", 6379)
val jedis = pool.getResource
partition.foreach { row =>
val key = row.getAs[String]("key")
val value = jedis.get(key)
// 处理逻辑
}
jedis.close()
pool.close()
}
连接池的参数也需要配合调整，比如 maxTotal 和 maxIdle 要合理设置，避免连接数超过 Redis 端的 maxclients 配置引发拒绝连接。Redis 单实例的 QPS 上限是有限的，如果 Spark 端并行度太高，需要提前给 Spark 任务降级并发或对热点数据做本地缓存。我就曾经把高频维度 Key 在 Executor 本地用 HashMap 缓存，只有未命中的 key 才查 Redis，整个任务的时间缩短了不止一半。
另外需要注意：如果你读取的是 Redis 的 Hash 类型，要用 hgetAll 而不仅仅是 get；如果你要批量查询多个 key，尽量用 pipeline。这些都是 Redis 使用的基本功，但是在 Spark 里一放大，处理不好就会变成灾难。
4.3 GPU 与加速硬件的选择：常规集群和 DGX Spark 这类平台如何评估
最近圈子里开始讨论 GPU 加速 Spark，也有像 DGX Spark 这类集成方案出现。不少人一看到 GPU 就兴奋，以为所有 Spark 作业都能大幅提速。实际上 GPU 对 Spark 的加速主要集中在特定算子，比如 SQL 执行中的 Scan/Filter/Aggregation、机器学习库中的矩阵运算等。如果你的业务主要是复杂 Join、Shuffle 密集型的 ETL，GPU 的收益远没有想象中大，瓶颈往往在网络和磁盘 I/O 上。
从集群规划的视角来看，我先回答一个更实际的问题：哪些场景一定要引入 GPU 能力？
- 深度学习推理与训练：Spark 常用于大规模数据预处理，之后把处理好的数据喂给 GPU 训练。如果预处理也要跑在 GPU 上，必须搭配支持 GPU 调度的集群。
- 大规模向量检索与相似度计算：比如推荐系统里的用户 Embedding 和物品 Embedding 计算，这确实是 GPU 的强项。
- 复杂 SQL 中的低延迟查询：某些 SQL 引擎推出 GPU 加速执行计划后，能明显降低查询延迟，但这要求文件格式、数据布局都提前优化好。
如果团队刚开始搞大数据，并没有成熟的 GPU 基础设施，但未来明确要做推荐、NLP 等方向，可以考虑具备 GPU 扩展能力的平台。如果业务纯粹是离线报表和 ETL，选择一个稳定的 CPU 集群做资源隔离和弹性伸缩，性价比更高。千万不要为了“用 GPU”而把整个架构搞得特别复杂，先把 CPU 集群的 Spark 作业调优到极致，再评估性能瓶颈是否真在计算上，这才是稳妥的演进路径。
4.4 Spark 作业资源评估的五个判断维度
每次接手一个新 Spark 作业，我习惯先做一个快速评估，而不是拿到代码就开始调。下面这五个维度能帮你快速定位作业的健康度：
- 数据量级与存储格式：输入数据有多大？是 Parquet、ORC、Avro 还是 CSV/JSON？列式存储对 Spark SQL 的扫描过滤有天然优势，CSV/JSON 在这种场景下性能会差很多。
- Shuffle 数据规模：这个作业在哪个 Stage 会发生 Shuffle？Shuffle Write 的数据量大约多少？如果 Shuffle 规模超过总数据量的 50%，要重点检查是否存在不必要的 Join、去重或 groupBy。
- 单 Task 输入数据量：用 Spark UI 看每个 Task 的 Input 和 Shuffle Read 数据量。如果单个 Task 超过 1G，通常要考虑增加分区数。
- Executor 资源配比：总 CPU 核数、总内存、并发 Task 数是否匹配。理想情况是单 Executor 的并发 Task 数与 CPU 核数接近，避免线程切换过多。
- 是否存在可复用的中间结果：如果同一份数据被多个 Action 使用，务必考虑 cache 或 persist。
4.5 大表关联小表场景的另一种思路：读 Redis 做维表关联
前面讲的是用 Broadcast Join 做维表关联，但有些场景的维表不在 Hive 表，而在 Redis 或者其他外部存储中。此时可以用 Broadcast 变量把维度数据封装成 Map 分发到 Executor，然后使用 map 算子完成关联。这种方式避免了 Redis 网络开销，也避免了 Shuffle，是业界常见的维表关联优化方案。
scala复制val cityMap = spark.read.parquet("/data/dim_city")
.collect()
.map(row => row.getAs[String]("city_id") -> row.getAs[String]("city_name"))
.toMap
val broadcastMap = spark.sparkContext.broadcast(cityMap)
df.map { row =>
val cityName = broadcastMap.value.getOrElse(row.getAs[String]("city_id"), "UNKNOWN")
(row.getAs[String]("order_id"), cityName)
}
用 Broadcast 变量有一个限制：维度数据不能太大，否则 Driver 端 collect 时可能 OOM，广播到 Executor 后又会挤压缓存空间。如果维表超过 50MB，建议谨慎使用。
5. 从行存储到列式存储：理解存储格式对执行性能的实质影响
5.1 SQL 引擎和 Spark SQL 在读取 Parquet/ORC 时为什么更快
很多调试性能问题的人，最后都会发现瓶颈不在计算而在 I/O。Spark 的数据源是 HDFS 或云存储，数据读取量直接决定作业的下限。如果你还在用 CSV 或 JSON 存大表，Spark 即使优化做得再好，也快不到哪里去。原因不在于 Spark 本身，而在于文件格式的物理布局。
Parquet 和 ORC 都是列式存储格式。列式存储的意思是：同一个文件里按列连续存放数据。当你只需要读取两个字段的时候，Spark 可以直接跳过其他所有列的数据块，只读取这两列所在的 Page。而 CSV 是行式存储，一行数据的所有字段都在同一个块中，你要取两列就必须扫描整行内容。这也就是为什么在 Spark 场景下，我强烈建议把数据源换成 Parquet 的主要原因。
举个例子，一张订单表有 80 个字段，单日数据量 1 亿行，CSV 格式占用约 200GB。换成 Parquet 后，占用通常能降到 30-40GB，再加上 Snappy 压缩，磁盘空间和 I/O 都会大幅减少。如果你的表只有三个字段是高频查询列，那么列式存储的效果会好得更夸张。
5.2 Snappy 与 Zstandard：压缩算法选择的路径是与不是
分析 CSV 和 Parquet 差异时，压缩格式也是影响性能的一大变量。Parquet 支持 Snappy、Gzip、Zstd 等压缩算法。Snappy 的解压速度快但压缩率低，Gzip 压缩率高但 CPU 开销大。
下面的表格总结了我在生产中使用各类压缩算法的参考经验：
| 压缩格式 | 压缩比 | 压缩/解压速度 | 适用场景 |
|---|---|---|---|
| Snappy | 中低 | 非常快 | 默认首选，兼顾速度与空间 |
| Gzip | 高 | 慢 | 冷数据存储、长期归档 |
| Zstd | 高 | 快（接近 Snappy） | 大量查询、追求高压缩比时可替代 Gzip |
| LZO | 中 | 快（需要额外 native 库） | 少数 Hadoop 生态兼容场景，已逐渐边缘化 |
Spark 写 Parquet 时，可以设置 spark.sql.parquet.compression.codec 为 snappy 或 zstd。比如：
bash复制spark.sql.parquet.compression.codec snappy
我个人的选择是：如果磁盘空间不紧张，优先 Snappy；如果数据量巨大且查询频率不高，使用 Zstd 能省不少存储成本。
5.3 分区裁剪与文件布局优化的小技巧
列式存储解决了数据读取量的问题，而文件分区策略解决的是“该读哪些数据”的问题。按日期字段做分区是最常见的操作。
scala复制df.write.partitionBy("dt", "city_id").parquet("/data/orders")
之后查询时带上分区过滤条件：
scala复制spark.read.parquet("/data/orders")
.filter($"dt" === "2025-06-01" && $"city_id" === "110000")
这部分 Spark 会自动做分区裁剪，只读取匹配目录下的文件，而不是全表扫描。这里有一个容易被忽略的问题：分区字段的选择对文件数量影响极大。过度使用细粒度分区，比如把唯一性很强的 order_id 作为分区字段，会产生数以万计的“小文件”，反而拖慢作业。我在实际项目中就踩过这个坑，按天分区合理，按小时分区就导致 HDFS 上出现大量几 KB 的小文件，之后清理和合并花费了大量精力。
生产实践里也建议定期做小文件合并，尤其是 Spark Streaming 或高频调度任务。最简单的做法是在完成数据写入后，使用 coalesce 或 repartition 控制最终输出文件数，使每个输出文件的大小在 256MB 到 512MB 之间，这样才能让后续读取任务达到合适的并行度。
以上这些内容来自于我实际跑任务过程中的一些总结，尤其是反复调试数据倾斜和 OOM 之后的一些体会。每一个坑的背后，都是 Spark 框架对资源管理和数据分布逻辑的映射。如果你一开始就能从“数据分布”“分区大小”“Shuffle 规模”这几个底层角度去想问题，很多性能问题都能提前拦截在设计阶段。
在收尾之前，我想再强调一点：Spark 优化没有银弹。不要盲目照搬别人文章里给的参数，因为你的数据分布、集群规模、业务复杂度完全不同。合理的路径是，在理解原理的基础上，借助 Web UI 和日志里的指标，顺着瓶颈层层反推，最终找到适合自己的配置组合。踩过的这些坑不会白踩，它们会逐渐变成你写 Spark 任务时的直觉。