Archive for marzo 2014
MapReduce... ¿Quién necesita un mapa?
¡Hola! :D
Una de las ventajas del MapReduce distribuido, es que si uno
de los trabajadores falla, el cálculo se puede volver a hacer bajo ciertas
condiciones. El cálculo se debe repetir debido a que solo el equipo que falló
tiene acceso a la información que era resultado de la(s) funciones que
realizaba, por lo que la información es inalcanzable. Ahora bien, si lo que se
estaba realizando era una función map, todo sucede como se describió
anteriormente; sin embargo, si se tiene un reduce, se debe revisar si el
trabajo ya fue revisado. Si se revisó, entonces se deberá repetir; de lo
contrario no hace falta repetir el trabajo. Finalmente cabe mencionar que si la
falla se ha presentado en el maestro, simplemente se puede avisar de un error y
el usuario puede hacer una nueva petición.
Finalmente, podemos hacer énfasis en que los usuarios de MapReduce pueden encontrarse con pocas problemáticas de sección crítica, ya que si el reduce definido por el usuario no está definido correctamente, existirá una condición de carrera o deadlocks.
Espero que esta entrada haya sido de su agrado :)
En esta ocasión hablaré acerca del artículo titulado "MapReduce: Simplified Data Processing on Large Clusters" escrito por Jeffrey Dean y Sanjay Ghemawat, y publicado en el Communications of the ACM en enero del 2008.
Como ya bien sabemos, la cantidad de información contenida
en bases de datos se ha incrementado exponencialmente, por lo que las bases de
datos relacionales han ido perdiendo efectividad al momento de realizar
búsquedas de información. Por eso mismo los modelos relacionales han pasado a
segundo plano, dejando lugar a conceptos nuevos como NoSQL y Big Data. Una de
las técnicas para buscar información en Big Data es, justamente, MapReduce.
Esta técnica consiste en dos operaciones: map y reduce. Map
consiste en tomar una entrada y devolver un conjunto con pares “intermedios” de
llaves-valores. A su vez, este conjunto
será pasado como parámetro a la función reduce (que además recibe una llave
adicional) para juntar la información realizada por el map. Tanto la función
map como la función reduce son definidas por el usuario. Estas dos funciones
pueden verse como aquellas que están definidas en lenguajes funcionales como
Lisp o Clojure.
La importancia del MapReduce llega cuando hablamos de
realizarlo de manera distribuida (es distribuido debido a que tenemos una red
de procesadores y no hay una memoria compartida para todos los equipos). De
esta manera, se tienen a los “trabajadores” de map realizando esta función,
almacenar los resultados temporales en un búfer y posteriormente los
“trabajadores” de reduce realizando esta función en un almacenamiento común
(por obvias razones, debe haber un maestro que se encargue de coordinar estas
operaciones y obtener el resultado final).
Finalmente, podemos hacer énfasis en que los usuarios de MapReduce pueden encontrarse con pocas problemáticas de sección crítica, ya que si el reduce definido por el usuario no está definido correctamente, existirá una condición de carrera o deadlocks.
Espero que esta entrada haya sido de su agrado :)
Provocando Segmentation Faults con Erlang... Así se aprende :)
¡Hola! :D
En estaentrada hablaré sobre el arículo titulado Teaching Concurrency-Oriented Programming with Erlang escrito por Ariel Ortiz y publicado en las memorias del 42° SIGCSE Technical Symposium on Computer Science Education en marzo del 2011.
En el artículo se habla acerca de problemáticas que se han discutido en entradas anteriores, como lo es la necesidad de comenzar a escribir programas paralelos en lugar de seguir con los programas secuenciales, ya que se necesita aprovechar al máximo todo el procesamiento disponible. Adicionalmente, se tratan conceptos previamente vistos, como definir qué es concurrente, paralelo y distribuido. Además, se recuerdan algunas de las reglas (antes vistas) que se deben seguir para realizar programas paralelos.
La parte importante del artículo viene cuando se habla de la
enseñanza de programación concurrente utilizando Erlang. Este lenguaje
funcional tiene muchas características que lo vuelven un lenguaje interesante
de aprender, que van desde tener su propio REPL, hasta la utilizar pattern matching para realizar el binding de las variables (cosa
completamente nueva para mí). En cuanto a performance,
hay que considerar a Erlang debido a que es útil para muchas tareas que,
personalmente, no me hubiera imaginado y que incluso pueden tener ciertas
aplicaciones para el área de especialidad que estoy tomando (redes).
Más adelante se comentan algunos principios de diseño de Erlang
para asegurar que los programas sean óptimos. Estos principios van desde usar un
número de procesos proporcional al número de procesadores disponibles (y
distribuir el trabajo de manera adecuada) hasta asegurarnos de minimizar el
tiempo que se espera por una respuesta. Hay que recordar que las operaciones de
entrada/salida suelen consumir muchos recursos.
Cabe señalar que Erlang no es un lenguaje perfecto, ya que
hay tareas para las que no tiene un desempeño tan bueno y que también sufre de
su versión de problemas de programación en paralelo (deadlocks, starvation,
etc.).
Ahora bien, en la parte de enseñanza de programación
paralela y concurrente, Erlang me parece un lenguaje interesante de aprender,
debido a su simplicidad (característica de lenguajes funcionales) y a cómo funciona
internamente. En lo personal, me parece que la enseñanza de programación
paralela y concurrente se puede volver aún mejor si se toman lenguajes como
Clojure y se comparan con Erlang en cuanto a su desempeño en general.
Espero que esta entrada haya sido de su agrado :)
Espero que esta entrada haya sido de su agrado :)