小编Pet*_*ney的帖子

我见过各种各样的人都认为这Dataframe.explode是一种有用的方法,但它会导致比原始数据帧更多的行,这根本不是我想要的.我只是想做Dataframe相当于非常简单:

rdd.map(lambda row: row + [row.my_str_col.split('-')])

它看起来像:

col1 | my_str_col
-----+-----------
  18 |  856-yygrm
 201 |  777-psgdg

并将其转换为:

col1 | my_str_col | _col3 | _col4
-----+------------+-------+------
  18 |  856-yygrm |   856 | yygrm
 201 |  777-psgdg |   777 | psgdg

我知道pyspark.sql.functions.split(),但它导致嵌套数组列而不是我想要的两个顶级列.

理想情况下,我希望这些新列也可以命名.

我已经使用大熊猫进行研究了大约两个月,效果很好.有了大量的中型跟踪事件数据集,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 …