Ich habe sehr große Tabellen (30 Millionen Zeilen), die ich als Datenrahmen in R laden möchte. Es read.table()hat viele praktische Funktionen, aber es scheint, dass die Implementierung viel Logik enthält, die die Dinge verlangsamen würde. In meinem Fall gehe ich davon aus, dass ich die Spaltentypen im Voraus kenne, die Tabelle keine Spaltenüberschriften oder Zeilennamen enthält und keine pathologischen Zeichen enthält, über die ich mir Sorgen machen muss.

Ich weiß, dass das Lesen einer Tabelle als Liste mit scan()sehr schnell sein kann, z.

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

Einige meiner Versuche, dies in einen Datenrahmen umzuwandeln, scheinen jedoch die Leistung des oben genannten um den Faktor 6 zu verringern:

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

Gibt es einen besseren Weg, dies zu tun? Oder ganz andere Herangehensweise an das Problem?

Ein Update, einige Jahre später

Diese Antwort ist alt und R ist weitergegangen. Das Optimieren read.table, um ein bisschen schneller zu laufen, hat nur einen geringen Nutzen. Ihre Optionen sind:

1. Verwendung vroomaus dem tidyverse-Paket vroomzum Importieren von Daten aus durch CSV / Tabulatoren getrennten Dateien direkt in ein R-Tibble.

2. Verwenden von freadin data.tablezum Importieren von Daten aus durch CSV / Tabulatoren getrennten Dateien direkt in R. Siehe die Antwort von mnel .

3. Verwendung read_tablein readr(auf CRAN ab April 2015). Dies funktioniert ähnlich wie freadoben. Die Readme-Datei im Link erklärt den Unterschied zwischen den beiden Funktionen ( readrbehauptet derzeit, "1,5-2x langsamer" zu sein als data.table::fread).

4. read.csv.rawfrom iotoolsbietet eine dritte Option zum schnellen Lesen von CSV-Dateien.

5. Versuchen Sie, so viele Daten wie möglich in Datenbanken anstatt in Flatfiles zu speichern. (Daten sind nicht nur ein besseres permanentes Speichermedium, sondern werden auch in einem schnelleren Binärformat an und von R übergeben.) read.csv.sqlIm sqldfPaket werden, wie in der Antwort von JD Long beschrieben , Daten in eine temporäre SQLite-Datenbank importiert und dann gelesen Siehe auch: das RODBCPaket, und die Rückseite hängt vom Abschnitt der DBIPaketseite ab . MonetDB.Rgibt Ihnen einen Datentyp, der vorgibt, ein Datenrahmen zu sein, aber tatsächlich eine MonetDB darunter ist, was die Leistung erhöht. Daten mit seiner monetdb.read.csvFunktion importieren. dplyrErmöglicht die direkte Arbeit mit Daten, die in verschiedenen Datenbanktypen gespeichert sind.

6. Das Speichern von Daten in Binärformaten kann auch zur Verbesserung der Leistung hilfreich sein. Verwenden Sie saveRDS/ readRDS(siehe unten), die h5oder rhdf5Pakete für das HDF5-Format oder write_fst/ read_fstaus dem fstPaket.

Die ursprüngliche Antwort

Es gibt ein paar einfache Dinge zu versuchen, ob Sie read.table oder scan verwenden.

1. Set nrows= die Anzahl der Datensätze in Ihren Daten ( nmaxin scan).

2. Stellen Sie sicher, dass comment.char=""die Interpretation von Kommentaren deaktiviert ist.

3. Definieren Sie die Klassen jeder Spalte explizit mit colClassesin read.table.

4. Die Einstellung multi.line=FALSEkann auch die Leistung beim Scannen verbessern.

Wenn keines dieser Dinge funktioniert, verwenden Sie eines der Profilierungspakete, um festzustellen, welche Zeilen die Dinge verlangsamen. Vielleicht können Sie eine gekürzte Version von read.tablebasierend auf den Ergebnissen schreiben .

Die andere Alternative besteht darin, Ihre Daten zu filtern, bevor Sie sie in R einlesen.

Wenn das Problem darin besteht, dass Sie es regelmäßig einlesen müssen, verwenden Sie diese Methoden, um die Daten einmal einzulesen, und speichern Sie dann den Datenrahmen als binären Blob mit save saveRDS, dann können Sie es das nächste Mal schneller mit abrufen load readRDS.

Hier ist ein Beispiel, das freadvon verwendetdata.table 1.8.7

Die Beispiele stammen von der freadHilfeseite zu , mit den Timings auf meinem 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]

Standard-Lesetabelle

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

optimierte read.table

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

fread

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

Zusammenfassend:

##    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

Ich habe diese Frage anfangs nicht gesehen und einige Tage später eine ähnliche Frage gestellt. Ich werde meine vorherige Frage aufschreiben, aber ich dachte, ich würde hier eine Antwort hinzufügen, um zu erklären, wie ich das früher gemacht sqldf()habe.

Es wurde wenig darüber diskutiert, wie 2 GB oder mehr Textdaten am besten in einen R-Datenrahmen importiert werden können. Gestern habe ich einen Blog-Beitrag geschrieben, in dem es darum geht sqldf(), die Daten als Staging-Bereich in SQLite zu importieren und sie dann von SQLite in R zu übernehmen. Das funktioniert sehr gut für mich. Ich konnte 2 GB (3 Spalten, 40 mm Zeilen) Daten in <5 Minuten abrufen. Im Gegensatz dazu lief der read.csvBefehl die ganze Nacht und wurde nie ausgeführt.

Hier ist mein Testcode:

Richten Sie die Testdaten ein:

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

Ich habe R neu gestartet, bevor ich die folgende Importroutine ausgeführt habe:

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

Ich habe die folgende Zeile die ganze Nacht laufen lassen, aber sie wurde nie abgeschlossen:

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

Seltsamerweise hat jahrelang niemand den unteren Teil der Frage beantwortet, obwohl dies ein wichtiger Teil ist - data.framees handelt sich lediglich um Listen mit den richtigen Attributen. Wenn Sie also große Datenmengen haben, möchten Sie diese nicht as.data.framefür eine Liste verwenden oder ähnliches. Es ist viel schneller, eine Liste einfach in einen Datenrahmen zu "verwandeln":

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

Dadurch wird keine Kopie der Daten erstellt, sodass diese sofort verfügbar sind (im Gegensatz zu allen anderen Methoden). Es wird davon ausgegangen, dass Sie bereits eingestellt habennames() die Liste bereits entsprechend festgelegt haben.

[Was das Laden großer Datenmengen in R readBin()betrifft - ich persönlich speichere sie spaltenweise in Binärdateien und verwende sie -, ist dies bei weitem die schnellste Methode (außer Mapping) und wird nur durch die Festplattengeschwindigkeit begrenzt. Das Parsen von ASCII-Dateien ist im Vergleich zu Binärdaten von Natur aus langsam (auch in C).]

Dies wurde zuvor in der R-Hilfe gefragt , daher lohnt es sich, dies zu überprüfen.

Ein Vorschlag war, readChar()das Ergebnis mit strsplit()und zu verwenden und dann zu manipulieren substr(). Sie können sehen, dass die Logik von readChar viel geringer ist als die von read.table.

Ich weiß nicht, ob Speicher ein Problem ist, aber vielleicht möchten Sie auch einen Blick auf das HadoopStreaming- Paket werfen . Hierbei wird Hadoop verwendet , ein MapReduce-Framework, das für den Umgang mit großen Datenmengen entwickelt wurde. Dazu würden Sie die Funktion hsTableReader verwenden. Dies ist ein Beispiel (aber es hat eine Lernkurve, um Hadoop zu lernen):

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)

Die Grundidee hier ist, den Datenimport in Blöcke aufzuteilen. Sie könnten sogar so weit gehen, eines der parallelen Frameworks (z. B. Schnee) zu verwenden und den Datenimport parallel durchzuführen, indem Sie die Datei segmentieren. Höchstwahrscheinlich jedoch für große Datenmengen, die nicht helfen, da Sie auf Speicherbeschränkungen stoßen. Aus diesem Grund ist das Reduzieren von Karten ein besserer Ansatz.

Eine Alternative ist die Verwendung des vroomPakets. Jetzt auf CRAN. vroomLädt nicht die gesamte Datei, sondern indiziert, wo sich die einzelnen Datensätze befinden, und wird später gelesen, wenn Sie sie verwenden.

Zahlen Sie nur für das, was Sie verwenden.

Siehe Einführung in vroom , Erste Schritte mit vroom und den vroom-Benchmarks .

Die grundlegende Übersicht ist, dass das anfängliche Lesen einer großen Datei viel schneller ist und nachfolgende Änderungen an den Daten möglicherweise etwas langsamer sind. Je nachdem, was Sie verwenden, ist dies möglicherweise die beste Option.

Sehen Sie sich unten ein vereinfachtes Beispiel aus den vroom-Benchmarks an . Die wichtigsten Teile sind die superschnellen Lesezeiten, aber leicht säende Vorgänge wie Aggregate usw.

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

Ein kleiner zusätzlicher erwähnenswerter Punkt. Wenn Sie eine sehr große Datei haben, können Sie die Anzahl der Zeilen (wenn kein Header vorhanden ist) im laufenden Betrieb berechnen (wobei bedGraphsich der Name Ihrer Datei in Ihrem Arbeitsverzeichnis befindet):

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

Sie können das dann entweder in 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

Oft denke ich, dass es nur eine gute Praxis ist, größere Datenbanken in einer Datenbank zu halten (z. B. Postgres). Ich benutze nichts zu viel Größeres als (nrow * ncol) ncell = 10M, was ziemlich klein ist; Ich stelle jedoch häufig fest, dass R nur dann speicherintensive Diagramme erstellen und speichern soll, wenn ich aus mehreren Datenbanken abfrage. In der Zukunft von 32-GB-Laptops werden einige dieser Arten von Speicherproblemen verschwinden. Der Reiz, eine Datenbank zum Speichern der Daten zu verwenden und dann den Speicher von R für die resultierenden Abfrageergebnisse und Diagramme zu verwenden, kann dennoch nützlich sein. Einige Vorteile sind:

(1) Die Daten bleiben in Ihrer Datenbank geladen. Sie stellen in pgadmin einfach wieder eine Verbindung zu den gewünschten Datenbanken her, wenn Sie Ihren Laptop wieder einschalten.

(2) Es ist wahr, dass R viel mehr raffinierte statistische und grafische Operationen ausführen kann als SQL. Ich denke jedoch, dass SQL besser dafür ausgelegt ist, große Datenmengen abzufragen als 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)

Ich lese Daten sehr schnell mit dem neuen arrow Paket. Es scheint in einem ziemlich frühen Stadium zu sein.

Insbesondere verwende ich das Parkett- Säulenformat. Dies konvertiert zurück zu adata.frame in R , aber Sie können noch tiefere Beschleunigungen erzielen, wenn Sie dies nicht tun. Dieses Format ist praktisch, da es auch von Python aus verwendet werden kann.

Mein Hauptanwendungsfall hierfür ist ein ziemlich zurückhaltender RShiny-Server. Aus diesen Gründen ziehe ich es vor, Daten an die Apps anzuhängen (dh außerhalb von SQL), und benötige daher eine geringe Dateigröße sowie Geschwindigkeit.

Dieser verlinkte Artikel bietet Benchmarking und einen guten Überblick. Ich habe unten einige interessante Punkte zitiert.

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

Dateigröße

Das heißt, die Parkettdatei ist halb so groß wie die komprimierte CSV-Datei. Einer der Gründe, warum die Parkettdatei so klein ist, ist die Wörterbuchcodierung (auch als "Wörterbuchkomprimierung" bezeichnet). Die Wörterbuchkomprimierung kann zu einer wesentlich besseren Komprimierung führen als die Verwendung eines Allzweck-Byteekompressors wie LZ4 oder ZSTD (die im FST-Format verwendet werden). Parkett wurde entwickelt, um sehr kleine Dateien zu erstellen, die schnell zu lesen sind.

Lesegeschwindigkeit

Bei der Steuerung nach Ausgabetyp (z. B. Vergleich aller R data.frame-Ausgaben miteinander) sehen wir, dass die Leistung von Parkett, Feder und FST innerhalb eines relativ kleinen Bereichs voneinander liegt. Gleiches gilt für die Ausgaben von pandas.DataFrame. data.table :: fread ist mit der Dateigröße von 1,5 GB beeindruckend konkurrenzfähig, liegt jedoch bei der 2,5-GB-CSV hinter den anderen zurück.

Unabhängiger Test

Ich habe ein unabhängiges Benchmarking für einen simulierten Datensatz von 1.000.000 Zeilen durchgeführt. Grundsätzlich habe ich ein paar Dinge durcheinander gebracht, um die Komprimierung herauszufordern. Außerdem habe ich ein kurzes Textfeld mit zufälligen Wörtern und zwei simulierten Faktoren hinzugefügt.

Daten

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

Lesen und Schreiben

Das Schreiben der Daten ist einfach.

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)

Das Lesen der Daten ist ebenfalls einfach.

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)

Ich habe das Lesen dieser Daten anhand einiger konkurrierender Optionen getestet und dabei etwas andere Ergebnisse erzielt als mit dem obigen Artikel, der erwartet wird.

Diese Datei ist bei weitem nicht so groß wie der Benchmark-Artikel. Vielleicht ist das der Unterschied.

Tests

• rds: test_data.rds (20,3 MB)
• parquet2_native: (14,9 MB mit höherer Komprimierung und as_data_frame = FALSE)
• parquet2: test_data2.parquet (14,9 MB mit höherer Komprimierung)
• Parkett: test_data.parquet (40,7 MB)
• fst2: test_data2.fst (27,9 MB mit höherer Komprimierung)
• fst: test_data.fst (76,8 MB)
• fread2: test_data.csv.gz (23,6 MB)
• fread: test_data.csv (98,7 MB)
• Federpfeil: test_data.feather (157,2 MB lesen mit arrow)
• Feder: test_data.feather (157,2 MB lesen mit feather)

Beobachtungen

Für diese bestimmte Datei freadist eigentlich sehr schnell. Ich mag die kleine Dateigröße aus dem stark komprimierten parquet2Test. Ich kann die Zeit investieren, um mit dem nativen Datenformat zu arbeiten, anstatt mit einemdata.frame wenn ich die Beschleunigung wirklich brauche.

Hier fstist auch eine gute Wahl. Ich würde entweder das stark komprimierte fstFormat oder das stark komprimierte Format verwenden, parquetje nachdem, ob ich den Kompromiss zwischen Geschwindigkeit oder Dateigröße benötigte.

Anstelle der herkömmlichen read.table ist fread meiner Meinung nach eine schnellere Funktion. Wenn Sie zusätzliche Attribute angeben, z. B. nur die erforderlichen Spalten auswählen, Spalten und Zeichenfolgen als Faktoren angeben, wird der Zeitaufwand für den Import der Datei verkürzt.

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

Ich habe alles oben versucht und [readr] [1] den besten Job gemacht. Ich habe nur 8 GB RAM

Schleife für 20 Dateien, jeweils 5 GB, 7 Spalten:

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