为什么排序后的Parquet文件体积反而大于未排序的Parquet文件？

核心原因：排序后乱序索引被写入文件 #

你未排序的原始DataFrame使用的是pandas默认的RangeIndex，这种索引本质上只存储起始值、步长、长度三个元数据，写入Parquet时不需要逐行存储索引值，几乎不占用额外空间。
而调用sort_values()方法时，pandas默认会保留原始的行索引，排序完成后索引变为无序的整数序列，属于普通的Int64Index/Int32Index，写入Parquet时会逐行存储每个索引值，3000万行的单列索引就要占用至少120MB（32位整型）到240MB（64位整型）的空间，这是文件体积暴涨的最主要原因。

你可以通过如下代码验证，写入时关闭索引存储，或者排序后重置索引再存储：

# 方法1：写入时不保存索引
expanded_1.sort_values(by=['Point']).to_parquet('/expanded_1_sorted.parquet', index=False)

# 方法2：排序后重置索引再存储
expanded_1.sort_values(by=['Point']).reset_index(drop=True).to_parquet('/expanded_1_sorted.parquet')

修改后你会发现排序后的文件体积远小于90.2MB，符合压缩效率提升的预期。

其他可能的次要原因 #

如果关闭索引存储后体积还是不符合预期，可以排查如下问题：

• 写入引擎的压缩配置不一致：确认两次写入用的是相同的Parquet引擎（pyarrow/fastparquet）和压缩算法，默认情况下pandas的to_parquet使用Snappy压缩，但如果环境配置有差异也可能导致体积变化，显式指定压缩参数可以规避这个问题：to_parquet(path, compression='snappy')
• 字段基数过高：如果Point字段的基数（去重后的元素数量）接近总行数3000万，排序后重复数据的连续分布收益极低，反而可能因为行组划分、字典编码阈值的问题导致压缩效率略微下降，但不会出现体积翻倍的情况。
• 行组大小配置差异：两次写入时如果行组大小参数不同，会影响压缩效率，排序后的数据建议适当调大行组大小，进一步提升压缩比。

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