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.

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 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.

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.

Una entrada en el blog de Data Wrangling describe tres data sets de la Wikipedia: el ya conocido raw dump, uno que contiene estadísticas de las frecuencias de visitas a las páginas de la Wikipedia durante 7 meses (el cual ya está subido a los AWS), y uno con la lista de los enlaces de las páginas a otras páginas.

Los invito a darme ideas de usos interesantes de estos data sets.

El lunes 15 de junio se llevará a cabo el evento HotCloud ’09, en el cual se presentarán varios papers de investigaciones recientes sobre infraestructuras de cloud computing y temas relacionados. Los papers no se pueden bajar directamente del sitio (ya que pide un usuario y contraseña), pero se puede googlear el nombre del paper ya que generalmente los autores lo publican en sus páginas Web personales.

Un artículo reciente del New York Times habla de los costos energéticos involucrados en el funcionamiento de los actuales datacenters que mantienen empresas como Microsoft, Google, Yahoo!, Facebook, entre muchas otras. En data centers como estos están implementadas las actuales infraestructuras de cloud computing, como la de los Amazon Web Services. Hay unas fotos muy buenas en el sitio del New York Times. Una vez visité uno de los data centers del National Center for Supercomputing Applications, y es algo realmente impresionante; uno de los pisos del edificio contenía gigantescos ventiladores que formaban parte del sistema de enfriamiento.

En un post en los foros de la materia, Romeo Cabrera publicó información sobre la nueva distribución de Hadoop liberada por Yahoo!, y sobre una alternativa a Hive que Yahoo! planea lanzar en un futuro. Lo bueno de todo esto, es que mientras más respaldo tenga Hadoop y sus sub-proyectos de gigantes como Yahoo!, más probable es que otras empresas conozcan de las ventajas de esta herramienta para el procesamiento masivo de datos y se animen a adoptarla (o al menos, probarla). Por otro lado, el problema que se puede presentar es que a medida que empresas como Cloudera y Yahoo! empiezan a parchar el código de Apache Hadoop de manera independiente, surjan incompatibilidades y problemas difíciles de rastrear.