Archive for the ‘Desarrollo’ Category

The Eucalyptus Open-source Cloud-computing System

martes, junio 15th, 2010

Esta entrada es la primera de varias que publicaré durante los próximos meses, resumiendo papers importantes relacionados al tema de cloud computing.

Eucalyptus es un proyecto open-source que permite levantar clústeres bajo demanda, con nodos virtualizados (Xen). A más de ser un proyecto de código abierto, tiene la gran ventaja de implementar el API de los AWS (EC2 y S3), de tal manera que es compatible con las herramientas desarrolladas para esa plataforma.

El paper no entra en muchos detalles, pero sí menciona las principales decisiones de diseño y componentes del mismo.

ESPOLciencia: Jinesh Varia sobre “The State of the AWS Cloud”

viernes, enero 22nd, 2010

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.

BOOM y Datalog: Nuevas alternativas para programación en las nubes

lunes, diciembre 21st, 2009

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.

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.

Sistemas de recomendación con Hadoop

miércoles, julio 22nd, 2009

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.

Hadoop input formats

martes, junio 23rd, 2009

A más del TextInputFormat (cada registro es una línea de un archivo de texto) usado por defecto, Hadoop soporta varios formatos de entrada para los mappers. Por ejemplo,

  • WholeFileInputFormat: Cada registro es un archivo completo. No utiliza keys (NullWritable). Los valores son instancias de BytesWritable. Usando esta clase como formato de entrada para los mappers, nos permite asegurar que un mapper reciba el contenido de un archivo completo (a manera de arreglo de bytes). En el libro Hadoop: The definitive guide (págs. 193-196) hay una explicación detallada de cómo usar esta clase.
  • KeyValueTextInputFormat: Cada registro es una línea de texto. Utilizado para leer de archivos de texto en los que cada línea representa una tupla <key, value> (por ejemplo, los archivos generados por los reducers que emiten TextOutputFormat). El delimitador entre la clave y el valor es configurable (TAB por defecto).
  • StreamInputFormat en combinación con StreamXmlRecordReader: Cada registro es un “registro” XML. Los tags de inicio y fin del “registro” XML son configurables.
  • DBInputFormat: permite leer datos de una base de datos relacional, vía JDBC. Hay una entrada detallando el uso de esta clase en el blog de Cloudera.

El PiggyBank: Funciones definidas por usuarios

miércoles, junio 17th, 2009

El repositorio de funciones definidas por usuarios (UDFs) para el manejo de datos en Pig se llama, muy apropiadamente, PiggyBank. Entre las funciones disponibles en el repositorio encontramos operaciones matemáticas, UPPER (para la conversión de strings a mayúsculas), y unas para el uso de expresiones regulares (con lo que fácilmente se puede definir cualquier tipo de dato especial).

Una entrada reciente en el blog de Cloudera muestra cómo usar el PiggyBank para el analizar logs de las descargas de los proyectos de Apache.

Tip de rendimiento: reutilizar la JVM entre tareas Map

martes, junio 16th, 2009

En un e-mail de la lista core-user de hadoop, alguien preguntó lo siguiente:

Subject: Can I share datas for several map tasks?
Hi,
I want to share some data structures for the map tasks on a same node(not through files), I mean, if one map task has already initialized some data structures (e.g. an array or a list), can other map tasks share these memorys and directly access them, for I don’t want to reinitialize these datas and I want to save some memory. Can hadoop help me do this?

Eason.Lee sugirió:

I think you can just define the data structures in your map classinit it in
setup(Context context) and use it in your map method
hope it is helpful!

Pero si lo que se quiere es que los mappers que se levanten en el mismo nodo re-utilicen la estructura de datos creada por el primer Map task levantado en ese nodo, entonces la solución—planteada por Sharad Agarwal de Yahoo!—es re-utilizar la JVM:

You can enable jvm reuse across tasks. See mapred.job.reuse.jvm.num.tasks in mapred-default.xml for usage. Then you can cache the data in a static variable in your mapper.