Spark性能优化实战：从诊断、内存模型到SQL调优与集群规划

1. 先别急着调参把Spark的运行状态看明白再说做Spark优化这几年我最深的感受是大多数Spark程序慢不是慢在代码本身而是慢在你根本不知道它把时间花在哪了。我见过不少同事一上来就改spark.executor.memory、加spark.default.parallelism改完跑一遍发现没多少变化然后又改回去白白折腾半天。Spark优化第一步不是调参数而是做诊断。Spark自带的监控体系其实已经非常完善只是很多人没有充分利用。你至少要知道作业卡在哪个Stage、哪个Task是数据倾斜还是资源不足是GC频繁还是网络 shuffle 太大这些信息全在 Spark UI 和日志里躺着就看你有没有去看。1.1 用好Spark UI先定位瓶颈再动手Spark UI 是优化的第一现场。提交作业后访问http://driver节点:4040你能看到完整的作业执行链路。我最常用的几个面板Jobs 面板看整体作业的耗时分布哪个 Job 最久一眼就能看出来。Stages 面板核心中的核心。看每个 Stage 的 Shuffle Read/Write 量、Task 的运行时间分布、GC 时间占比。如果某个 Stage 的 Task 运行时间呈两极分化——大部分几十毫秒个别几十秒甚至几分钟那大概率是数据倾斜。Storage 面板看 RDD 缓存和广播变量的实际占用内存判断缓存策略是否合理。Executors 面板看每个 Executor 的运行时间、GC 时间、活跃 Task 数。如果某个 Executor 长时间忙碌别的 Executor 闲着也是倾斜或者分配不均的信号。SQL 面板Spark 2.0 以后执行 Spark SQL 会自动生成物理执行计划图能看清楚每一个算子的耗时这是做 SQL 优化最直接的抓手。1.2 采集真实指标内存线程监测与日志分析光看 UI 还不够遇到线上问题特别是内存问题UI 上的数据往往滞后或者不够细。我习惯把 Event Log 打开用spark.eventLog.enabledtrue持久化记录配合 History Server 做离线分析。这样即使作业跑挂了事后依然能把各个 Stage 的内存使用情况翻出来复盘。在需要更细粒度观测的场景下我会用 jstat 看 JVM 的堆内存和 GC 情况jstat -gcutil pid 1000一秒刷新一次观察 Eden、Old 区占用和 Full GC 次数。做 Spark 优化要记住一个原则不能只看 Spark 层面的参数还要看 JVM 运行时的真实表现。很多 Executor 的 OOM其实是 JVM 老年代被撑爆而你在 Spark 参数里怎么调都调不对因为问题根本不在那一层。另一个容易被忽略的是线程维度。Executor 内部本质是线程池在执行任务如果一个 Executor 上同时跑的 Task 太多线程间频繁切换上下文CPU 利用率虚高实际吞吐反而下降。通过jstack抓线程快照你可以看到哪些线程长时间处于RUNNABLE哪些在BLOCKED这能辅助判断 Executor 核心数设置是否合理。1.3 指标采样案例一次典型的长尾 Job举个例子。之前我处理过一个数据分析任务每天凌晨跑平均要 40 分钟。打开 Spark UI 后发现是一个 Shuffle 量极大的 Join Stage 拖慢了整体进度Stage 里 200 个 Task其中 180 个 10 秒内跑完剩下 20 个要跑 5 分钟以上。再看数据分布发现 join key 里有大量空值和一个高频的热点 key。这就是典型的数据倾斜和内存参数没有半点关系。后来我把空值 key 做了随机前缀打散热点 key 拆分成子查询单独处理整个 Job 从 40 分钟降到了 11 分钟——这不是调出来的是看出来的。所以Spark优化的第一课永远是先把自己变成能看到问题的人。后面所有参数调整、代码重写都是建立在诊断结论之上的针对性动作而不是盲试。2. 内存模型与执行模型优化前必须建立的核心认知很多Spark优化文章一上来就列参数spark.executor.memory给多少、spark.executor.cores给多少但你要是不理解Spark内存到底怎么划分的这些参数只会害了你。讲一个真实的事故某团队把spark.executor.memory从 8G 调到 16G结果 OOM 更频繁了。原因很简单他们以为内存越多越好却忽略了 JVM 堆内内存还要拆分出 execution 和 storage 两部分默认两者是统一管理、互相抢占的关系。2.1 Spark 内存到底怎么分的Spark 3.0 之后的内存模型核心是spark.memory.fraction和spark.memory.storageFraction这两个参数。Executor 的总堆内存里要先留出一部分给 JVM 自身字符串常量池、代码缓存、Native 内存等剩下的才进入 Unified Memory 统一管理区。统一区内execution 内存用于 shuffle、join、aggregation 等计算和 storage 内存用于 RDD 缓存、广播变量可以互相借用但有底线——storage 至少保留storageFraction的份额不被 execution 抢走。理解这个模型后你会发现很多所谓的内存不足其实不是物理内存不够而是 execution 和 storage 的配比出了问题。比如你把 broadcast 变量做得巨大storage 内存吃紧会反过来挤压 execution 的执行空间导致频繁 spill 甚至 OOM。反过来如果某个任务大量占用 execution 内存做排序聚合RDD 缓存就会被挤掉重新计算反而更慢。2.2 Executor 内存参数怎么设才靠谱从我的实操经验来看内存设置要考虑三个层面单个 Executor 的总内存。这个取决于单节点物理内存总量和你想在一台机器上起几个 Executor。以 64G 内存的 Worker 节点为例如果打算每个节点起 4 个 Executor那单个 Executor 堆内存控制在 12G~14G 比较稳妥剩下留给操作系统和 Page Cache。不要试图把 64G 全分出去JVM 堆太大时 GC 停顿非常要命。堆内和堆外。如果用了spark.memory.offHeap.enabledtrue堆外内存也会参与统一内存管理但这块主要适合对 GC 极度敏感的场景。普通任务慎用堆外内存的管理和排查成本更高出了问题很难从 UI 上直接看到。和 Executor 数量的平衡。我见过一个典型配置spark.executor.memory8G、spark.executor.cores4。单看觉得还行但仔细算一下会发现一个 8G 堆的 Executor 最多同时跑 4 个 Task每个 Task 分到的内存其实很有限。大 shuffle 场景下Reduce 端 Task 需要把整个 key 的聚合数据放进内存内存不够就开始 spill。这时候与其加内存不如降低单 Executor 的 core 数让每个 Task 分到的内存更充足。举个我常用的估算方法如果单条 Shuffle 记录平均 1KB一个 reduce Task 需要聚合 500 万条记录那至少需要 5GB 内存做聚合缓冲。如果 Executor 堆内存 8G4 个 Task 并发每个 Task 只分到 2G 可用必然严重 spill。这时把 Executor 改为 2 核单 Executor 内存保持 8G每个 Task 分到 4G情况大幅改善。2.3 序列化与内存释放容易被忽略的隐形杀手内存优化里序列化方式是一个性价比极高的调整点。默认的 Java 序列化性能差、体积大换成 Kryo 之后数据体积能缩小到原来的 1/5 到 1/10序列化时间也大幅缩短。特别是 Shuffle 数据量大或者 RDD 需要缓存到 Storage 时效果非常明显。但 Kryo 有一个容易踩的坑需要提前注册类。spark.kryo.registrator配置不好时会遇到ClassNotFoundException或者序列化失败。我的建议是在开发环境就先配置好spark.kryo.registrationRequiredtrue这样任何未注册的类都会直接报错逼你提前把注册表补齐而不是等上线跑挂了再排查。还有一个容易被忽略的点是spark.cleaner.periodicGC.interval。这个参数控制 PeriodiGCleaner 定期清理无引用的 shuffle 数据和 RDD 缓存。默认周期比较长如果你发现 Executor 内存占用一直下不来、GC 频繁可以适当调短这个周期。但这属于治标手段更根本的还是要看是不是有 RDD 一直占着 Storage 内存没有被 unpersist。2.4 数据倾斜的底层判断不是所有长尾都是倾斜回到上一章说的数据倾斜。我的判断标准是看 Task 的运行时间分布和数据处理量的分布是否正相关。如果某个 Task 运行的久但 Shuffle Read 只有几十 KB那可能是这个 Task 分配到了 CPU 资源少的 Executor 上或者是机器本身负载高不一定是数据倾斜。如果 Shuffle Read 是几 GB而别的 Task 只有几 KB那才是真正的倾斜。判断清楚之后常见的处理方案有这么几种空值或者异常 key 打散对 null key 或者像空字符串这种高频 key添加随机前缀让它们分散到不同的 Task。热点 key 拆解把热点 key 单独拎出来和广播变量做 map join不和普通数据走同一个 shuffle join。两阶段聚合加盐 聚合一次再去盐 聚合一次。适合 group by 场景但不适合 join。广播小表如果 join 的另一边不大比如几百 MB直接广播直接从根上消除 shuffle。倾斜处理是我在Spark优化里觉得最像医生的工作先确诊再开药每个方案都有自己的适用范围没有万能药。3. 慢 Spark SQL、日期处理与 Join 反向广播几个高频排查场景Spark 做离线数据处理日常写的最多的就是 Spark SQL。可恰恰是这些看起来简单的 SQL在数据量上来后会出现各种慢查询。下面我挑几个热搜词里出现率最高的场景用实际排查链路来讲怎么处理。3.1 Spark SQL 日期加减与日期转月一个隐形的性能坑热搜词里出现了spark sql 日期加 年、spark sql 日期加减、spark sql 日期转存月份。这几个看着简单但日期处理的写法会直接影响过滤条件下推和分区裁剪。举个最常见的反例-- 不推荐的写法在分区字段上做函数运算 SELECT * FROM orders WHERE year(order_date) 2024 AND month(order_date) 11这种写法的问题在于year()和month()函数包住了分区字段order_dateSpark 无法直接把条件转换成分区过滤会扫描该表的所有分区再逐行做函数计算。如果表有几百个分区扫描量直接放大。正确写法是用日期区间-- 推荐的写法直接构造日期上下界 SELECT * FROM orders WHERE order_date 2024-11-01 AND order_date 2024-12-01这样 Spark 可以直接裁剪出 11 月这一个分区来读。别小看这个改动我在实际项目里遇到过同样一个报表 SQL改成区间写法后执行时间从 25 分钟降到 4 分钟差别就是分区裁剪。日期转换还有一个常见场景是把时间戳转成月份字符串做分组SELECT date_format(order_time, yyyy-MM) AS month, count(*) FROM orders GROUP BY date_format(order_time, yyyy-MM)如果order_time本身是字符串类型date_format需要先做类型推断耗时更高。建议在写入时就冗余一列月份字段或者在 SQL 里先用cast转成 timestamp 类型再格式化。日期函数在小表上无所谓大表上每一层函数转换都是几百万甚至上亿次的计算。3.2 Left Outer Join 为什么只能广播右侧热搜词里有一条很具体spark 对 left outer join 只能广播右侧。这条值得展开说因为很多人踩过坑。Spark 在做 Broadcast Hash Join 时有个规则如果是left outer join只能广播右表如果是right outer join只能广播左表。核心原因在于 outer join 的语义——Left Outer Join 要保留左表的所有记录所以左表不能被广播后分别处理否则每个 Executor 上的左表数据不完整无法生成完整的左表全集。右表则可以广播到每个 Executor因为右表只是用来查缺补漏的。这也意味着如果你的 SQL 是一个大表left join一个小表小表应该写在右侧。写反了则 Spark 只能走 Sort Merge Join会引入一次全量 shuffle代价很大。具体到写法-- 推荐小表在右侧 SELECT /* BROADCAST(d) */ l.*, d.dep_name FROM large_orders l LEFT JOIN dim_department d ON l.dept_id d.id如果确实需要把小表放在左侧利用子查询先把大表缩小再和小表做 left join 也是一种思路。不过最省心的方式还是记住这句规则写 left join 时把大表放左边小表放右边顺手加个 BROADCAST hint。3.3 Hive 小文件问题为什么会在 Spark SQL 里爆发热搜词里有hive优化小文件。其实小文件问题在 Spark SQL 里也极其常见特别是用INSERT OVERWRITE写结果表时如果 Spark 生成的分区很多、每个分区的数据量又不大很容易落出大量小于 128MB 的碎文件。小文件的危害主要体现在三个层面一是写 NameNode 的压力变大元数据膨胀二是下游读取时每个小文件都需要单独打开文件流Task 数量暴增调度开销比计算本身还大三是如果文件格式是 Parquet每个小文件的 footer 都要单独解析扫描效率低。处理方案分事前和事后事前用coalesce()或者repartition()控制输出文件数。例如df.repartition(20).write.mode(overwrite).parquet(path)repartition(20)会触发一次 shuffle按照 Hash 分区把数据分配到 20 个分区文件。如果数据本来就在一个 Stage 中用coalesce(20)不触发 shuffle效率更高。事后如果文件已经写出来了可以用 Spark 读一遍再合并写回。有些场景我会用 Hive 的ALTER TABLE ... CONCATENATE合并 ORC 小文件比 Spark 重新跑一遍快得多。这招只对 ORC 格式有效Parquet 格式没有类似的命令行工具只能读写重写。3.4 并行的慢 SQL从并行度说起并行 SQL 优化是另一个高频的热搜词。Spark SQL 里并行度主要由两个参数控制spark.sql.shuffle.partitions和spark.default.parallelism。前者决定 Shuffle 后的分区数后者决定 RDD 操作和未经过 Shuffle 的 Stage 的默认分区数。很多人的误区是把spark.sql.shuffle.partitions设置成一个固定值就不管了。实际上这个值应该根据数据量动态调整。经验公式目标分区数约等于 单分区 128MB~256MB 数据量。比如 Shuffle 数据总量 20GB目标分区数可以设为 80~160 之间。设太小每个 Task 处理的数据量过大容易 OOM设太大Task 数量过多调度和序列化开销占比升高。在代码里动态设置是一个更精细的做法df df.repartition(800, user_id) # 按 user_id 的 800 个分区这个例子是显式控制分区数尤其适合下游需要按 key 对齐的场景。但要注意repartition本身也是一次 shuffle不要随意用。能通过spark.sql.shuffle.partitions解决的就不要手动 repartition。4. 集群搭建与资源规划在部署阶段就把优化做在前面前面大部分讲的是代码和参数层面的调优但还有一个更前置的优化点是很多项目容易忽视的集群搭建时就把 Spark 的运行机制映射到物理资源上。热搜词里spark集群搭建、spark环境搭建及wordcount、spark的安装与使用热度都很高说明很多人还在从零搭环境。如果这一步的基础参数没定好后面怎么调代码都是隔靴搔痒。4.1 从单机到集群先理解三种部署形态的差异Spark 支持 Local、Standalone、YARN、Kubernetes 几种部署模式实际干活时最常用的还是 YARN 和 StandaloneKubernetes 在云原生场景下越来越多。本地模式Local[N]适合开发调试和单元测试spark.masterlocal[4]表示本机开 4 个线程模拟分布式。很多初学者上来就在这种模式下调参数调出来的结果根本无法反映生产情况。本地模式的资源是伪分布式Executor 只是线程模拟shuffle 也在本地完成IO 模式和生产完全不一样。Standalone 模式走的是 Spark 自带的 Master/Worker 调度搭建相对简单适合中小团队。要点是两个一是确保SPARK_WORKER_CORES和SPARK_WORKER_MEMORY配置合理二是 Master 的高可用要配置 ZooKeeper否则 Master 挂了整个集群不能用。YARN 模式则把资源管理交给 Hadoop YARNSpark 作为一个应用提交到 YARN 上运行。在 YARN 模式下spark.executor.memory是申请给 Executor 的但还需要注意spark.yarn.executor.memoryOverhead这部分是为堆外内存、JVM 开销等预留的。默认值是 executor 内存的 10%如果 Executor 给的很大比如 16G 以上10% 对应的 overhead 往往不够推荐显式设置为 2G 或更高。4.2 一个合理的集群资源配置示例假设你有 10 台物理机每台 128G 内存、32 核 CPU。目标是为一个每天处理 500GB 到 1TB 数据的离线数仓服务。单从资源总量来看10 台机器很富余。但要考虑 Spark 作业的并发度、内存需求以及可能同时跑多套作业。我的设计思路是这样的配置项推荐值理由spark.executor.memory16G单 Executor 内存过大时 GC 长停顿16G 是兼顾数据量和 GC 的折中spark.executor.cores4每 Executor 4 个 Task 并发避免线程竞争导致 CPU 浪费spark.executor.instances按作业需求如无特殊需求起步设为 20观察后再调spark.sql.shuffle.partitions400~800按单分区 128MB~256MB 估算spark.memory.fraction0.8保留 20% JVM 内部开销稳定优先spark.driver.memory4GDriver 不参与大量计算4G 足够大多数场景spark.yarn.executor.memoryOverhead2G显式预留堆外开销不过要说明的是这只是一个基线模板。不同业务形态差异很大数仓 ETL 场景shuffle 量大execution 内存要充足服务化查询场景SQL 比较复杂但数据集不大反而要把广播阈值调高一点多走 Broadcast Join。最忌讳的就是一套参数打天下。4.3 POC概念验证阶段的优化验证方法在集群刚刚搭好还没有正式数据跑之前我建议先做一次 POC。构建一张足够大的测试表比如 10 亿行跑几个典型查询和清洗任务记录下作业总耗时、每个 Stage 的耗时、Shuffle 数据量、GC 时间、Task 运行分布。然后针对性地修改参数再跑一遍做对比。这比上线后再调参要稳妥得多。POC 阶段最容易暴露的坑有三个网络带宽瓶颈、磁盘 IO 瓶颈和 NameNode 压力。这些在单机开发环境根本看不出来只有真正的分布式集群里才会显现。比如 Shuffle 数据量很大时磁盘 IO 会成为瓶颈这时可以考虑把spark.local.dir指向多块磁盘分散 IO 压力。这是代码优化做不到的必须在集群规划阶段解决。4.4 单机部署的坑DGX、小集群也要有内存章法热搜词里有dgx spark 单机部署和dgx spark 部署。单机部署 Spark 主要出现在 GPU 服务器和研究场景里资源很充足但单机集群也有它自己的问题——所有 Executor 都在一台物理机上内存、CPU、网络都共享处理不当会互相干扰。单机部署我建议适当减少 Executor 数量增加单 Executor 的资源量。比如一台 512G 内存的机器与其开 20 个 16G 的 Executor不如开 8 个 32G 的 Executor减少 Executor 之间的调度竞争和网络复制开销。当然了还是要看 JVM GC 的表现如果 Old 区持续增长说明还是得降低单 Executor 内存换更多的 Executor 来分摊。部署时还有一个容易被忽略的点是SPARK_LOCAL_IP环境变量。单机多网卡或者使用容器网络时如果 Spark 绑定的 IP 不通作业可能一直卡在注册阶段。这个坑遇到一次就印象深刻。5. 两个真实的 Spark 优化复盘从清洗到分析的全流程实战刚好对应热搜词里的网约车大数据综合项目——基于spark的数据清洗、农产品价格数据分析-spark这类场景。我挑两个有代表性的项目复盘把前面讲的理论串在一起。5.1 网约车订单数据清洗核心在内存与串行化优化网约车订单数据有个特点单条记录字段多、格式杂、还有大量嵌套 JSON。比如司机的轨迹信息、乘客的上下车位置、订单的状态流转经常混在一个 JSON 字段里。数据清洗阶段的核心操作是解析 JSON、过滤异常值、补充地理维度信息、写出到数仓。这个项目里我踩过最大的坑是对 DataFrame 做了过多的 UDF 转换。原始的 JSON 解析逻辑用 Python UDF 写处理几十万条没问题但数据量到亿级时Python UDF 和 JVM 之间来回序列化的开销完全把计算时间拖垮了。优化顺序是这样第一步把 Python UDF 换成 Spark SQL 内置函数。用get_json_object()或者from_json()函数处理 JSON 字段这些函数运行在 JVM 内部没有序列化开销。同样的逻辑用 Python UDF 要把整个 Row 对象序列化到 Python 进程处理完再序列化回 JVM一条记录的成本可能是 SQL 内置函数的几十倍。第二步是裁剪字段。别把原始订单里所有字段都保留。数仓里真正用于分析的字段只有 20% 不到其余都是冗余。我在清洗阶段就把字段列表从 80 个缩减到 28 个Shuffle 和落盘的数据量直接下降整体耗时又缩短了一截。第三步是配置 Kryo 序列化。这个项目的中间 RDD 需要多次复用Java 序列化在亿级数据上的开销很明显换成 Kryo 后缓存 RDD 的存储空间少了一半多。清洗任务的最终效果处理 1 亿条订单数据从原来的 55 分钟降到 18 分钟。其中最显著的优化是 Python UDF 换内置函数单这一项就省了一半时间。5.2 农产品价格数据分析核心在 SQL 优化与数据倾斜治理农产品价格数据是典型的多维分析场景。数据本身不大一天几百万条记录但是分析任务里 join 很多维度表产地表、品种表、市场表、时间维度表。维度表不大但事实表数据分散度高偶尔会有单日价格波动极大的热点记录。这个项目的第一个优化点很典型多个小维度表 join 时全部走 Broadcast Join。把所有维度表都广播出去事实表只需要一次 scan 就能拿到全部维度属性整条 SQL 的执行链路从 3 次 shuffle 变成 0 次。做法也很简单from pyspark.sql import functions as F df_fact spark.sql( SELECT /* BROADCAST(d1, d2, d3) */ f.*, d1.province, d2.category, d3.market_name FROM fact_price f LEFT JOIN dim_province d1 ON f.province_id d1.id LEFT JOIN dim_category d2 ON f.category_id d2.id LEFT JOIN dim_market d3 ON f.market_id d3.id )至于spark.sql.autoBroadcastJoinThreshold参数默认 10MB对于维度表在几十 MB 的情况可以调大到 100MB 甚至 200MB。但要谨慎广播表太大会占用 Executor 的 storage 内存挤压 execution 空间。这个项目的数据倾斜场景也有代表性。某些热门农产品猪肉、白菜这类价格记录非常多按产地分组做统计时个别 Task 压力特别大。我的处理是把倾斜 key 加随机后缀拆开df_grouped df.repartition(1000, province_id).groupBy(province_id)repartition(1000, province_id)会让热点 key 分布到更多的分区然后再做聚合压力就平摊开了。需要注意这里如果只是groupBy(province_id)Spark 默认用 hash 分区热点 key 依然会集中到一个 Task 上必须显式调整分区数。5.3 跨项目通用的优化复盘模板做完这两个项目后我给自己沉淀了一个优化复盘模板每次遇到慢任务都按这个顺序排查先看Spark UI 里哪个 Stage 最慢Task 时间分布是否均匀。再问这个 Stage 是 CPU 密集、内存密集还是 IO 密集有没有 ShuffleShuffle 量大不大后改CPU 密集看序列化和代码逻辑内存密集看并行度和内存分配IO 密集看文件格式、分区裁剪和小文件。验证改完后再跑一遍对比前后各 Stage 的耗时和 Resource 用量确认改动有效再继续下一项。这套模板不依赖具体业务几乎适用于所有 Spark 任务。优化不是一次性的每次数据量涨一个量级之前的很多合理参数都会变得不合理重新按这个模板走一遍比翻旧账有效得多。6. 几个写在最后的实操心得讲了这么多最后想分享几个比较个人化的经验都是踩坑踩出来的。第一个是关于默认值的警惕。Spark 的默认参数在生产环境面前只是一个起点不是推荐值。比如默认的spark.sql.shuffle.partitions200在小数据量时很好用但数据一涨就明显不够。任何参数都不存在最优点只有最适合你这个业务当前数据量的值。第二个是不要一次性改多个参数。我在代码 review 时经常看到一次 commit 里同时改了六七个 Spark 参数然后说作业快了。可到底是哪个参数起的作用不知道。下次数据量变了需要调回去也不知道调哪个。正确的做法是一次只验证一个变量改完跑一次作业记录对比数据再改下一个。第三个是关于小文件治理和分区设计的。海量小文件对 Spark 的伤害往往不是第一个作业暴露出来的而是下游第一个读它的作业暴露出来的。所以在写表时就要规划好分区的粒度和文件大小。分区太细比如按小时分区每天 24 个分区一个月 720 个分区多数分区数据量很小文件碎片化严重。我一般会结合查询模式决定如果只会按天或者按月查分区就按天建不要更细。第四个是监控一定要持续。Spark UI 只能看到已经结束的作业如果一个任务跑了一天中途某个 Stage 早就过去了你再回头找问题会很麻烦。建议在作业执行过程中也用脚本定期抓取当前运行 Job、Stage 的信息有问题可以提前发现。很多时候优化做得好不光是反应快还要有持续观测的机制。最后一条也是我反复和团队强调的Spark 优化不是一门玄学每一步都要有结论、有数据、有对比。你看到作业慢了先忍住改参数的冲动打开 UI 看看用 jstat 和 jstack 抓一下运行时状态把瓶颈定位到具体 Stage、具体资源维度再动手。我自己的经验是大约 70% 的 Spark 性能问题和参数无关而是和数据分布、SQL 写法、资源评估有关。把这些基本盘看好性能往往会自己好起来。