Spark中repartition(num)是否比repartition(num,col)更快？EMR分区策略咨询

一、repartition性能对比与可靠性问题 #

1. 性能差异：repartition(num)确实更快 #

• 仅指定分区数的repartition(num_of_partitions_wanted)基于数据量均匀拆分，无需对每条记录计算哈希，shuffle开销极低；
• 带'id'列的repartition(num_of_partitions_wanted, 'id')需要对每条记录计算id的哈希值，再按哈希分配分区，额外的哈希计算和shuffle逻辑会增加开销，因此速度更慢。

2. 仅指定分区数的repartition可靠性 #

• 如果数据本身分布均匀（无严重倾斜），可靠性足够，能保证各分区数据量大致相当；
• 如果数据存在严重倾斜（比如单个键占比超过50%），这种方式会继承原数据的倾斜问题，导致部分分区过大，此时可靠性不足。

3. 仅传唯一ID列分区效果差的原因 #

大概率不是哈希冲突（唯一ID的哈希分布理论上是均匀的），更可能是：

• 原DataFrame存在大量小分区，局部shuffle导致分区不均匀；
• 未指定分区数，Spark使用默认并行度（如spark.default.parallelism），默认值与数据量不匹配；
• 唯一ID生成规则有问题（比如自增ID，哈希后出现局部聚集），这种情况少见。

二、AQE配置下直接df.write能否实现均匀分区？ #

开启以下配置后，直接df.write可以实现约500MB的均匀分区，但有前提：

'spark.sql.adaptive.enabled': 'true',
'spark.sql.adaptive.coalescePartitions.enabled': 'true',
'spark.sql.adaptive.coalescePartitions.minPartitionSize': '500000000'

• AQE会自动合并小分区：当现有分区大小小于500MB时，会合并成接近该大小的分区，解决你当前KB级小分区的问题；
• 但AQE不会拆分大分区：如果原有分区本身大于500MB，还是需要先通过repartition或coalesce拆分；
• 适用于所有大小的表：MB级小表会自动合并为符合最小大小的分区，TB级大表只要原有分区不超过目标大小，就能得到均匀的500MB分区。

三、EMR写入Parquet实现均匀分区的其他策略 #

• 动态计算分区数+AQE兜底：先估算总数据大小，用总大小 / 目标分区大小得到分区数，调用repartition(计算出的分区数)，再配合AQE自动调整偏差分区。比如10TB数据，500MB/分区就是20480个分区；
• BucketBy持久化表：对于长期查询的表，使用bucketBy(num_buckets, 'id')写入Hive表，基于哈希的bucket分布稳定，还能支持查询时的bucket pruning，适合静态表；
• 自定义分区器：针对特殊数据分布（如时间序列），自定义Partitioner做范围分区，保证每个分区的时间范围对应的数据量均匀；
• EMR专属优化配置：开启spark.emr.dynamicPartitioning.enabled，配合AQE动态调整分区数；设置spark.sql.parquet.compression.codec=snappy保证压缩比稳定，避免因压缩率差异导致分区大小波动；
• 先采样再分区：对未知分布的表，先采样10%数据估算分布，根据采样结果确定分区数或分区键，再对全量数据做repartition，避免倾斜影响。

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