Parquet 格式的可重复性/确定性如何？

Question

我正在向非常熟悉 Apache Parquet 二进制布局的人寻求建议：

F(a) = b进行完全确定性的数据转换F，并使用整个软件堆栈（框架、箭头和 parquet 库）的相同版本 -每次保存到 Parquet 中时，我在不同主机上获得相同的数据帧二进制表示的可能性有多大？bb

换句话说，Parquet 在二进制级别上的可重现性如何？当数据逻辑上相同时，什么会导致二进制差异？

• 由于对齐，值之间是否可能存在一些 uninit 内存？
• 假设所有序列化设置（压缩、分块、字典的使用等）都相同，结果是否仍然会漂移？

语境

我正在开发一个系统，用于完全可重现和确定性的数据处理和计算数据集哈希来断言这些保证。

我的主要目标是确保数据集b包含一组相同的记录作为数据集b'- 这当然与对 Arrow/Parquet 的二进制表示进行哈希处理非常不同。不想处理存储格式的可重复性，我一直在计算逻辑数据哈希。这是缓慢但灵活的，例如，即使记录被重新排序（我认为是等效的数据集），我的哈希值也保持不变。

但是，当考虑与依赖于文件哈希的IPFS其他内容可寻址存储集成时，只有一个哈希（物理）而不是两个（逻辑+物理）会大大简化设计，但这意味着我必须保证Parquet 文件是可复制的。

---

更新

我决定暂时继续使用逻辑哈希。

我创建了一个新的 Rust 箱arrow-digest，它实现了 Arrow 数组和记录批次的稳定哈希，并努力隐藏与编码相关的差异。如果有人发现哈希算法有用并希望用另一种语言实现它，则该板条箱的自述文件描述了该算法。

当我将其集成到我正在开发的去中心化数据处理工具中时，我将继续扩展支持的类型集。

从长远来看，我不确定逻辑哈希是否是最好的前进方式 - Parquet 的一个子集，它牺牲了一些效率，只是为了使文件布局具有确定性，这可能是内容可寻址性的更好选择。

Answer 1

至少在箭头的实现中，我期望如此，但尚未以相同的顺序验证完全相同的输入（包括相同的元数据），以产生具有相同配置的确定性输出（出于安全原因，我们尝试不保留未初始化的值）（假设所选择的压缩算法也做出了确定性保证）。元数据或其他地方可能存在一些哈希映射迭代，这也可能会打破这一假设。

正如 @Pace 指出的那样，我不会依赖它并建议不要依赖它）。规范中没有任何内容可以保证这一点，并且由于编写器版本在写入文件时会保留，因此如果您决定升级，则保证会出现损坏。如果添加或删除额外的元数据，事情也会崩溃（我相信过去已经对往返数据集进行了一些重大修复，这会导致不确定性）。

总而言之，这在今天可能行得通，也可能行不通，但即使行得通，我预计这也会非常脆弱。