Nuevos comentarios sobre RevoScaleR

El reto lanzado por Revolution Analytics a SAS está relacionado con el lanzamiento por parte de la primera empresa de un paquete, RevoScaleR, diseñado para permitir el análisis de conjuntos de datos grandes. La lectura más detallada de uno de los pocos documentos técnicos que circulan sobre el paquete me invita a compartir con mis lectores mis impresiones más allá de las primeras y más someras que realicé hace unos días.

La primera es que sigo sin entender claramente cómo es y cómo funciona el nuevo formato de almacenamiento de tablas, XDF. Al menos, no es público. Aunque es un tema de investigación candente (de lo que son prueba esto, esto, esto o el mismo paquete ff de R), no está claro si reaprovecha desarrollos previos o si es una implementación desde cero.

La segunda impresión es que el nuevo paquete utiliza una notación muy SAS:

# Create function to transform data
myTransforms <- function(data){
       data$Late    <- data$ArrDelay > 15
       data$DepHour <- as.integer(data$CRSDepTime)
       data$Night   <- data$DepHour >= 20 | data$DepHour <= 5
       return(data)
}

# The rxDataStepXdf function read the existing data set, performs the
# transformations, and creates a new data set.
rxDataStepXdf( outData="ADS2",
              inData=dataName,
              transformFunc=myTransforms,
              varsToKeep=c("ArrDelay","CRSDepTime","DepTime"))

rxShowInfoXdf("ADS2", numRows=5)
# Run a logistic regression using the new variables
logitObj <- rxLogit(Late~DepHour+Night, data="ADS2", verbose=TRUE )

Pensé en un primer momento que podía ser intencional y buscando facilitar la migración de un sistema a otro. Luego, preguntándome a mí mismo qué tipo de interfaz hubiese usado yo para implementar algo parecido, no se me ocurrió nada radicalmente distinto: al tener la información en disco, los ficheros de datos se leen y se escriben: ya no se cargan en memoria. Por lo tanto, es necesario especificar fuentes y destinos de datos, qué transformaciones realizar sobre ellos, etc. Sin embargo, el nombre de la función rxDataStepXdf() sí resulta sumamente revelador.

La tercera, es que hay algo en los experimentos que describe el artículo que huele a chamusquina. Se trata de un análisis para comprobar el rendimiento del paquete a la hora de realizar una regresión sobre un conjunto de datos con 123M de filas y 29 columnas y que ocupa 13GB en disco. El estudio lo realizan con un portátil con 3GB de RAM (también con un servidor, pero eso no nos preocupa en esta entrada). Los tiempos que obtienen son:

¡Curioso! En la segunda y posteriores ejecuciones, el tiempo de proceso desciende a 4 segundos desde los casi 40 de la primera. ¿Motivo? Dizque las cachés. Y yo me pregunto, ¿cómo pueden cachear 13GB con 3GB de RAM? De ser por las cachés, la mejora en tiempos sólo podría explicarse si el fichero original ocupase menos de 3GB. ¿Será que los 13GB de fichero inicial realmente ocupan muchísimo menos (incluso menos de 3GB) en formato XDF? Porque tampoco es creíble que un portátil lea 13GB en 40 segundos. Ni mi portátil ni el de nadie. Según la Wikipedia, no cabe esperar velocidades de lectura superiores a 1000Mbits por segundo; es decir, nunca más de 125MB por segundo. Únicamente leer 13GB a esta velocidad requeriría algo más de 100 segundos.

Al autor de esta entrada se le escapa algo de lo que cuenta el artículo.

Una última salvedad: sólo R (con el paquete RevoScaleR) puede leer y generar ficheros de tipo XDF. Entonces, ¿cómo generarlos? Porque si, por ejemplo, alguien te hace llegar un fichero de texto enorme, antes de poder cargarlo con R tienes que pasarlo a formato XDF. Pero para pasarlo a XDF tienes que haberlo cargado antes en R. Etc. De nuevo, ¿me pierdo algo?

¡Quién sabe si Revolution Analytics estará usando mi paquete colbycol (a propósito, ¿lo conocéis? ¿lo habéis probado?) para realizar la primera lectura!

13 comentarios sobre “Nuevos comentarios sobre RevoScaleR

  1. dcb 4 marzo, 2011 17:26

    Hay una manera sencilla de explicarlo si no lo entiendo mal. Podría ser que los datos no se almacenen como en el formato aparente de SAS, de una pieza, sino en almacenamiento particionado físicamente en este caso diría yo que por columnas. De este modo una regrresión simple no requiere de leer 13 GB sino un par de ficheros y obviamente es fácilmente cargada en caché. Trabajar así hace que en determinadas pruebas como esta sea relativamente fácil batir los registros que da SAS con tablas muy grandes.

    Respecto a cargar ficheros , puede que los datos se generen automáticamente en el formato xdf sin tener que pasar por R, sino simplemente generando una implementación binaria adecuada a partir de la lectura de datos planos.

    Es una pena que la comunidad de R no se vuelque en la generación de un core aunque sea experimental que permita un tratamiento sobre datos muy grandes , permita estructuras en disco adecuadas a las necesidades de información que se avecinan y que permitiesen dar soporte a determinados métodos de bootstraping o similares que consumen mucha memoria sin poder ir almacenando los datos en disco a través de las iteraciones por ejemplo, lo cual sería de gran ayuda sin suponer una gran merma en el rendimiento.

  2. datanalytics 5 marzo, 2011 16:12

    @dcb
    Puede ser, puede ser que tengas razón: que sólo tengas que leer porciones de fichero. Todo es muy especulativo por el momento. Pero eso habría que explicarlo en el artículo mejor. Porque, si no, admitirás que suena como raro.

    Y estoy de acuerdo contigo en que habría que dirigir los esfuerzos de la comunidad hacia la creación de unos procedimientos que permitan de una manera simple trabajar con conjuntos de datos grandes. Por el momento, la solución más a la mano que veo es la de utilizar R en conjunción con una base de datos.

  3. dcb 6 marzo, 2011 17:11

    @datanalytics
    Cierto, suena como que quieren competir con SAS y para ello se van a situar en un nivel de opacidad más propio de SAS que de una evolución derivada de software libre.

    En lo segundo también estoy de acuerdo.. Yo sólo he probado con cierta profundidad ff y aunque puede llegar a ser útil y ágil si se conoce bien , muchas veces resulta mucho más cómodo conectarse a una BBDD directamente.

  4. datanalytics 6 marzo, 2011 17:18

    @dcb
    De todos modos, una cosa que vengo pensando hace tiempo es que podría tener futuro una solución basada en los nuevos gestores de bases de datos «orientados a columnas».

    Un cuello de botella importante al usar R junto con, p.e., Postgres (y como Postgres el 99% de los restantes DBMS) es que las tablas se almacenan en filas y R las almacena en columnas. Quiérase o no, en algún sitio hay que realizar una trasposición computacionalmente pesada.

    Pero si se pudieran «mapear» columnas de un DBMS orientado a columnas en vectores de R (y varios en un DF de R) de forma que el DF pareciese un objeto «normal» de R pero que en realidad estuviese físicamente en disco…

  5. rvaquerizo 7 marzo, 2011 14:37

    Comienza a preocuparme seriamente el presente de R. Lleva demasiados años siendo la «eterna promesa».

  6. datanalytics 7 marzo, 2011 15:18

    @rvaquerizo
    ¿No era Planck el que decía que la ciencia avanza entierro a entierro? En España avanza de prejubilación en prejubilación.

    ¿No te he hablado de mis R-clientes de latitudes más felices?

  7. dcb 7 marzo, 2011 19:32

    @datanalytics
    POr supuesto, te entiendo y comparto la idea del almacenamiento en columnas al 100%.Creo que es sin duda un a de las pocas vías de almacenamiento compatible con grandes volúmenes. En cuanto a si podría ser más o menos difícil «dar el cambiazo» y hacer un core basado en disco que resultara eficiente y 100% compatible con el leguaje en sí (transparente o casi al intérprete) no tengo mucha idea porque sinceramente no conozco demasiado las tripas de R.. La verdad es que viendo la cantidad ingente de gente que trabaja en desarrollar cosas en R se me antoja un poco raro que no se haya planteado seriamente pero… HAce no mucho vi esto

    http://www.stat.auckland.ac.nz/~ihaka/downloads/Compstat-2008.pdf

    en esta presentación

    http://www.slideshare.net/rusersla/los-angeles-r-users-group-nov-17-2010-part-2?from=ss_embed

    y como en muchos otros sitios veo divagaciones.. pero curiosamente nada que aborde la cuestión desde el punto de vista que estamos discutiendo aquí, de modo claro y atacando la raíz del problema.Quizá sea ignorancia mía, ya digo, por desconocimiento del interior más profundo de R..

  8. datanalytics 7 marzo, 2011 19:47

    @dcb
    Si te interesa el asunto de un R «a la Lisp», que es de lo que habla Ihaka, mira http://incanter.org.

    De todos modos, dentro de unos pocos años, todo cabrá en RAM. Y la diferencia entre RAM y disco duro, con la popularización de los discos de estado sólido, irá desapareciendo.

    En este sentido, el modelo R es el futuro.

  9. juan 18 octubre, 2011 23:34

    Hola

    Hace un tiempo aprendí a usar R para realizar unos cálculos con series temporales y descubrí que si las series eran muy grandes había que usar bases de datos o apañarselas para ir leyendolos a trozos . El problema es luego no puedes usar directamente paquetes como zoo, xts,….
    Al final me harté y lo dejé.

    Todo esto para preguntaros si habeis visto el programa ROOT, del CERN y gratuito.
    Está hecho desde el principio para trabajar con datos muy muy grandes, y tiene muchas funciones, pero no tiene nada para analizar series temporales como R. Vamos que estoy jodido.

  10. datanalytics 19 octubre, 2011 19:12

    @juan
    Sí, conocía ROOT y, de hecho, lo he probado alguna vez. Aunque mi C++ está más bien oxidado, tengo que reconocer.

    ¿Cómo de grandes son tus series temporales? ¿Tantísimo? ¿De cuánta RAM dispones? El de las series temporales no suele ser el ámbito en que se manejen datos _tan_ grandes.

    Puede que haya métodos de series temporales implementados sobre Hadoop que te puedan resultar útiles.

  11. Otto Wagner 20 octubre, 2011 12:31

    Para series temporales puedes usar Gretl, pero como dicen por aqui lo normal es tener pocas filas: por dias, meses, años, trimestres…

  12. Otto Wagner 20 octubre, 2011 12:37

    @datanalytics
    No sé si el comentario se ha quedado registrado, lo pongo de nuevo:

    Puedes usar Gretl (es sencillo de usar), de todas formas el numero de registros de una tabla de series temporales es pequeño ya que puede sumarizar por intervalos de tiempo, es decir, en tendrás tantas filas como dias, meses, trimestres… tengas.

    Saludos

Los comentarios están desabilitados.