Spark SQL写入Hive动态分区时重分区类算子的效率探讨

核心前提 #

Spark SQL写入Hive动态分区表时，默认会自动根据分区列执行shuffle，目的是让同一个(part1, part2)分区的数据落到同一个Task，避免单个Task写入多个分区带来的IO开销和小文件问题。

显式操作的收益场景 #

1. 精准控制shuffle分区数 #

默认的shuffle分区数由spark.sql.shuffle.partitions控制（默认200），如果数据量不匹配这个值：

• 数据量极大时：200个分区会导致单个Task处理的数据量过大，执行缓慢。此时用/*+ REPARTITION(100, part1, part2) */（指定合适的分区数），既能按分区列分组，又能拆分大Task，提升并行度。
• 数据量极小时：200个分区会生成大量小文件，后续Hive查询性能受影响。此时指定更小的分区数（比如REPARTITION(10, part1, part2)），减少小文件数量。

2. 避免自动分区的不确定性 #

如果数据源tmp_tbl的分区分布不均匀（比如存在数据倾斜），Spark自动shuffle可能出现分区数据分布失衡的情况。显式指定DISTRIBUTE BY part1, part2或REPARTITION(part1, part2)，可以强制同一个(part1, part2)的所有数据进入同一个shuffle分区，保证后续写入时每个Task只处理一个分区的数据，避免IO资源浪费。

3. 合并shuffle操作 #

如果你的查询本身需要对part1, part2做聚合、过滤等操作，显式提前按分区列shuffle，可以让Spark将这个shuffle和写入分区所需的shuffle合并，避免重复shuffle开销。

无意义甚至有害的操作 #

• ORDER BY：全局排序会强制所有数据进入单个Task，完全违背并行写入的逻辑，性能暴跌，绝对不要用。
• SORT BY：仅在单个Task内排序，写入分区不需要数据有序，只会增加Task的排序开销，无任何收益。
• CLUSTER BY：等价于DISTRIBUTE BY + SORT BY，排序部分完全多余，徒增计算成本，不如只用DISTRIBUTE BY。
• 无参数的REPARTITION(part1, part2)或默认分区数的DISTRIBUTE BY：和Spark自动做的shuffle逻辑完全重复，不会带来任何收益，反而可能因为多一次shuffle规划的开销拖慢执行。

总结 #

• 当默认shuffle分区数不匹配数据量、存在数据倾斜，或者查询本身需要按分区列shuffle时，显式指定REPARTITION(n, part1, part2)或DISTRIBUTE BY part1, part2有明确收益。
• 当数据已经按分区列有序/分区，或者默认shuffle逻辑足够合理时，额外的显式操作只会增加复杂度和不必要的shuffle开销，完全没必要。

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