Pandas最佳持久性策略以获得最高压缩比？

Question

问题

给定一系列数据帧，数据类型种类很少，如果我首先考虑压缩比，其次是解压缩速度，第三是初始压缩速度，那么熊猫数据帧持久化/序列化的最佳设计是什么？在

背景：

我有大约200k个形状为[2900,8]的数据帧，需要存储在每个文件大约50个数据帧的逻辑块中。数据框包含类型为的变量np.int8公司, np.浮动64. 大多数数据帧都是稀疏类型的很好的候选对象，但是HDF'table'格式存储中不支持稀疏（稀疏的gzip pickle请参阅下面的大小）。每天都会生成数据，目前数据总量超过20GB。虽然我没有绑定到HDF，但我还没有找到一个更好的解决方案，它允许读取持久存储中的单个数据帧，并结合高质量的压缩。再一次，我愿意牺牲一点速度来获得更好的压缩比，特别是因为我需要把这个发送到整个线路。在

还有一些其他的SO线程和其他链接可能与处于相似位置的那些线程相关。然而，我发现的大部分内容并没有将存储大小最小化作为优先事项：

“Large data” work flows using pandas

HDF5 and SQLite. Concurrency, compression & I/O performance [closed]

环境：

OSX 10.9.5
Pandas 14.1
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PyTables version:  3.1.1
HDF5 version:      1.8.13
NumPy version:     1.8.1
Numexpr version:   2.4 (not using Intel's VML/MKL)
Zlib version:      1.2.5 (in Python interpreter)
LZO version:       2.06 (Aug 12 2011)
BZIP2 version:     1.0.6 (6-Sept-2010)
Blosc version:     1.3.5 (2014-03-22)
Blosc compressors: ['blosclz', 'lz4', 'lz4hc', 'snappy', 'zlib']
Cython version:    0.20.2
Python version:    2.7.8 (default, Jul  2 2014, 10:14:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
Platform:          Darwin-13.4.0-x86_64-i386-64bit
Byte-ordering:     little
Detected cores:    8
Default encoding:  ascii
Default locale:    (en_US, UTF-8)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

示例：

^{pr2}$

结果

-rw-r--r--   1 bazel  staff  10292760 Oct 17 14:31 test_fixed_None-9.hdf
-rw-r--r--   1 bazel  staff   9531607 Oct 17 14:31 test_fixed_blosc-9.hdf
-rw-r--r--   1 bazel  staff   7867786 Oct 17 14:31 test_fixed_bzip2-9.hdf
-rw-r--r--   1 bazel  staff   9506483 Oct 17 14:31 test_fixed_lzo-9.hdf
-rw-r--r--   1 bazel  staff   8036845 Oct 17 14:31 test_fixed_zlib-9.hdf
-rw-r--r--   1 bazel  staff  26627915 Oct 17 14:31 test_pickle.pkl
-rw-r--r--   1 bazel  staff   8752370 Oct 17 14:32 test_pickle_gzip.pklz
-rw-r--r--   1 bazel  staff   8407704 Oct 17 14:32 test_pickle_gzip_sparse.pklz
-rw-r--r--   1 bazel  staff  14464924 Oct 17 14:31 test_table_None-9.hdf
-rw-r--r--   1 bazel  staff   8619016 Oct 17 14:31 test_table_blosc-9.hdf
-rw-r--r--   1 bazel  staff   8154716 Oct 17 14:31 test_table_bzip2-9.hdf
-rw-r--r--   1 bazel  staff   8481631 Oct 17 14:31 test_table_lzo-9.hdf
-rw-r--r--   1 bazel  staff   8047125 Oct 17 14:31 test_table_zlib-9.hdf

考虑到上面的结果，最好的“压缩优先”解决方案似乎是用bzip2将数据以HDF固定格式存储。有没有更好的方式来组织数据，也许没有HDF，可以让我节省更多的空间？在

更新1

根据Jeff下面的评论，我在表store HDF文件上使用了ptrepack，没有进行初始压缩——然后重新压缩。结果如下：

-rw-r--r--   1 bazel  staff   8627220 Oct 18 08:40 test_table_repack-blocsc-9.hdf
-rw-r--r--   1 bazel  staff   8627620 Oct 18 09:07 test_table_repack-blocsc-blosclz-9.hdf
-rw-r--r--   1 bazel  staff   8409221 Oct 18 08:41 test_table_repack-blocsc-lz4-9.hdf
-rw-r--r--   1 bazel  staff   8104142 Oct 18 08:42 test_table_repack-blocsc-lz4hc-9.hdf
-rw-r--r--   1 bazel  staff  14475444 Oct 18 09:05 test_table_repack-blocsc-snappy-9.hdf
-rw-r--r--   1 bazel  staff   8059586 Oct 18 08:43 test_table_repack-blocsc-zlib-9.hdf
-rw-r--r--   1 bazel  staff   8161985 Oct 18 09:08 test_table_repack-bzip2-9.hdf

奇怪的是，使用ptrepack重新压缩似乎会增加文件的总大小（至少在本例中，使用类似压缩器的表格式）。在