为何Pyarrow/Pandas导出的Parquet文件比AWS Databrew占用更多内存？

问题 #

使用Pyarrow或Pandas的to_parquet函数将Dataframe导出为Parquet文件时，发现生成的文件大小是AWS Databrew相同设置下输出文件的两倍，且输入数据完全一致。

Pyarrow代码示例：

df = df.convert_dtypes()
stream = pa.BufferOutputStream()
table = pa.Table.from_pandas(df)
pq.write_table(table, stream, compression='SNAPPY')

Pandas代码示例：

df = df.convert_dtypes()
stream = io.BytesIO()
df.to_parquet(stream, compression='snappy',engine='pyarrow', index=False)

已确认Dataframe数据与AWS处理的数据完全一致，数据类型也匹配，但文件大小差距明显。还尝试过：

pa.compress(df, codec='snappy', memory_pool=None)

同时将to_parquet的压缩参数设为None，但生成的文件无法被AWS读取，且大小也不符合预期。

疑问：是否遗漏了某些配置？to_parquet函数是否真的执行了压缩？AWS Databrew是如何实现更小文件大小的？已知AWS相关库使用Pyarrow，因此更困惑为何无法匹配文件大小。

解答 #

1. 确认to_parquet是否执行了压缩 #

可以通过两种方式验证：

• 对比未压缩（compression=None）和压缩后的文件大小：如果启用snappy后文件明显变小，说明压缩已生效。
• 读取Parquet文件元数据查看压缩信息：

  import pyarrow.parquet as pq
  metadata = pq.read_metadata("your_file.parquet")
  print(metadata.row_group(0).column(0).compression)  # 输出应为'SNAPPY'
  

你之前用pa.compress直接压缩df的方式错误，这是对原始字节流的压缩，生成的不是标准Parquet格式，自然无法被AWS读取。

2. 可能遗漏的关键配置 #

以下配置会直接影响Parquet文件的压缩效率：

• Row Group大小调整：Pyarrow默认Row Group大小为64MB（未压缩），如果数据被分割成过小的Row Group，会降低Snappy的压缩效率。可以手动指定row_group_size参数，比如调整为128MB或256MB，匹配Databrew的默认设置：

  # Pyarrow示例
  pq.write_table(table, stream, compression='SNAPPY', row_group_size=134217728)  # 128MB
  # Pandas示例
  df.to_parquet(stream, compression='snappy', engine='pyarrow', index=False, row_group_size=134217728)
  

• 启用字典编码：Databrew可能默认对字符串列启用字典编码，而Pyarrow仅对部分场景自动启用。可以手动强制开启：

  # Pyarrow示例
  pq.write_table(table, stream, compression='SNAPPY', use_dictionary=True)
  # Pandas示例
  df.to_parquet(stream, compression='snappy', engine='pyarrow', index=False, use_dictionary=True)
  

  也可以针对特定列配置：column_encoding={"string_col": "dictionary"}
• 精细调整数据类型：即使整体类型匹配，也可能存在精度冗余，比如将int64转为int32（如果数据范围允许）、将float64转为float32，缩小原始数据体积后压缩效率会更高。

3. AWS Databrew实现更小文件的原因 #

Databrew基于Pyarrow但做了更多默认优化：

• 自动根据数据量调整Row Group大小，确保每个Row Group的大小适合Snappy压缩；
• 默认对所有适合的列启用字典编码、比特打包（Bit-Packing）等Parquet高级编码特性；
• 导出前自动做隐形的类型优化，比如将空值占比高的列转为更紧凑的存储类型，合并重复字典项；
• 可能采用了文件分块并行压缩的策略，进一步优化压缩效果。

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