Este artículo acerca de la tecnología MapReduce, escrito por
Dean y Ghemawat, me resultó un tanto interesante, ya que habla acerca de qué es
esta tecnología y cuál es el enfoque con el que se desarrolló.
Como hemos visto en artículos diferentes, este es otro
esquema de paralelismo computacional. Pero lo que lo hace diferente a los
demás, es su estructura de funcionamiento y el sistema en el que corre. El
sistema de ejecución de este esquema podría ser implementado en cualquier
ordenador, pero funciona mucho mejor en un cluster. Un cluster es un arreglo de
varias (muchas) computadoras conectadas entre sí, que pueden ser utilizadas
para un sinfín de propósitos. Uno de estos propósitos es la búsqueda de
información en la red, tal y como es el servicio de Google.
El funcionamiento de MapReduce puede asemejarse un poco a lo
que es una cadena de producción, o una búsqueda en masa de la información. Si
suponemos que los datos clave que se deben buscar es una petición de
producción, y los documentos donde se busca es la materia prima, existen varios
threads (también llamados workers) que se encargan de realizar la búsqueda de
los materiales necesarios que se deben utilizar para la producción del lote en
cuestión. Posteriormente, cuando los workers terminan, otro conjunto de
trabajadores realiza la producción del lote, generando un resultado. Esto
viéndolo desde una perspectiva muy sencilla. MapReduce cuenta con su propio
calendarizador (scheduler), el cual es el equivalente al líder de equipo o
administrador de proyectos, quien es el que se encarga de asignar tareas
específicas a cada trabajador, y en caso de que uno acabe antes que los demás,
le asigna más trabajo para que no esté en estado de ocio la mayor cantidad de
tiempo (siempre y cuando haya algo que hacer).
Me pareció muy interesante ver la esquematización de esta
tecnología, ya que se asemeja mucho a situaciones como la anterior, y que tiene
un manejo de errores muy eficiente, el cual consiste en que si por algo falla
un trabajador, otro toma su lugar y ejecuta lo que el primero deió hacer para
poder tener el resultado consistente. Esto, tanto en el algoritmo como en la
vida real, resulta ser muy bueno, ya que en un equipo no podemos depender 100%
de nuestros colegas, y menos cuando se presenta una falla (baja de energía, un segmentation
fault, enfermedad [bug], etc.).
No hay comentarios.:
Publicar un comentario