Principios básicos de HDFS
Hadoop Distributed File System (HDFS) implementa lectura/escritura confiable y distribuida de cantidades masivas de datos. HDFS es aplicable al escenario en el que las características de lectura/escritura de datos "escriban una vez y lean varias veces". Sin embargo, la operación de escritura se realiza en secuencia, es decir, es una operación de escritura realizada durante la creación del archivo o una operación de adición realizada detrás del archivo existente. HDFS se asegura de que solo una persona que llama puede realizar la operación de escritura en un archivo, pero varias personas que llaman pueden realizar la operación de lectura en el archivo al mismo tiempo.
Arquitectura
El HDFS se compone de NameNodes activo y en espera y DataNodes múltiples, como se muestra en el Figura 1.
HDFS trabaja en arquitectura maestra/esclava. NameNodes se ejecuta en el nodo maestro (activo) y DataNodes se ejecuta en el nodo esclavo (en espera). ZKFC debería funcionar junto con el NameNodes.
La comunicación entre NameNodes y DataNodes se basa en el Protocolo de Control de Transmisión (TCP)/Protocolo de Internet (IP). Los NameNode, DataNode, ZKFC y JournalNode se pueden implementar en servidores de Linux.
Tabla 1 describe las funciones de cada módulo mostrado en Figura 1.
|
Módulo |
Descripción |
|---|---|
|
NameNode |
Un NameNode se utiliza para gestionar el espacio de nombres, la estructura de directorios y la información de metadatos de un sistema de archivos y proporcionar el mecanismo de copia de respaldo. El NameNode se clasifica en los dos tipos siguientes:
|
|
DataNode |
Se utiliza un DataNode para almacenar bloques de datos de cada archivo e informar periódicamente al NameNode del estado de almacenamiento. |
|
JournalNode |
En el clúster de HA, sincroniza los metadatos entre los NameNodes activo y en espera. |
|
ZKFC |
Se debe implementar ZKFC para cada NameNode. Supervisa el estado de NameNode y escribe información de estado en ZooKeeper. ZKFC también tiene permisos para seleccionar el NameNode activo. |
|
ZK Cluster |
ZooKeeper es un servicio de coordinación que ayuda a la ZKFC a elegir el NameNode activo. |
|
HttpFS gateway |
HttpFS es un único proceso de gateway sin estado que proporciona la WebHDFS REST API para procesos externos y FileSystem API para HDFS. HttpFS se utiliza para la transmisión de datos entre diferentes versiones de Hadoop. También se utiliza como gateway para acceder al HDFS detrás de un firewall. |
- Arquitectura de HDFS HA
HA se utiliza para resolver el problema de SPOF de NameNode. Esta función proporciona un NameNode en espera para el NameNode activo. Cuando el NameNode activo está defectuoso, el NameNode en espera puede asumir rápidamente el control para proporcionar continuamente servicios para sistemas externos.
En un escenario de HDFS HA típico, normalmente hay dos NameNodes. Uno está en el estado activo, y el otro en el estado de espera.
Se requiere un sistema de almacenamiento compartido para admitir la sincronización de metadatos del NameNodes activo y en espera. Esta versión proporciona la solución de HA del Quorum Journal Manager (QJM), como se muestra en el documento Figura 2. Se utiliza un grupo de JournalNodes para sincronizar metadatos entre los NameNodes activo y en espera.
Generalmente, se configura un número impar (2N+1) de JournalNodes y se requieren al menos tres JournalNodes. Para un mensaje de actualización de metadatos, la escritura de datos se considera exitosa siempre que la escritura de datos sea exitosa en JournalNodes N+1. En este caso, se permite una falla de escritura de datos de un máximo de N JournalNodes. Por ejemplo, cuando hay tres JournalNodes, se permite el error de escritura de datos de un JournalNode; cuando hay cinco JournalNodes, se permite el error de escritura de datos de dos JournalNodes.
JournalNode es un proceso de daemon ligero y comparte un host con otros servicios de Hadoop. Se recomienda que el JournalNode se despliegue en el nodo de control para evitar el fallo de escritura de datos en el JournalNode durante la transmisión masiva de datos.
Principio
MRS utiliza el mecanismo de copia de HDFS para garantizar la confiabilidad de los datos. Un archivo de copia de respaldo se genera automáticamente por cada archivo guardado en HDFS, es decir, se generan dos copias en total. El número de copias HDFS se puede consultar mediante el parámetro dfs.replication.
- Cuando la especificación del nodo de Core del clúster MRS se establece en una unidad de disco duro no local (HDD) y el clúster solo tiene un nodo de Core, el número predeterminado de copias HDFS es 1. Si el número de nodos de Core en el clúster es mayor o igual a 2, el número predeterminado de copias HDFS es 2.
- Cuando la especificación del nodo Core del clúster MRS se establece en disco local y el clúster solo tiene un nodo de Core, el número predeterminado de copias HDFS es 1. Si hay dos nodos de Core en el clúster, el número predeterminado de copias HDFS es 2. Si el número de nodos de Core en el clúster es mayor o igual a 3, el número predeterminado de copias HDFS es 3.
El componente de HDFS de MRS admite las siguientes características:
- Soporta código de borrado, reduciendo la redundancia de datos al 50% y mejorando la confiabilidad. Además, se introduce la estructura de almacenamiento de bloques divididos para maximizar el uso de la capacidad de un único nodo y múltiples discos en un clúster existente. Después de introducir el proceso de codificación, se mejora el rendimiento de escritura de datos, y el rendimiento es cercano al de la redundancia multicopia.
- Admite la programación de nodos balanceados en HDFS y la programación de disco balanceado en un solo nodo, lo que mejora el rendimiento de almacenamiento de HDFS después del escalamiento horizontal del nodo o del disco.
Para obtener más información sobre la arquitectura y los principios de Hadoop, consulte https://hadoop.apache.org/.
