将HDF5用于大型阵列存储(而不是平面二进制文件)是否具有分析速度或内存使用优势?


96

我正在处理大型3D阵列,通常需要以各种方式对其进行切片以进行各种数据分析。一个典型的“立方体”可以达到〜100GB(将来可能会更大)

似乎对于python中的大型数据集,通常推荐的文件格式是使用HDF5(h5py或pytables)。我的问题是:使用HDF5来存储和分析这些多维数据集,而不是将它们存储在简单的平面二进制文件中,对速度或内存使用有好处吗?HDF5是否更适合表格数据,而不是像我正在使用的大型数组?我看到HDF5可以提供很好的压缩,但是我对处理速度和处理内存溢出更感兴趣。

我经常只想分析多维数据集的一个大子集。pytables和h5py的一个缺点似乎是,当我对数组进行切片时,我总是得到一个numpy数组,占用了内存。但是,如果我对平面二进制文件的numpy内存映射进行切片,则可以获得一个视图,该视图将数据保留在磁盘上。因此,看来我可以更轻松地分析数据的特定扇区,而不会耗尽内存。

我已经浏览了pytables和h5py,到目前为止,还没有看到两者对我的好处。


1
HDF是一种“块”文件格式。平均而言,它将使您更快地读取数据集的任意部分。memmap将具有最快的最佳情况,但是非常非常慢的最坏情况。h5py与相比,它更适合像您这样的数据集pytables。此外,h5py没有返回内存numpy的阵列。相反,它返回的行为类似于一个,但没有加载到内存中(类似于memmapped数组)。我正在写一个更完整的答案(可能无法完成),但希望此评论在此期间有所帮助。
乔·肯顿2014年

谢谢。我同意h5py返回类似于memmap的数据集。但是,如果对h5py数据集进行切片,它将返回一个numpy数组,我相信(?)意味着数据已不必要地放入了内存。如果可能,memmamp会将视图返回到原始memmap。换句话说:type(cube)h5py._hl.dataset.Dataset。虽然type(cube[0:1,:,:])numpy.ndarray
Caleb 2014年

但是,关于平均读取时间的观点很有趣。
Caleb 2014年

4
如果您有I / O瓶颈,那么在许多情况下,压缩实际上可以提高读写性能(尤其是使用BLOSC和LZO等快速压缩库),因为压缩会减少所需的I / O带宽,但会花费一些额外的CPU周期。您可能需要查看此页面该页面包含有关使用PyTables HDF5文件优化读写性能的大量信息。
ali_m 2014年

2
“如果我切片一个平面二进制文件的numpy memmap,我可以得到一个视图,该视图将数据保留在磁盘上”-可能是正确的,但是如果您实际上想对该数组中的值进行任何操作,则迟早要进行您将不得不将它们加载到RAM中。内存映射的数组仅提供一些封装,因此您不必考虑何时读取数据或数据是否会超出系统内存容量。在某些情况下,内存映射数组的本地缓存行为确实可能不是很理想
ali_m 2014年

Answers:


158

HDF5的优势:组织,灵活性,互操作性

HDF5的一些主要优点是其层次结构(类似于文件夹/文件),与每个项目一起存储的可选任意元数据以及其灵活性(例如压缩)。这种组织结构和元数据存储听起来很琐碎,但在实践中非常有用。

HDF的另一个优点是,数据集可以是固定大小的灵活的尺寸。因此,将数据附加到大型数据集很容易,而无需创建整个新副本。

此外,HDF5是一种标准格式,几乎所有语言都可以使用库,因此使用HDF可以很容易地在Matlab,Fortran,R,C和Python之间共享磁盘数据。(公平地说,只要知道C与F的顺序并知道存储数组的形状,dtype等,使用大型二进制数组也不太困难。)

HDF对于大型阵列的优势:更快的任意切片I / O

就像TL / DR一样:对于约8GB的3D阵列,使用分块的HDF5数据集沿任何轴读取“完整”切片大约需要20秒,而对于3个小时(最坏情况),则需要0.3秒(最佳情况)相同数据的映射数组。

除了上面列出的内容外,“块状” *磁盘数据格式(例如HDF5)还有另一个大优势:读取任意片(强调任意)通常会更快,因为磁盘上的数据更连续。平均。

*(HDF5不必是分块的数据格式。它支持分块,但不是必需的。实际上h5py,如果我没记错的话,在其中创建数据集的默认设置是不分块。)

基本上,对于一个给定的数据集片,最佳情况下的磁盘读取速度和最坏情况下的磁盘读取速度将与分块的HDF数据集相当接近(假设您选择了一个合理的块大小,或者让一个库为您选择了一个)。用一个简单的二进制数组,最好的情况也比较快,但最坏的情况是糟糕。

请注意,如果您有SSD,则可能不会注意到读/写速度的巨大差异。但是,使用常规硬盘驱动器,顺序读取要比随机读取快得多。(即,普通硬盘驱动器需要很长的seek时间。)HDF在SSD上仍然具有优势,但更多的原因是其其他功能(例如,元数据,组织等)而不是原始速度。


首先,为了消除混乱,访问h5py数据集将返回一个对象,该对象的行为与numpy数组非常相似,但是直到将数据切片后才将其加载到内存中。(类似于memmap,但不完全相同。)有关更多信息,请参见h5py介绍

对数据集进行切片会将数据的一个子集加载到内存中,但是大概您想对它做点什么,这时无论如何您都将需要它在内存中。

如果您确实想进行核外计算,则可以使用pandas或轻松地获得表格数据pytables。可能h5py(大型ND阵列更合适),但是您需要降低到较低的水平并自己处理迭代。

但是,类似numpy的内核外计算的未来是Blaze。如果您真的想走那条路,请看一下


“无条件”案例

首先,考虑一个写入磁盘的3D C顺序数组(我将通过调用arr.ravel()和打印结果来模拟它,以使内容更加可见):

In [1]: import numpy as np

In [2]: arr = np.arange(4*6*6).reshape(4,6,6)

In [3]: arr
Out[3]:
array([[[  0,   1,   2,   3,   4,   5],
        [  6,   7,   8,   9,  10,  11],
        [ 12,  13,  14,  15,  16,  17],
        [ 18,  19,  20,  21,  22,  23],
        [ 24,  25,  26,  27,  28,  29],
        [ 30,  31,  32,  33,  34,  35]],

       [[ 36,  37,  38,  39,  40,  41],
        [ 42,  43,  44,  45,  46,  47],
        [ 48,  49,  50,  51,  52,  53],
        [ 54,  55,  56,  57,  58,  59],
        [ 60,  61,  62,  63,  64,  65],
        [ 66,  67,  68,  69,  70,  71]],

       [[ 72,  73,  74,  75,  76,  77],
        [ 78,  79,  80,  81,  82,  83],
        [ 84,  85,  86,  87,  88,  89],
        [ 90,  91,  92,  93,  94,  95],
        [ 96,  97,  98,  99, 100, 101],
        [102, 103, 104, 105, 106, 107]],

       [[108, 109, 110, 111, 112, 113],
        [114, 115, 116, 117, 118, 119],
        [120, 121, 122, 123, 124, 125],
        [126, 127, 128, 129, 130, 131],
        [132, 133, 134, 135, 136, 137],
        [138, 139, 140, 141, 142, 143]]])

这些值将按顺序存储在磁盘上,如下面的第4行所示。(暂时忽略文件系统详细信息和碎片。)

In [4]: arr.ravel(order='C')
Out[4]:
array([  0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,
        13,  14,  15,  16,  17,  18,  19,  20,  21,  22,  23,  24,  25,
        26,  27,  28,  29,  30,  31,  32,  33,  34,  35,  36,  37,  38,
        39,  40,  41,  42,  43,  44,  45,  46,  47,  48,  49,  50,  51,
        52,  53,  54,  55,  56,  57,  58,  59,  60,  61,  62,  63,  64,
        65,  66,  67,  68,  69,  70,  71,  72,  73,  74,  75,  76,  77,
        78,  79,  80,  81,  82,  83,  84,  85,  86,  87,  88,  89,  90,
        91,  92,  93,  94,  95,  96,  97,  98,  99, 100, 101, 102, 103,
       104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116,
       117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129,
       130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143])

在最佳情况下,让我们沿第一个轴剖一下。请注意,这些只是数组的前36个值。这将是一个非常快的阅读!(一寻一读)

In [5]: arr[0,:,:]
Out[5]:
array([[ 0,  1,  2,  3,  4,  5],
       [ 6,  7,  8,  9, 10, 11],
       [12, 13, 14, 15, 16, 17],
       [18, 19, 20, 21, 22, 23],
       [24, 25, 26, 27, 28, 29],
       [30, 31, 32, 33, 34, 35]])

同样,沿第一个轴的下一个切片将仅是下一个36个值。要沿该轴读取完整的切片,我们只需执行一项seek操作。如果我们要读取的只是沿着该轴的各个切片,那么这就是理想的文件结构。

但是,让我们考虑最坏的情况:沿着最后一个轴的切片。

In [6]: arr[:,:,0]
Out[6]:
array([[  0,   6,  12,  18,  24,  30],
       [ 36,  42,  48,  54,  60,  66],
       [ 72,  78,  84,  90,  96, 102],
       [108, 114, 120, 126, 132, 138]])

要读入此片,我们需要36次搜索和36次读取,因为所有值都在磁盘上分开。他们都不是相邻的!

这看起来似乎很小,但是随着我们使用越来越大的数组,操作的数量和大小seek迅速增长。对于以这种方式存储并通过via读入的大型(〜10Gb)3D阵列memmap,即使使用现代硬件,沿“最差”轴读取整个切片也很容易花费数十分钟。同时,沿最佳轴的切片可能会花费不到一秒钟的时间。为了简单起见,我只显示单个轴上的“完整”切片,但是对于数据的任何子集的任意切片,都会发生完全相同的事情。

顺便说一句,有几种文件格式可以利用此功能,并且基本上在磁盘上存储三份巨大的 3D阵列副本:一份以C顺序,一份以F顺序,一份在两者之间的中间位置。(一个示例是Geoprobe的D3D格式,尽管我不确定它是否在任何地方都有记录。)谁在乎最终文件大小是否为4TB,但存储空间却很便宜!疯狂的是,由于主要用例是在每个方向上提取单个子切片,因此您要进行的读取非常非常快。效果很好!


简单的“块状”案例

假设我们将3D数组的2x2x2“块”存储为磁盘上的连续块。换句话说,类似:

nx, ny, nz = arr.shape
slices = []
for i in range(0, nx, 2):
    for j in range(0, ny, 2):
        for k in range(0, nz, 2):
            slices.append((slice(i, i+2), slice(j, j+2), slice(k, k+2)))

chunked = np.hstack([arr[chunk].ravel() for chunk in slices])

因此磁盘上的数据如下所示chunked

array([  0,   1,   6,   7,  36,  37,  42,  43,   2,   3,   8,   9,  38,
        39,  44,  45,   4,   5,  10,  11,  40,  41,  46,  47,  12,  13,
        18,  19,  48,  49,  54,  55,  14,  15,  20,  21,  50,  51,  56,
        57,  16,  17,  22,  23,  52,  53,  58,  59,  24,  25,  30,  31,
        60,  61,  66,  67,  26,  27,  32,  33,  62,  63,  68,  69,  28,
        29,  34,  35,  64,  65,  70,  71,  72,  73,  78,  79, 108, 109,
       114, 115,  74,  75,  80,  81, 110, 111, 116, 117,  76,  77,  82,
        83, 112, 113, 118, 119,  84,  85,  90,  91, 120, 121, 126, 127,
        86,  87,  92,  93, 122, 123, 128, 129,  88,  89,  94,  95, 124,
       125, 130, 131,  96,  97, 102, 103, 132, 133, 138, 139,  98,  99,
       104, 105, 134, 135, 140, 141, 100, 101, 106, 107, 136, 137, 142, 143])

只是为了表明它们是的2x2x2块arr,请注意这些是的前8个值chunked

In [9]: arr[:2, :2, :2]
Out[9]:
array([[[ 0,  1],
        [ 6,  7]],

       [[36, 37],
        [42, 43]]])

要读取沿轴的任何切片,我们将读取6或9个连续的块(所需数据的两倍),然后仅保留所需的部分。在最坏的情况下,最大搜索数为9,而非分块版本的搜索数最大为36。(但是最好的情况仍然是6个搜索,而对于内存阵列则为1个。)由于顺序读取与搜索相比非常快,因此大大减少了将任意子集读入内存所需的时间。再次,这种效果随着更大的阵列而变得更大。

HDF5更进一步。块不必连续存储,它们由B树索引。此外,它们不必在磁盘上具有相同的大小,因此可以将压缩应用于每个块。


分块数组 h5py

默认情况下,h5py不会在磁盘上创建分块的HDF文件(pytables相比之下,我认为是)。chunks=True但是,如果在创建数据集时指定,则会在磁盘上获得分块数组。

作为一个简短的示例:

import numpy as np
import h5py

data = np.random.random((100, 100, 100))

with h5py.File('test.hdf', 'w') as outfile:
    dset = outfile.create_dataset('a_descriptive_name', data=data, chunks=True)
    dset.attrs['some key'] = 'Did you want some metadata?'

请注意,这会chunks=True告诉h5py我们自动选择块大小。如果您最了解最常用的用例,则可以通过指定形状元组来优化块的大小/形状(例如(2,2,2),在上面的简单示例中)。这使您可以更有效地沿特定轴进行读取,或针对特定大小的读取/写入进行优化。


I / O性能比较

为了强调这一点,让我们比较从分块的HDF5数据集和包含相同确切数据的大型(〜8GB)Fortran排序3D数组中读取的片段。

我已经清除了每次运行之间的所有操作系统缓存,因此我们看到的是“冷”性能。

对于每种文件类型,我们将测试沿第一个轴的“完整” x切片和沿最后一个轴的“完整” z切片读取。对于按Fortran排序的映射数组,“ x”切片是最坏的情况,而“ z”切片是最好的情况。

所使用的代码基于要点(包括创建hdf文件)。我无法轻松共享此处使用的数据,但是您可以通过形状相同的零数组(621, 4991, 2600)和type)来模拟它np.uint8

chunked_hdf.py如下所示:

import sys
import h5py

def main():
    data = read()

    if sys.argv[1] == 'x':
        x_slice(data)
    elif sys.argv[1] == 'z':
        z_slice(data)

def read():
    f = h5py.File('/tmp/test.hdf5', 'r')
    return f['seismic_volume']

def z_slice(data):
    return data[:,:,0]

def x_slice(data):
    return data[0,:,:]

main()

memmapped_array.py相似,但要确保将切片实际加载到内存中要复杂得多(默认情况下,memmapped将返回另一个数组,这不是苹果与苹果的比较)。

import numpy as np
import sys

def main():
    data = read()

    if sys.argv[1] == 'x':
        x_slice(data)
    elif sys.argv[1] == 'z':
        z_slice(data)

def read():
    big_binary_filename = '/data/nankai/data/Volumes/kumdep01_flipY.3dv.vol'
    shape = 621, 4991, 2600
    header_len = 3072

    data = np.memmap(filename=big_binary_filename, mode='r', offset=header_len,
                     order='F', shape=shape, dtype=np.uint8)
    return data

def z_slice(data):
    dat = np.empty(data.shape[:2], dtype=data.dtype)
    dat[:] = data[:,:,0]
    return dat

def x_slice(data):
    dat = np.empty(data.shape[1:], dtype=data.dtype)
    dat[:] = data[0,:,:]
    return dat

main()

首先让我们看一下HDF的性能:

jofer at cornbread in ~ 
$ sudo ./clear_cache.sh

jofer at cornbread in ~ 
$ time python chunked_hdf.py z
python chunked_hdf.py z  0.64s user 0.28s system 3% cpu 23.800 total

jofer at cornbread in ~ 
$ sudo ./clear_cache.sh

jofer at cornbread in ~ 
$ time python chunked_hdf.py x
python chunked_hdf.py x  0.12s user 0.30s system 1% cpu 21.856 total

“完整的” x切片和“完整的” z切片大约需要相同的时间(约20秒)。考虑到这是一个8GB的阵列,还算不错。大多数时候

并且,如果将其与映射的数组时间进行比较(按Fortran顺序排序:最佳情况是“ z切片”,最坏情况是“ x切片”):

jofer at cornbread in ~ 
$ sudo ./clear_cache.sh

jofer at cornbread in ~ 
$ time python memmapped_array.py z
python memmapped_array.py z  0.07s user 0.04s system 28% cpu 0.385 total

jofer at cornbread in ~ 
$ sudo ./clear_cache.sh

jofer at cornbread in ~ 
$ time python memmapped_array.py x
python memmapped_array.py x  2.46s user 37.24s system 0% cpu 3:35:26.85 total

是的,你看的没错。一个切片方向为0.3秒,另一个切片方向为〜3.5 小时

在“ x”方向上进行切片的时间远远大于将整个8GB阵列加载到内存中并选择所需切片所需的时间!(同样,这是一个按Fortran顺序排列的数组。对于C顺序的数组来说,相反的x / z slice时序将是这种情况。)

但是,如果我们一直想沿最佳情况方向进行切片,那么磁盘上的大二进制数组就非常好。(〜0.3秒!)

对于映射阵列,您将陷入这种I / O差异(或者各向异性是一个更好的说法)。但是,对于分块的HDF数据集,您可以选择分块大小,以使访问权限相等或针对特定用例进行了优化。它为您提供了更多的灵活性。

综上所述

希望这可以帮助您至少部分解决问题。HDF5与“原始”内存映射相比还具有许多其他优点,但是我在这里没有足够的空间来扩展它们。压缩可以加快某些速度(我处理的数据不能从压缩中获得很多好处,因此我很少使用它),并且与“原始”内存映射相比,HDF5文件对OS级缓存的播放效果更好。除此之外,HDF5是一种非常出色的容器格式。它为您提供了很大的灵活性来管理数据,并且可以或多或少地使用任何编程语言来使用它。

总体而言,尝试一下,看看它是否适合您的用例。我想您可能会感到惊讶。


3
好答案。我想补充一点,您可以自定义分块布局以适应典型的数据访问模式。如果访问模式的模板尺寸相当可预测,则通常可以选择分块以便始终保持接近最佳速度。
Eelco Hoogendoorn 2015年

2
好答案!关于分块,没有提到的一件事是分块缓存的效果。每个打开的数据集都有其自己的块缓存,其默认大小为1 MB,可以使用C中的H5Pset_chunk_cache()进行调整。考虑访问模式时,考虑可以在内存中保留多少块通常非常有用。如果您的缓存可以容纳8个数据块,而数据集在扫描方向上为10个数据块,那么您将遭受很大的损失,性能将非常糟糕。
丹娜·罗宾逊
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.