GROUP BY 易产生大量小文件,因其触发 shuffle 且 reduce task 数由 spark.sql.shuffle.partitions(默认200)决定,即使数据量小也会生成200个输出文件;动态分区和多轮 shuffle 进一步加剧该问题,需通过 repartition/N 或 AQE 自适应合并优化。

多级 GROUP BY 本身不直接产生小文件,但会触发 shuffle 并放大 spark.sql.shuffle.partitions 的副作用——如果数据量小而分区数仍为默认 200,最终写入时就会生成 200 个空或极小的输出文件。
为什么 GROUP BY 后容易冒出几百个小文件?
Spark SQL 中每个 GROUP BY(含 COUNT、SUM、AVG 等聚合)都会走 Shuffle 路径,reduce 阶段 task 数完全由 spark.sql.shuffle.partitions 决定。默认值 200 意味着:哪怕你只聚合 10MB 数据,也会硬拆成 200 个 task,每个 task 写一个文件(哪怕只有几 KB)。动态分区插入时还会叠加分区列组合,进一步放大文件数。
- 执行计划里看到多个 Exchange(如
HashAggregate→Exchange→HashAggregate),说明发生了多轮 shuffle,每轮都按同一spark.sql.shuffle.partitions值分发 - 如果中间结果已大幅缩减(例如从亿级行聚合成千行),后续 shuffle 完全没必要维持 200 分区
- Hive 表的
hive.merge.*参数对 Spark SQL 无效,不能指望写完自动合并
用 REPARTITION / COALESCE 在 INSERT 前收口分区数
最直接有效的方式,是在最终 INSERT 语句前显式控制输出分区数,把“宽而浅”的 shuffle 结果压成“窄而深”的结构。
- 优先用
repartition(N):它强制 shuffle,能真正打散并重平衡数据,适合 GROUP BY 后数据分布不均的场景 - 慎用
coalesce(N):仅适用于 N 小于当前分区数且无需重平衡的情况;若原分区倾斜严重,coalesce只是合并空分区,无法解决数据倾斜导致的部分文件为空、部分过大问题 - 示例:
spark.sql("SELECT dept, COUNT(*) FROM emp GROUP BY dept").repartition(5).write.mode('overwrite').saveAsTable('dept_agg')—— 明确限定最终只写 5 个文件
配合 AQE 自动调优 shuffle 分区数(Spark 3.0+)
开启自适应执行后,Spark 能在运行时根据实际 shuffle 输出大小动态合并小分区,比静态设 spark.sql.shuffle.partitions 更可靠。
- 必须启用:
spark.sql.adaptive.enabled=true - 关键配套项:
spark.sql.adaptive.coalescePartitions.enabled=true(默认 true,但建议显式打开) - 它会在 shuffle write 阶段检测:若某 partition 输出 spark.sql.adaptive.coalescePartitions.initialPartitionSizeInBytes),就合并相邻小分区
- 注意:AQE 不改变逻辑执行计划,所以仍需确保上游聚合结果不过于稀疏;若 GROUP BY key 极少(如全表统计单个 count),建议直接
repartition(1),别依赖 AQE 合并
避免嵌套 GROUP BY 引发的隐式多 shuffle
看似一个 SQL,但子查询 + 外层 GROUP BY 很可能触发两轮独立 shuffle,每轮都用满 200 分区。
- 反模式:
SELECT a, COUNT(*) FROM (SELECT *, ROW_NUMBER() OVER(PARTITION BY b ORDER BY c) rn FROM t) tmp WHERE rn = 1 GROUP BY a—— 窗口函数和外层 GROUP BY 各 shuffle 一次 - 优化方向:能用单次聚合完成的,别拆;窗口函数后立即过滤再聚合,考虑用
agg(expr).over(...)或提前物化中间结果 - 检查物理计划:关注
Exchange节点数量,超过 1 个就要警惕分区数被重复应用
真正要盯住的不是“GROUP BY 语法”,而是 shuffle 后的分区数是否与数据量匹配。哪怕只聚合出 10 行结果,也别让它带着 200 个 task 去写磁盘——那 190 个文件大概率是空的,还占 NameNode 元数据和 driver 内存。










