Capítulo 6 del libro "Hadoop: The Definitive Guide, 3rd Edition". En este capítulo se detalla como trabaja MapReduce mientras se ejecuta un determinado trabajo.
1 – La anatomía de un trabajo MapReduce ejecutándose.
Podemos correr un trabajo MapReduce utilizando la API de Java mediante una llamada al método submit() o waitForCompletion() de un objeto Job. La forma en que Hadoop ejecuta el programa depende de los ajustes realizados en la configuración del trabajo. El framework usado para la ejecución depende de la propiedad mapreduce.framework.name (nueva API), tomando los valores local (ejecución en local), classic (MapReduce 1) o yarn (MapReduce 2).
En este apartado se ilustra el proceso que siguen las diferentes entidades en un cluster Hadoop cuando un cliente ejecuta un programa MapReduce, tanto en la versión clásica como en YARN.
1.1 – MapReduce clásico (MapReduce 1).
1.1.1 – Petición de un trabajo.
1.1.2 – Inicialización de un trabajo.
1.1.3 – Asignación de tareas.
1.1.4 – Ejecución de tareas.
1.1.5 – Progreso y actualización de estado.
1.1.6 – Trabajo completado.1.2 – YARN (MapReduce 2).
1.2.1 – Petición de un trabajo.
1.2.2 – Inicialización de un trabajo.
1.2.3 – Asignación de tareas.
1.2.4 – Ejecución de tareas.
1.2.5 – Progreso y actualización de estado.
1.2.6 – Trabajo completado.
2 – Fallos.
Pueden producirse distintos tipos de fallos mientras se ejecuta una aplicación MapReduce: el código de usuario puede contener bugs, los procesos pueden colgarse o las máquinas pueden fallar. Uno de los beneficios que proporciona Hadoop es su habilidad para manejar algunos de estos fallos y permitir que un trabajo pueda completarse.
En este apartado se explica las posibles fuentes de fallo durante la ejecución de un trabajo MapReduce y como Hadoop lidia con ellos.
2.1 – Fallos en MapReduce 1.
2.1.1 – Fallo en una tarea.
2.1.2 – Fallo en tasktracker.
2.1.3 – Fallo en jobtracker.
2.2 – Fallos en YARN (MapReduce 2).
2.2.1 – Fallo en la tarea.
2.2.2 – Fallo en el ‘Application Master’.
2.2.3 – Fallo en el ‘Node Manager’.
2.2.4 – Fallo en el ‘Resource Manager’.
3 – Planificador de trabajos.
Las primeras versiones de Hadoop implementaban un sencillo planificador de trabajos siguiendo una filosofía FIFO ante la petición de ejecución de varios trabajos por diversos clientes. Generalmente cada uno de los trabajos utilizan el cluster al completo, por lo que el resto debe esperar su turno. Un esquema FIFO no es el más adecuado para lidiar de forma "justa" con la petición de ejecución de trabajos en un cluster compartido.
Se añadió la posibilidad de asignar prioridades a cada uno de los trabajos, pero sigue siendo un esquema con problemas: por ejemplo, un trabajo de baja prioridad, pero con un tiempo de ejecución muy elevado puede bloquear a un trabajo de alta prioridad al empezar a ejecutarse antes se realize la petición del trabajo prioritario.
Actualmente, Hadoop proporciona diferentes planificadores de trabajos pensados para entornos multiusuario. En este apartado se comenta su funcionamiento y se explica como configurarlos.
3.1 – Fair Scheduler.
3.2 – Capacity Scheduler.
4 – Etapa ‘shuffle and sort’ (mezclado y ordenado).
El llamado 'Shuffle' (barajado/mezclado) es el proceso donde se ordenan por key los datos de salida de los map y se transfieren hacia los reducers. Este proceso puede considerarse el corazón de MapReduce, por lo que es el área de Hadoop donde mayor se trabaja en mejorar y refinar.
En este apartado entra en detalles sobre cómo se realiza este proceso, y cómo podemos realizar diferentes ajustes en los procesos map y reduce para optimizar el Shuffle y así mejorar el rendimiento de nuestro trabajo MapReduce.
4.1 – Desde el punto de vista de proceso Map.
4.2 - Desde el punto de vista de proceso Reduce.
4.3 – Ajuste en la configuración.
5 – Ejecución de tareas.
Se revisan ciertos parámetros que el usuario puede gestionar para controlar la ejecución de sus trabajos MapReduce:
Desde un proceso map o reduce podemos acceder a cierta información sobre el entorno en el que se ejecutan, por ejemplo el Job ID, Task ID, índice de la tarea en el trabajo o Task attemp ID (pueden ser útiles por ejemplo para debugging).El modelo MapReduce se basa en trocear los trabajos en tareas que se ejecutan en paralelo para reducir el tiempo de ejecución, por lo el tiempo de ejecución de un trabajo puede verse degradada si una de las tareas es muy lenta. Una ejecución lenta puede ocurrir por diversas razones, incluyendo problemas hardware o software en algún nodo. Hadoop no trata de diagnosticar y corregir tareas que se ejecutan de forma lenta, pero implementa la ejecución especulativa: cuando detecta que una tarea esta ejecutandose de manera más lenta de lo que se supone, lanza otra tarea equivalente como backup.Hadoop utiliza un protocolo de 'commit' para asegurarse que, tanto tareas como trabajos se han ejecutado de forma satisfactoria o han fallado. Este comportamiento se implementa en el OutputCommitter usado por el trabajo. Se introduce la API del OutputCommitter.
Los tasktrackers pueden ejecutar más de una tarea al mismo tiempo, siempre en JVM separadas. Se habla de los parámetros para controlar el numero de slots de tareas map y reduce que pueden ejecutar cada tasktraker.
Los datasets utilizados a veces contienen registros corruptos o incorrectos. Algunos de estos registros corruptos pueden causar que una tarea no se ejecute correctamente y lanze una excepción. Lo mejor es manejar los registros corruptos desde las propias tareas map o reduce, detectandolas y actuando en consecuencia. Otra posibilidad es utilizar el modo automático que proporciona Hadoop para ignorarlos de forma automática (no soportado en la api nueva).
5.1 – Entorno de ejecución de tareas.
5.2 – Ejecución especulativa.
5.3 – Output Committers.
5.4 – Reutilización de JVM (Java Virtual Machine).
5.5 – Desechando registros corruptos o erróneos.
No hay comentarios:
Publicar un comentario