HDF5与带有文件的文件夹有什么不同？
我正在开发一个处理文件夹添加元数据的开源项目 。 提供的（Python）API允许您浏览和访问元数据，就像它只是另一个文件夹。 因为它只是另一个文件夹。
\folder\.meta\folder\somedata.json 然后我遇到了HDF5及其衍生Alembic 。
阅读Python和HDF5这本书中的HDF5 ，与使用文件夹中的文件相比，我一直在寻找使用它的好处，但是我所遇到的大部分内容都讲述了分层文件格式在添加数据方面的优点通过它的API：
>>> import h5py >>> f = h5py.File("weather.hdf5") >>> f["/15/temperature"] = 21
或者是根据请求只读取其中某些部分的能力（例如随机访问），以及单个HDF5文件的并行执行（例如，用于多处理）
你可以挂载HDF5文件， https://github.com/zjttoefs/hdfuse5
它甚至拥有一个强大而简单的基本概念的组和数据集 ，从wiki中读取：
- 数据集，这是一个同types的multidimensional array
- 组，这是可以容纳数据集和其他组的容器结构
将数据集replace为文件和文件夹 组 ，整个function集听起来像是文件夹中的文件已经完全能够做到。
对于我所遇到的每一个好处，都没有一个是HDF5专有的。
所以我的问题是，如果我要给你一个HDF5文件和一个带有相同内容的文件夹，在这种情况下HDF5会更适合吗？
编辑：
对HDF5的可移植性有了一些反应。
这听起来很可爱，但是我仍然没有给出一个例子，一个HDF5会将文件夹放在一个文件夹中的场景。 为什么有人会考虑在任何计算机上读取文件夹时使用HDF5，通过networking支持“并行I / O”的任何文件系统，都可以在没有HDF5解释器的情况下被人读取。
我甚至会说，带有文件的文件夹比任何HDF5都要便携得多。
编辑2：
Thucydides411刚刚举了一个可移植性问题的例子。 https://stackoverflow.com/a/28512028/478949
我认为我从这个线索中得到的答案是，当你需要文件和文件夹的组织结构时，HDF5非常适合，就像在上面的示例场景中，有很多（百万）小（〜1字节）数据结构; 像个人号码或string。 它通过提供一个“小文件系统”来弥补文件系统缺乏的优势。
在计算机graphics学中，我们用它来存储几何模型和有关各个顶点的任意数据，这似乎与它在科学界的使用非常吻合。
作为开发一个从文件夹到HDF5的科学项目的人，我想我可以看到HDF5的优势。
当我开始我的项目时，我正在使用小的testing数据集，并产生less量的输出，范围是千字节。 我从最简单的数据格式开始，表格编码为ASCII。 对于我处理的每个对象，我都在ASCII表格上生成。
我开始将我的代码应用到对象组中，这意味着在每次运行结束时写入多个ASCII表格，以及包含与整个组相关的输出的附加ASCII表格。 对于每个组，我现在有一个文件夹，如下所示：
+ group | |-- object 1 | |-- object 2 | |-- ... | |-- object N | |-- summary
此时，我开始遇到第一个困难。 ASCII文件的读写速度非常慢，并且它们不能非常有效地打包数字信息，因为每个数字都需要一个完整的字节进行编码，而不是〜3.3位。 于是我转而将每个对象写成自定义二进制文件，这加快了I / O并减小了文件大小。
当我扩大处理大量（数以万计到数百万）的团体时，我突然发现自己正在处理大量的文件和文件夹。 有太多的小文件可能是许多文件系统的问题（许多文件系统的可存储的文件数量有限，无论有多less磁盘空间）。 我也开始发现，当我尝试对整个数据集进行后期处理时，读取许多小文件的磁盘I / O开始耗费大量的时间。 我试图通过整合我的文件来解决这些问题，这样我只为每个组生成两个文件：
+ group 1 | |-- objects | |-- summary + group 2 | |-- objects | |-- summary ...
我也想压缩我的数据，所以我开始为组合集合创build.tar.gz文件。
在这一点上，我的整个数据计划变得非常繁琐，而且如果我想把数据交给其他人，那么就有很大的风险，向他们解释如何使用它。 例如，包含这些对象的二进制文件具有自己的内部结构，它们只存在于存储库中的自述文件中，以及办公室中的一张纸上。 谁想要读取我的组合对象二进制文件之一，就必须知道标题中每个元数据条目的字节偏移量，types和字节顺序以及文件中每个对象的字节偏移量。 如果他们不这样做，那么这个文件对他们来说就是一句胡言乱语。
我分组和压缩数据的方式也造成了问题。 假设我想find一个对象。 我将不得不find它所在的.tar.gz文件，将存档的全部内容解压缩到一个临时文件夹，导航到我感兴趣的组，然后用我自己的自定义API检索对象来读取我的二进制文件。 完成之后，我将删除暂时解压缩的文件。 这不是一个优雅的解决scheme。
此时，我决定切换到标准格式。 由于多种原因，HDF5具有吸引力。 首先，我可以将数据的整体组织保存到组，对象数据集和摘要数据集中。 其次，我可以抛弃我的自定义二进制文件I / O API，只使用multidimensional array数据集来存储组中的所有对象。 我甚至可以创build更复杂数据types的数组，比如C结构数组，而不必精心logging每个条目的字节偏移量。 接下来，HDF5对数据的最终用户进行了分块压缩，这对数据完全是透明的。 由于压缩是分块的，如果我觉得用户要查看单个对象，我可以将每个对象压缩在一个单独的块中，以便只有用户感兴趣的数据集的部分需要解压缩。 分块压缩是一个非常强大的function。
最后，我现在可以给一个人一个单一的文件，而不必解释如何在内部组织。 最终用户可以通过命令行或GUI HDFView在Python，C，Fortran或h5ls读取文件，并查看里面的内容。 这是我的自定义二进制格式不可能的，更不用提我的.tar.gz集合。
当然，可以使用文件夹，ASCII和自定义二进制文件复制HDF5所能做的所有事情。 这就是我原来所做的事情，但是却成了一件令人头痛的事情，最后，HDF5以高效便携的方式做了所有我拼凑在一起的东西。
感谢您提出这个有趣的问题。 是一个可移植的文件夹，因为我可以将一个目录复制到Mac上的一个棒上，然后在PC上看到相同的目录和文件？ 我同意文件目录结构是可移植的，这要感谢编写操作系统的人员，但是这与可移植文件中的数据无关。 现在，如果这个目录中的文件是PDF文件，它们是可移植的，因为有多种工具可以阅读和理解多个操作系统中的pdf（感谢Adobe）。 但是，如果这些文件是原始的科学数据（ASCII或二进制文件无关紧要），它们根本就不是可移植的。 ASCII文件看起来像一堆字符，二进制文件看起来像乱码。 如果是XML或json文件，它们将是可读的，因为json是ASCII，但是它们包含的信息可能不是可移植的，因为对于没有写入文件的人来说XML / json标记的含义可能不清楚。 这是重要的一点，ASCII文件中的字符是可移植的，但它们所代表的信息不是。
HDF5数据是可移植的，就像pdf一样，因为许多操作系统中都有工具可以读取HDF5文件中的数据（就像PDF阅读器一样，请参阅http://www.hdfgroup.org/products/hdf5_tools/index.html ）。 也有许多语言的库可以用来读取数据，并以一种对用户有意义的方式来呈现 – 这是Adobe读者所做的。 HDF5社区有数百个团体为他们的用户做同样的事情（参见http://www.hdfgroup.org/HDF5/users5.html ）。
这里也有一些关于压缩的讨论。 在HDF5文件中压缩的重要之处在于对象是独立压缩的，只有你需要的对象才能被解压缩。 这显然比压缩整个文件更有效率，并且不得不解压整个文件来读取它。
另一个重要的部分是HDF5文件是自我描述 – 所以，写文件的人可以添加信息，帮助用户和工具知道文件中的内容。 什么是variables，他们的types是什么，他们写了什么软件，什么工具收集他们等。这听起来像你正在工作的工具可以读取文件的元数据。 HDF5文件中的属性可以附加到文件中的任何对象 – 它们不仅仅是文件级别的信息。 这是巨大的。 当然，这些属性可以使用许多语言和许多操作系统编写的工具读取。
对我来说，我们可以将文件夹和文件与HDF5进行比较，只能在科学数据的相关上下文中，其中最重要的数据是由一组元数据描述的数组。
在一般情况下，马库斯是正确的，当他声称文件夹比任何HDF5更便携。 我将在一般情况下添加一个带有文件的文件夹，它比HDF5文件最容易访问。 显而易见的挑战是，对于“普通”文件夹和文件，不需要额外的API来访问数据。 HDF5将数据和元数据保存在同一个文件中是不可能的。
想象一下，阅读你的pdf文件，你需要一个理解HDF5的新的PDF阅读器？ 想象一下，要播放你的音乐，你需要一个可以解码HDF5的音乐播放器？ 要运行你的python脚本，python解释器需要先解码HDF5？ 或者说，要启动你的python解释器，你的操作系统需要解码HDF5吗？ 等我将无法写这个答案，因为我的操作系统将无法启动我的网页浏览器，将无法读取其内部文件，因为我以前把所有的东西都变成HDF5（也许是一个大硬盘中的一切都是HDF5）。
将元数据存储在单独的文件中有很大的好处，可以很好地处理已经存在的大量数据文件和软件，而不会有任何额外的麻烦。
我希望这有帮助。
我认为主要的优点是便携性 。
HDF5存储有关数据集的信息，例如整数的大小，types和字节序以及浮点数，这意味着您可以移动hdf5文件并读取其内容，即使它是在具有不同体系结构的计算机上创build的。
您还可以将任意元数据附加到组和数据集。 如果你的文件系统支持扩展属性，可以说你也可以用文件和文件夹来做到这一点。
一个hdf5文件是一个单独的文件，有时可以比zip / tar文件夹和文件更方便。 这也有一个主要的缺点：如果你删除一个数据集，你不能回收的空间，而不创build一个新的文件。
一般来说，HDF5非常适合存储大量的数字，通常是科学数据集。
需要将大量资源加载到内存中的游戏是HDF5可能比带有文件的文件夹更好的场景。 从文件加载数据具有搜寻时间，打开每个文件所需的时间以及将文件中的数据读入内存的成本。 从DVD或蓝光读取数据时，这些操作可能会更慢。 打开一个文件可以大大降低这些成本。
我目前正在评估HDF5，所以有相同的问题。
这篇文章 – 从HDF5走开 – 问几乎相同的问题。 文章提出了一些好的观点，即在现代开源标准的相对不透明的环境下，HDF5库只有一个实现。
从标题中可以看出，作者决定从HDF5转移到包含具有JSON文件元数据的数组的二进制文件的文件系统层次结构。 尽pipe在HDF5上投入了大量资金，但数据腐败和性能问题使得他们的手指被烧毁了。
是的，主要优点是HDF5是便携式的。 HDF5文件可以被许多其他的编程/解释语言访问，比如Python（你的API所build立的），MATLAB，Fortran和C. Simon提到，HDF5被广泛用于科学界存储大型数据集。 根据我的经验，我发现只能检索某些有用的数据集（和区域）的能力。 此外，为并行I / O构buildHDF5库对于稍后对原始数据的后处理非常有利。
由于该文件也是自描述的，因此它不仅能够存储原始数据，还能够存储数据的描述，如数组大小，数组名称，单位和一系列附加元数据。
希望这可以帮助。
HDF5最终是一种存储数字的格式，针对大型数据集进行了优化。 主要的优势是支持压缩（可以使读写数据在许多情况下更快）以及快速的内核查询（检索符合某些条件的数据，例如温度超过30℃时的所有压力值C）。
事实上，你可以在同一个文件中结合几个数据集只是一个方便。 例如，您可以有几个组对应不同的气象站，每个组包含多个数据表。 对于每个组，您将拥有一组描述仪器细节的属性，并且每个表格都包含个别设置。 每个数据块可以有一个h5文件，在相应的位置有一个属性，它会给你相同的function。 但现在，HDF5可以做的是重新包装文件以优化查询，稍微压缩整个文件，并以极快的速度检索您的信息。 如果你有几个文件，每个文件都会被单独压缩，操作系统会决定磁盘上的布局，这可能不是最佳的。
HDF5允许你做的最后一件事就是在内存中加载一个文件（或者一块），以暴露与磁盘相同的API。 所以，例如，你可以使用一个或者其他的后端，这取决于数据的大小和可用的RAM。 在你的情况下，这相当于将相关信息复制到Linux中的/ dev / shm，你将负责将任何修改提交给磁盘。
