python - HDF5 与包含文件的文件夹有何不同？

Question

我正在处理 open source project处理向文件夹添加元数据。提供的 (Python) API 让您可以像浏览和访问另一个文件夹一样浏览和访问元数据。因为它只是另一个文件夹。

\folder\.meta\folder\somedata.json

然后我遇到了 HDF5及其推导 Alembic .

阅读书中关于 HDF5 的内容 Python and HDF5与使用文件夹中的文件相比，我一直在寻找使用它的好处，但我遇到的大部分内容都谈到了分层文件格式的好处，即通过其 API 添加数据的简单性:

>>> import h5py
>>> f = h5py.File("weather.hdf5")
>>> f["/15/temperature"] = 21

或者它能够根据请求仅读取其中的某些部分(例如随机访问)，以及并行执行单个 HDF5 文件(例如用于多处理)

您可以挂载 HDF5 文件， https://github.com/zjttoefs/hdfuse5

它甚至拥有强大而简单的基础概念 群组 和 数据集 来自维基的内容是:

数据集，它们是同构类型的多维数组

组，它们是容器结构，可以保存数据集和
其他组

替换 数据集 与 文件 和 群 与 文件夹整个功能集在我看来就像文件夹中的文件已经完全有能力做的那样。

对于我遇到的每一个好处，没有一个是 HDF5 独有的。

所以我的问题是，如果我给你一个 HDF5 文件和一个包含文件的文件夹，两者都具有相同的内容，那么 HDF5 更适合哪种情况？

编辑:

得到了一些关于 HDF5 可移植性的回应。

这听起来很可爱，但我仍然没有得到一个例子，一个场景，在这个场景中，HDF5 会胜过包含文件的文件夹。当文件夹在任何计算机、任何文件系统、网络上可读、支持“并行 I/O”、无需 HDF5 解释器即可被人类读取时，为什么有人会考虑使用 HDF5。

我会说，一个包含文件的文件夹比任何 HDF5 都更便携。

编辑2:

Thucydides411 只是举例说明了可移植性很重要的场景。
https://stackoverflow.com/a/28512028/478949

我认为我从该线程中的答案中得出的结论是，当您需要文件和文件夹的组织结构时，HDF5 非常适合，就像上面的示例场景一样，有很多(数百万)小(~1 字节)数据结构;像单个数字或字符串。它通过提供一个有利于小而多而不是少数和大的“子文件系统”来弥补文件系统的不足。

在计算机图形学中，我们使用它来存储几何模型和关于单个顶点的任意数据，这似乎与它在科学界的使用非常吻合。

Answer 1

作为开发从使用文件文件夹到 HDF5 的科学项目的人，我想我可以阐明 HDF5 的优势。

当我开始我的项目时，我正在对小型测试数据集进行操作，并产生少量输出，在千字节范围内。我从最简单的数据格式开始，即编码为 ASCII 的表格。对于我处理的每个对象，我都在 ASCII 表上生成。

我开始将我的代码应用于对象组，这意味着在每次运行结束时编写多个 ASCII 表，以及包含与整个组相关的输出的附加 ASCII 表。对于每个组，我现在有一个如下所示的文件夹:

+ group
|    |-- object 1
|    |-- object 2
|    |-- ...
|    |-- object N
|    |-- summary

在这一点上，我开始遇到我的第一个困难。 ASCII 文件的读写速度非常慢，并且它们不能非常有效地打包数字信息，因为每个数字都需要一个完整的字节来编码，而不是大约 3.3 位。所以我转而将每个对象作为自定义二进制文件写入，这加快了 I/O 并减小了文件大小。

当我扩大到处理大量(数万到数百万)组时，我突然发现自己要处理大量的文件和文件夹。对于许多文件系统来说，拥有太多小文件可能是一个问题(许多文件系统可以存储的文件数量是有限的，无论磁盘空间有多少)。我还开始发现，当我尝试对整个数据集进行后处理时，读取许多小文件的磁盘 I/O 开始占用相当多的时间。我试图通过合并我的文件来解决这些问题，因此我只为每个组生成两个文件:

+ group 1
|    |-- objects
|    |-- summary
+ group 2
|    |-- objects
|    |-- summary
...

我还想压缩我的数据，所以我开始为组的集合创建 .tar.gz 文件。

此时，我的整个数据方案变得非常繁琐，并且存在风险，如果我想将我的数据交给其他人，则需要花费大量精力向他们解释如何使用它。例如，包含对象的二进制文件有它们自己的内部结构，该结构仅存在于存储库的 README 文件中和我办公室的纸本上。无论谁想要读取我的组合对象二进制文件之一，都必须知道 header 中每个元数据条目的字节偏移量、类型和字节序，以及文件中每个对象的字节偏移量。如果他们不这样做，该文件对他们来说就是胡言乱语。

我对数据进行分组和压缩的方式也带来了问题。假设我想找到一个对象。我必须找到它所在的 .tar.gz 文件，将存档的全部内容解压缩到一个临时文件夹，导航到我感兴趣的组，并使用我自己的自定义 API 检索对象以读取我的二进制文件.完成后，我会删除临时解压缩的文件。这不是一个优雅的解决方案。

此时，我决定切换到标准格式。 HDF5 之所以具有吸引力，原因有很多。首先，我可以将我的数据整体组织成组、对象数据集和汇总数据集。其次，我可以放弃我的自定义二进制文件 I/O API，而只使用一个多维数组数据集来存储一个组中的所有对象。我什至可以创建更复杂数据类型的数组，比如 C 的数组。结构，而不必仔细记录每个条目的字节偏移量。接下来，HDF5 进行了分块压缩，这对数据的最终用户来说是完全透明的。因为压缩是分块的，如果我认为用户想要查看单个对象，我可以将每个对象压缩在一个单独的块中，以便只需要解压缩用户感兴趣的数据集部分。分块压缩是一个非常强大的功能。

最后，我现在可以只给某人一个文件，而无需解释它的内部组织方式。最终用户可以使用 Python、C、Fortran 或 h5ls 读取文件。在命令行或 GUI HDFView 上，看看里面有什么。我的自定义二进制格式不可能做到这一点，更不用说我的 .tar.gz 集合了。

当然，可以使用文件夹、ASCII 和自定义二进制文件复制 HDF5 所能做的一切。这就是我最初所做的，但它成为了一个令人头疼的问题，最终，HDF5 以一种高效且便携的方式完成了我拼凑的所有工作。