ResourceManager (rm) : Procesar solicitudes de clientes, iniciar / monitorear ApplicationMaster, monitorear NodeManager, asignación de recursos y programación;

NodeManager (nm) : administración de recursos en un solo nodo, procesamiento de comandos del ResourceManager y procesamiento de comandos del ApplicationMaster;

ApplicationMaster (am) : segmentación de datos, aplicación de recursos para aplicaciones y asignación a tareas internas, monitoreo de tareas y tolerancia a fallas.

Contenedor : una abstracción del entorno de operación de la tarea, que encapsula la información relacionada con la operación de la tarea, como CPU, memoria y otros recursos multidimensionales, así como variables de entorno y comandos de inicio.

Sección 2 Envío de la tarea de hilo (mecanismo de trabajo)

HILO del proceso de envío del trabajo ( para poder repetirlo )

Entrega de Trabajo

Paso 1: el cliente llama al método job.waitForCompletion para enviar trabajos de MapReduce a todo el clúster.

Paso 2: El cliente solicita una identificación de trabajo de RM.

Paso 3: RM devuelve la ruta de envío y la identificación del trabajo del recurso del trabajo al cliente.

Paso 4: El cliente envía el paquete jar, la información de corte y los archivos de configuración a la ruta de envío de recursos especificada.

Paso 5: Una vez que el cliente envía los recursos, se aplica al RM para ejecutar MrAppMaster.

Inicialización del trabajo

Paso 6: cuando RM recibe la solicitud del cliente, agrega el trabajo al programador de capacidad.

Paso 7: un determinado NM gratuito recibe el trabajo.

Paso 8: El NM crea un contenedor y produce MRAppmaster.

Paso 9: Descargue los recursos enviados por el Cliente al local.

Asignación de tareas

Paso 10: MrAppMaster se aplica a RM para ejecutar múltiples recursos de tareas de MapTask.

Paso 11: El RM asigna la tarea MapTask a los otros dos NodeManagers, y los otros dos NodeManagers reciben las tareas y crean contenedores respectivamente.

Operación de tareas

Paso 12: MR envía el script de inicio del programa a los dos
NodeManagers que han recibido la tarea.Los dos NodeManagers inician MapTask respectivamente, y MapTask ordena las particiones de datos.

Paso 13: Después de que MrAppMaster espera a que se ejecuten todas las MapTasks, solicite un contenedor de RM y ejecute ReduceTask.

Paso 14: ReduceTask obtiene los datos de la partición correspondiente de MapTask.

Paso 15: Después de que se ejecute el programa, MR se aplicará a RM para cerrar la sesión.

Actualizaciones de progreso y estado Las tareas en YARN devuelven su progreso y estado al administrador de la aplicación, y el cliente solicita actualizaciones de progreso del administrador de la aplicación cada segundo (establecido por mapreduce.client.progressmonitor.pollinterval) y se las muestra al usuario.

Tarea completada

Además de solicitar el progreso del trabajo al administrador de la aplicación, el cliente llama a waitForCompletion () cada 5 segundos para verificar si el trabajo está completo.

El intervalo de tiempo se puede establecer mediante mapreduce.client.completion.pollinterval.

Una vez finalizado el trabajo, el administrador de aplicaciones y el contenedor limpiarán el estado del trabajo. El servidor de historial de trabajos almacenará la información del trabajo para su posterior verificación por parte del usuario.

Sección 3 Estrategia de programación del hilo

Hay tres tipos principales de programadores de trabajos Hadoop: FIFO , Capacity Scheduler y Fair Scheduler .

El programador de recursos predeterminado de Hadoop 2.9.2 es Capacity Scheduler .

Puede ver yarn-default.xml

1. FIFO (programador primero en entrar, primero en salir)

2. Programador de capacidad (programador predeterminado del Programador de capacidad)

La estrategia de programación utilizada por Apache Hadoop de forma predeterminada. El programador de capacidad permite que varias organizaciones compartan todo el clúster, y cada organización puede obtener una parte de la potencia informática del clúster. Al asignar una cola dedicada a cada organización y luego asignar un determinado recurso de clúster a cada cola, todo el clúster puede proporcionar servicios a varias organizaciones mediante la configuración de varias colas. Además, la cola se puede dividir verticalmente, de modo que varios miembros dentro de una organización puedan compartir los recursos de la cola. Dentro de una cola, la programación de recursos se basa en una estrategia de primero en entrar, primero en salir (FIFO).

3. Programador justo (Programador justo, el programador predeterminado utilizado por la versión CDH de hadoop)

El objetivo del diseño del programador de la equidad es asignar recursos justos para todas las aplicaciones (la definición de equidad se puede establecer mediante parámetros). La programación justa también se puede realizar entre varias colas.

Por ejemplo, suponga que hay dos usuarios A y B, y cada uno tiene una cola.
Cuando A inicia un trabajo y B no tiene tareas, A obtendrá todos los recursos del clúster; cuando B inicia un trabajo, el trabajo de A continuará ejecutándose, pero después de un tiempo, las dos tareas obtendrán cada una la mitad de los recursos Recursos del clúster. Si B inicia el segundo trabajo en este momento y otros trabajos todavía se están ejecutando, compartirá los recursos de la cola B con el primer trabajo de B, es decir, los dos trabajos de B se utilizarán para una cuarta parte de los recursos del clúster de A, pero El trabajo de A todavía se usa para la mitad de los recursos del clúster, el resultado es que los recursos finalmente se comparten equitativamente entre los dos usuarios

Sección 4 Configuración de aislamiento de recursos multiinquilino de Yarn

Los recursos del clúster de hilos se establecen en dos colas, A y B. La cola
A está configurada para ocupar el 70% de los recursos y se usa principalmente para ejecutar tareas programadas regulares, y la
cola B está configurada para ocupar el 30% de los recursos para ejecutar tareas temporales.
dos colas pueden interactuar entre sí. Recurso compartido, si los recursos de la cola A están llenos y los recursos de la cola B son más abundantes, la cola A puede utilizar los recursos de la cola B para maximizar la utilización general de los recursos

¡Elija utilizar la estrategia de programación Fair Scheduler! !

Colocación específica

1. yarn-site.xml

<!-- 指定任务调度使⽤fairScheduler的调度⽅式 -->
<property>
     <name>yarn.resourcemanager.scheduler.class</name>
     <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
     <description>In case you do not want to use the default scheduler</description>
</property>

2. Cree el archivo fair-Scheduler.xml Cree el archivo
en el directorio de instalación de Hadoop / etc / hadoop

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
      <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
      <queue name="root" >
          <queue name="default">
              <aclAdministerApps>*</aclAdministerApps>
              <aclSubmitApps>*</aclSubmitApps>
              <maxResources>9216 mb,4 vcores</maxResources>
              <maxRunningApps>100</maxRunningApps>
              <minResources>1024 mb,1vcores</minResources>
              <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
              <schedulingPolicy>fair</schedulingPolicy>
              <weight>7</weight>
          </queue>
          <queue name="queue1">
              <aclAdministerApps>*</aclAdministerApps>
              <aclSubmitApps>*</aclSubmitApps>
              <maxResources>4096 mb,4vcores</maxResources>
              <maxRunningApps>5</maxRunningApps>
              <minResources>1024 mb, 1vcores</minResources>
              <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
              <schedulingPolicy>fair</schedulingPolicy>
              <weight>3</weight>
          </queue>
      </queue> 
      <queuePlacementPolicy>
         <rule create="false" name="specified"/>
          <rule create="true" name="default"/>
      </queuePlacementPolicy>
</allocations>

Verificación de límites

La segunda parte del análisis del código fuente central de Apache Hadoop HDFS

Sección 1 Preparación de la lectura del código fuente

1. Descargue el código fuente oficial de Apache Hadoop-2.9.2
2. Importe el código fuente a idea

Inicie la idea y elija importar en la interfaz de solicitud

Espere a que se complete la descarga y la resolución de las dependencias, ¡la importación del código fuente es exitosa! !

Sección 2 Proceso de inicio de NameNode

Comando para iniciar el clúster HDFS

start-dfs.sh

Este comando iniciará NameNode y DataNode de Hdfs. El NameNode se inicia principalmente a través de la
clase org.apache.hadoop.hdfs.server.namenode.NameNode.

Nos centramos en lo que hace el NameNode durante el proceso de inicio (no se estudiarán los detalles técnicos que se desvíen de la línea principal)

Para el proceso de inicio del análisis, dos partes del código se refieren principalmente a:

La principal responsabilidad de namenode es la gestión de la metainformación de archivos y el mapeo de bloques de datos. En consecuencia, el proceso de inicio del nodo de nombre debe centrarse en el hilo de trabajo que se comunica con el cliente y el nodo de datos, el mecanismo de gestión de metainformación de archivos y el mecanismo de gestión de bloques de datos. Entre ellos, RpcServer es el principal responsable de la comunicación con los clientes y los nodos de datos, y FSDirectory es el principal responsable de administrar la metainformación del archivo.

Sección 3 Proceso de inicio de DataNode

La clase principal de datanode es DataNode, primero busque DataNode.main ()

Sección 4 Proceso de escritura de datos

Hay muchos hilos de trabajo importantes en datanode. Entre ellos, DataXceiverServer y BPServiceActor están más estrechamente relacionados con el proceso de escritura de bloques de datos. El cliente y el nodo de datos completan principalmente la lectura / escritura del bloque de datos a través del protocolo de transferencia de datos.

DataTransferProtocol se utiliza para transmitir la comunicación entre clientes y nodos de datos en todo el pipeline. Entre ellos, DataTransferProtocol - writeBlock () es responsable de escribir bloques de datos:

Sección 5 Cómo NameNode admite un alto acceso concurrente (mecanismo de almacenamiento en búfer doble)

Qué tipo de problemas se encontrarán al acceder a NameNode al mismo tiempo:

Después de aprender el mecanismo de gestión de metadatos de HDFS, el cliente solicita al NameNode que modifique una pieza de metadatos cada vez

(En lugar de solicitar la carga de un archivo, debe escribir un registro de ediciones, que consta de dos pasos:

Escribir en el disco local: edita el archivo

Se transmite al clúster JournalNodes a través de la red (clúster Hadoop HA combinado con zookeeper para aprender).

La dificultad de una alta concurrencia radica en la seguridad de los datos de múltiples subprocesos y la eficiencia de cada operación. !

Para seguridad multihilo:

NameNode tiene algunos principios al escribir el registro de ediciones:

Al escribir datos en edits_log, es necesario asegurarse de que cada edición tenga un transactionId (txid para abreviar) que aumenta en orden global, de modo que se pueda identificar el orden de las ediciones.

Si desea asegurarse de que se incremente el txid de cada edición, debe agregar un bloqueo de sincronización. Es decir, cuando cada hilo modifica los metadatos, cuando quieres escribir una edición, debes hacer cola para adquirir el bloqueo para generar un txid incremental, que representa el número de serie de las ediciones que se escribirán esta vez.

El problema resultante:
si cada vez que se genera un bloque de código bloqueado, se genera txid y luego se escribe el registro de ediciones del archivo de disco, este tipo de operación de bloqueo de sincronización y escritura en disco consume mucho tiempo. !

Solución de optimización de HDFS
La razón principal del problema es que la serialización y la puesta en cola al escribir ediciones dan como resultado un aumento en txid + la operación del disco de escritura lleva tiempo,

Solución HDFS
1. Serialización: utilice bloqueo de segmento
2. Escritura en disco: utilice doble búfer

En el mecanismo de bloqueo segmentado, cada subproceso adquiere el bloqueo por primera vez en secuencia, genera un txid que aumenta secuencialmente y luego escribe las ediciones en el área 1 de memoria con doble búfer y luego libera el bloqueo por primera vez. Aprovechando esta brecha, los subprocesos posteriores pueden adquirir el bloqueo nuevamente por primera vez y luego escribir inmediatamente sus propias ediciones en el búfer de memoria.

El programa del mecanismo de doble búfer abrirá dos espacios de memoria idénticos, uno de los cuales es bufCurrent, y los datos generados se escribirán directamente en bufCurrent, y el otro se llamará bufReady, y los datos se escribirán en bufCurrent (hasta uno After fijando el estándar), se intercambiarán las dos memorias. Intercambie directamente el área 1 y el área 2 con doble búfer. Se garantiza que todas las solicitudes de escritura de datos del cliente se reciban desde la memoria operativa, no en el disco de forma síncrona.

Análisis de código fuente de doble búfer

Amplíe la descripción general de las nuevas funciones de Hadoop 3.x

Se han mejorado muchas características en Hadoop3.x. En Hadoop3.x, jdk1.7 ya no está permitido y se requiere jdk1.8 o superior. Esto se debe a que Hadoop 2.0 se desarrolló en base a JDK 1.7, y JDK 1.7 se dejó de actualizar en abril de 2015, lo que obligó directamente a la comunidad de Hadoop a volver a lanzar una nueva versión de Hadoop basada en JDK 1.8, que es exactamente Hadoop 3.x. Hadoop 3.x ajustará la arquitectura del proyecto en el futuro, y mapreduce se basará en memoria + io + disco para procesar datos juntos.

Hadoop 3.x introdujo algunas funciones y optimizaciones importantes, incluida la codificación borrable HDFS, la compatibilidad con múltiples Namenode, la optimización MR NativeTask, la memoria basada en cgroup YARN y el aislamiento de E / S de disco, el cambio de tamaño del contenedor YARN, etc.

La dirección del documento oficial de Hadoop3.x es la siguiente:

http://hadoop.apache.org/docs/r3.0.1/

Mejoras comunes de las nuevas funciones de Hadoop3.x

Mejoras comunes de Hadoop:

1. Optimice el kernel de Hadoop, incluida la eliminación de las API e implementaciones obsoletas, el reemplazo de la implementación del componente predeterminado con la implementación más eficiente (por ejemplo, el cambio de la implementación predeterminada de FileOutputCommitter a v2, la abolición de hftp y su reemplazo con webhdfs, y la eliminación del sub de Hadoop -implementación de la biblioteca de serialización org.apache.hadoop.Records

2. El aislamiento Lasspath se utiliza para evitar conflictos entre diferentes versiones de paquetes jar. Por ejemplo, cuando Google Guava mezcla Hadoop, HBase y Spark, es fácil causar conflictos. (Https://issues.apache.org/jira/browse / HADOOP -11656)

3. Reconstrucción del script de shell. Hadoop 3.0 refactorizó los scripts de administración de Hadoop, corrigió una gran cantidad de errores, agregó nuevas funciones y admitió comandos dinámicos. El método de uso es consistente con la versión anterior. (Https://issues.apache.org/jira/browse/HADOOP-9902)

Mejora de HDFS de las nuevas funciones de Hadoop3.x

El cambio más significativo en Hadoop3.x es HDFS. HDFS se calcula mediante el último bloque negro. De acuerdo con el principio de cálculo reciente, el bloque negro local se agrega a la memoria, primero calculado, a través del IO, área de cálculo de memoria compartida, y finalmente formó rápidamente el resultado del cálculo.

1. HDFS admite la codificación de borrado de datos, lo que permite que HDFS ahorre la mitad del espacio de almacenamiento sin reducir la confiabilidad. (Https://issues.apache.org/jira/browse/HDFS-7285)

2. Compatibilidad con Multi-NameNode, es decir, admitir la implementación de un namenode activo y múltiples en espera en un clúster. Nota: La función multi-ResourceManager ha sido compatible con hadoop 2.0. (Https://issues.apache.org/jira/browse/HDFS-6440)

La dirección del documento oficial para estas dos características:

http://hadoop.apache.org/docs/r3.0.1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html

http://hadoop.apache.org/docs/r3.0.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

Mejora de YARN de las nuevas funciones de Hadoop3.x

1. Aislamiento de memoria basado en Cgroup y aislamiento de disco de E / S (https://issues.apache.org/jira/browse/YARN-2619)

2. Utilice el curador para implementar la elección del líder de RM (https://issues.apache.org/jira/browse/YARN-4438)

3. tamaño del contenedor （https://issues.apache.org/jira/browse/YARN-1197）

4. Timelineserver de próxima generación （https://issues.apache.org/jira/browse/YARN-2928）

Dirección del documento oficial:

http://hadoop.apache.org/docs/r3.0.1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2 .html

MapReduce mejora de las nuevas funciones de Hadoop3.x

1. Optimización de tareas. Se agregó la implementación del recopilador de salida de mapas C / C ++ (incluidos Derramar, Ordenar, IFile, etc.) a MapReduce, y puede cambiar a esta implementación ajustando los parámetros de nivel de trabajo. Para aplicaciones intensivas en reproducción aleatoria, su rendimiento se puede mejorar en aproximadamente un 30%. (Https://issues.apache.org/jira/browse/MAPREDUCE-2841)

2. Los parámetros de memoria de MapReduce se infieren automáticamente. En Hadoop 2.0, configurar los parámetros de memoria para los trabajos de MapReduce es muy engorroso, ya que implica dos parámetros: mapreduce. {Map, reduce} .memory.mb y mapreduce. {Map, reduce} .java.opts. Una vez que la configuración sea irrazonable, lo hará causar un grave desperdicio de recursos de memoria. Si el primero se establece en 4096 MB, pero el segundo se establece en "-Xmx2g", los 2g restantes no pueden ser utilizados por el montón de Java. (Https://issues.apache.org/jira/browse/MAPREDUCE-5785)

Otras características nuevas de Hadoop 3.x

1. Agregue nuevos componentes hadoop-client-api y hadoop-client-runtime a un solo paquete jar para resolver el problema de la incompatibilidad de dependencias (https://issues.apache.org/jira/browse / HADOOP-11804)
2. Admite el sistema de archivos distribuidos Azure de Microsoft y el sistema de archivos distribuidos aliyun de Arab

3.1.4 Hadoop, Yarn, estrategia de programación de recursos, análisis del código fuente del núcleo de Apache Hadoop, descripción general de las nuevas características de Hadoop 3.x

Parte 7 Programación de recursos de YARN

Sección 1 Arquitectura del hilo