Archive for noviembre, 2009

Tip de rendimiento: Usar compresión LZO para archivos de entrada en Hadoop

miércoles, noviembre 18th, 2009

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.

Reduce empezando antes que termine Map

lunes, noviembre 16th, 2009

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.

Alternativa al Plug-in de Hadoop para Eclipse

jueves, noviembre 5th, 2009

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.