El modelo MapReduce surge a partir de la experiencia de los ingenieros de Google desarrollando multitud de aplicaciones internas para procesar las grandes cantidades de datos heterogéneos manejados por Google (documentos indexados por el buscador, registros de peticiones de páginas, etc.) y extraer cálculos a partir de ellos. Una de las características comunes a todas estas aplicaciones es el gran volumen de datos a manejar y la necesidad de un esquema paralelo de computación para poder distribuir estos procesamientos y cálculos entre diferentes máquinas con el fin de reducir el tiempo de dichas operaciones.
Con la idea de aliviar de alguna manera la complejidad en el desarrollo de estas aplicaciones, e inspirándose en algunas ideas ya presentes en diversos lenguajes de programación funcional, diseñan un modelo que intenta “sacar factor común” de entre dichas aplicaciones, abstrayendo las complejidades de bajo nivel (cómo distribuir el proceso en paralelo entre las diferentes máquinas, cómo reaccionar a posibles fallos en alguna de dichas máquinas para reanudar el trabajo reasignando la tarea a otra máquina, cómo equilibrar la carga de trabajo…) y al mismo tiempo siendo lo suficientemente genérico como para ser aplicable en todos esos problemas a los que se enfrentaba el buscador. Esta es la motivación de la que se origina el modelo MapReduce.
En este modelo el programador “sólo” tiene que preocuparse de definir los detalles de dos funciones, map y reduce (que corresponden a las dos etapas principales que completan el procesamiento de los datos), sin tener que conocer los detalles de cómo se organiza el trabajo distribuido entre las diferentes máquinas que lo resolverán. La función que se define para el paso map es la que transforma (hace corresponder, en términos más “matemáticos”) un conjunto de datos de partida en forma de (clave, valor) en otra serie diferente de datos intermedios también en forma de (clave, valor), y la función definida para el paso reduce procesa de manera agrupada los valores de los datos intermedios correspondientes a una misma clave para producir el resultado final.
El ejemplo simplificado (sin entrar en variantes u optimizaciones) que se suele utilizar para ilustrar este funcionamiento, y que es el utilizado en el artículo de Dean y Ghemawat), es el de contar el número de veces que aparece cada una de las palabras contenidas en un conjunto de documentos. Para este caso:
La lógica que funciona por debajo del modelo es la que va asignando a las diferentes máquinas la tarea de hacer map o hacer reduce (y los datos con que hacerlas) y de ir integrando todos los resultados. Esto es lo que permite poder realizar un computo como el del ejemplo para un gran volumen de datos (y sin duda podemos hacernos una idea de la inmensa cantidad de documentos que podría tener que procesar alguien como Google) en un tiempo asumible.
Con la idea de aliviar de alguna manera la complejidad en el desarrollo de estas aplicaciones, e inspirándose en algunas ideas ya presentes en diversos lenguajes de programación funcional, diseñan un modelo que intenta “sacar factor común” de entre dichas aplicaciones, abstrayendo las complejidades de bajo nivel (cómo distribuir el proceso en paralelo entre las diferentes máquinas, cómo reaccionar a posibles fallos en alguna de dichas máquinas para reanudar el trabajo reasignando la tarea a otra máquina, cómo equilibrar la carga de trabajo…) y al mismo tiempo siendo lo suficientemente genérico como para ser aplicable en todos esos problemas a los que se enfrentaba el buscador. Esta es la motivación de la que se origina el modelo MapReduce.
En este modelo el programador “sólo” tiene que preocuparse de definir los detalles de dos funciones, map y reduce (que corresponden a las dos etapas principales que completan el procesamiento de los datos), sin tener que conocer los detalles de cómo se organiza el trabajo distribuido entre las diferentes máquinas que lo resolverán. La función que se define para el paso map es la que transforma (hace corresponder, en términos más “matemáticos”) un conjunto de datos de partida en forma de (clave, valor) en otra serie diferente de datos intermedios también en forma de (clave, valor), y la función definida para el paso reduce procesa de manera agrupada los valores de los datos intermedios correspondientes a una misma clave para producir el resultado final.
El ejemplo simplificado (sin entrar en variantes u optimizaciones) que se suele utilizar para ilustrar este funcionamiento, y que es el utilizado en el artículo de Dean y Ghemawat), es el de contar el número de veces que aparece cada una de las palabras contenidas en un conjunto de documentos. Para este caso:
- Los datos de partida serían un conjunto de datos con el formato “(documento, lista de palabras contenidas en el documento)”
- Se define una función map que transforma esos pares en otros diferentes donde la clave es una palabra concreta y el valor siempre es 1, es decir, genera un elemento “(palabra, 1)” por cada palabra que ve en los documentos que procesa.
- Se define una función reduce que se encarga de procesar todos los elementos “(palabra, 1)” de la misma palabra y calcular la suma final para cada palabra.
La lógica que funciona por debajo del modelo es la que va asignando a las diferentes máquinas la tarea de hacer map o hacer reduce (y los datos con que hacerlas) y de ir integrando todos los resultados. Esto es lo que permite poder realizar un computo como el del ejemplo para un gran volumen de datos (y sin duda podemos hacernos una idea de la inmensa cantidad de documentos que podría tener que procesar alguien como Google) en un tiempo asumible.
No hay comentarios:
Publicar un comentario