快速读取非常大的表作为数据框

Question

我有非常大的表（3000 万行），我想在 R 中作为数据帧加载它们。 read.table()有很多方便的功能，但似乎实现中有很多逻辑会减慢事情下来。 就我而言，我假设我提前知道列的类型，该表不包含任何列标题或行名称，并且没有任何我必须担心的病态字符。

我知道使用scan()将表格作为列表读取可能非常快，例如：

datalist <- scan('myfile',sep='\t',list(url='',popularity=0,mintime=0,maxtime=0)))

但是我将其转换为数据帧的一些尝试似乎将上述性能降低了 6 倍：

df <- as.data.frame(scan('myfile',sep='\t',list(url='',popularity=0,mintime=0,maxtime=0))))

有没有更好的方法来做到这一点？ 或者很可能完全不同的方法来解决这个问题？

Answer 1

几年后的更新

这个答案很旧，R 已经继续前进。 调整read.table运行得更快一点好处很少。 您的选择是：

1. 使用vroom包vroom将数据从 csv/tab-delimited 文件直接导入 R tibble。 见赫克托的回答。

2. 在data.table使用fread将数据从 csv/制表符分隔的文件直接导入 R。请参阅mnel 的回答。

3. 在readr使用read_table （2015 年 4 月在 CRAN 上）。 这很像上面的fread 。 链接中的自述文件解释了这两个函数之间的区别（ readr目前声称比data.table::fread “慢 1.5-2 倍”）。

4. read.csv.raw的iotools提供了第三个选项来快速读取 CSV 文件。

5. 尝试在数据库而不是平面文件中存储尽可能多的数据。 （除了作为一个更好的永久存储介质，数据被传递到和来自R以二进制格式，这是更快。） read.csv.sql在sqldf包，如在JD龙的回答，进口数据到临时SQLite 数据库，然后将其读入 R。另见： RODBC包，以及DBI包页面的反向依赖部分。MonetDB.R为您提供了一种数据类型，它假装是一个数据框，但实际上是一个 MonetDB，从而提高了性能。 使用monetdb.read.csv函数导入数据。 dplyr允许您直接处理存储在多种类型数据库中的数据。

6. 以二进制格式存储数据对于提高性能也很有用。 使用saveRDS / readRDS （见下文），该h5或rhdf5为HDF5格式，或包write_fst / read_fst从fst包。

---

原来的答案

无论您使用 read.table 还是 scan，都可以尝试一些简单的方法。

1. 设置nrows =数据中的记录数（ scan nmax ）。

2. 确保comment.char=""关闭注释的解释。

3. 使用read.table colClasses显式定义每列的类。

4. 设置multi.line=FALSE也可以提高扫描性能。

如果这些都不起作用，则使用其中一个分析包来确定哪些行会减慢速度。 也许您可以根据结果编写一个精简版的read.table 。

另一种选择是在将数据读入 R 之前过滤数据。

或者，如果问题是你必须定期读取它，那么使用这些方法一次读取数据，然后将数据帧保存为二进制 blob save saveRDS ，然后下次您可以更快地检索它load readRDS 。

Answer 2

这是一个利用来自data.table 1.8.7 的fread的示例

示例来自帮助页面fread ，以及我的 windows XP Core 2 duo E8400 上的计时。

library(data.table)
# Demo speedup
n=1e6
DT = data.table( a=sample(1:1000,n,replace=TRUE),
                 b=sample(1:1000,n,replace=TRUE),
                 c=rnorm(n),
                 d=sample(c("foo","bar","baz","qux","quux"),n,replace=TRUE),
                 e=rnorm(n),
                 f=sample(1:1000,n,replace=TRUE) )
DT[2,b:=NA_integer_]
DT[4,c:=NA_real_]
DT[3,d:=NA_character_]
DT[5,d:=""]
DT[2,e:=+Inf]
DT[3,e:=-Inf]

标准读表

write.table(DT,"test.csv",sep=",",row.names=FALSE,quote=FALSE)
cat("File size (MB):",round(file.info("test.csv")$size/1024^2),"\n")    
## File size (MB): 51 

system.time(DF1 <- read.csv("test.csv",stringsAsFactors=FALSE))        
##    user  system elapsed 
##   24.71    0.15   25.42
# second run will be faster
system.time(DF1 <- read.csv("test.csv",stringsAsFactors=FALSE))        
##    user  system elapsed 
##   17.85    0.07   17.98

优化读表

system.time(DF2 <- read.table("test.csv",header=TRUE,sep=",",quote="",  
                          stringsAsFactors=FALSE,comment.char="",nrows=n,                   
                          colClasses=c("integer","integer","numeric",                        
                                       "character","numeric","integer")))


##    user  system elapsed 
##   10.20    0.03   10.32

恐惧

require(data.table)
system.time(DT <- fread("test.csv"))                                  
 ##    user  system elapsed 
##    3.12    0.01    3.22

sqldf

require(sqldf)

system.time(SQLDF <- read.csv.sql("test.csv",dbname=NULL))             

##    user  system elapsed 
##   12.49    0.09   12.69

# sqldf as on SO

f <- file("test.csv")
system.time(SQLf <- sqldf("select * from f", dbname = tempfile(), file.format = list(header = T, row.names = F)))

##    user  system elapsed 
##   10.21    0.47   10.73

ff / ffdf

 require(ff)

 system.time(FFDF <- read.csv.ffdf(file="test.csv",nrows=n))   
 ##    user  system elapsed 
 ##   10.85    0.10   10.99

总之：

##    user  system elapsed  Method
##   24.71    0.15   25.42  read.csv (first time)
##   17.85    0.07   17.98  read.csv (second time)
##   10.20    0.03   10.32  Optimized read.table
##    3.12    0.01    3.22  fread
##   12.49    0.09   12.69  sqldf
##   10.21    0.47   10.73  sqldf on SO
##   10.85    0.10   10.99  ffdf

Answer 3

我最初没有看到这个问题，几天后问了一个类似的问题。 我将把我之前的问题记下来，但我想我会在这里添加一个答案来解释我如何使用sqldf()来做到这一点。

关于将 2GB 或更多文本数据导入 R 数据帧的最佳方式，有 一些讨论。 昨天我写了一篇关于使用sqldf()将数据导入 SQLite 作为暂存区，然后将其从 SQLite 吸入 R 的博客文章。这对我来说非常有效。 我能够在 < 5 分钟内提取 2GB（3 列，40 毫米行）的数据。 相比之下， read.csv命令整夜运行，从未完成。

这是我的测试代码：

设置测试数据：

bigdf <- data.frame(dim=sample(letters, replace=T, 4e7), fact1=rnorm(4e7), fact2=rnorm(4e7, 20, 50))
write.csv(bigdf, 'bigdf.csv', quote = F)

在运行以下导入例程之前，我重新启动了 R：

library(sqldf)
f <- file("bigdf.csv")
system.time(bigdf <- sqldf("select * from f", dbname = tempfile(), file.format = list(header = T, row.names = F)))

我让以下行整夜运行，但从未完成：

system.time(big.df <- read.csv('bigdf.csv'))

Answer 4

奇怪的是，多年来没有人回答问题的底部，尽管这是一个重要的问题—— data.frame只是具有正确属性的列表，所以如果你有大量数据，你不想使用as.data.frame或类似的列表。 简单地将列表“转换”为就地数据框要快得多：

attr(df, "row.names") <- .set_row_names(length(df[[1]]))
class(df) <- "data.frame"

这不会复制数据，因此它是即时的（与所有其他方法不同）。 它假定您已经相应地在列表中设置了names() 。

[至于将大数据加载到 R - 就个人而言，我将它们按列转储到二进制文件中并使用readBin() - 这是迄今为止最快的方法（除了 mmapping）并且仅受磁盘速度的限制。 与二进制数据相比，解析 ASCII 文件本质上很慢（即使在 C 中）。]

Answer 5

这是之前在R-Help上问过的，所以值得回顾一下。

一个建议是使用readChar()然后使用strsplit()和substr()对结果进行字符串操作。 可以看到readChar涉及的逻辑比read.table少很多。

我不知道这里是否存在内存问题，但您可能还想查看HadoopStreaming包。 这使用了 Hadoop ，它是一个 MapReduce 框架，专为处理大型数据集而设计。 为此，您将使用 hsTableReader 函数。 这是一个例子（但它有一个学习 Hadoop 的学习曲线）：

str <- "key1\t3.9\nkey1\t8.9\nkey1\t1.2\nkey1\t3.9\nkey1\t8.9\nkey1\t1.2\nkey2\t9.9\nkey2\"
cat(str)
cols = list(key='',val=0)
con <- textConnection(str, open = "r")
hsTableReader(con,cols,chunkSize=6,FUN=print,ignoreKey=TRUE)
close(con)

这里的基本思想是将数据导入分成块。 您甚至可以使用并行框架之一（例如，snow）并通过对文件进行分段来并行运行数据导入，但很可能对于大型数据集无济于事，因为您将遇到内存限制，这就是为什么 map-reduce 是一种更好的方法。

Answer 6

另一种方法是使用vroom包。 现在在 CRAN 上。 vroom不会加载整个文件，它会索引每条记录所在的位置，并在您稍后使用它时读取。

只为你使用的东西付费。

请参阅vroom 简介、vroom 入门和vroom 基准测试。

基本概述是，初始读取大文件会快得多，随后对数据的修改可能会稍微慢一些。 因此，根据您的用途，它可能是最佳选择。

请参阅下面vroom 基准测试中的一个简化示例，要查看的关键部分是超快的读取时间，但像聚合等操作略有减少。

package                 read    print   sample   filter  aggregate   total
read.delim              1m      21.5s   1ms      315ms   764ms       1m 22.6s
readr                   33.1s   90ms    2ms      202ms   825ms       34.2s
data.table              15.7s   13ms    1ms      129ms   394ms       16.3s
vroom (altrep) dplyr    1.7s    89ms    1.7s     1.3s    1.9s        6.7s

Answer 7

我正在使用新的arrow包非常快速地读取数据。 它似乎处于相当早期的阶段。

具体来说，我使用的是镶木地板柱状格式。 这将转换回 R 中的data.frame ，但如果不这样做，您可以获得更深的加速。 这种格式很方便，因为它也可以从 Python 中使用。

我的主要用例是在相当受限的 RShiny 服务器上。 由于这些原因，我更喜欢将数据附加到应用程序（即 SQL 之外），因此需要小文件大小和速度。

这篇链接文章提供了基准测试和一个很好的概述。 我在下面引用了一些有趣的观点。

https://ursalabs.org/blog/2019-10-columnar-perf/

文件大小

也就是说，Parquet 文件的大小只有 gzip 压缩的 CSV 文件的一半。 Parquet 文件如此小的原因之一是因为字典编码（也称为“字典压缩”）。 与使用通用字节压缩器（如 LZ4 或 ZSTD（用于 FST 格式））相比，字典压缩可以产生明显更好的压缩。 Parquet 旨在生成非常小的文件，可以快速读取。

读取速度

当按输出类型控制时（例如，将所有 R 数据帧输出相互比较），我们看到 Parquet、Feather 和 FST 的性能彼此相差很小。 pandas.DataFrame 输出也是如此。 data.table::fread 与 1.5 GB 文件大小的竞争令人印象深刻，但在 2.5 GB CSV 上落后于其他文件。

---

独立测试

我对 1,000,000 行的模拟数据集进行了一些独立的基准测试。 基本上我洗了一堆东西来尝试挑战压缩。 我还添加了一个随机单词的短文本字段和两个模拟因素。

数据

library(dplyr)
library(tibble)
library(OpenRepGrid)

n <- 1000000

set.seed(1234)
some_levels1 <- sapply(1:10, function(x) paste(LETTERS[sample(1:26, size = sample(3:8, 1), replace = TRUE)], collapse = ""))
some_levels2 <- sapply(1:65, function(x) paste(LETTERS[sample(1:26, size = sample(5:16, 1), replace = TRUE)], collapse = ""))


test_data <- mtcars %>%
  rownames_to_column() %>%
  sample_n(n, replace = TRUE) %>%
  mutate_all(~ sample(., length(.))) %>%
  mutate(factor1 = sample(some_levels1, n, replace = TRUE),
         factor2 = sample(some_levels2, n, replace = TRUE),
         text = randomSentences(n, sample(3:8, n, replace = TRUE))
         )

读和写

写入数据很容易。

library(arrow)

write_parquet(test_data , "test_data.parquet")

# you can also mess with the compression
write_parquet(test_data, "test_data2.parquet", compress = "gzip", compression_level = 9)

读取数据也很容易。

read_parquet("test_data.parquet")

# this option will result in lightning fast reads, but in a different format.
read_parquet("test_data2.parquet", as_data_frame = FALSE)

我针对几个竞争选项测试了读取这些数据，并且确实得到了与上面文章略有不同的结果，这是预期的。

这个文件远没有基准文章那么大，所以也许这就是区别。

测试

• rds： test_data.rds (20.3 MB)
• parquet2_native: (14.9 MB 压缩更高， as_data_frame = FALSE )
• parquet2： test_data2.parquet（14.9 MB，压缩率更高）
• 镶木地板： test_data.parquet (40.7 MB)
• fst2： test_data2.fst（27.9 MB，压缩率更高）
• fst : test_data.fst (76.8 MB)
• fread2: test_data.csv.gz (23.6MB)
• fread: test_data.csv (98.7MB)
• feather_arrow： test_data.feather（157.2 MB 用arrow读取）
• 羽毛： test_data.feather（157.2 MB 用feather读取）

观察

对于这个特定文件， fread实际上非常快。 我喜欢高度压缩的parquet2测试中的小文件大小。 如果我真的需要加快速度，我可能会花时间使用本机数据格式而不是data.frame 。

这里fst也是不错的选择。 我会使用高度压缩的fst格式或高度压缩的parquet具体取决于我是否需要速度或文件大小的权衡。

Answer 8

值得一提的小附加点。 如果您有一个非常大的文件，您可以使用（其中bedGraph是您工作目录中的文件名）动态计算行数（如果没有标题）：

>numRow=as.integer(system(paste("wc -l", bedGraph, "| sed 's/[^0-9.]*\\([0-9.]*\\).*/\\1/'"), intern=T))

然后您可以在read.csv 、 read.table ...

>system.time((BG=read.table(bedGraph, nrows=numRow, col.names=c('chr', 'start', 'end', 'score'),colClasses=c('character', rep('integer',3)))))
   user  system elapsed 
 25.877   0.887  26.752 
>object.size(BG)
203949432 bytes

Answer 9

很多时候我认为将较大的数据库保存在数据库中是一种很好的做法（例如 Postgres）。 我不使用比 (nrow * ncol) ncell = 10M 大太多的东西，这非常小； 但我经常发现我希望 R 仅在从多个数据库查询时创建和保存内存密集型图。 在 32 GB 笔记本电脑的未来，其中一些类型的内存问题将消失。 但是使用数据库来保存数据然后使用 R 的内存来生成查询结果和图形的魅力仍然可能有用。 一些优点是：

(1) 数据保持加载在您的数据库中。 当您重新打开笔记本电脑时，您只需在 pgadmin 中重新连接到您想要的数据库。

(2) R 确实比 SQL 可以做更多漂亮的统计和图形操作。 但我认为 SQL 比 R 更适合查询大量数据。

# Looking at Voter/Registrant Age by Decade

library(RPostgreSQL);library(lattice)

con <- dbConnect(PostgreSQL(), user= "postgres", password="password",
                 port="2345", host="localhost", dbname="WC2014_08_01_2014")

Decade_BD_1980_42 <- dbGetQuery(con,"Select PrecinctID,Count(PrecinctID),extract(DECADE from Birthdate) from voterdb where extract(DECADE from Birthdate)::numeric > 198 and PrecinctID in (Select * from LD42) Group By PrecinctID,date_part Order by Count DESC;")

Decade_RD_1980_42 <- dbGetQuery(con,"Select PrecinctID,Count(PrecinctID),extract(DECADE from RegistrationDate) from voterdb where extract(DECADE from RegistrationDate)::numeric > 198 and PrecinctID in (Select * from LD42) Group By PrecinctID,date_part Order by Count DESC;")

with(Decade_BD_1980_42,(barchart(~count | as.factor(precinctid))));
mtext("42LD Birthdays later than 1980 by Precinct",side=1,line=0)

with(Decade_RD_1980_42,(barchart(~count | as.factor(precinctid))));
mtext("42LD Registration Dates later than 1980 by Precinct",side=1,line=0)

Answer 10

而不是传统的 read.table 我觉得 fread 是一个更快的功能。 指定其他属性，例如仅选择所需的列、指定 colclasses 和 string 作为因子将减少导入文件所需的时间。

data_frame <- fread("filename.csv",sep=",",header=FALSE,stringsAsFactors=FALSE,select=c(1,4,5,6,7),colClasses=c("as.numeric","as.character","as.numeric","as.Date","as.Factor"))

Answer 11

我已经尝试了以上所有方法，[readr][1] 做得最好。 我只有 8GB 内存

循环 20 个文件，每个 5GB，7 列：

read_fwf(arquivos[i],col_types = "ccccccc",fwf_cols(cnpj = c(4,17), nome = c(19,168), cpf = c(169,183), fantasia = c(169,223), sit.cadastral = c(224,225), dt.sitcadastral = c(226,233), cnae = c(376,382)))

Answer 12

我想以最简单的形式贡献基于 Spark 的解决方案：

# Test Data ---------------------------------------------------------------

set.seed(123)
bigdf <-
    data.frame(
        dim = sample(letters, replace = T, 4e7),
        fact1 = rnorm(4e7),
        fact2 = rnorm(4e7, 20, 50)
    )
tmp_csv <- fs::file_temp(pattern = "big_df", ext = ".csv")
readr::write_csv(x = bigdf, file = tmp_csv)

# Spark -------------------------------------------------------------------

# Installing if needed
# sparklyr::spark_available_versions()
# sparklyr::spark_install()

library("sparklyr")
sc <- spark_connect(master = "local")

# Uploading CSV
system.time(tbl_big_df <- spark_read_csv(sc = sc, path = tmp_csv))

Spark 生成了相当不错的结果：

>> system.time(tbl_big_df <- spark_read_csv(sc = sc, path = tmp_csv))
   user  system elapsed 
  0.278   0.034  11.747 

这是在 32GB 内存的 MacBook Pro 上测试的。

评论

Spark，通常不应该能够“赢得”针对速度优化的包。 不过，我想使用 Spark 贡献一个答案：

• 对于某些使用 Spark 无法正常工作的评论和答案，可能是一个可行的替代方案
• 从长远来看，将尽可能多的数据data.frame可能会在以后被证明是有问题的，因为在该对象上尝试其他操作并达到架构的性能范围

我认为对于这样的问题，应该考虑处理 1e7 行或更多行 Spark 的任务。 即使有可能将这些数据“ data.frame ”到单个data.frame它也感觉不对。 在部署模型等时，该对象可能难以使用并产生问题。