Funciones mejoradas de código abierto de HDFS
Función de código abierto mejorada: Colocación de bloques de archivos
En el escenario de resumen de datos y estadísticas fuera de línea, Join es una función informática de uso frecuente, y se implementa en el MapReduce de la siguiente manera:
- La tarea de Map procesa los registros de los dos archivos de tabla en Join Key y Value, realiza la partición hash por Join Key y envía los datos a diferentes tareas de Reduce para su procesamiento.
- Las tareas de Reduce que leen datos en la tabla izquierda recursivamente en el modo de nested loop y recorra cada línea de la tabla derecha. Si los valores de join key son idénticos, los resultados de join se generan.
El método anterior reduce drásticamente el rendimiento del cálculo de join. Debido a que se requiere una gran cantidad de transferencia de datos de red cuando los datos almacenados en diferentes nodos se envían desde MAP a Reduce, como se muestra en Figura 1.
Las tablas de datos se almacenan en el sistema de archivos físico por bloque de HDFS. Por lo tanto, si dos bloques a join se colocan en el mismo host en consecuencia después de que se particionen por join key, puede obtener los resultados directamente desde Map join en el nodo local sin ninguna transferencia de datos en el proceso Reduce del cálculo de join. Esto mejorará en gran medida el rendimiento.
Con la característica de distribución idéntica de los datos de HDFS, se asigna un mismo ID de distribución a los archivos, FileA y FileB, en los que se deben realizar cálculos de asociación y suma. De esta manera, todos los bloques se distribuyen juntos, y el cálculo se puede realizar sin recuperar datos entre nodos, lo que mejora enormemente el rendimiento de join de MapReduce.
Función de código abierto mejorada: Configuración de volumen de disco duro dañado
En la versión de código abierto, si se configuran varios volúmenes de almacenamiento de datos para un DataNode, el DataNode deja de proporcionar servicios de forma predeterminada si uno de los volúmenes está dañado. Si el elemento de configuración dfs.DataNode.failed.volumes.tolerated está configurado para especificar el número de volúmenes dañados permitidos, el DataNode sigue proporcionando servicios cuando el número de volúmenes dañados no supera el umbral.
El valor de dfs.DataNode.failed.volumes.tolerated oscila entre -1 y el número de volúmenes de disco configurados en el DataNode. El valor predeterminado es -1, como se muestra en el documento Figura 3.
Por ejemplo, se montan tres volúmenes de almacenamiento de datos en un DataNode y el dfs.DataNode.failed.volumes.tolerated se establece en 1. En este caso, si un volumen de almacenamiento de datos del DataNode no está disponible, este DataNode todavía puede proporcionar servicios, como se muestra en Figura 4.
Este elemento de configuración nativo tiene algunos defectos. Cuando el número de volúmenes de almacenamiento de datos en cada DataNode es inconsistente, debe configurar cada DataNode de forma independiente en lugar de generar el archivo de configuración unificado para todos los nodos.
Supongamos que hay tres DataNodes en un clúster. El primer nodo tiene tres directorios de datos, el segundo nodo tiene cuatro y el tercer nodo tiene cinco. Si desea asegurarse de que los servicios de DataNode están disponibles cuando solo hay un directorio de datos disponible, debe realizar la configuración como se muestra en Figura 5.
En HDFS mejorados de desarrollo propio, este elemento de configuración se mejora, con un valor agregado -1. Cuando este elemento de configuración se establece en -1, todos los DataNodes pueden proporcionar servicios siempre que esté disponible un volumen de almacenamiento de datos en todos los DataNodes.
Para resolver el problema en el ejemplo anterior, establezca esta configuración en -1 como se muestra en Figura 6.
Función de código abierto mejorada: aceleración de inicio de HDFS
En HDFS, cuando se inicia NameNodes, es necesario cargar el archivo de metadatos FsImage. A continuación, el DataNodes reportará la información del bloque de datos después del inicio del DataNodes. Cuando la información de bloque de datos reportada por DataNodes alcanza el porcentaje preestablecido, el NameNodes sale del modo seguro para completar el proceso de inicio. Si el número de archivos almacenados en el HDFS alcanza el nivel de millones o mil millones, los dos procesos consumen mucho tiempo y darán lugar a un largo tiempo de inicio del NameNode. Por lo tanto, esta versión optimiza el proceso de carga del archivo de metadatos FsImage.
En HDFS de código abierto, FsImage almacena todo tipo de información de metadatos. Cada tipo de información de metadatos (como la información de metadatos de archivos y la información de metadatos de carpetas) se almacena en un bloque de sección, respectivamente. Estos bloques de sección se cargan en modo serie durante el inicio. Si se almacena un gran número de archivos y carpetas en el HDFS, la carga de las dos secciones requiere mucho tiempo, lo que prolonga el tiempo de inicio del HDFS. El NameNode HDFS divide cada tipo de metadatos por segmentos y almacena los datos en varias secciones al generar los archivos FsImage. Cuando se inicia el NameNodes, las secciones se cargan en modo paralelo. Esto acelera el inicio de HDFS.
Función de código abierto mejorada: Políticas de colocación de bloques basadas en etiquetas (HDFS Nodelabel)
Debe configurar los nodos para almacenar bloques de datos de archivos HDFS en función de las características de datos. Puede configurar una expresión de etiqueta en un directorio o archivo HDFS y asignar una o más etiquetas a un DataNode para que los bloques de datos de archivo se puedan almacenar en DataNodes especificado. Si se utiliza la política de colocación de bloques de datos basada en etiquetas para seleccionar DataNodes para almacenar los archivos especificados, el intervalo de DataNode se especifica en función de la expresión de etiqueta. A continuación, se seleccionan los nodos adecuados del intervalo especificado.
- Puede almacenar las réplicas de bloques de datos en los nodos con diferentes etiquetas en consecuencia. Por ejemplo, almacenar dos réplicas del bloque de datos en el nodo etiquetado con L1, y almacenar otras réplicas del bloque de datos en los nodos etiquetados con L2.
- Puede establecer la política en caso de fallo de colocación de bloques, por ejemplo, seleccionar un nodo de todos los nodos al azar.
Figura 7 da un ejemplo:
- Los datos en /HBase se almacenan en A, B y D.
- Los datos en /Spark se almacenan en A, B, D, E y F.
- Los datos en /user se almacenan en C, D y F.
- Los datos en /user/shl se almacenan en A, E y F.
Función de código abierto mejorada: balanceo de carga HDFS
Las políticas de lectura y escritura actuales de HDFS son principalmente para la optimización local sin considerar la carga real de nodos o discos. Basado en cargas de E/S de diferentes nodos, el balanceo de carga de HDFS garantiza que cuando se realizan operaciones de lectura y escritura en el cliente HDFS, el nodo con baja carga de E/S se selecciona para realizar tales operaciones para balancear la carga de E/S y utilizar completamente el rendimiento global del grupo.
Si balancel de carga de HDFS está habilitado durante la escritura de archivos, el NameNode selecciona un DataNode (en el orden de nodo local, rack local y rack remoto). Si la carga de E/S del nodo seleccionado es pesada, el NameNode elegirá otro DataNode con una carga más ligera.
Si HDFS Load Balance está habilitado durante la lectura de archivos, un cliente HDFS envía una solicitud al NameNode para proporcionar la lista de DataNodes que almacenan el bloque que se va a leer. El NameNode devuelve una lista de DataNodes ordenados por distancia en la topología de red. Con la función de balanceo de carga HDFS, los DataNodes de la lista también se ordenan por su carga de E/S. Los DataNodes con carga pesada se encuentran en la parte inferior de la lista.
Función mejorada de código abierto: movimiento automático de datos HDFS
Hadoop se ha utilizado para el procesamiento por lotes de datos inmensos en mucho tiempo. El modelo HDFS existente se utiliza para satisfacer las necesidades de las aplicaciones de procesamiento por lotes muy bien porque tales aplicaciones se centran más en el rendimiento que en el retardo.
Sin embargo, como Hadoop se utiliza cada vez más para aplicaciones de capa superior que requieren acceso aleatorio frecuente de E/S, como Hive y HBase, los discos de baja latencia, como el disco de estado sólido (SSD), se ven favorecidos en escenarios sensibles al retardo. Para satisfacer la tendencia, HDFS admite una variedad de tipos de almacenamiento. Los usuarios pueden elegir un tipo de almacenamiento de acuerdo a sus necesidades.
Las políticas de almacenamiento varían en función de la frecuencia con la que se utilicen los datos. Por ejemplo, si los datos a los que se accede con frecuencia en HDFS se marcan como ALL_SSD o HOT los datos a los que se accede varias veces pueden marcarse como WARM y los datos a los que se accede raramente (solo una o dos veces) pueden marcarse como COLD. Puede seleccionar diferentes políticas de almacenamiento de datos según la frecuencia de acceso a los datos.
Sin embargo, los discos de baja latencia son mucho más caros que los discos giratorios. Los datos suelen ver un uso inicial intenso con una disminución en el uso durante un período de tiempo. Por lo tanto, puede ser útil si los datos que ya no se utilizan se mueven de discos costosos a los medios de almacenamiento más baratos.
Un ejemplo típico es el almacenamiento de registros de detalle. Los nuevos registros de detalle se importan a SSD porque las aplicaciones de capa superior consultan con frecuencia. A medida que disminuye la frecuencia de acceso a estos registros detallados, se trasladan a un almacenamiento más barato.
Antes de lograr el movimiento automático de datos, debe determinar manualmente por tipo de servicio si los datos se utilizan con frecuencia, establecer manualmente una política de almacenamiento de datos y activar manualmente la Herramienta de movimiento automático de datos HDFS, como se muestra en la siguiente figura.
Si los datos antiguos se pueden identificar automáticamente y transferir a un almacenamiento más barato (como el disco/archivo), verá reducciones significativas de costos y mejoras en la eficiencia de la gestión de datos.
- Marcar una política de almacenamiento de datos como All_SSD, One_SSD, Hot, Warm, Cold o FROZEN según la edad, el tiempo de acceso y las reglas de movimiento manual de datos.
- Defina reglas para distinguir los datos fríos y calientes según age de los datos, access time y las reglas de migración manual.
- Definir las medidas que se deben tomar si se cumplen las normas basadas en la age.
MARK: la acción para identificar si los datos se usan con frecuencia o rara vez en función de las reglas de age y establecer una política de almacenamiento de datos. MOVE: la acción para invocar la Herramienta de movimiento automático de datos HDFS y mover datos según las reglas de age para identificar si los datos se utilizan con frecuencia o rara vez después de haber determinado la política de almacenamiento correspondiente.
- MARK: identifica si los datos se utilizan con frecuencia o con poca frecuencia y establece la política de almacenamiento de datos.
- MOVE: la acción para invocar la Herramienta de movimiento automático de datos HDFS y mover datos entre niveles.
- SET_REPL: la acción para establecer una nueva cantidad de réplica para un archivo.
- MOVE_TO_FOLDER: la acción para mover archivos a una carpeta de destino.
- DELETE: la acción para eliminar un archivo o directorio.
- SET_NODE_LABEL: la acción para establecer etiquetas de nodo de un archivo.
Con la función de movimiento automático de datos HDFS, solo tiene que definir age en función de las reglas de access time. La herramienta de movimiento automático de datos HDFS hace coincidir los datos de acuerdo con las reglas basadas en age, establece políticas de almacenamiento y mueve datos. De esta manera, se mejora la eficiencia de la gestión de datos y la eficiencia de los recursos del clúster.
