【问题标题】:HDF5 chunking without compression leads to increase in file size未压缩的 HDF5 分块会导致文件大小增加
【发布时间】:2016-03-17 16:29:06
【问题描述】:

我有一个未分块、未压缩的 HDF5 文件,大小为 460MB。我使用 h5repack 来保存带有压缩块的文件,如下所示:

h5repack -v -l CHUNK=128x128x1 -f GZIP=1 file.h5 file_chunked.h5 

效果很好,生成的文件大小约为原始文件 (170MB) 的 1/3。

但是,如果我尝试像这样使用 无压缩分块

h5repack -v -l CHUNK=128x128x1 -f NONE file.h5 file_chunked.h5

甚至

h5repack -v -l CHUNK=128x128x1 file.h5 file_chunked.h5

那么生成的文件大小比原始文件 (3.9GB) 大得多 (10x)。

生成的数据集的维度、数据类型和内容似乎相同。当我在 HDFView 中检查文件时,除了将 Chunking 设置为 128x128x1 之外,我看不出与原始文件没有任何区别。

我希望分块但未压缩的文件与原始文件的大小大致相同。

谁能给我解释一下?我可能在这里遗漏了一些基本的东西。

非常感谢!

【问题讨论】:

    标签: compression hdf5 chunking


    【解决方案1】:

    每个块都有一些开销。在内部,它们是 B 树中的节点。这个开销乘以块的数量。如果你有相对较小的块,你会有很多。如果没有压缩,这种开销可能会很大。

    关于things that can affect performance 的页面说:

    避免使用非常小的块大小。小块大小可能会产生大量开销,这会影响性能,此外还会使文件变得更大。

    【讨论】:

    • 感谢 Simon,我之前已经阅读过这些说明,并且我确信我为我的数据集选择了一个合理的块大小。它们在 x 和 y (5,000) 上相当大,在 z (15) 上非常小。但我现在发现我把维度的顺序搞混了。它必须是 1x128x128(z 优先)而不是 128x128x1,这显然会产生巨大的差异。
    • 太棒了!我对开销的数量感到惊讶。这很好地解释了它!
    猜你喜欢
    • 2013-05-23
    • 2010-12-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-11-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多