Pet*_*ney 32 python performance hdf5 pytables pandas
我已经使用大熊猫进行研究了大约两个月,效果很好.有了大量的中型跟踪事件数据集,pandas + PyTables(HDF5接口)在允许我使用我所熟悉和喜爱的所有Python工具处理异构数据方面做了大量工作.
一般来说,我在PyTables中使用Fixed(以前称为"Storer")格式,因为我的工作流程是一次写入,多次读取,并且我的许多数据集的大小都是这样的,我可以将50-100个数据集加载到内存中.时间没有严重的缺点.(注意:我的大部分工作都是在具有128GB +系统内存的Opteron服务器级机器上完成的.)
但是,对于大型数据集(500MB或更高),我希望能够使用PyTables"Tables"格式的更具可伸缩性的随机访问和查询功能,这样我就可以在内存之外执行查询,然后将更小的结果集加载到内存中进行处理.然而,这里的一大障碍是写性能.是的,正如我所说,我的工作流程是一次写入,多次读取,但相对时间仍然是不可接受的.
作为一个例子,我最近在我的48核心机器上运行了一个大型的Cholesky分解,花了3分8秒(188秒).这会生成~2.2 GB的跟踪文件 - 跟踪与程序并行生成,因此没有额外的"跟踪创建时间".
我的二进制跟踪文件初始转换为pandas/PyTables格式花费了相当多的时间,但很大程度上是因为二进制格式是故意无序的,以减少跟踪生成器本身的性能影响.这与从Storer格式转换为Table格式时的性能损失无关.
我的测试最初是用pandas 0.12,numpy 1.7.1,PyTables 2.4.0和numexpr 0.20.1运行的.我的48核心机器每个核心运行2.8GHz,我正在写一个ext3文件系统,它可能(但不一定)在SSD上.
我可以在7.1秒内将整个数据集写入Storer格式的HDF5文件(生成文件大小:3.3GB).写入表格式的相同数据集(结果文件大小也是3.3GB),写入需要178.7秒.
代码如下:
with Timer() as t:
store = pd.HDFStore('test_storer.h5', 'w')
store.put('events', events_dataset, table=False, append=False)
print('Fixed format write took ' + str(t.interval))
with Timer() as t:
store = pd.HDFStore('test_table.h5', 'w')
store.put('events', events_dataset, table=True, append=False)
print('Table format write took ' + str(t.interval))
输出很简单
Fixed format write took 7.1
Table format write took 178.7
我的数据集有28,880,943行,列是基本数据类型:
node_id int64
thread_id int64
handle_id int64
type int64
begin int64
end int64
duration int64
flags int64
unique_id int64
id int64
DSTL_LS_FULL float64
L2_DMISS float64
L3_MISS float64
kernel_type float64
dtype: object
...所以我认为写入速度不应该存在任何特定于数据的问题.
我还尝试添加BLOSC压缩,以排除可能影响一种情况或另一种情况的任何奇怪的I/O问题,但压缩似乎同样会降低两者的性能.
现在,我意识到pandas文档说Storer格式提供了更快的写入速度和更快的读取速度.(我确实体验到更快的读取,因为读取Storer格式似乎需要大约2.5秒,而读取Table格式大约需要10秒.)但是,表格格式写入应该花费25倍,这似乎太过分了.只要Storer格式写.
参与PyTables或pandas的任何人都可以解释为什么写入可查询格式(显然只需要很少的额外数据)的架构(或其他)原因应该延长一个数量级？是否有希望在未来改善这一点？我喜欢参与一个项目或另一个项目的贡献,因为我的领域是高性能计算,我看到这个领域的两个项目都有一个重要的用例......但是对它做一些澄清是有帮助的.首先涉及的问题,和/或关于如何加快那些了解系统构建方式的人的建议.
编辑:
在IPython中使用%prun运行以前的测试会为Storer/Fixed格式提供以下(可读性有所降低)配置文件输出:
%prun -l 20 profile.events.to_hdf('test.h5', 'events', table=False, append=False)
3223 function calls (3222 primitive calls) in 7.385 seconds
Ordered by: internal time
List reduced from 208 to 20 due to restriction <20>
ncalls tottime percall cumtime percall filename:lineno(function)
6 7.127 1.188 7.128 1.188 {method '_createArray' of 'tables.hdf5Extension.Array' objects}
1 0.242 0.242 0.242 0.242 {method '_closeFile' of 'tables.hdf5Extension.File' objects}
1 0.003 0.003 0.003 0.003 {method '_g_new' of 'tables.hdf5Extension.File' objects}
46 0.001 0.000 0.001 0.000 {method 'reduce' of 'numpy.ufunc' objects}
表格格式如下:
%prun -l 40 profile.events.to_hdf('test.h5', 'events', table=True, append=False, chunksize=1000000)
499082 function calls (499040 primitive calls) in 188.981 seconds
Ordered by: internal time
List reduced from 526 to 40 due to restriction <40>
ncalls tottime percall cumtime percall filename:lineno(function)
29 92.018 3.173 92.018 3.173 {pandas.lib.create_hdf_rows_2d}
640 20.987 0.033 20.987 0.033 {method '_append' of 'tables.hdf5Extension.Array' objects}
29 19.256 0.664 19.256 0.664 {method '_append_records' of 'tables.tableExtension.Table' objects}
406 19.182 0.047 19.182 0.047 {method '_g_writeSlice' of 'tables.hdf5Extension.Array' objects}
14244 10.646 0.001 10.646 0.001 {method '_g_readSlice' of 'tables.hdf5Extension.Array' objects}
472 10.359 0.022 10.359 0.022 {method 'copy' of 'numpy.ndarray' objects}
80 3.409 0.043 3.409 0.043 {tables.indexesExtension.keysort}
2 3.023 1.512 3.023 1.512 common.py:134(_isnull_ndarraylike)
41 2.489 0.061 2.533 0.062 {method '_fillCol' of 'tables.tableExtension.Row' objects}
87 2.401 0.028 2.401 0.028 {method 'astype' of 'numpy.ndarray' objects}
30 1.880 0.063 1.880 0.063 {method '_g_flush' of 'tables.hdf5Extension.Leaf' objects}
282 0.824 0.003 0.824 0.003 {method 'reduce' of 'numpy.ufunc' objects}
41 0.537 0.013 0.668 0.016 index.py:607(final_idx32)
14490 0.385 0.000 0.712 0.000 array.py:342(_interpret_indexing)
39 0.279 0.007 19.635 0.503 index.py:1219(reorder_slice)
2 0.256 0.128 10.063 5.031 index.py:1099(get_neworder)
1 0.090 0.090 119.392 119.392 pytables.py:3016(write_data)
57842 0.087 0.000 0.087 0.000 {numpy.core.multiarray.empty}
28570 0.062 0.000 0.107 0.000 utils.py:42(is_idx)
14164 0.062 0.000 7.181 0.001 array.py:711(_readSlice)
编辑2:
使用pandas 0.13的预发布副本再次运行(2013年11月20日美国东部时间11点左右),表格格式的写入时间显着改善,但仍然没有"合理地"与Storer/Fixed的写入速度进行比较格式.
%prun -l 40 profile.events.to_hdf('test.h5', 'events', table=True, append=False, chunksize=1000000)
499748 function calls (499720 primitive calls) in 117.187 seconds
Ordered by: internal time
List reduced from 539 to 20 due to restriction <20>
ncalls tottime percall cumtime percall filename:lineno(function)
640 22.010 0.034 22.010 0.034 {method '_append' of 'tables.hdf5Extension.Array' objects}
29 20.782 0.717 20.782 0.717 {method '_append_records' of 'tables.tableExtension.Table' objects}
406 19.248 0.047 19.248 0.047 {method '_g_writeSlice' of 'tables.hdf5Extension.Array' objects}
14244 10.685 0.001 10.685 0.001 {method '_g_readSlice' of 'tables.hdf5Extension.Array' objects}
472 10.439 0.022 10.439 0.022 {method 'copy' of 'numpy.ndarray' objects}
30 7.356 0.245 7.356 0.245 {method '_g_flush' of 'tables.hdf5Extension.Leaf' objects}
29 7.161 0.247 37.609 1.297 pytables.py:3498(write_data_chunk)
2 3.888 1.944 3.888 1.944 common.py:197(_isnull_ndarraylike)
80 3.581 0.045 3.581 0.045 {tables.indexesExtension.keysort}
41 3.248 0.079 3.294 0.080 {method '_fillCol' of 'tables.tableExtension.Row' objects}
34 2.744 0.081 2.744 0.081 {method 'ravel' of 'numpy.ndarray' objects}
115 2.591 0.023 2.591 0.023 {method 'astype' of 'numpy.ndarray' objects}
270 0.875 0.003 0.875 0.003 {method 'reduce' of 'numpy.ufunc' objects}
41 0.560 0.014 0.732 0.018 index.py:607(final_idx32)
14490 0.387 0.000 0.712 0.000 array.py:342(_interpret_indexing)
39 0.303 0.008 19.617 0.503 index.py:1219(reorder_slice)
2 0.288 0.144 10.299 5.149 index.py:1099(get_neworder)
57871 0.087 0.000 0.087 0.000 {numpy.core.multiarray.empty}
1 0.084 0.084 45.266 45.266 pytables.py:3424(write_data)
1 0.080 0.080 55.542 55.542 pytables.py:3385(write)
我注意到在运行这些测试时,有很长一段时间写入似乎"暂停"(磁盘上的文件没有活跃增长),但在某些时段内CPU使用率也很低.
我开始怀疑一些已知的ext3限制可能与pandas或PyTables严重交互.Ext3和其他非基于范围的文件系统有时很难立即取消链接大文件,例如,即使在1GB文件的简单'rm'中,类似的系统性能(CPU使用率低,但等待时间长)也很明显.
为了澄清,在每个测试用例中,我确保在开始测试之前删除现有文件(如果有的话),以免导致任何ext3文件删除/覆盖惩罚.
但是,当使用index = None重新运行此测试时,性能会大幅提升(约为50秒,而索引时为~120).所以看起来这个过程要么继续受CPU限制(我的系统有相对较旧的AMD Opteron Istanbul CPU运行@ 2.8GHz,尽管它也有8个插槽,每个插槽有6个核心CPU,除了其中一个,所有当然,在写入过程中处于空闲状态),或者PyTables或pandas尝试操作/读取/分析文件的方式之间存在一些冲突,当文件系统已部分或完全导致文件系统导致病态错误的I/O行为时,索引是发生.
编辑3:
@ Jeff建议对较小的数据集(磁盘上为1.3 GB)进行测试,将PyTables从2.4升级到3.0.0之后,让我来到这里:
In [7]: %timeit f(df)
1 loops, best of 3: 3.7 s per loop
In [8]: %timeit f2(df) # where chunksize= 2 000 000
1 loops, best of 3: 13.8 s per loop
In [9]: %timeit f3(df) # where chunksize= 2 000 000
1 loops, best of 3: 43.4 s per loop
实际上,除了打开索引时(默认情况下),我的表现似乎在所有场景中都超过了他.然而,索引仍然似乎是一个杀手,如果我解释输出的方式top和ls我运行这些测试是正确的,仍然有一段时间没有重要的处理或任何文件写入发生(即CPU Python进程的用法接近0,文件大小保持不变).我只能假设这些是文件读取.为什么文件读取会导致速度减慢我很难理解,因为我可以在3秒内将这个磁盘中的整个3+ GB文件可靠地加载到内存中.如果它们不是文件读取,那么系统"等待"的是什么？(没有其他人登录到该计算机,并且没有其他文件系统活动.)
此时,对于相关python模块的升级版本,我的原始数据集的性能下降到下面的数字.特别感兴趣的是系统时间,我假设它至少是执行IO所花时间的上限,以及Wall时间,这似乎可能解释了这些没有写入/没有CPU活动的神秘时期.
In [28]: %time f(profile.events)
CPU times: user 0 ns, sys: 7.16 s, total: 7.16 s
Wall time: 7.51 s
In [29]: %time f2(profile.events)
CPU times: user 18.7 s, sys: 14 s, total: 32.7 s
Wall time: 47.2 s
In [31]: %time f3(profile.events)
CPU times: user 1min 18s, sys: 14.4 s, total: 1min 32s
Wall time: 2min 5s
尽管如此,索引似乎会导致我的用例显着减慢.也许我应该尝试限制索引的字段而不是简单地执行默认情况(这可能很好地索引DataFrame中的所有字段)？我不确定这可能会如何影响查询时间,尤其是在查询基于非索引字段选择的情况下.
根据Jeff的请求,生成文件的ptdump.
ptdump -av test.h5
/ (RootGroup) ''
/._v_attrs (AttributeSet), 4 attributes:
[CLASS := 'GROUP',
PYTABLES_FORMAT_VERSION := '2.1',
TITLE := '',
VERSION := '1.0']
/df (Group) ''
/df._v_attrs (AttributeSet), 14 attributes:
[CLASS := 'GROUP',
TITLE := '',
VERSION := '1.0',
data_columns := [],
encoding := None,
index_cols := [(0, 'index')],
info := {1: {'type': 'Index', 'names': [None]}, 'index': {}},
levels := 1,
nan_rep := 'nan',
non_index_axes :=
[(1, ['node_id', 'thread_id', 'handle_id', 'type', 'begin', 'end', 'duration', 'flags', 'unique_id', 'id', 'DSTL_LS_FULL', 'L2_DMISS', 'L3_MISS', 'kernel_type'])],
pandas_type := 'frame_table',
pandas_version := '0.10.1',
table_type := 'appendable_frame',
values_cols := ['values_block_0', 'values_block_1']]
/df/table (Table(28880943,)) ''
description := {
"index": Int64Col(shape=(), dflt=0, pos=0),
"values_block_0": Int64Col(shape=(10,), dflt=0, pos=1),
"values_block_1": Float64Col(shape=(4,), dflt=0.0, pos=2)}
byteorder := 'little'
chunkshape := (4369,)
autoindex := True
colindexes := {
"index": Index(6, medium, shuffle, zlib(1)).is_csi=False}
/df/table._v_attrs (AttributeSet), 15 attributes:
[CLASS := 'TABLE',
FIELD_0_FILL := 0,
FIELD_0_NAME := 'index',
FIELD_1_FILL := 0,
FIELD_1_NAME := 'values_block_0',
FIELD_2_FILL := 0.0,
FIELD_2_NAME := 'values_block_1',
NROWS := 28880943,
TITLE := '',
VERSION := '2.7',
index_kind := 'integer',
values_block_0_dtype := 'int64',
values_block_0_kind := ['node_id', 'thread_id', 'handle_id', 'type', 'begin', 'end', 'duration', 'flags', 'unique_id', 'id'],
values_block_1_dtype := 'float64',
values_block_1_kind := ['DSTL_LS_FULL', 'L2_DMISS', 'L3_MISS', 'kernel_type']]
以及更新的模块和完整数据集的另一个%prun:
%prun -l 25 %time f3(profile.events)
CPU times: user 1min 14s, sys: 16.2 s, total: 1min 30s
Wall time: 1min 48s
542678 function calls (542650 primitive calls) in 108.678 seconds
Ordered by: internal time
List reduced from 629 to 25 due to restriction <25>
ncalls tottime percall cumtime percall filename:lineno(function)
640 23.633 0.037 23.633 0.037 {method '_append' of 'tables.hdf5extension.Array' objects}
15 20.852 1.390 20.852 1.390 {method '_append_records' of 'tables.tableextension.Table' objects}
406 19.584 0.048 19.584 0.048 {method '_g_write_slice' of 'tables.hdf5extension.Array' objects}
14244 10.591 0.001 10.591 0.001 {method '_g_read_slice' of 'tables.hdf5extension.Array' objects}
458 9.693 0.021 9.693 0.021 {method 'copy' of 'numpy.ndarray' objects}
15 6.350 0.423 30.989 2.066 pytables.py:3498(write_data_chunk)
80 3.496 0.044 3.496 0.044 {tables.indexesextension.keysort}
41 3.335 0.081 3.376 0.082 {method '_fill_col' of 'tables.tableextension.Row' objects}
20 2.551 0.128 2.551 0.128 {method 'ravel' of 'numpy.ndarray' objects}
101 2.449 0.024 2.449 0.024 {method 'astype' of 'numpy.ndarray' objects}
16 1.789 0.112 1.789 0.112 {method '_g_flush' of 'tables.hdf5extension.Leaf' objects}
2 1.728 0.864 1.728 0.864 common.py:197(_isnull_ndarraylike)
41 0.586 0.014 0.842 0.021 index.py:637(final_idx32)
14490 0.292 0.000 0.616 0.000 array.py:368(_interpret_indexing)
2 0.283 0.142 10.267 5.134 index.py:1158(get_neworder)
274 0.251 0.001 0.251 0.001 {method 'reduce' of 'numpy.ufunc' objects}
39 0.174 0.004 19.373 0.497 index.py:1280(reorder_slice)
57857 0.085 0.000 0.085 0.000 {numpy.core.multiarray.empty}
1 0.083 0.083 35.657 35.657 pytables.py:3424(write_data)
1 0.065 0.065 45.338 45.338 pytables.py:3385(write)
14164 0.065 0.000 7.831 0.001 array.py:615(__getitem__)
28570 0.062 0.000 0.108 0.000 utils.py:47(is_idx)
47 0.055 0.001 0.055 0.001 {numpy.core.multiarray.arange}
28570 0.050 0.000 0.090 0.000 leaf.py:397(_process_range)
87797 0.048 0.000 0.048 0.000 {isinstance}
这是我刚才做的类似比较.它约有1/3的数据10M行.最终尺寸为1.3GB
我定义了3个定时功能:
测试固定格式(在0.12中称为Storer).这以PyTables数组格式写入
def f(df):
store = pd.HDFStore('test.h5','w')
store['df'] = df
store.close()
使用PyTables表格式以表格格式写入.不要创建索引.
def f2(df):
store = pd.HDFStore('test.h5','w')
store.append('df',df,index=False)
store.close()
与f2相同,但创建索引(通常已完成)
def f3(df):
store = pd.HDFStore('test.h5','w')
store.append('df',df)
store.close()
创建框架
In [25]: df = concat([DataFrame(np.random.randn(10000000,10)),DataFrame(np.random.randint(0,10,size=50000000).reshape(10000000,5))],axis=1)
In [26]: df
Out[26]:
<class 'pandas.core.frame.DataFrame'>
Int64Index: 10000000 entries, 0 to 9999999
Columns: 15 entries, 0 to 4
dtypes: float64(10), int64(5)
v0.12.0
In [27]: %timeit f(df)
1 loops, best of 3: 14.7 s per loop
In [28]: %timeit f2(df)
1 loops, best of 3: 32 s per loop
In [29]: %timeit f3(df)
1 loops, best of 3: 40.1 s per loop
master/v0.13.0
In [5]: %timeit f(df)
1 loops, best of 3: 12.9 s per loop
In [6]: %timeit f2(df)
1 loops, best of 3: 17.5 s per loop
In [7]: %timeit f3(df)
1 loops, best of 3: 24.3 s per loop
时间运行与OP提供的文件相同(链接如下)
In [4]: df = pd.read_hdf('test.h5','df')
In [5]: df
Out[5]:
<class 'pandas.core.frame.DataFrame'>
Int64Index: 28880943 entries, 0 to 28880942
Columns: 14 entries, node_id to kernel_type
dtypes: float64(4), int64(10)
像f1一样,固定格式
In [6]: %timeit df.to_hdf('test.hdf','df',mode='w')
1 loops, best of 3: 36.2 s per loop
像f2,表格式,没有索引
In [7]: %timeit df.to_hdf('test.hdf','df',mode='w',format='table',index=False)
1 loops, best of 3: 45 s per loop
In [8]: %timeit df.to_hdf('test.hdf','df',mode='w',format='table',index=False,chunksize=2000000)
1 loops, best of 3: 44.5 s per loop
像f3一样,表格格式带索引
In [9]: %timeit df.to_hdf('test.hdf','df',mode='w',format='table',chunksize=2000000)
1 loops, best of 3: 1min 36s per loop
像f3一样,带有索引的表格式,用blosc压缩
In [10]: %timeit df.to_hdf('test.hdf','df',mode='w',format='table',chunksize=2000000,complib='blosc')
1 loops, best of 3: 46.5 s per loop
In [11]: %timeit pd.read_hdf('test.hdf','df')
1 loops, best of 3: 10.8 s per loop
显示原始文件(test.h5,压缩,test.hdf)
In [13]: !ls -ltr test.h*
-rw-r--r-- 1 jreback users 3471518282 Nov 20 18:20 test.h5
-rw-rw-r-- 1 jreback users 649327780 Nov 20 21:17 test.hdf
有几点需要注意.
不创建索引可以在时间上产生非平凡的差异.我也相信,如果你有一个基于字符串的索引,它可以大大恶化写入时间.也就是说,您总是希望创建一个索引来快速进行检索.
你没有包括你的索引是什么,也没有包括它的排序(虽然我只认为这会产生一些小的差异).
我的例子中的写入惩罚大约是2倍(尽管我已经看到它在包含索引时间时有点大).因此你的7s(我的时间的1/2),是我写作数字的3倍是非常可疑的.我正在使用一个相当快的磁盘阵列.如果你使用基于闪存的磁盘,那么这是可能的.
master/v0.13.0(很快发布),大大改善了表的写入时间.
您可以尝试chunksize在写入数据时将参数设置为更大的数字(默认值为100000)."相对"低数字的目的是具有恒定的内存使用率.(例如,如果更大,你将使用更多的内存,理论上它应该写得更快).
与固定格式相比,表提供2个优点:1)查询检索,以及2)可附加性.读取整个表都没有利用,所以如果你只想读取整个表,那么建议使用Fixed格式.(根据我的经验,Table的灵活性大大超过了写入惩罚,但是YMMV)
底线是重复计时(使用ipython,因为它将运行多个测试).如果你可以重现你的结果,那么请发一个%prun,我会看一看.
更新:
所以这个大小的表的推荐方法是用blosc压缩并使用pandas master/0.13.0和PyTables 3.0.0
小智 5
这是一个有趣的讨论.我认为Peter在固定格式上的性能非常出色,因为格式一次写入,而且他有一个非常好的SSD(它的写入速度超过450 MB/s).
附加到表是一个更复杂的操作(必须放大数据集,并且必须检查新记录,以便我们可以确保它们遵循表的模式).这就是为什么在表中追加行通常较慢(但仍然,Jeff正在达到~70 MB/s,这是非常好的).杰夫的速度比彼得快,可能是因为他拥有更好的处理器.
最后,PyTables中的索引使用单个处理器,是的,这通常是一个昂贵的操作,所以如果你不打算在磁盘上查询数据,你应该真的禁用它.
| 归档时间： |
|
| 查看次数： |
14179 次 |
| 最近记录： |