删除Parquet数据后文件体积反而增大，原因何在？

这问题我之前处理类似场景时碰到过，确实有点反直觉，但背后其实有几个常见原因，咱们一步步拆解：

1. 压缩效率因数据分布/写入配置下降 #

原Parquet文件是ETL流程生成的，大概率做了针对性优化：比如按主键排序让重复值集中、设置了合适的块大小（Block Size）和页大小（Page Size）。而你去重后重新写入时，很可能没沿用这些配置：

• 如果去重后的数据没有按原规则排序，原本集中的重复值被打乱，压缩算法（比如Snappy、Gzip）没法高效识别重复模式，压缩率会大幅下降。
• 若写入时用了默认的小块大小，每个块内的数据重复度变低，哪怕总行数减少，每个块的压缩效果差，整体体积反而上涨。

2. 元数据开销占比提升 #

Parquet文件的元数据（Footer、Column Chunks、Page Index等）是固定开销。如果原ETL生成的是少量大文件，元数据占比极低；但去重后如果生成了大量小文件（比如并行写入时分区不合理、写入阈值设得太小），每个小文件都要带一套完整的元数据，总开销加起来可能抵消甚至超过数据减少的部分，导致整体体积变大。

3. 编码方式或数据类型的变化 #

原ETL流程可能给某些列启用了高效编码（比如RLE游程编码、Dictionary编码）：

• 比如某个重复率极高的列，原文件用Dictionary编码只存一份值+索引，去重后如果该列基数变高，写入工具可能自动切换成Plain编码，单条记录的存储体积直接变大。
• 要是你的去重代码没有显式指定编码方式，默认的编码效率可能远低于原文件的配置。

针对你的疑问的解答： #

• 压缩机制未生效？：不是未生效，而是压缩效率大幅降低，这完全是可能的，核心原因就是数据分布和写入配置变了，压缩算法没法发挥原本的作用。
• 去重逻辑有漏洞？：虽然可能性低，但可以快速验证：用parquet-tools rowcount命令（或Spark/Pandas的count方法）统计原文件和去重后文件的总行数。如果行数确实明显减少但体积变大，基本可以排除逻辑问题；如果行数没变化，那肯定要排查去重的判断条件（比如是不是漏了某些隐藏的差异列，比如毫秒级时间戳、带空格差异的字符串）。

建议的排查/修复步骤： #

• 先确认去重效果：抽样对比原文件和新文件的重复行，统计总行数差异。
• 对比元数据：用parquet-tools inspect查看原文件和新文件的块大小、编码方式、压缩算法，确保新写入时沿用相同配置。
• 优化写入策略：按原文件的列排序后再写入，设置相同的Block Size/Page Size，显式启用原有的编码和压缩算法。
• 合并小文件：如果生成了大量小文件，用coalesce（Spark）或df.to_parquet(engine='pyarrow', row_group_size=xxx)（Pandas）合并成少量大文件，降低元数据开销。

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