martes, 25 de marzo de 2014

MapReduce: paradigma de hoy

En los últimos años mucha personas han tratado de dar solución al problema de procesamiento de grandes cantidades de datos (Big Data), pues este representa un problema practico en el que es necesario analizar toda esta información en un tiempo razonable. Muchos esfuerzos se han hecho para tratar de  solucionar este problema (e.g. supercomputadoras, paradigmas de multiprocesamiento, etc.), sin embargo, una de las soluciones más efectivas (gracias a la escalabilidad y costos) es el uso del computo distribuido.
El computo paralelo ha evolucionado a través del tiempo, y mientras que sus bases, la distribución de las operaciones lógica y de entrada-salida a través de procesadores y/o equipos, muchos paradigmas se ha explorado, pero el problema del sincronizado de datos a través de diferentes nodos ha continuado. Recientemente, un nuevo paradigma, el map-reduce, ha sido adoptado y evolucionado hasta convertirse en el indicado para compañías donde sus procesos están muy relacionados con el procesamiento extensivo de datos, como Google, Microsoft, y Amazon.
El paradigma de Map-reduce utiliza el concepto de map y reduce incluidos en los lenguajes derivados de LISP, que procesan independientemente datasets con el fin de producto nuevas instancias de estos, pero as pequeños. Básicamente, la idea es procesar datos en una función map, previamente definida por el usuario donde la información es indexada y procesada, y enviada a una función reduce, que también esta definida por el usuario, de tal forma que “agregue” las tuplas resultantes previamente procesadas de tal forma que estas sean presentadas de una forma útil al ser post-procesadas.

La ventaja de usar este nuevo paradigma es que la información puede ser dividida en diferentes datasets, procesados independientemente, y reducidos posteriormente en una función reduce especializada. Esto provee una alternativa para reducir costos al usar grandes clústeres formados de computadoras domesticas (de conveniencia) que podían superar a las grandes computadoras comerciales al ser comparadas en su relación desempeño/costo, además de proveer una infraestructura muy robusta, tolerante a fallas, en la que las optimizaciones correctas a una computadora maestra, que asigna los nodos que ejecutaran tareas de map y reduce, puede sencillamente reemplazar y/o compensar la falla de una computadora gracias al poder de la grid que maneja, proveyendo un clúster confiable compuesto de maquinas sencillas y que en si mismas no son confiables.

viernes, 7 de marzo de 2014

Teaching Concurrency-Oriented Programming with Erlang

En esta ocasión, leímos el paper escrito por nuestro profesor de programación multinúcleo, Ariel Ortiz, el cual fue publicado en el contexto del SIGCSE’11. En este articulo se trata principalmente la enseñanza de programación concurrente utilizando el modelo de pase de mensajes (message-passing) de Erlang.
Adicionalmente, podemos explorar de nuevo las principales características de las lecturas que hemos hecho acerca de la importancia de la programación concurrente al aprovechar plenamente los nuevos modelos de arquitectura computacional o la distribución de tareas a través de diversos equipos a través de la red.
Un apartado que me pareció especialmente importante es To Mutate, Or To Not Mutate, donde se exploran las principales debilidades del modelo concurrente en lenguajes diseñados bajo el paradigma procedural u orientado a objetos, ya que hace énfasis en que la raíz de todos los problemas de sincronización surge básicamente al permitir la mutación de estados, y obviamente la falta de atomicidad de los cambios, sin embargo, al reducir las variables a estados no mutables, o finales, se reduce considerablemente la complejidad de las implementaciones concurrentes.
El uso de Erlang para implementación de algoritmos u sistemas concurrentes me parece interesante, ya que permite una implementación un poco mas transparente de los algoritmos desde su fase de planeación y producción, del lado del desarrollador, sin embargo, me parece que su API es algo limitado, además de un poco diferente a lo que los demás lenguajes funcionales (y naturalmente los procedurales) nos tienen acostumbrados.  Por lo que creo que prefiero (al menos por ahora) un lenguaje como Clojure, que implementa un API mucho mas extenso e inherentemente seguro en lo concurrente.

Para concluir, creo que lo que me parecería interesante, y espero ver en el futuro, seria un lenguaje naturalmente paralelo que además implemente alguna forma de objetos, para poder encapsular funcionalidades.