PySpark文件合并后目录体积增大，求原因及解决办法

原因分析 #

• Snappy压缩率依赖数据局部性：Snappy的压缩效率高度依赖数据重复度。原1431个小文件大概率按业务逻辑或写入规则生成，同文件内数据特征相似、重复度高，压缩率好；repartition会全局洗牌数据，相同特征的数据被分散到不同分区，重复度下降，压缩率降低，最终文件总体积上升。
• Parquet字典编码效率降低：原文件写入时，每个小文件会针对列数据生成专属字典编码，适配局部数据的基数分布。repartition后重新写入，Spark会为新分区重新生成字典，若新分区内列的基数分布更分散，字典编码的压缩效率会大幅下降，导致文件体积变大。
• Row Group大小不合理：Parquet的Row Group是压缩和读取的基本单元，原文件的Row Group大小可能经过优化（比如适配Snappy最优压缩区间），repartition后写入时，Spark默认的Row Group大小可能与原文件不匹配，过大或过小都会影响压缩效果。

解决方法 #

• 优先使用coalesce替代repartition：如果只是单纯减少文件数，coalesce不会打乱现有分区的数据分布，只是将多个分区的数据合并到一个分区写入，能最大程度保留原数据的局部性，压缩率与原文件接近。注意coalesce仅支持减少分区数，无法增加。
• 精准控制Parquet写入参数：
  • 设置spark.sql.parquet.rowGroupSize为128MB-256MB（Snappy压缩的最优区间），确保每个Row Group的大小适配压缩算法；
  • 显式启用spark.sql.parquet.enableDictionary=true，强制保留字典编码优化；
  • 确认spark.sql.parquet.compression.codec=snappy，避免因参数缺失导致未启用压缩。
• 基于原有分区键合并：如果原数据有天然分区（如日期、业务ID），先按分区读取数据，再在每个分区内执行coalesce合并。这样既能减少文件数，又能保留每个分区内的数据局部性，压缩率不会明显下降。
• 避免全局随机repartition：若必须调整分区，改用repartitionByRange或基于原文件的分区列进行repartition，让新分区的数据分布尽可能接近原文件，维持较高的重复度和压缩率。

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