Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.

En esta página

Función mejorada de código abierto de MapReduce: JobHistoryServer HA
Función mejorada de código abierto: mejora del rendimiento de MapReduce mediante optimización del proceso de fusión/ordenación en escenarios específicos
Función mejorada de código abierto: Problema de archivo de log pequeño resuelto después de la optimización de MR History Server

Mostrar todo

Centro de ayuda/ MapReduce Service/ Descripción general del servicio/ Componentes/ MapReduce/ Funciones mejoradas de código abierto de MapReduce

Funciones mejoradas de código abierto de MapReduce

Actualización más reciente 2023-04-14 GMT+08:00

Ver PDF

Función mejorada de código abierto de MapReduce: JobHistoryServer HA

JobHistoryServer (JHS) es el servidor utilizado para ver la información de tareas de MapReduce históricas. Actualmente, el JHS de código abierto solo admite servicios de instancia única. JHS HA puede resolver el problema de que una aplicación no puede acceder a la API MapReduce cuando se producen SPOFs en el JHS, lo que hace que la aplicación no se ejecute. Esto mejora considerablemente la alta disponibilidad del servicio MapReduce.

Figura 1 Transición de estado de la conmutación activa/en espera de JobHistoryServer HA
haga clic para agrandar

Alta disponibilidad de JobHistoryServer

ZooKeeper se utiliza para implementar la elección activa/en espera y la conmutación.
JHS utiliza la dirección IP flotante para proporcionar servicios externamente.
Se admiten tanto los modos de implementación de instancia única de JHS como los modos de implementación de HA.
Solo un nodo inicia el proceso JHS en un punto de tiempo para evitar que varias operaciones JHS procesen el mismo archivo.
Puede realizar escalamiento horizontal, encogimiento, migración de instancia, actualización y comprobación de estado.

Función mejorada de código abierto: mejora del rendimiento de MapReduce mediante optimización del proceso de fusión/ordenación en escenarios específicos

La siguiente figura muestra el flujo de trabajo de una tarea de MapReduce.

Figura 2 MapReduce job
haga clic para agrandar

Figura 3 Flujo de ejecución de job de MapReduce
haga clic para agrandar

El proceso Reducir se divide en tres pasos diferentes: Copy, Sort (en realidad se supone que se llama Merge) y Reduce. En la fase de Copy, Reducer intenta obtener la salida de Maps de NodeManagers y almacenarla en Reducer ya sea en memoria o en disco. A continuación, comienza la fase de Shuffle (Sort and Merge). Todas las salidas de mapa obtenidas se están ordenando, y los segmentos de diferentes salidas de mapa se fusionan antes de enviarse a Reducer. Cuando un job tiene un gran número de maps que se procesarán, el proceso de shuffle consume mucho tiempo. Para tareas específicas (por ejemplo, tareas de SQL como hash join y hash aggregation), la ordenación no es obligatoria durante el proceso de shuffle. Sin embargo, la ordenación se requiere de forma predeterminada en el proceso de shuffle.

Esta función se mejora mediante el uso de la API MapReduce, que puede cerrar automáticamente el proceso Sort para dichas tareas. Cuando la clasificación está deshabilitada, la API fusiona directamente los datos de salida de Maps obtenidos y los envía a Reducer. Esto ahorra mucho tiempo y mejora significativamente la eficiencia de las tareas de SQL.

Función mejorada de código abierto: Problema de archivo de log pequeño resuelto después de la optimización de MR History Server

Después de ejecutar el job que se ejecuta en Yarn, NodeManager utiliza LogAggregationService para recopilar y enviar logs generados a HDFS y los elimina del sistema de archivos local. Una vez que logs se almacenan en HDFS, son gestionados por MR HistoryServer. LogAggregationService fusionará logs locales generados por containers en un archivo de log y lo subirá al HDFS, reduciendo en cierta medida el número de archivos de log. Sin embargo, en un clúster a gran escala y ocupado, habrá excesivos archivos de log en HDFS después de ejecutarse a largo plazo.

Por ejemplo, si hay 20 nodos, se generan alrededor de 18 millones de archivos de log dentro del período de limpieza predeterminado (15 días), que ocupan alrededor de 18 GB de la memoria de un NameNode y ralentizan la respuesta del sistema de HDFS.

Solo se requiere la lectura y eliminación para los archivos almacenados en HDFS. Por lo tanto, Hadoop Archives se puede utilizar para archivar periódicamente el directorio de los archivos de registro recopilados.

Archivado de logs

El módulo de AggregatedLogArchiveService se agrega al MR HistoryServer para comprobar periódicamente el número de archivos en el directorio log. Cuando el número de archivos alcanza el umbral, AggregatedLogArchiveService inicia una tarea de archivado para archivar archivos de log. Después de archivar, elimina los archivos de log originales para reducir los archivos de log en HDFS.

Limpieza de logs archivados

Hadoop Archives no admite la eliminación en archivos archivados. Por lo tanto, todo el paquete de log de archivo debe eliminarse al limpiar log. El último tiempo de generación de log se obtiene modificando el módulo de AggregatedLogDeletionService. Si todos los archivos de log cumplen los requisitos de limpieza, se puede eliminar el paquete de log de archivo.

Exploración de logs archivados

Hadoop Archives permite el acceso basado en URI al contenido del archivo en el paquete de log de archivo. Por lo tanto, si MR History Server detecta que los archivos de registro originales no existen durante la exploración de archivos, redirige directamente el URI al paquete de log de archivo para acceder al archivo de log archivado.

NOTA:

Esta función invoca Hadoop Archives de HDFS para el archivo de log. Porque la ejecución de una tarea de archivado por Hadoop Archives es ejecutar una aplicación de MR. Por lo tanto, después de ejecutar una tarea de archivado, se agrega un registro de ejecución de MR.
Esta función de archivar logs se basa en la función de recopilación de log. Por lo tanto, esta función es válida solo cuando la función de recopilación de log está habilitada.

Tema principal: MapReduce

Tema anterior: Relación entre MapReduce y otros componentes

Tema siguiente: Oozie

Comentarios

¿Le pareció útil esta página?

Sí No

Deje algún comentario

Muchas gracias por sus comentarios. Seguiremos trabajando para mejorar la documentación.

El sistema está ocupado. Vuelva a intentarlo más tarde.

¿Cuáles de los siguientes problemas se presentaron?

Contenido diferente a la de la IU del producto

Descripciones poco claras

Falta de ejemplos o código

Pasos incorrectos

No puedo encontrar lo que necesito

Falta de prácticas recomendadas

Comentarios (opcional)

0/500

Seleccione al menos un tipo de problema e ingrese sus comentarios o sugerencias.

Ingrese 500 caracteres como máximo.

Enviar Cancelar