Spark中AQEShuffleRead分区数低于配置值的技术咨询

核心逻辑前提 #

首先明确：AQE的分区合并逻辑仅负责合并过小的分区，不会主动拆分大分区；所有配置参数中，spark.sql.adaptive.advisoryPartitionSizeInBytes是参考目标而非硬限制。结合你的现象，原因可从以下几点逐一分析：

• 建议分区大小为软约束
  spark.sql.adaptive.advisoryPartitionSizeInBytes=268435456只是AQE合并分区时的理想目标，Spark不会强制将分区大小严格控制在该值内。当数据无法均匀拆分（比如存在超大单条记录、不可拆分的文件块），或受其他参数限制时，分区大小会自然超过建议值。

• 初始分区数参数的作用误解
  spark.sql.adaptive.coalescePartitions.initialPartitionNum的实际作用是：当Shuffle输出的原始分区数超过该值时，AQE才会启动合并逻辑尝试将分区数往建议大小方向调整。如果原始Shuffle分区数本身就小于该配置值，AQE不会触发任何分区调整（因为没有过多小分区需要合并）。此时若总数据量除以原始分区数的结果大于256MB，就会出现分区超量且最终分区数低于初始配置值的情况。

  举个实例：假设initialPartitionNum=100，但Shuffle后原始分区数仅为50，总数据量15GB（单分区平均300MB）。由于原始分区数已小于配置值，AQE不会操作，最终分区数保持50，单分区大小超过256MB。

• 数据倾斜导致大分区无法处理
  若Shuffle过程中存在数据倾斜，部分分区的数据量远高于平均值，AQE的合并逻辑不会对这类大分区进行拆分（拆分倾斜分区需要单独启用spark.sql.adaptive.skewJoin.enabled等倾斜处理配置）。此时即使其他小分区被合并，倾斜的大分区依然保留，最终整体分区数可能低于initialPartitionNum，同时存在超大小分区。

• 合并分区的下限限制
  若总数据量除以建议分区大小的结果小于spark.sql.adaptive.coalescePartitions.minPartitionNum（默认值为1），Spark会强制将分区数设置为该下限值。比如总数据量300MB，建议大小256MB，计算出的目标分区数约1.17，会被取整为1，此时单分区大小直接为300MB，远超建议值，且分区数远低于initialPartitionNum。

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