Límites prácticos de la trama de datos R

Question

He estado leyendo acerca de cómo read.table no es eficiente para archivos de datos de gran tamaño. También cómo R no es adecuado para grandes conjuntos de datos. Así que me preguntaba dónde puedo encontrar cuáles son los límites prácticos y las tablas de rendimiento para (1) Leer datos de varios tamaños (2) trabajando con datos de distintos tamaños.

En efecto, quiero saber cuando el rendimiento se deteriora y cuando llego a un bloqueo de carretera. También cualquier comparación contra C++/MATLAB u otros lenguajes sería realmente útil. finalmente, si hay alguna comparación de rendimiento especial para Rcpp y RInside, ¡sería genial!

Answer 1

R es adecuado para grandes conjuntos de datos, pero puede que tenga que cambiar su forma de trabajar un poco de lo que le enseñan los libros de texto introductorios. Hice una publicación en Big Data for R que procesa un conjunto de datos de 30 GB y que puede encontrar útil para la inspiración.

Las fuentes habituales de información para comenzar son High-Performance Computing Task View y la lista de correo de R-SIG HPC en R-SIG HPC.

El límite principal que tiene que trabajar es un límite histórico en la longitud de un vector a 2^31-1 elementos que no sería tan malo si R no almacenara matrices como vectores. (El límite es la compatibilidad con algunas bibliotecas BLAS.)

Analizamos regularmente los registros de datos de llamadas de telecomunicaciones y las bases de datos de marketing con millones de clientes que utilizan R, por lo que nos complacerá hablar más si está interesado.

Answer 2

Solo puedo responder al de read.table, ya que no tengo ninguna experiencia con grandes conjuntos de datos. read.table funciona mal si no proporciona colClasses argumentos. Sin él, read.table tiene como valor predeterminado NA e intenta adivinar una clase de cada columna, y eso puede ser lento, especialmente cuando tiene muchas columnas.

Answer 3

Los límites físicos surgen del uso de índices de 32 bits en vectores. Como resultado, se permiten vectores de hasta 2^31 - 1. Las matrices son vectores con dimensiones, por lo que el producto de nrow(mat) y ncol(mat) debe estar dentro de 2^31 - 1. Los marcos de datos y las listas son vectores generales, por lo que cada componente puede tomar 2^31 - 1 entradas, que para marcos de datos significa que puede tener que muchas filas y columnas. Para las listas, puede tener 2^31 - 1 componentes, cada uno de 2^31 - 1 elementos. Esto se extrae de un reciente posting por Duncan Murdoch en respuesta a una Q en R-Ayuda

Ahora que todo tiene que caber en la RAM con R estándar, por lo que podría ser un límite más apremiante, pero la tarea High-Performance Computing Ver otros ha mencionado contiene detalles de paquetes que pueden eludir los problemas en memoria.

Answer 4

1) El manual de importación/exportación R debe ser el primer puerto de escala para preguntas sobre la importación de datos: hay muchas opciones y lo que funcionará para usted podría ser muy específico.

http://cran.r-project.org/doc/manuals/R-data.html

read.table rendimiento específicamente ha mejorado en gran medida si se utilizan las opciones proporcionadas a la misma, en particular colClasses, comment.char y nrows - esto se debe a que esta información tiene que ser deducido de los datos en sí, que puede ser costoso .

2) Existe un límite específico para la longitud (número total de elementos) para cualquier vector, matriz, matriz, columna en un data.frame o lista.Esto se debe a un índice de 32 bits utilizado bajo el capó, y es cierto para 32 bits y 64 bits R. El número es 2^31 - 1. Este es el número máximo de filas para un data.frame, pero es tan grande que es mucho más probable que se quede sin memoria incluso para vectores individuales antes de comenzar a recopilar varios de ellos.

Ver help(Memory-limits) y help(Memory) para más detalles.

Un solo vector de esa longitud tomará muchos gigabytes de memoria (depende del tipo y modo de almacenamiento de cada vector - 17.1 para numérico) por lo que es poco probable que sea un límite adecuado a menos que realmente esté presionando cosas. Si realmente necesita pasar las cosas por la memoria del sistema disponible (aquí es obligatorio 64 bits), vale la pena considerar las técnicas de base de datos estándar descritas en el manual de importación/exportación o las opciones de archivo asignadas en memoria (como el paquete ff). La Computación de alto rendimiento CRAN Task View High Performance es un buen recurso para este fin de cosas.

Por último, si usted tiene pilas de memoria RAM (16 GB o más) y necesitan 64 bits indexación que podría venir en una versión futura de R. http://www.mail-archive.com/r-help@r-project.org/msg92035.html

Además, Ross Ihaka se analizan algunas de las decisiones históricas y futuro instrucciones para un R como el lenguaje en los documentos y habla aquí: http://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks

Answer 5

al leer grandes archivos csv x GB <=> y.1e6 rows creo data.table::fread (en la versión 1.8.7) es la alternativa más rápida se puede conseguir haciendo install.packages("data.table", repos="http://R-Forge.R-project.org")

Por lo general, gana un factor de 5 a 10 (y todos los sep, row.names etc. son tratados por la función en sí). Si tiene muchos archivos y una computadora lo suficientemente decente (varios núcleos), le recomiendo usar el paquete parallel (como parte de R.2.14) para cargar un archivo por núcleo.

última vez que hice esta entre la carga monothreaded con read.csv y multiproceso en 4 núcleos uso de fread Fui a partir de 5 minutos a 20 segundos