Hace un tiempo vi en diferentes blogs de Yahoo! su propuesta para una reimplementación de una parte bastante importante de Hadoop. Una propuesta interesante, pero que creí bastante teórica. Bueno, pues la semana pasada pude ir a otra edición del grupo de usuarios de hadoop del reino unido, en el que Owen O'malley mismo presentó estas mismas ideas a la comunidad, podéis ver la página del evento así como las presentaciones en:
Entrando un poco más en detalle. Esta propuesta (que está en fase de testing en Yahoo! por lo tanto, de teórico nada) se trata de sustituir el JobTracker de Hadoop (la parte que lanza los jobs a los diferentes nodos que forman el cluster de Hadoop) por dos nuevos elementos:
- Un Resource Manager / Scheduler: El cual cogerá los requerimientos del job en concreto y buscará un nodo capaz de poder realizarlo.
- Un Node Manager en cada nodo: El cual monitorizará el nodo y informará al Resource Manager. Dentro de este nodo el Node Manager será capaz de crear un container, dentro del qual se ejecutará el mapper, el reducer, y lo que es más interesante: o lo que sea. Ya que este diseño pretende hacer de Hadoop un framework de programación distribuido general.
podéis encontrar más información ( y mucho más detallada ) en:
Mis primeras impresiones fueron bastante negativas. En primer lugar porque estamos sustituiendo un elemento QUE FUNCIONA de Hadoop por otro de mucho más complejo. Y en segudo lugar por la complejidad de este segundo elemento. No quisiera parecer conservador pero mis temores se fundamentan en la experiencia que tuve con otros middlewares de computación distribuida, en los que estabas más tiempo definiendo las características del job en un "formato simple de definición genérica de jobs" en XML que programando el job en sí mismo.
Otro aspecto es que como ya he dicho anteriormente este Node Manager permitiría no sólo crear containers con mappers o reducers, sino otro tipo de containers (implementados por la comunidad) en los que se podría lanzar otro tipo de procesos (intensivos de CPU, MPI, ...). Tampoco me hizo mucha gracia esto, y otra vez fue por culpa de alguna mala experiencia. Lo que me gustó de Hadoop desde el principio es que era un framework que sólo hacía una cosa, pero que la hacía muy bien. Cosa que no hacían otros, que intentaban hacer muchas cosas diferentes y no hacían nada bien.
Aproveché la ronda de cervezas del final de la reunión para ver más opiniones acerca de estos cambios, las conclusiones que saqué es que la gente es muy optimista, frases que oí mucho:
- La comunidad hadoop será capaz de hacerlo bien.
- Asi podremos aprovechar el cluster para más cosas.
Veremos qué tal la primera, espero que si :) en cuando a la segunda, es pura verdad.
Estoy viendo muchos clústers dedicados 100% a hadoop/map reduce. Esto no es necesariamente malo, pero como no me canso de decir, Map Reduce es un modelo de programación y va muy bien para unas cosas y va muy mal para otras. El hecho de que sólo haya instalado Hadoop en un cluster hace que todo tenga que estar programado siguiendo una estrategia map/reduce o tengamos que instalar otro framework (Condor/Globus/...) en las mismas máquinas. Por ejemplo he sido testigo de un intento (que acabó en nada) de implementar un Load Tester con Hadoop, cuando claramente map/reduce no es el modelo más apropiado (que se puede hacer ojo!, simplemente digo que hay cosas mejores).
Si la comunidad Hadoop consigue hacerlo bien Hadoop se puede convertir en un framework de sistemas distribuidos _genérico_, cosa que facilitaría mucho la tarea de administradores de sistema, ya que sólo tendríamos que tener Hadoop instalado. Pero bueno, estamos hablando de largo plazo.
Asi que más o menos, cambié de opinión, aún me quedan dudas sobre la complejidad de estos nuevos componentes.
0 comentarios:
Publicar un comentario en la entrada
Comenta: