MapReduce y su simulación de procesos

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

Erlang: un cambio de perspectiva

El artículo escrito por el profesor Ariel Ortiz resume lo que, desde el inicio del curso de programación multinúcleo, nos ha ido diciendo: el paralelismo a nivel de software es un hecho que no podemos ignorar. Y, como ingenieros en software (y algunos en hardware), debemos ser capaces de poder utilizar y explotar las bondades que las nuevas tecnologías nos ofrecen.

Siempre he sido fiel partidario de que hay cosas que el software no puede realizar sin el hardware adecuado. Un ejemplo relevante es la unidad de punto flotante. Sin este módulo, todas las operaciones aritméticas que tengan números flotantes, simplemente se quedarían siempre truncadas a su entero. En este caso, el paralelismo en software se puede dar ya que existen procesadores con más de un núcleo en el mismo chip. Y ahora, con las redes de computación y otras tecnologías, se puede hacer paralelismo utilizando más de una máquina para ello.

Otra de las aseveraciones que defiendo es que el software potencializa al hardware. La verdad, no me imagino programando una computadora con puros ceros y unos (que no niego que sería interesante y al mismo tiempo agobiante). Los lenguajes de programación en sí son un fuerte ejemplo de que el software potencializa al hardware. Sin lenguajes de programación, muchísimas cosas que utilizamos hoy en día podrían existir, pero requerirían de mucho tiempo de trabajo y corrección para que funcionen de manera “aceptable”.

Dados estos dos argumentos, considero que Erlang es una herramienta interesante, empezando por el tipo de lenguaje que es. Los principios por los que surge el lenguaje son interesantes, y su impacto en las aplicaciones más actuales son sorprendentes, considerando que tienen miles de usuarios activos todo el tiempo y que la eficiencia es muy satisfactoria. De no ser así, no tendría caso utilizar Erlang.

En otros cursos, he tenido la oportunidad de utilizar esquemas de threads, Message-passing, entre otros. Pero Erlang promete algo diferente. Para empezar, el hecho de comprender su sintaxis me da curiosidad de cómo funciona la herramienta, y de ver qué cosas podría hacer con ella. Actualmente, estaré aprendiendo Erlang y Cuda al mismo tiempo, por lo que tendré la oportunidad de ver el enfoque de ambos lenguajes, y ver qué podría hacer de manera individual o en conjunto.

Erlang y los nodos concurrentes

La concurrencia es uno de los esquemas más recientes que se han introducido a la computación. Como es sabido, y como lo reitera Joe Armstrong en su podcast, la concurrencia se generó alrededor del año 2003, una vez que las empresas que fabrican procesadores llegaron al límite físico, en la tendencia por el incremento de la frecuencia de reloj de los mismos procesadores. La razón principal: sobrecalentamiento, ya que la misma frecuencia de reloj incrementa proporcionalmente la potencia consumida por el procesador. Dado esto, la nueva tendencia es el desarrollo de chips que contengan varios procesadores, capaces de trabajar simultáneamente, ya sea compartiendo información en memoria, o cada núcleo con su segmento de memoria privado.

Joe Armstrong enfatiza que muchas de las tecnologías que se usan hoy en día para generar concurrencia, en realidad no son concurrentes, sino que sin formas de hacer que el calendarizador del sistema operativo mande los diferentes procesos, o threads a los diferentes núcleos que tiene una misma computadora. Sin embargo, estas tecnologías no permiten que un sólo ordenador envíe procesos a los núcleos de otro ordenador. En otras palabras, si tenemos acceso a otro ordenador mediante una conexión a Internet u otro medio, no podríamos utilizarlo para realizar multiprocesamiento aunque el vínculo sea compatible para ello. Se pueden implementar tareas como el “message passing”, entre otros; para realizar multiprocesamiento. Sin embargo, estas implementaciones son costosas en tiempo y recursos de los equipos.

Erlang es un algo similar a un sistema operativo que permite a los programadores realizar segmentos de código que realmente sean capaces de correr por sí mismos en una computadora con un procesador multinúcleo, e inclusive utilizar nodos para intercomunicar computadoras entre sí, y que cada proceso funcione de manera independiente completamente, en relación a los demás núcleos y/o chips de procesador. Una de las cualidades de Erlang, es que soporta el “message-passing”; sin embargo, esto se utiliza solamente cuando es requerido, y no es una implementación fija en cada programa en Erlang.

Joe Armstrong enfatiza que hay 3 cuestiones en las que debemos siempre tener cuidado para lograr una verdadera aplicación concurrente, y evitar muchas cosas que terminan haciendo de nuestro programa una implementación más parecida a una secuencial que a una paralela: a) el tiempo de cambio de contexto, b) el tiempo de paso de mensaje, y c) el tiempo de creación de los procesos. Personalmente, a estos puntos les puedo dar validez, como ingeniero electrónico, ya que a nivel de hardware es más eficiente un procesador que tarde menos en cambiar de contexto, en especial para las aplicaciones de alto riesgo y que trabajan mediante interrupciones. Si un procesador se espera mucho tiempo en atender una interrupción de alta prioridad, la secuencia de atención no sería ejecutada a tiempo, y podría tener resultados catastróficos. Por ejemplo, si tenemos un microcontrolador, interconectado con muchos otros, y este microcontrolador tarda en procesar que nuestro coche ha chocado y no trabaja oportunamente, el mensaje que debe recibir el microcontrolador que maneja las bolsas de aire, no las abriría a tiempo y los pasajeros correrían peligro de muerte.

Será interesante ver las implementaciones que se pueden hacer con Erlang, y las ventajas que tiene este “lenguaje” en comparación de las tecnologías thread y Fork/Join.