如何确定读取Delta表的Executor数量及相关配置最佳实践

第一步：先做基础数据摸底（所有配置的前提，别上来就调参数） #

• 先拿核心统计值：跑DESCRIBE DETAIL 你的表名拿到全表总大小，再按小时分区聚合统计单分区的平均大小、最大单分区大小、每个分区下的文件总数。重点记两个基准：单Task最优处理数据量固定在128MB-256MB（Delta+Spark生产环境验证过的最优区间，太小调度开销大，太大会OOM或者GC严重），全表总文件数。
• 先排查小文件问题：因为你同时跑批和流摄入，流微批默认会产生大量KB级、MB级小文件，如果没做过定期OPTIMIZE，先别算资源——小文件会导致读取时Task数虚高几十上百倍，算出来的Executor数完全不准。

Executor数量计算逻辑 #

先固定Executor的基准配置，别搞花里胡哨的参数：

• 单Executor核数固定4-8核，推荐5核，超过8核GC压力陡增，稳定性差
• 单Executor内存按核数1:4~1:6配，比如5核配20G-30G，预留20%内存给堆外、系统开销，不要全部分给堆内
• Spark基础调度逻辑是1核同一时间跑1个Task，基于这个算总需求：

1. 理想状态（表已经做过OPTIMIZE，文件大小均匀在128-256MB）：总Task数 = 全表总容量 / 256MB。比如全表10TB，总Task数就是1010241024/256 = 40960。
2. 未做OPTIMIZE的小文件场景：总Task数 = 全表总文件数，这种情况强烈建议先对全表（至少是最近3个月的分区）跑一次OPTIMIZE，合并小文件后再重新算，不然资源浪费率能到90%以上。
3. 结合任务SLA反推Executor数：普通SSD存储下，单Task处理256MB数据平均耗时1-3分钟，5核Executor每小时大概能跑100-150个Task。如果要求全表扫描任务2小时跑完，需要的Executor数就是 总Task数 /（单Executor每小时处理Task数 * 2）* 1.2（预留20%冗余给重试、倾斜）。举个例子：10TB表总Task数40960，2小时跑完需要的Executor数就是 40960/(120*2)*1.2 ≈ 205个，按200-220个申请就行。

注意：不要一开始就按计算值拉满资源，先按70%的量跑第一次任务，看Spark UI的Stage执行情况再微调，避免资源浪费。

配套参数配置（别完全依赖自动扩缩容） #

自动扩缩容只能按Task pending数调Executor数量，解决不了分区不合理、Shuffle倾斜、小文件的问题，必须配合以下参数：

• 动态扩缩容兜底配置：
  • 全表大任务不要直接用默认动态分配配置，设置spark.dynamicAllocation.minExecutors为计算值的30%，spark.dynamicAllocation.maxExecutors为计算值的120%，spark.dynamicAllocation.executorIdleTimeout设为60s，避免Executor空转占资源，也不会因为资源上限卡任务。
• Shuffle核心参数：
  • spark.sql.shuffle.partitions不要用默认的200，按Shuffle阶段总数据量算，保持单Shuffle分区大小在128MB-256MB区间就行。比如Shuffle总数据量2TB，这个值就设为210241024/256=8192。
  • spark.sql.files.maxPartitionBytes设为268435456（即256MB），控制读取阶段的分片大小，自动合并过小的文件分片，避免读取时Task数虚高。
  • 强制开AQE自适应执行：spark.sql.adaptive.enabled=true、spark.sql.adaptive.skewJoin.enabled=true、spark.sql.adaptive.coalescePartitions.enabled=true，运行时自动合并过小的Shuffle分区、拆分倾斜分区，比手动调固定参数适配性好很多。
• Delta专属配置：
  • 开spark.delta.optimizeWrite.enabled=true，如果全表读取后需要写回Delta表，自动优化输出文件大小，减少后续小文件堆积。
  • 保持spark.delta.partitionPruning.enabled=true，哪怕读全表也能减少不必要的元数据扫描，尤其是多分区键的表，元数据扫描的开销不可忽略。

生产落地注意事项 #

• 不用每天调资源：持续写入的表按周更新一次分区大小、文件数统计，调整一次资源基线就行，不用每次跑任务都重新算。
• 定期维护表：按天对前一天的小时分区跑OPTIMIZE合并小文件，定期执行VACUUM清理过期版本文件，从根源上减少读取时的无效开销。
• 错峰跑全表任务：全表扫描尽量和实时流写入、核心批任务错峰，避免IO、CPU资源抢占导致两边任务都变慢。
• 优先处理倾斜再加资源：如果Spark UI里看到90%的Task都在2分钟内跑完，剩下10%的Task跑10分钟以上，就是数据倾斜，先拆分倾斜key、调整Join逻辑，再考虑加Executor——倾斜不解决，加再多Executor也会被慢Task拖死，资源利用率极低。

内容的提问来源于stack exchange，提问作者Sadhna Jain