Programación

Esta de hoy es una entrada muy friqui que se sirve de la casi excusa de que los creadores de Apache Spark han ganado la competición Gray Sort de 2014 para recomendar a sus lectores a estar alerta a las novedades que llegan.

Todavía colea el siglo XX y todavía pagan dinero por cosas que algún día consideraremos tan entrañables como el ZX Spectrum de 48kB tales como:

• Colorear casillas en Excel.
• Escribir pasos data en SAS.
• Tener reuniones de dos horas.
• Guardar todos los archivos en el disco duro de un portátil.
• Y otras cosas que igual un día me suelto y cuento.

Pero el futuro está a la vuelta de la esquina y los pájaros tempraneros de hoy en día, que ya saben R (porque son, como digo, pájaros tempraneros), aprenden Spark y Scala.

Uno de mis últimos pet projects tiene que ver con el análisis de las componentes conexas de unos grafos muy grandes. Como aquí pero con datos de un tamaño muchos órdenes de magnitud mayores. Usando Spark, claro. Y ya que lo cito, aprovecho la ocasión para regalar un consejo a mis lectores más jóvenes: no esperéis a los cuarenta para aprender Scala y Spark.

Voy a limitarme a copiar el código para referencia mía y de otros. Creo que se autoexplica:

Muchos cuidamos de nuestro ordenador casi como una mascota: le ponemos un nombre (a menudo escribo desde tiramisu), le hacemos algo de mantenimiento, etc. Hay quienes, incluso, decoran sus máquinas con pegatinas.

Pero llega un momento en que hay que comenzar a tratar a las máquinas no tanto como mascotas sino como rebaños. Desde una pantalla aneja a esta en la que escribo estoy manejando un clúster de más de 200 GB y 50 núcleos distribuido en varias máquinas que ni sé dónde están. Además, solo espero que crezca. Ya no cuido de una mascota; cuido de un rebaño.

Me he puesto en modo estoy serio con Spark. Lo instalé en mi ya manida máquina virtual (voy a subir una nueva versión de ella pronto), pero hoy la voy a instalar en mi portátil. Y con la idea de, en los próximos días, montar un clúster en condiciones.

Los pasos son los siguientes:

1. Ir a la página de descargas y seleccionar una versión ya precompilada. Hay varias porque Spark se enlaza con librerías relacionadas con Hadoop (aunque uno puede utilizar Spark perfectamente sin él) y hay varias versiones mutuamente incompatibles de Hadoop. Como no tengo ninguna instalada en el portátil, cualquiera me vale.
2. Descomprimir, mover el directorio a /opt y, opcionalmente, cambiar propietarios y grupos (a root).
3. Crear un enlace blando para vagos: sudo ln -s /opt/spark-1.0.1-bin-hadoop1/ /opt/spark
4. Arrancarlo (usando la interfaz para Python): /opt/spark/bin/pyspark

En la consola, ahora, se puede ejecutar:

Voy a seguir poco a poco con este tema mío tan recurrente de las factorizaciones (aproximadas) positivas de matrices (también positivas). No escribo más porque, como casi todo lo que llamamos trabajo es, simplemente ruido, las cosas que llevan a otras nunca pasan por el asunto en cuestión.

Pero hay dos descomposiciones positivas de matrices positivas bien conocidas de todos. La primera es esta: $latex X=IX$, donde $latex X$ es una matriz de dimensión nxm e $latex I$ es la cosa más parecida a la matriz identidad de dicha dimensión. No aporta gran cosa. En particular, no compresión y no comprensión de la estructura de la matriz.

Hay quienes preguntan cómo cargar con R un csv de 8GB en un portátil de 4GB de RAM. La verdad, he leído respuestas la mar de extravagantes a este tipo de cuestiones: p.e., recomendar SQLite.

Yo recomendaría Scalable Strategies for Computing with Massive Data. Entre otras cosas, porque para eso lo escribieron sus autores: para que se lea. Y porque está cargado de razón y buenos consejos.

Una cosa con la que tropezará enseguida quien lo hojee es:

No hay regla sin excepción, dicen. Para la recomendación casi única para quienes se quejan de la lentitud de R, es decir, ¡vectoriza!, he encontrado hoy una.

Sí, el artículo deja R por los suelos. En el fondo, no tanto, porque viene a decir que R es malo para lo que la documentación de R dice que es malo: véase cómo en Writing R Extensions nos advierten que la convolución is hard to do fast in interpreted R code, but easy in C code. Y el problema que tratan de resolver los autores contiene una convolución (a través de una cadena de Markov, para pasar de un nivel de capital al del siguiente periodo). Es decir, en cierta medida solo viene a confirmar que la documentación de R es buena.

Los forofos de las APIs de Madrid están de enhorabuena. El jueves 3 de julio tendrán ocasión de juntarse y celebrar un APIDays Mediterránea informal en MartinaCocina.

El resto de la información para los interesados, aquí.

Rescato aquí para mis lectores dos citas de un artículo de 1983, Computer Intensive Methods in Statistics, de Efron y Diaconis, por dos motivos: su valor intrínseco y que consideren leer el resto, particularmente el principio y el final.

La primera es (con mi traducción):

[…] el ordenador está cambiando la teoría de la estadística. Arriba hemos examinado nuevas teorías que han surgido a causa del ordenador. Otro cambio evidente es de los conjuntos de datos enormes que están disponibles a causa de la memoria de los ordenadores. Además, el ordenador permite usar métodos tradicionales para resolver problemas más grandes. El análisis de componentes principales es un buen ejemplo: fue inventado antes de que fuese realmente práctico.

Anuncio algo que no he conseguido hacer: agrupar grafos por topología. Pero no me he quedado lejos. Y espero que si alguien tiene alguna idea al respecto, nos lo haga saber al resto en la coda.

Contexto (disfrazado). Hay usuarios que tienen correos electrónicos. La relación esperada es de uno a uno. Pero la realidad es, como siempre, mucho más compleja: hay usuarios que tienen varios correos y correos compartidos por varios usuarios.