【问题标题】:Fastest method to reformat terabytes of data重新格式化数 TB 数据的最快方法
【发布时间】:2019-02-11 01:00:51
【问题描述】:

我有 100 个文件,每个文件 10 个 GB。我需要重新格式化文件并组合成更可用的表格格式,以便对数据进行分组、求和、平均等。使用 Python 重新格式化数据需要一个多星期的时间。即使我将其重新格式化为表格后,我也不知道它是否对于数据框来说太大了,但一次一个问题。

谁能建议一种更快的方法来重新格式化文本文件?我会考虑任何 C++、perl 等。

样本数据:

Scenario:  Modeling_5305 (0.0001)

Position:  NORTHERN UTILITIES SR NT,

"  ","THEO/Effective Duration","THEO/Yield","THEO/Implied Spread","THEO/Value","THEO/Price","THEO/Outstanding Balance","THEO/Effective Convexity","ID","WAL","Type","Maturity Date","Coupon Rate","POS/Position Units","POS/Portfolio","POS/User Defined 1","POS/SE Cash 1","User Defined 2","CMO WAL","Spread Over Yield",

"2017/12/31",16.0137 T,4.4194 % SEMI 30/360,0.4980 % SEMI 30/360,"6,934,452.0000 USD","6,884,052.0000 USD","7,000,000.0000 USD",371.6160 T,CachedFilterPartitions-PL_SPLITTER.2:665876C#3,29.8548 T,Fixed Rate Bond,2047/11/01,4.3200 % SEMI 30/360,"70,000.0000",All Portfolios,030421000,0.0000 USD,FRB,N/A,0.4980 % SEMI 30/360,

"2018/01/12",15.5666 T,4.8499 % SEMI 30/360,0.4980 % SEMI 30/360,"6,477,803.7492 USD","6,418,163.7492 USD","7,000,000.0000 USD",356.9428 T,CachedFilterPartitions-PL_SPLITTER.2:665876C#3,29.8219 T,Fixed Rate Bond,2047/11/01,4.3200 % SEMI 30/360,"70,000.0000",All Portfolios,030421000,0.0000 USD,FRB,N/A,0.4980 % SEMI 30/360,

Scenario:  Modeling_5305 (0.0001)

Position:  OLIVIA ISSUER TR SER A (A,

"  ","THEO/Effective Duration","THEO/Yield","THEO/Implied Spread","THEO/Value","THEO/Price","THEO/Outstanding Balance","THEO/Effective Convexity","ID","WAL","Type","Maturity Date","Coupon Rate","POS/Position Units","POS/Portfolio","POS/User Defined 1","POS/SE Cash 1","User Defined 2","CMO WAL","Spread Over Yield",

"2017/12/31",1.3160 T,19.0762 % SEMI 30/360,0.2990 % SEMI 30/360,"3,862,500.0000 USD","3,862,500.0000 USD","5,000,000.0000 USD",2.3811 T,CachedFilterPartitions-PL_SPLITTER.2:681071AA4,1.3288 T,Interest Rate Index Linked Note,2019/05/30,0.0000 % MON 30/360,"50,000.0000",All Portfolios,010421002,0.0000 USD,IRLIN,N/A,0.2990 % SEMI 30/360,

"2018/01/12",1.2766 T,21.9196 % SEMI 30/360,0.2990 % SEMI 30/360,"3,815,391.3467 USD","3,815,391.3467 USD","5,000,000.0000 USD",2.2565 T,CachedFilterPartitions-PL_SPLITTER.2:681071AA4,1.2959 T,Interest Rate Index Linked Note,2019/05/30,0.0000 % MON 30/360,"50,000.0000",All Portfolios,010421002,0.0000 USD,IRLIN,N/A,0.2990 % SEMI 30/360,

我想重新格式化这个 csv 表,以便导入数据框:

Position, Scenario, TimeSteps, THEO/Value

NORTHERN UTILITIES SR NT, Modeling_5305, 2018/01/12, 6477803.7492

OLIVIA ISSUER TR SER A (A, Modeling_5305, 2018/01/12, 3815391.3467

【问题讨论】:

  • 根据我的经验,最大的瓶颈是您用来访问/操作 csv 或其他文件格式的库。你用什么图书馆?您是否尝试过其他库?为什么一个简单的 bash 脚本不能解决问题?

标签: python pandas bigdata


【解决方案1】:

当您必须处理大文件或大量文件时,存在两大瓶颈。一个是您的文件系统,它受 HDD 或 SSD(您的存储介质)、与存储介质的连接和您的操作系统的限制。通常你不能改变它。但是你要问自己,我的最高速度是多少?系统读写速度有多快?你永远不会比这更快。 最大速度的粗略估计是读取所有数据所需的时间加上写入所有数据所需的时间。

另一个瓶颈是您用来进行更改的库。并非所有 Python 包都是平等的,存在巨大的速度差异。我建议在一个小的测试样本上尝试多种方法,直到找到适合您的方法。

请记住,大多数文件系统喜欢读取或写入大量垃圾数据。所以你应该尽量避免交替读一行然后写一行的情况。换句话说,不仅库很重要,而且你如何使用它。

不同的编程语言,虽然它们可能为这项任务提供了一个很好的库并且可能是一个很好的想法,但不会以任何有意义的方式加速这个过程(所以你不会得到 10 倍的速度或任何东西)。

【讨论】:

  • 数据位于千兆连接的网络文件存储中。我可以将它移动到与文件存储建立 10Gb 环连接的服务器上。我正在尝试使用“打开”文件并逐行浏览。也尝试过 perl 但这也是逐行单线程。您有什么可用的批处理方法或多线程进程的建议吗?我确实注意到,当我从 Python 2.7 迁移到 3.5 时,我使用“open”命令的转换程序明显变慢了(在 i/o 中慢了大约 5 倍)。 3.6 稍快,但远不及 2.7。
  • 再一次,python 的版本或一般的编程语言与速度无关。您必须了解如何读取大量垃圾数据并将它们存储在缓冲区中,然后再将它们批量写回。你在python中逐行阅读并不意味着你使用的包是逐行阅读。
  • 另外,你用什么包来做python?尤其是一些 CSV 包非常慢。
  • 我没有导入除 sys 和 pandas 之外的任何包。使用 open(file,'r') 打开文件并使用 open(file,'w', newline = '\r\n') 写入。写作是大块的。使用“for line in file:”逐行遍历。
  • 尝试在您的代码上使用 pylint 并打开一个新问题,如果您知道瓶颈在哪里。或者寻找一个可以满足您需求的软件包。
【解决方案2】:

我会使用带有内存映射的 C/C++。

使用内存映射,您可以像处理一个大字节数组一样遍历数据(这也将阻止数据从内核空间复制到用户空间(在 Windows 上,不确定 Linux)。

对于非常大的文件,您可以一次映射一个块(例如 10GB)。

对于写入,使用缓冲区(比如 1MB)存储结果,然后每次将该缓冲区写入文件(使用 fwrite())。

无论您做什么,都不要使用流式 I/O 或 readline()

该过程所花费的时间不应超过(或至少不会长太多)将文件复制到磁盘(或通过网络,因为您使用网络文件存储)所花费的时间。

如果您可以选择,请将数据写入与您正在读取的磁盘不同的(物理)磁盘。

【讨论】:

  • 这太棒了。一旦我弄清楚如何进行内存映射,我会尝试一下。谢谢。
  • @J.Sung 你是为 Windows 还是 Linux 编程?
  • 我通常在 Windows 中构建和测试,然后将其移至 linux 服务器。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-07-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多