Spark 数据本地性优化：PROCESS_LOCAL 和 NODE_LOCAL 的调度策略

跑 Spark 任务的时候，你有没有注意过日志里那一行小字："Preferred location: node-xxx"？很多人直接忽略了，但这个信息决定了你的任务是在本地读数据还是跨节点网络传输，直接影响整个作业的执行速度。今天我们来深入聊聊 Spark 的数据本地性调度策略，搞懂 PROCESS_LOCAL 和 NODE_LOCAL 的区别，以及怎么调优让你的任务跑得更快。

一、数据本地性是什么，为什么重要

Spark 的核心设计理念之一就是"计算向数据靠拢"，而不是"数据向计算靠拢"。道理很简单——移动计算（Task 代码）的成本远低于移动数据（GB 级的 shuffle 数据）。

Spark 定义了五个本地性级别，从最优到最差依次为：

具体来看，当 Executor JVM 与数据位于同一节点时，若数据存储在 BlockManager 缓存中，则实现 PROCESS_LOCAL 级别的内存访问；若数据位于本地 HDFS DataNode 磁盘，则属于 NODE_LOCAL 级别。当数据位于同一机架的不同节点时，Executor 通过机架内网络访问远端 DataNode，对应 RACK_LOCAL 级别。而当数据位于跨机架的远端节点时，则属于 ANY 级别，需经历跨机架网络传输。

一个简单对比：假设每个 Task 处理 128MB 数据，PROCESS_LOCAL 几乎零传输耗时，而 ANY 级别可能需要 1-2 秒的网络传输时间。如果你的作业有 10000 个 Task，累计就是 10000-20000 秒的额外开销，这差距不容忽视。

二、PROCESS_LOCAL：最优但也最难持久维持

PROCESS_LOCAL 是最理想的本地性——Task 运行在缓存了数据的 Executor 上，直接从 BlockManager 内存中读取数据，零网络、零磁盘、零序列化。

触发 PROCESS_LOCAL 的典型场景：

• Cache/Persist 数据：df.persist(StorageLevel.MEMORY_ONLY)后，后续 Task 会优先分配到缓存所在 Executor
• Shuffle Read 前一阶段同一 Executor：如果 Map 阶段的输出数据还在同一 Executor 的内存中未落盘

from pyspark.sql import SparkSession spark = SparkSession.builder \ .appName("ProcessLocalDemo") \ .config("spark.sql.shuffle.partitions", "200") \ .getOrCreate() # 读取数据并缓存，触发 PROCESS_LOCAL df = spark.read.parquet("/data/user_events/") \ .filter("event_date = '2026-07-01'") \ .persist() # 缓存到内存，后续操作倾向 PROCESS_LOCAL # 第一次操作：缓存构建阶段，本地性可能只是 NODE_LOCAL result1 = df.groupBy("user_id").count() # 第二次操作：数据已在内存，倾向 PROCESS_LOCAL result2 = df.groupBy("event_type").agg({"duration": "mean"}) # 用完记得释放缓存 df.unpersist()

但 PROCESS_LOCAL 有个致命弱点——它依赖内存缓存。一旦 Executor 内存不够，数据被 evict 到磁盘，本地性就降级为 NODE_LOCAL；如果磁盘也不够了，数据丢失，就得重新从 HDFS 拉，降级为 RACK_LOCAL 或 ANY。

三、NODE_LOCAL：稳定可靠的主流选择

NODE_LOCAL 意味着 Task 和数据在同一物理节点上，但不在同一个 JVM 进程。典型场景是 HDFS 数据读取——HDFS 的 DataNode 进程和 Spark Executor 进程在同一台机器上，Task 从本地磁盘读取 HDFS Block。

NODE_LOCAL 相比 PROCESS_LOCAL：

• 没有零拷贝内存直读的优势，需要经过磁盘 I/O + 反序列化
• 但不依赖内存缓存，稳定性更高——只要 HDFS Block 还在这台机器上，本地性就不会降级
• 对于大规模数据读取任务，NODE_LOCAL 是最实际的"默认最优"

在实际调度过程中，TaskScheduler 会根据数据位置动态决策。当收到 Task 时，系统首先检查是否存在拥有缓存数据的 Executor。若有且内存充足，则分配 PROCESS_LOCAL；若有但内存不足，则分配 NODE_LOCAL 并将缓存落盘。若完全无缓存，系统会进一步判断数据所在节点是否有可用 Executor。若有，则分配 NODE_LOCAL 直接读取 HDFS；若无，则进入等待状态或降级为 RACK_LOCAL/ANY。

关键配置参数：

# 本地性等待时间（毫秒）——在每个本地性级别等待多久后降级 spark.locality.wait=3000 # 默认3秒 spark.locality.wait.process=3000 # PROCESS_LOCAL 等待时间 spark.locality.wait.node=3000 # NODE_LOCAL 等待时间 spark.locality.wait.rack=3000 # RACK_LOCAL 等待时间 # 增大等待时间可以让 TaskScheduler 多等一会儿，争取更好的本地性

但等待时间太长会导致资源空闲，反而降低整体吞吐

## 四、实战调优策略 ### 4.1 提高 PROCESS_LOCAL 比例 - 合理使用 `persist()`：对被多次使用的 DataFrame/Dataset 进行缓存 - 调整 Executor 内存比例：增大 `spark.memory.fraction`（默认 0.6），让更多数据留在内存 - 减小分区数避免单个分区过大：单个分区太大容易触发内存 evict ```python # 优化配置示例：提高缓存命中率 spark = SparkSession.builder \ .appName("LocalityOptimized") \ .config("spark.memory.fraction", "0.7") \ # 提高存储内存比例 .config("spark.memory.storageFraction", "0.5") \ # 存储内存中缓存占一半 .config("spark.sql.shuffle.partitions", "400") \ # 适度增加分区数，每分区更小 .config("spark.locality.wait.process", "5000") \ # 给 PROCESS_LOCAL 多等2秒 .config("spark.locality.wait.node", "5000") \ # 给 NODE_LOCAL 也多等2秒 .getOrCreate()

4.2 保障 NODE_LOCAL 基线

• Spark Executor 和 HDFS DataNode 共置部署：这是最基本的要求，否则 NODE_LOCAL 都无法保证
• HDFS 短路读（Short-Circuit Local Read）：配置dfs.client.read.shortcircuit=true，让 Spark 绕过 DataNode 进程直接通过本地文件系统读 Block，减少一次进程间通信
• 避免数据倾斜导致 Executor 不均衡：如果某些 Executor 上的数据量远大于其他，会导致部分 Task 的本地性降级

4.3 本地性监控与诊断

Spark UI 的 Stage 详情页会显示每个 Task 的本地性级别统计。关注这几个指标：

• PROCESS_LOCAL Task 占比：理想值 > 60%（对于有缓存的场景）
• NODE_LOCAL Task 占比：理想值 > 80%（对于 HDFS 直读场景）
• ANY Task 占比：> 10% 就需要排查原因

# 通过 Spark REST API 拉取本地性统计 import requests app_id = "app-202607010000-0001" url = f"http://spark-history-server:18080/api/v1/applications/{app_id}/stages" stages = requests.get(url).json() for stage in stages: # 统计每个 Stage 的 Task 本地性分布 locality_summary = stage.get("taskLocalitySummary", {}) print(f"Stage {stage['stageId']}: {locality_summary}") # 输出类似: {"PROCESS_LOCAL": 800, "NODE_LOCAL": 150, "ANY": 50}

4.4 常见误区

1. 过度增大 locality.wait：等太久不分配 Task，Executor 空闲浪费资源。对于短 Task（< 10秒），等待时间不应超过 Task 执行时间
2. 盲目追求 PROCESS_LOCAL：对于只读一次的数据，persist 的成本（内存占用 + 序列化）可能比网络传输还高。只在数据被多次使用时才缓存
3. 忽略数据重分布：repartition()和coalesce()会改变数据分布，可能导致本地性降级。合并小分区时用coalesce()（避免 shuffle），重分区时才用repartition()

五、总结

Spark 数据本地性优化的核心思路是"计算向数据靠拢"。PROCESS_LOCAL 是最优级别，通过内存缓存实现零拷贝数据访问，但它依赖内存稳定性；NODE_LOCAL 是可靠基线，通过同节点磁盘访问避免网络开销。调优的关键不是一味追求 PROCESS_LOCAL，而是在资源利用率和本地性级别之间找到平衡：合理使用 persist 提高缓存命中率，配置 locality.wait 争取更好的本地性但不过度等待，监控 Spark UI 的本地性统计及时发现问题。记住，调优是持续迭代的过程——每次作业跑完都看看 Task Locality Summary，不断调整配置直到 PROCESS_LOCAL + NODE_LOCAL 占比稳定在 80% 以上。