PyArrow Parquet往返读写后列nbytes不一致问题咨询

复现代码 #

import numpy as np
import pandas as pd
import pyarrow as pa
import pyarrow.parquet as pq

table = pa.Table.from_pandas(pd.DataFrame(data={'a':np.arange(100)}))

with open('example.parquet', 'wb') as f:
    pq.write_table(table, f) 

with open('example.parquet', 'rb') as ff:
    read_table = pq.read_table(ff)

执行结果 #

• 原表table输出：

pyarrow.Table
a: int64
----
a: [[0,1,2,3,4,...,95,96,97,98,99]]

• 读取后的表read_table输出：

pyarrow.Table
a: int64
----
a: [[0,1,2,3,4,...,95,96,97,98,99]]

异常现象 #

两张表及其Schema对比完全相等，但：

• table['a'].nbytes结果为800
• read_table['a'].nbytes结果为813

背景需求：需要计算PyArrow表的哈希值，且该哈希值在Parquet往返读写后需保持稳定。

差异原因 #

nbytes的差异源于PyArrow内存布局的细微区别：

1. 原表的列从Pandas转换而来，内存是连续的原生数组，100个int64元素正好是100*8=800字节。
2. 从Parquet读取后的列，会携带额外的内部元数据开销——比如Parquet读写过程中引入的页头、填充字节，或是PyArrow为兼容Parquet存储格式添加的辅助结构，这些额外字节让总nbytes变为813，但实际业务数据完全一致。

nbytes统计的是PyArrow列对象在内存中的总占用量，不止包含原始业务数据，还包含内部管理元数据，因此会出现这种看似矛盾的结果。

哈希稳定的解决方案 #

要让哈希值在读写后保持稳定，不能直接基于整个列对象的内存计算哈希，需基于原始业务数据的字节流来计算：

方案1：转换为连续数组提取原始数据字节 #

import hashlib

def compute_table_hash(table):
    hasher = hashlib.sha256()
    for col in table.columns:
        # 将列转换为Pandas数组，提取原始数据字节
        raw_bytes = col.to_pandas().values.tobytes()
        hasher.update(raw_bytes)
    return hasher.hexdigest()

# 验证：原表与读取后的表哈希一致
print(compute_table_hash(table))
print(compute_table_hash(read_table))

方案2：使用PyArrow原生哈希计算接口（推荐） #

PyArrow提供了直接基于列数据内容的哈希计算接口，不受内存布局影响：

import hashlib
import pyarrow.compute as pc

def compute_arrow_table_hash(table):
    # 对每列计算内容哈希
    col_hashes = [pc.hash(col, hash_type="sha256").as_py() for col in table.columns]
    # 合并列哈希得到最终结果
    hasher = hashlib.sha256()
    for h in col_hashes:
        hasher.update(h.encode())
    return hasher.hexdigest()

# 验证一致性
print(compute_arrow_table_hash(table))
print(compute_arrow_table_hash(read_table))

注意事项 #

• 避免直接对PyArrow列对象的内存（如用memoryview）计算哈希，内部元数据会干扰结果。
• 如果需要严格的Schema一致性，计算哈希时需加入Schema的序列化字节（比如将table.schema序列化为字节后更新哈希）。

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