2013-07-11 21 views
11

Chciałem wiedzieć, czy istnieje ograniczenie liczby wierszy, które można odczytać za pomocą funkcji data.table fread. Pracuję z tabelą z 4 miliardami wierszy, 4 kolumnami, około 40 GB. Wygląda na to, że fread odczyta tylko pierwsze ~ 840 milionów wierszy. Nie daje żadnych błędów, ale wraca do znaku zachęty R, tak jakby odczytał wszystkie dane!Limit wierszy dla tabeli danych w R przy użyciu fidry

Rozumiem, że fidera nie używa się obecnie w "prod use" i chciałem się dowiedzieć, czy był jakiś czas na wdrożenie wersji prod-release.

Powodem Używam data.table jest to, że dla plików takich rozmiarów, jest niezwykle skuteczny przy przetwarzaniu danych w porównaniu do ładowania pliku w data.frame itp

W tej chwili staram 2 inne alternatywy -

1) Za pomocą skanowania i przekazywania do data.table

data.table(matrix(scan("file.csv",what="integer",sep=","),ncol=4)) 

Resulted in -- 
Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, : 
    too many items 

2) Przełamując plik na wiele pojedynczych segmentów z limitem ok. 500 milionów wierszy przy użyciu Uniksa dzieli i czyta je sekwencyjnie ... a następnie przechwytuje pliki sekwencyjnie w plik fread - nieco uciążliwy, ale wydaje się być jedynym praktycznym rozwiązaniem.

Myślę, że może istnieć sposób Rcpp to zrobić jeszcze szybciej, ale nie jestem pewien, jak to jest ogólnie realizowane.

Z góry dziękuję.

+1

Upewnij się, że nie jest niczym niezwykłym w pliku w ostatnim wierszu, który został odczytany lub linii po tym, a następnie [Akceptuj] (https: // r-Forge. r-project.org/tracker/?group_id=240) raport o błędzie lub skontaktuj się z pakietem mantainer. – Roland

+0

Czy na pewno masz wystarczającą ilość pamięci RAM? Czy pracujesz z 64-bitowym R? – eddi

+0

Nie, niekoniecznie jest szybszy sposób z Rcpp, ponieważ Matt już używa mmap. Sprawdź dokumentację systemu operacyjnego pod kątem limitów wywołania mmap. Miliardy mogą naciskać to ... –

Odpowiedz

8

Udało mi się to osiągnąć, wykorzystując opinie z innego wpisu na Stackoverflow. Proces był bardzo szybki i odczytano 40 GB danych w około 10 minut przy użyciu iteracyjnie odczytywania. Foreach-dopar nie działał, gdy był uruchamiany przez siebie, aby odczytywać pliki na nowe dane. Tabele sekwencyjnie ze względu na pewne ograniczenia, które są również wymienione na poniższej stronie.

Uwaga: lista plików (file_map) wytworzono po prostu działa -

file_map <- list.files(pattern="test.$") # Replace pattern to suit your requirement 

mclapply with big objects - "serialization is too large to store in a raw vector"

Cytując -

collector = vector("list", length(file_map)) # more complex than normal for speed 

for(index in 1:length(file_map)) { 
reduced_set <- mclapply(file_map[[index]], function(x) { 
    on.exit(message(sprintf("Completed: %s", x))) 
    message(sprintf("Started: '%s'", x)) 
    fread(x)    # <----- CHANGED THIS LINE to fread 
}, mc.cores=10) 
collector[[index]]= reduced_set 

} 

# Additional line (in place of rbind as in the URL above) 

for (i in 1:length(collector)) { rbindlist(list(finalList,yourFunction(collector[[i]][[1]]))) } 
# Replace yourFunction as needed, in my case it was an operation I performed on each segment and joined them with rbindlist at the end. 

Moja funkcja zawiera pętlę przy użyciu Foreach dopar że wykonywane przez kilka rdzeni na plik, jak określono w file_map. Pozwoliło mi to używać dopara bez napotkania "zbyt dużego błędu serializacji" podczas pracy z połączonym plikiem.

Kolejnym pomocnym post jest na - loading files in parallel not working with foreach + data.table

Powiązane problemy