Spark重分区写入Parquet后目标文件夹体积增大近3倍的原因分析

结合你提供的信息，体积增大主要由以下几个因素导致：

• 行组大小差异影响压缩效率
  Parquet的压缩效果高度依赖行组（Row Group）的大小。Hive通过insertInto写入的Parquet文件通常会生成大尺寸的行组（Hive默认parquet.block.size为128MB），单个大行组能让Snappy压缩算法找到更多重复数据模式，压缩比更高。而Spark重分区后写入时，每个Task处理的数据量可能远小于默认行组大小，导致生成多个小行组（你观察到目标文件有6个行组）。小行组的压缩效率远低于大行组，直接导致文件体积膨胀。

• Schema序列化方式差异
  原文件使用hive_schema，目标文件使用spark_schema，两者对Parquet元数据的序列化逻辑存在差异：

  • Hive的Schema更精简，仅保留必要的字段信息；
  • Spark的Schema会额外携带一些Spark特有的元数据（比如字段的扩展属性、类型的精细标记），这会增加Parquet文件的元数据体积，虽占比不大，但也是体积增长的辅助因素。

• 数据分布变化降低压缩比
  Hive写入Hive表时，数据通常会按表的分区键或分桶键有序排列，相同特征的数据集中在一起，进一步提升了压缩效率。而Spark重分区操作会打乱原有数据的分布，数据变得随机分散，Snappy压缩无法找到足够多的重复模式，压缩比自然下降。

• 小文件的元数据开销
  目标文件生成了6个行组，对应多个小行组（或拆分的小文件），每个行组都需要单独的元数据（包括文件头、Footer、列统计信息等）。相比原文件单个大行组的元数据，多个小行组的元数据总和会显著增加，这部分额外开销也会推高整体体积。

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