Como parte de ESPOLciencia, el 20 de enero tuvimos una vídeo-conferencia titulada “The State of the AWS Cloud” a cargo de Jinesh Varia, un Evangelist de los AWS. La conferencia tuvo una excelente acogida, entre estudiantes, profesionales e investigadores. Si bien algunos estudiantes de la FIEC ya estaban familiarizados con estos servicios al haberlos utilizado en mi materia de graduación, para otros el concer sobre estos fue algo nuevo.

Para los que les pareció interesante la charla, recomiendo leer el whitepaper “Architecting for the Cloud: Best Practices”, el cual proporciona ejemplos y casos de mejores prácticas en el uso de los AWS.

Como hubo interés de investigadores y profesores de usar los AWS, pongo a disposición también el enlace de los fondos del programa AWS in Education.

Según el MIT Review, un grupo de investigadores de la Universidad de California, Berkeley está trababajdo en un proyecto llamado BOOM que facilitará la creación de programas que corran en las nubes. La meta del proyecto BOOM (Berkeley Orders Of Magnitude) es facilitar la construcción de sistemas distribuidos que sean mucho más escalables, usando mucho menos código. La idea es que el desarrollador se pueda preocupar del flujo de datos del sistema, y no de las complejidades del sistema distribuido como tal.

Las “nuevas” técnicas de BOOM están basadas en técnicas de bases de datos originalmente desarrolladas en los 80s; específicamente, en un lenguaje llamado Datalog. Para ser precisos, el ambiente de desarrollo de alto nivel de BOOM se llama Bloom, y está basado en el lenguaje Dedalus. Los creadores de Dedalus lo han descrito como Datalog en tiempo y espacio; es una adaptación de Datalog que permite expresar sistemas distribuidos como un conjunto de invariantes lógicas. A su vez, Datalog es un lenguaje de consultas y reglas para bases de datos que se deriva de Prolog.

El libro The Fourth Paradigm (disponible en-línea) parece ser muy interesante y busca motivar una nueva oleada de investigación basada en procesamiento masivo de datos. A través de varios ensayos, se argumenta que los nuevos avances tecnológicos se basarán en descubrimientos posibles gracias al desarrollo actual de técnicas computacionales avanzadas que permiten a los investigadores manipular y explorar datasets masivos.

Kevin Weil de Twitter (a quien mencioné en mi entrada anterior) acaba de publicar en el blog de Cloudera un tutorial sobre como usar archivos con compresión LZO. La compresión LZO resulta más adecuada que los algoritmos gzip y bz2 para el procesamiento masivo de datos con Hadoop. Gzip no puede ser usado en Hadoop porque un bloque (chunk) independiente de un gran archivo no puede descomprimirse sin conocer la información de los bloques anteriores; es decir, no se puede trabajar en paralelo con pedazos de archivos grandes. Bz2 sí puede ser usado en Hadoop, pero tiene la desventaja de ser muy lento, lo cual hace que una gran parte de lo que se gana en reducir E/S al usar compresión, se pierde debido a la sobrecarga de CPU requerida para las operaciones de descompresión. LZO tiene la ventaja de poder descomprimirse en paralelo y de manera muy rápida, lo que lo hace ideal para Hadoop.

En los gráficos que ilustran las implementaciones MapReduce podemos ver una “barrera” entre la fase Map y la Reduce. Una “barrera” es un mecanismo de sincronización entre procesos que espera a que todos los procesos de un lado de la barrera terminen antes que empiecen los procesos del otro lado. En este caso, eso significa que la fase Map debe terminar antes que empiece la fase Reduce. Este comportamiento parece no verse plasmado en Hadoop, en donde podemos ver que la fase Reduce empieza antes que terminen los Maps. Por ejemplo:

09/11/14 10:58:50 INFO mapred.JobClient: map 79% reduce 18%
09/11/14 10:58:54 INFO mapred.JobClient: map 79% reduce 19%
09/11/14 10:58:55 INFO mapred.JobClient: map 80% reduce 19%
09/11/14 10:58:58 INFO mapred.JobClient: map 80% reduce 20%
09/11/14 10:59:00 INFO mapred.JobClient: map 81% reduce 20%
09/11/14 10:59:04 INFO mapred.JobClient: map 82% reduce 20%
09/11/14 10:59:05 INFO mapred.JobClient: map 82% reduce 21%
09/11/14 10:59:08 INFO mapred.JobClient: map 82% reduce 22%

Recientemente, en un thread en la lista common-user de Hadoop se justificó muy bien este comportamiento.

David Howell dijo: “The first 2/3 of the reduce phase (as reported by the progress meters) are all about getting the map results from the map tasktracker to the reduce tasktracker and sorting them. The real reduce happens in the last third, and that part won’t start until all of the maps are done. ”

Kevin Weil (líder del equipo de Analytics de Twitter) dijo: “The first third of the reduce phase is really the shuffle, where map outputs get sent to and collected at their respective refucers. You’ll see this transfer happening, and the “reduce” creeping up towards 33%, towards the end of your map phase.  The 33% mark is where the real barrier is.”

Lo que quiere decir que la fase Reduce no empieza realmente hasta que termina la fase Map. Ese porcentaje de “Reduce” que se ve avanzando en paralelo con los Maps, en realidad es la llamada fase de “Shuffle and Sort” que copia y ordena los valores intermedios generados por los Mappers antes de que puedan ser procesados por los Reducers.

En clase algunos tuvieron problemas con el plug-in de Hadoop para Eclipse. Este problema se debe a que el mantenimiento del plug-in ha sido descontinuado. Leí en un e-mail (y respuestas) enviado a la lista common-user de Hadoop y se puede solucionar el problema re-compilando el plug-in. Pero al parecer una mejor alternativa sería trabajar con el Karmasphere Studio for Hadoop basado en Netbeans.

Un estudio reciente publicado por una profesora de la Universidad de Toronto y gente de Google ha encontrado que los errores en memoria DRAM (memoria principal) son mucho  más comúnes de lo que se pensaba anteriormente. Esto tiene implicaciones importantes en los sistemas actuales, sobre todo para data centers implementados con componentes de bajo costo (los cuales vienen sin mecanismos de corrección de errores para la RAM).

A continuación, listo las conclusiones finales de la investigación:

1. We found the incidence of memory errors and the range of error rates across different DIMMs to be much higher than previously reported.
2. Memory errors are strongly correlated.
3. The incidence of CEs increases with age, while the incidence of UEs decreases with age (due to re-placements).
4. There is no evidence that newer genera-tion DIMMs have worse error behavior.
5. Within the range of temperatures our production systems experience in the field, temperature hasa surprisingly low effect on memory errors.
6. Error rates are strongly correlated withutilization.
7. Error rates are unlikely to be dominatedby soft errors.

Un artículo publicado en Computerworld indica que un equipo de investigadores de Yale (que incluye a Silberchatz, el autor del libro que uso en la materia Sistemas Operativos) han desarrollado un híbrido entre una base de datos relacional y Hadoop, denominada HadoopDB.

Según uno de los profesores del equipo de investigación HadoopDB, se diferencia de otros productos comerciales existentes en que:

[...] unlike already-developed projects and vendors such as Aster Data, Greenplum or Hive, HadoopDB “is not a hybrid simply at the language/interface level. It is a hybrid at a deeper, systems implementation level.”

En el artículo de Computerworld, mecionan también HadoopDB podría ser de interés a empresas de la Web 2.0 y otros miembros del creciente movimiento “NoSQL”.

En una entrada anterior mencionaba lo caro que puede ser mantener un data center. Una alternativa para los usuarios finales serían las nubes virtuales, creadas a través de la donación de ciclos no utilizados de computadores personales. La idea no es nueva, y de hecho tuvo mediano éxito con la plataforma BOINC, usada por proyectos como SETI@home.

La verdad no me queda claro cuál sería la diferencia entre una nube virtual y un servicio de Internet computing (como BOINC), excepto—tal vez—la interfaz proporcionada al usuario final.

Y hablando de BOINC y MapReduce, MapReduce es uno de los 13 enanos identificados por investigadores de Berkeley. Estos “enanos” representan diferentes métodos algorítmicos que capturan patrones computacionales y de comunicaciones. La idea es que estos patrones puedan ser usados para evaluar modelos y arquitecturas de programación paralela. En la página que describe el “enano” MapReduce hay un comentario que indica que BOINC puede ser visto como un “specification framework” para problemas MapReduce (que indica es básicamente una generalización del enano antes llamado Monte Carlo).

Uno de los grupos de la materia de graduación me comentó que estaba teniendo problemas implementando un sistema de recomendaciones usando Mahout (específicamente, Taste), debido a que tenían problemas de insuficiencia de memoria. Debe haber una manera de solucionar el problema, pero como alternativa pienso que podrían analizar utilizar el algoritmo descrito en el paper “Pairwise Document Similarity in Large Collections with MapReduce“. Encontré una entrada en un blog detallando el uso de este algoritmo, y un tutorial que muestra cómo implementarlo usando Elastic MapReduce.