2.1 Análisis de contenedor
2.2, Diseño arquitectónico de MapReduce 2.x
2.3, analizar wordcount.java
2.4 ¿Quién determina el número de inicios de la tarea de mapa?
2.4 ¿Considere el formato de archivo y el formato de compresión en producción?
2.5, análisis de diagrama de flujo de WordCount (aleatorio)

1. La última revisión del curso

https://blog.csdn.net/SparkOnYarn/article/details/105126486

Dos, Hadoop seis

2.1 Análisis de Contenedor para ajuste de producción de hilo

Contenedor: contenedorizado, virtualizado, dimensión: memoria + vcore, tarea en ejecución

¿Cómo ajustar la producción de contenedores?

Supongamos que la máquina es 128G y tiene 16 núcleos físicos

Ejemplo: después de instalar la máquina CentOS, el sistema consumirá 1G de memoria del sistema; el sistema reservará entre el 15% y el 20% de la memoria (para evitar que el sistema se agote debido a todo el uso de la memoria y el mecanismo OOM), o reservado para futuros componentes de implementación Espacio

Calcule el espacio reservado de acuerdo con las condiciones indicadas anteriormente: 128G X 20% = 25.6G es aproximadamente igual a 26G

1. Suponiendo que solo haya nodos DN y NM, la memoria restante se puede usar 128G-26G = 102G
DN = 2G
NM = 4G // Quedan 96G en este momento

2. Memoria del contenedor:

yarn.nodemanager.resource.memory-mb 96G (la memoria total restante que se puede asignar es 96G)
yarn.scheduler.minimum -ignment-mb 1G (la memoria mínima establecida para un contenedor es 1G, en el caso extremo solo hay 96 contenedores y la memoria es 1G)
yarn.scheduler.maximum -ignment-mb 96G (la memoria máxima de un contenedor es 8G, en el caso extremo, solo hay un contenedor, la memoria es 96G)

La memoria del Contenedor aumentará automáticamente, el valor predeterminado es incrementos de 1G:
por lo tanto, el número de Conatiner en este momento: 1-96 incrementos

3. Contenedor de núcleo virtual:

No hay núcleo físico en el hilo, solo el concepto de núcleo virtual; núcleo físico: núcleo virtual = 1: 2; aquí hay 32vcore.

Núcleo físico: el núcleo virtual es 1: 2 y su parámetro predeterminado: yarn.nodemanager.resource.pcores-vcores-multiplier 2

yarn.nodemanager.resource.pcores-vcores-multiplier 32vcore
yarn.scheduler.minimum-asignacion-vcores 1 (en casos extremos, solo 32 contenedores)
yarn.scheduler.maxima-asignación-vcores 32 (en casos extremos, solo 1 contenedor)
contenedor: 1-32 núcleos virtuales

4. Sugerencia oficial:
Cloudera recomienda que el vcore de un contenedor no exceda de 5, por lo que lo establecemos en 4 aquí; en otras palabras:
yarn.scheduler.minimum -ignment-vcores 4

En el caso extremo: 32vcore / 4 = 8 ejecutores

5. Entonces, al final, de acuerdo con la memoria + vcore:
asegúrese de que vcore = 4 ejecutor = 8, en el caso del límite de empuje inverso, cada ejecutor se establece en 12G

Resumen:

Para una máquina con 128G de memoria y 16 núcleos físicos: lo que podemos asignar es:
32vcore / 4vcore = 8 contenedores, para cumplir con las condiciones de memoria: 96G / 8 Container = cada contenedor es 12G, el punto de ruptura es 4 Vcores recomendados por Cloudera
Cuando Spark calcula, la memoria no es lo suficientemente grande, este parámetro debe ajustarse, luego debe romperse el número ideal de configuraciones, principalmente la memoria, para decirlo claramente, el propósito es permitir que la CPU y la Memoria maximicen el uso.

Si debe medirse desde la memoria o vcore

Parámetros de la memoria:
yarn.nodemanager.resource.memory-mb 96G (que controla toda la memoria libre restante)
yarn.scheduler.minimum-asignacion-mb 1G
yarn.scheduler.maximum-mapping-mb 8G

Principalmente memoria: el número de contenedores de contenedores: 12-96; tomamos el vcore más grande para calcular, 12 x 2 = 24 vcore, 24 es mucho menos que 32, no se puede usar al 100%.

虚拟 núcleo 参数
yarn.nodemanager.resource.pcores-vcores-multiplier 32vcore
yarn.scheduler.minimum-asignacion-vcores 1
yarn.scheduler.maximum -ignment-vcores 2

Principalmente basado en el núcleo virtual: el número de contenedores de contenedores: 16-32; 16 contenedores x 8G = 128G, que es mucho más grande que 96G explotará
Inserte la descripción de la imagen aquí

La configuración en yarn-default.xml es la siguiente:

nombre	valor	descripción
yarn.nodemanager.resource.memory-mb	96G (memoria total utilizada para cálculos)
yarn.scheduler.minimum -ignment-mb	1024MB	La asignación mínima para cada solicitud de contenedor en el RM en MB. Las solicitudes de memoria inferiores a esta se establecerán en el valor de esta propiedad. Además, el administrador de recursos cerrará un administrador de nodos configurado para tener menos memoria que este valor.
yarn.scheduler.maxima-asignación-mb	8192MB	La asignación máxima para cada solicitud de contenedor en el RM en MB. Las solicitudes de memoria superiores a esta arrojarán una InvalidResourceRequestException.

2.2. Cómo asignar parámetros

Si 256G de memoria, 56 núcleos físicos, ¿cómo configurar los parámetros?

De forma predeterminada, el 20% del espacio está reservado para el sistema, ya sea para eliminar la memoria ocupada por DN y NM; se calcula que todavía hay 200G de memoria restante; calculado de acuerdo con los 4 vcores recomendados por cloudera
Parámetros de memoria:
yarn.nodemanager.resource.memory-mb 200G (que controla toda la memoria libre restante)
yarn.scheduler.minimum-asignacion-mb 1G
yarn.scheduler.maximum -ignment-mb 8G

El número de contenedores es de 25 a 200, y se realiza el cálculo elástico.

虚拟 núcleo 参数：
yarn.nodemanager.resource.pcores-vcores-multiplier 112vcore
yarn.scheduler.minimum-asignacion-vcores 1
yarn.scheduler.maximum-asignacion-vcores 2

El número de contenedores es 56 ~ 112,

Si el nodo todavía tiene componentes, como hbase regionerver process = 30G, ¿cómo configurarlo?

El concepto de vcore: fue introducido por el propio hilo. El diseño original era considerar que el rendimiento de las CPU de diferentes nodos es diferente, y la potencia de cálculo de cada CPU es diferente; por ejemplo, una CPU física es el doble de la otra CPU física. El núcleo virtual de la primera CPU física compensa esta diferencia.

La primera máquina es potente: núcleo físico: núcleo virtual = 1: 1
segunda máquina: no potente: pcore: vcore = 1: 2
se puede configurar en xml, establecer directamente pcore en todos los nodos: vcore = 1: 2, ahora Básicamente, la configuración de la máquina de todos es similar.

2.3. Tres planificadores en hilo

El planificador se divide en los siguientes tres tipos:
1. FIFO: primero en entrar, primero en salir

Por ejemplo: comience el trabajo1 a las 0 en punto, comience el trabajo2 a la 1 en punto, solo espere a que se complete el trabajo1 antes de calcular el trabajo2.

2. Capacidad: planificador de cálculo

Hay una cola especial para ejecutar tareas pequeñas, pero una cola se configura específicamente para que una tarea pequeña ocupe ciertos recursos del clúster de antemano, lo que hará que el tiempo de ejecución de las tareas grandes se quede atrás del tiempo de programación FIFO.
Es decir, los recursos son solo del 100% y el 20% se reservará para tareas pequeñas, lo que conducirá a menos recursos para ejecutar tareas grandes. El aumento correspondiente es el tiempo.

Inserte la descripción de la imagen aquí
3. Justo: justo

Sigue siendo el ejemplo anterior: envíe el trabajo 1 a las 0 en punto, envíe el trabajo 2 a la 1 en punto; el trabajo 1 requiere 100% de recursos, espere a que la tarea en un contenedor complete la tarea y libere la memoria, luego comience a ejecutar el trabajo 2, el trabajo 2 se ejecutará nuevamente después de la finalización Devolver recursos al trabajo1

Programador en apache y cdh:

El valor predeterminado de Apache es el planificador de cálculo, los parámetros son los siguientes:
yarn.resourcemanager.scheduler.class org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

CDH por defecto es un planificador justo

Por qué CDH elige un planificador justo: dado que el planificador de cálculo no puede liberar todos los recursos, el 20% de la memoria siempre está ocupada.

El conjunto de recursos dinámicos + las reglas de ubicación aparecerán en cursos posteriores de cdh.

2.4 Comandos comunes en Yarn

1. Escenario: no puede iniciar sesión en la interfaz web del clúster CDH que administra, o el programa se bloquea; puede matar directamente en la interfaz web, pero no puede iniciar sesión en la página web, por lo que realiza la operación de matar en el terminal de Linux.

aplicación de hilo - matar
troncos de hilo

[hadoop@hadoop001 ~]$ yarn logs -applicationId application_1585204919350_0002
20/03/27 13:11:57 INFO client.RMProxy: Connecting to ResourceManager at /0.0.0.0:8032
20/03/27 13:11:57 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
/tmp/logs/hadoop/logs/application_1585204919350_0002 does not exist.
Log aggregation has not completed or is not enabled.

//需要安装服务

Efecto barril:

1. La capacidad de almacenamiento de agua de un barril de madera depende del tablero más corto. Cuando hacemos cálculos, los datos son archivos desiguales y habrá un efecto de barril similar.

blockize = 128m
a1 130m 2 tareas ejecutadas 55s
a2 14m 1 tarea ejecutada 5s
a3 20m 1 tarea ejecutada 9s

El trabajo debe ejecutar 4 tareas, es decir, el tiempo de finalización del trabajo nunca depende del tiempo de ejecución corto, sino que depende del tiempo de ejecución prolongado; la tarea anterior necesita 55 segundos para completarse.

Para los datos anteriores, debe ser regularizado. Cómo fusionar y dividir en Linux, el estado ideal de los datos es el siguiente:
blockize o 128m, se puede dividir de la siguiente manera: el tiempo consumido no es el más largo y el más corto
a1 130m-> 55m 1tarea
a2 14m- > 55m 1tarea
a3 20m-> 54m 1tarea

3. Esta tarea del curso && resumen

1. Cómo asignar los parámetros de ajuste de recursos de hilo *****

2. Tres tipos de planificadores: cada característica, el planificador predeterminado de cdh

Resumen:

Comando de Linux: cd mkdir rm vi ls chown chmod tar
mysql
creación de tabla especificación hdfs arquitectura diseño proceso de lectura-escritura copia colocación estrategia snn mecanismo
hadoop fs comando de uso básico
MR diagrama de flujo de conteo de palabras MR
núcleo de hilo: explicación detallada de los parámetros de ajuste de producción
enviados al hilo de trabajo Diagrama de flujo