Обновление, появившееся несколько лет спустя

Это старый ответ, и R пошел дальше. Настройка read.table для более быстрой работы имеет мало пользы. Возможны следующие варианты:

1. Использование vroom из пакета tidyverse vroom для импорта данных из файлов csv / с разделителями табуляцией прямо в тиббл R. См. ответ Гектора.

2. Использование fread в _ 5_ для импорта данных из файлов csv / с разделителями табуляции непосредственно в R. См. ответ отmnel.

3. Использование read_table в _ 7_ (на CRAN с апреля 2015 г.). Это работает так же, как fread выше. readme в ссылке объясняет разницу между двумя функциями (readr в настоящее время утверждает, что она в 1,5-2 раза медленнее, чем data.table::fread).

4. read.csv.raw из _ 12_ предоставляет третий вариант для быстрого чтения файлов CSV.

5. Пытаться хранить как можно больше данных в базах данных, а не в плоских файлах. (Помимо того, что это лучший постоянный носитель, данные передаются в R и из R в двоичном формате, что происходит быстрее.) _ 13_ в sqldf, как описано в ответе JD Long, импортирует данные во временную базу данных SQLite и затем считывает их. в R. См. также: пакет RODBC и обратное зависит от раздела страницы DBI package. MonetDB.R предоставляет вам тип данных, который притворяется data, но на самом деле это MonetDB, повышающий производительность. Импортируйте данные с помощью функции monetdb.read.csv. dplyr позволяет работать напрямую с данными, хранящимися в нескольких типах база данных.

6. Хранение данных в двоичных форматах также может быть полезно для повышения производительности. Используйте _20 _ / _ 21_ (см. Ниже), h5 или _ 23_ пакеты для формата HDF5 или _24 _ / _ 25_ из _ 26_.

Исходный ответ

Есть несколько простых вещей, которые можно попробовать, независимо от того, используете ли вы read.table или scan.

1. Установите nrows = количество записей в ваших данных (nmax в scan).

2. Убедитесь, что comment.char="" отключена интерпретация комментариев.

3. Явно определите классы каждого столбца, используя colClasses в read.table.

4. Установка multi.line=FALSE также может улучшить производительность при сканировании.

Если ничего из этого не работает, используйте один из пакетов профилирования, чтобы определить, какие линии замедляют работу. Возможно, вы сможете написать урезанную версию read.table на основе результатов.

Другой альтернативой является фильтрация ваших данных перед их чтением в R.

Или, если проблема в том, что вам нужно регулярно читать его, используйте эти методы для однократного чтения данных, а затем сохраните фрейм данных как двоичный большой двоичный объект с помощью _ 35_ _ 36_, затем в следующий раз вы сможете получить его быстрее с помощью _ 37_ readRDS.

Вот пример, в котором используется fread из data.table 1.8.7

Примеры взяты со страницы справки на 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

Сначала я не видел этого вопроса и задал аналогичный вопрос несколько дней спустя. Я собираюсь ответить на свой предыдущий вопрос, но подумал, что добавлю здесь ответ, чтобы объяснить, как я использовал sqldf() для этого.

Было небольшое обсуждение наилучшего способа для импорта 2 ГБ или более текстовых данных во фрейм данных R. Вчера я написал сообщение в блоге об использовании sqldf() для импорта данных в SQLite в качестве промежуточной области, а затем засасывать его из SQLite в R. Это очень хорошо работает для меня. Я смог загрузить 2 ГБ (3 столбца, 40-миллиметровые строки) данных за ‹5 минут. Напротив, команда 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'))

Как ни странно, в течение многих лет никто не отвечал на нижнюю часть вопроса, даже несмотря на то, что это важный вопрос - data.frames - это просто списки с правильными атрибутами, поэтому, если у вас есть большие данные, вы не хотите использовать as.data.frame или аналогичные для списка . Гораздо быстрее просто "превратить" список во фрейм данных на месте:

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

Это не делает копию данных, поэтому она выполняется немедленно (в отличие от всех других методов). Предполагается, что вы уже указали names() в списке соответственно.

[Что касается загрузки больших данных в R - лично я выгружаю их по столбцам в двоичные файлы и использую readBin() - это, безусловно, самый быстрый метод (кроме mmapping), и он ограничен только скоростью диска. Анализ файлов ASCII по своей сути медленный (даже в C) по сравнению с двоичными данными.]

Ранее это было спросили в 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)

Основная идея здесь - разбить импорт данных на фрагменты. Вы даже можете зайти так далеко, чтобы использовать одну из параллельных сред (например, снег) и запустить импорт данных параллельно, сегментируя файл, но, скорее всего, для больших наборов данных это не поможет, поскольку вы столкнетесь с ограничениями памяти, поэтому map-reduce - лучший подход.

Альтернативой является использование пакета 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

Я очень быстро читаю данные с помощью нового пакета arrow. Похоже, он находится на довольно ранней стадии.

В частности, я использую столбчатый формат паркет. Это преобразуется обратно в data.frame в R, но вы можете получить еще большее ускорение, если этого не сделаете. Этот формат удобен, так как его можно использовать и из Python.

Мой основной вариант использования для этого - на довольно ограниченном сервере RShiny. По этим причинам я предпочитаю хранить данные прикрепленными к приложениям (т.е. вне SQL), и поэтому требую небольшой размер файла, а также скорость.

В этой связанной статье представлен сравнительный анализ и хороший обзор. Ниже я привел несколько интересных моментов.

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

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 МБ)
• parquet2_native: (14,9 МБ с более высоким сжатием и as_data_frame = FALSE)
• parquet2: test_data2.parquet (14,9 МБ с более высоким сжатием)
• паркет: test_data.parquet (40,7 МБ)
• fst2: test_data2.fst (27,9 МБ с более высоким сжатием)
• fst: test_data.fst (76,8 МБ)
• fread2: test_data.csv.gz (23,6 МБ)
• fread: test_data.csv (98,7 МБ)
• Pen_arrow: test_data.feather (157,2 МБ при чтении с arrow)
• перо: test_data.feather (157,2 МБ при чтении с feather)

Наблюдения

Для этого конкретного файла fread действительно работает очень быстро. Мне нравится небольшой размер файла из теста parquet2 с высокой степенью сжатия. Я могу потратить время на работу с собственным форматом данных, а не data.frame, если мне действительно нужно ускорение.

Здесь fst тоже отличный выбор. Я бы использовал либо сильно сжатый fst формат, либо сильно сжатый parquet, в зависимости от того, нужен ли мне компромисс между скоростью или размером файла.

Стоит упомянуть несколько дополнительных моментов. Если у вас очень большой файл, вы можете на лету вычислить количество строк (если нет заголовка), используя (где 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

Часто я думаю, что хранить большие базы данных внутри базы данных (например, Postgres) - это просто хорошая практика. Я не использую ничего слишком большого, чем (nrow * ncol) ncell = 10M, что довольно мало; но я часто обнаруживаю, что хочу, чтобы R создавал и сохранял графики с интенсивным использованием памяти только во время запроса из нескольких баз данных. В будущем ноутбуков с 32 ГБ памяти исчезнут некоторые из этих проблем с памятью. Но привлекательность использования базы данных для хранения данных и последующего использования памяти 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)

Мне кажется, что вместо обычной read.table более быстрая функция - fread. Указание дополнительных атрибутов, таких как выбор только необходимых столбцов, указание классов и строк в качестве факторов, сократит время, необходимое для импорта файла.

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"))

Я перепробовал все вышеперечисленное, и [readr] [1] справился лучше всех. У меня всего 8гб оперативной памяти

Цикл на 20 файлов по 5гб, 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)))