Arquitectura Apache Hadoop HDFS

Introducción:

En este blog, voy a hablar sobre Apache Hadoop HDFS Architecture. HDFS y YARN son los dos conceptos importantes que debe dominar para obtener la certificación Hadoop . Por mi blog anterior , ya sabe que HDFS es un sistema de archivos distribuido que se implementa en hardware básico de bajo costo. Por lo tanto, es hora de que profundicemos en la arquitectura Apache Hadoop HDFS y descubramos su belleza.
Los temas que se tratarán en este blog sobre la arquitectura Apache Hadoop HDFS son los siguientes:

• Topología maestro / esclavo HDFS
• NameNode , DataNode y NameNode secundario
• ¿Qué es un bloque?
• Gestión de la replicación
• Conciencia de rack
• Lectura / escritura HDFS: entre bastidores

Arquitectura HDFS:

Apache HDFS o Hadoop Distributed File System es un sistema de archivos estructurado por bloques donde cada archivo se divide en bloques de un tamaño predeterminado. Estos bloques se almacenan en un grupo de una o varias máquinas. Apache Hadoop HDFS Architecture sigue una arquitectura maestro / esclavo , donde un clúster se compone de un solo NameNode (nodo maestro) y todos los demás nodos son DataNodes (nodos esclavos).HDFS se puede implementar en un amplio espectro de máquinas compatibles con Java. Aunque se pueden ejecutar varios DataNodes en una sola máquina, en el mundo práctico, estos DataNodes se distribuyen en varias máquinas.

NameNode:

NameNode es el nodo maestro en la arquitectura Apache Hadoop HDFS que mantiene y administra los bloques presentes en los DataNodes (nodos esclavos). NameNode es un servidor de alta disponibilidad que administra el espacio de nombres del sistema de archivos y controla el acceso a los archivos por parte de los clientes. Hablaré de esta función de alta disponibilidad de Apache Hadoop HDFS en mi próximo blog. La arquitectura HDFS está construida de tal manera que los datos del usuario nunca residen en el NameNode. Los datos residen solo en DataNodes.
Funciones de NameNode:

• Es el demonio maestro que mantiene y administra los DataNodes (nodos esclavos)
• Registra los metadatos de todos los archivos almacenados en el clúster, por ejemplo, la ubicación de los bloques almacenados, el tamaño de los archivos, los permisos, la jerarquía, etc. Hay dos archivos asociados con los metadatos:
• FsImage: contiene el estado completo del espacio de nombres del sistema de archivos desde el inicio del NameNode.
• EditLogs: Contiene todas las modificaciones recientes realizadas al sistema de archivos con respecto a la FsImage más reciente.
• Registra cada cambio que tiene lugar en los metadatos del sistema de archivos. Por ejemplo, si se elimina un archivo en HDFS, NameNode lo registrará inmediatamente en el EditLog.
• Recibe regularmente un Heartbeat y un informe de bloque de todos los DataNodes en el clúster para garantizar que los DataNodes estén activos.
• Mantiene un registro de todos los bloques en HDFS y en qué nodos se encuentran estos bloques.
• El NameNode también es responsable de cuidar el factor de replicación de todos los bloques que discutiremos en detalle más adelante en este blog tutorial de HDFS.
• En caso de falla de DataNode , NameNode elige nuevos DataNodes para nuevas réplicas, equilibra el uso del disco y administra el tráfico de comunicación a los DataNodes.

DataNode:

Los DataNodes son los nodos esclavos en HDFS. A diferencia de NameNode, DataNode es un hardware básico, es decir, un sistema económico que no es de alta calidad ni alta disponibilidad. El DataNode es un servidor de bloques que almacena los datos en el archivo local ext3 o ext4.
Funciones de DataNode:

• Estos son demonios esclavos o procesos que se ejecutan en cada máquina esclava.
• Los datos reales se almacenan en DataNodes.
• Los DataNodes realizan las solicitudes de lectura y escritura de bajo nivel de los clientes del sistema de archivos.
• Envían latidos al NameNode periódicamente para informar el estado general de HDFS; de forma predeterminada, esta frecuencia se establece en 3 segundos.

Hasta ahora, debe haberse dado cuenta de que NameNode es bastante importante para nosotros. Si falla, estamos condenados. Pero no se preocupe, hablaremos sobre cómo Hadoop resolvió este problema de punto único de falla en el próximo blog de Apache Hadoop HDFS Architecture. Entonces, relájese por ahora y demos un paso a la vez.

Nodo de nombre secundario:

Aparte de estos dos demonios, hay un tercer demonio o un proceso llamado Nodo de nombre secundario. El NameNode secundario funciona al mismo tiempo que el NameNode primario como un demonio auxiliar. Y no se confunda acerca de que el NameNode secundario sea un NameNode de respaldo porque no lo es.

Funciones de NameNode secundario:

• El NameNode secundario es uno que lee constantemente todos los sistemas de archivos y metadatos de la RAM del NameNode y los escribe en el disco duro o en el sistema de archivos.
• Es responsable de combinar los EditLogs con FsImage del NameNode.
• Descarga los EditLogs del NameNode a intervalos regulares y se aplica a FsImage. La nueva FsImage se copia de nuevo al NameNode, que se usa cada vez que se inicia NameNode la próxima vez.

Por lo tanto, Secondary NameNode realiza puntos de control regulares en HDFS. Por lo tanto, también se llama CheckpointNode.

Bloques:

Ahora, como sabemos, los datos en HDFS se encuentran dispersos en los DataNodes como bloques. Echemos un vistazo a qué es un bloque y cómo se forma.
Los bloques no son más que la ubicación continua más pequeña en su disco duro donde se almacenan los datos. En general, en cualquiera de los sistemas de archivos, almacena los datos como una colección de bloques. De manera similar, HDFS almacena cada archivo como bloques que se encuentran dispersos por todo el clúster de Apache Hadoop. El tamaño predeterminado de cada bloque es de 128 MB en Apache Hadoop 2 . x (64 MB en Apache Hadoop 1 .x ) que puede configurar según sus necesidades.

No es necesario que en HDFS, cada archivo se almacene en múltiplos exactos del tamaño de bloque configurado (128 MB, 256 MB, etc.). Tomemos un ejemplo en el que tengo un archivo “example.txt” de tamaño 514 MB como se muestra en la figura anterior. Supongamos que estamos usando la configuración predeterminada de tamaño de bloque, que es de 128 MB. Entonces, ¿cuántos bloques se crearán? 5, a la derecha. El f rimero cuatro bloques será de 128 MB. Pero el último bloque tendrá solo 2 MB de tamaño.

Ahora, debe estar pensando por qué necesitamos tener un tamaño de bloque tan grande, es decir, 128 MB.

Bueno, siempre que hablamos de HDFS, hablamos de conjuntos de datos enormes, es decir, terabytes y petabytes de datos. Entonces, si tuviéramos un tamaño de bloque de digamos 4 KB, como en el sistema de archivos de Linux, tendríamos demasiados bloques y, por lo tanto, demasiados metadatos. Entonces, manejando estos no. de bloques y metadatos creará una sobrecarga enorme , que es algo que no queremos.
Como entendió qué es un bloque , comprendamos cómo se lleva a cabo la replicación de estos bloques en la siguiente sección de esta Arquitectura HDFS. Mientras tanto , puede consultar este video tutorial sobre la arquitectura HDFS, donde se han discutido en detalle todos los conceptos de la arquitectura HDFS:

Gestión de la replicación:

HDFS proporciona una forma confiable de almacenar grandes datos en un entorno distribuido como bloques de datos. Los bloques también se replican para proporcionar tolerancia a fallas. El factor de replicación predeterminado es 3, que nuevamente se puede configurar. Entonces, como puede ver en la figura a continuación, donde cada bloque se replica tres veces y se almacena en diferentes DataNodes (considerando el factor de replicación predeterminado):

Por lo tanto, si estás almacenando un archivo de 128 MB en HDFS usando la configuración predeterminada, terminarás ocupando un espacio de 384 MB (3 * 128 MB) ya que los bloques se replicarán tres veces y cada réplica residirá en un DataNode diferente.
Nota: NameNode recopila informes de bloques de DataNode periódicamente para mantener el factor de replicación. Por lo tanto, cada vez que un bloque se replica en exceso o no, el NameNode elimina o agrega réplicas según sea necesario.

Conciencia de rack:

De todos modos, avanzando, hablemos más sobre cómo HDFS coloca la réplica y qué es el reconocimiento de rack. Nuevamente, NameNode también garantiza que todas las réplicas no se almacenen en el mismo bastidor o en un único bastidor. Sigue un algoritmo de reconocimiento de bastidor incorporado para reducir la latencia y proporcionar tolerancia a fallas. Teniendo en cuenta que el factor de replicación es 3, el algoritmo Rack Awareness dice que la primera réplica de un bloque se almacenará en un rack local y las siguientes dos réplicas se almacenarán en un rack diferente (remoto) pero, en un DataNode diferente dentro de ese ( remoto) rack como se muestra en la figura anterior. Si tiene más réplicas, el resto de las réplicas se colocarán en DataNodes aleatorios siempre que no haya más de dos réplicas en el mismo bastidor, si es posible.
Así es como se ve un clúster de producción de Hadoop real. Aquí, tiene varios racks llenos de DataNodes:

Ventajas de Rack Awareness:
Entonces, ahora estará pensando por qué necesitamos un algoritmo de reconocimiento de rack. Las razones son:

• Para mejorar el rendimiento de la red: La comunicación entre nodos que residen en diferentes racks se dirige a través de un conmutador. En general, encontrará un mayor ancho de banda de red entre máquinas en el mismo bastidor que las máquinas que residen en distintos bastidores. Por lo tanto, Rack Awareness le ayuda a reducir el tráfico de escritura entre diferentes racks y, por lo tanto, proporciona un mejor rendimiento de escritura. Además, obtendrá un mayor rendimiento de lectura porque está utilizando el ancho de banda de varios racks.
• Para evitar la pérdida de datos: No tenemos que preocuparnos por los datos incluso si falla todo un rack debido a la falla del interruptor o al corte de energía. Y si lo piensas, tendrá sentido, ya que se dice que nunca pongas todos tus huevos en la misma canasta.

Arquitectura de lectura / escritura HDFS:

Ahora hablemos de cómo se realizan las operaciones de lectura / escritura de datos en HDFS. HDFS sigue la filosofía Write Once – Read Many. Por lo tanto, no puede editar archivos que ya estén almacenados en HDFS. Pero puede agregar nuevos datos volviendo a abrir el archivo.

Arquitectura de escritura HDFS:

Suponga una situación en la que un cliente HDFS desea escribir un archivo llamado “ejemplo.txt” de tamaño 248 MB.

Suponga que el tamaño del bloque del sistema está configurado para 128 MB (predeterminado). Entonces, el cliente dividirá el archivo “example.txt” en 2 bloques, uno de 128 MB (bloque A) y el otro de 120 MB (bloque B).

Entrenamiento de Big Data

Ahora, se seguirá el siguiente protocolo siempre que los datos se escriban en HDFS:

• Al principio, el cliente HDFS se comunicará con el NameNode para obtener una solicitud de escritura en los dos bloques, por ejemplo, Bloque A y Bloque B.
• El NameNode otorgará al cliente el permiso de escritura y proporcionará las direcciones IP de los DataNodes donde los bloques de archivos se copiarán eventualmente.
• La selección de direcciones IP de DataNodes es puramente aleatoria en función de la disponibilidad, el factor de replicación y el conocimiento del rack que hemos discutido anteriormente.
• Digamos que el factor de replicación está configurado por defecto, es decir, 3. Por lo tanto, para cada bloque, el NameNode proporcionará al cliente una lista de (3) direcciones IP de DataNodes. La lista será única para cada bloque.
• Supongamos que NameNode proporcionó las siguientes listas de direcciones IP al cliente:
  • Para el bloque A, enumere A = {IP de DataNode 1, IP de DataNode 4, IP de DataNode 6}
  • Para el bloque B, establezca B = {IP de DataNode 3, IP de DataNode 7, IP de DataNode 9
• Cada bloque se copiará en tres DataNodes diferentes para mantener el factor de replicación consistente en todo el clúster.
• Ahora todo el proceso de copia de datos ocurrirá en tres etapas:

1. Configuración de Pipeline
2. Transmisión y replicación de datos
3. Cierre del oleoducto (etapa de reconocimiento)

1. Configuración de Pipeline:

Antes de escribir los bloques, el cliente confirma si los DataNodes, presentes en cada una de la lista de IPs, están listos para recibir los datos o no. Al hacerlo, el cliente crea una canalización para cada uno de los bloques conectando los DataNodes individuales en la lista respectiva para ese bloque. Consideremos el Bloque A. La lista de DataNodes proporcionada por NameNode es :
Para el bloque A, enumere A = {IP de DataNode 1, IP de DataNode 4, IP de DataNode 6}.



Entonces, para el bloque A, el cliente realizará los siguientes pasos para crear una canalización:

• El cliente elegirá el primer DataNode de la lista (IP de DataNode para el Bloque A) que es DataNode 1 y establecerá una conexión TCP / IP.
• El cliente informará a DataNode 1 que esté listo para recibir el bloque. También proporcionará las direcciones IP de los siguientes dos DataNodes (4 y 6) al DataNode 1 donde se supone que se replicará el bloque.
• El DataNode 1 se conectará al DataNode 4. El DataNode 1 le informará al DataNode 4 que está listo para recibir el bloque y le dará la IP del DataNode 6. Luego, el DataNode 4 le dirá al DataNode 6 que esté listo para recibir los datos.
• A continuación, el reconocimiento de disponibilidad seguirá la secuencia inversa, es decir, desde el DataNode 6 al 4 y luego al 1.
• Por último, DataNode 1 informará al cliente que todos los DataNode están listos y se formará una tubería entre el cliente, DataNode 1, 4 y 6.
• Ahora la configuración de la canalización está completa y el cliente finalmente comenzará el proceso de copia o transmisión de datos.
2. Transmisión de datos:

A medida que se ha creado la canalización, el cliente enviará los datos a la canalización. Ahora, no olvide que en HDFS, los datos se replican según el factor de replicación. Entonces, aquí el Bloque A se almacenará en tres DataNodes ya que el factor de replicación asumido es 3. Continuando, el cliente copiará el bloque (A) en DataNode 1 solamente. DataNodes siempre realiza la replicación de forma secuencial.



Por lo tanto, se llevarán a cabo los siguientes pasos durante la replicación:

• Una vez que el cliente haya escrito el bloque en DataNode 1, DataNode 1 se conectará a DataNode 4.
• Luego, DataNode 1 empujará el bloque en la canalización y los datos se copiarán en DataNode 4.
• Nuevamente, DataNode 4 se conectará a DataNode 6 y copiará la última réplica del bloque.
3. Etapa de cierre de oleoducto o reconocimiento:

Una vez que el bloque se ha copiado en los tres DataNodes, se llevará a cabo una serie de reconocimientos para garantizar al cliente y al NameNode que los datos se han escrito correctamente. Luego, el cliente finalmente cerrará la canalización para finalizar la sesión TCP.
Como se muestra en la figura siguiente, el reconocimiento ocurre en la secuencia inversa, es decir, del DataNode 6 al 4 y luego al 1. Finalmente, el DataNode 1 insertará tres reconocimientos (incluido el suyo) en la canalización y lo enviará al cliente. El cliente informará a NameNode que los datos se han escrito correctamente. NameNode actualizará sus metadatos y el cliente cerrará la canalización.



De manera similar, el Bloque B también se copiará en los DataNodes en paralelo con el Bloque A. Por lo tanto, las siguientes cosas deben notarse aquí:

• El cliente copiará el Bloque A y el Bloque B al primer DataNode simultáneamente .
• Por tanto, en nuestro caso, se formarán dos oleoductos para cada uno de los bloques y todo el proceso comentado anteriormente sucederá en paralelo en estos dos oleoductos.
• El cliente escribe el bloque en el primer DataNode y luego los DataNodes replicarán el bloque secuencialmente.


Como puede ver en la imagen de arriba, hay dos tuberías formadas para cada bloque (A y B). A continuación se muestra el flujo de operaciones que se está llevando a cabo para cada bloque en sus respectivos ductos:

• Para el bloque A: 1A -> 2A -> 3A -> 4A
• Para el bloque B: 1B -> 2B -> 3B -> 4B -> 5B -> 6B

Arquitectura de lectura HDFS:

La arquitectura de lectura HDFS es comparativamente fácil de entender. Tomemos el ejemplo anterior nuevamente donde el cliente HDFS quiere leer el archivo “ejemplo.txt” ahora.

Ahora, se llevarán a cabo los siguientes pasos mientras lee el archivo:

• El cliente se comunicará con NameNode solicitando los metadatos del bloque para el archivo “ejemplo.txt”.
• El NameNode devolverá la lista de DataNodes donde se almacena cada bloque (Bloque A y B).
• Después de ese cliente, se conectará a los DataNodes donde se almacenan los bloques.
• El cliente comienza a leer datos en paralelo desde los DataNodes (Bloque A de DataNode 1 y Bloque B de DataNode 3).
• Una vez que el cliente obtiene todos los bloques de archivos necesarios, combinará estos bloques para formar un archivo.

Mientras atiende la solicitud de lectura del cliente, HDFS selecciona la réplica más cercana al cliente. Esto reduce la latencia de lectura y el consumo de ancho de banda. Por lo tanto, se selecciona esa réplica que reside en el mismo bastidor que el nodo lector, si es posible.
Ahora, debería tener una idea bastante clara sobre Apache Hadoop HDFS Architecture. Entiendo que hay mucha información aquí y puede que no sea fácil obtenerla de una vez. Le sugiero que lo revise de nuevo y estoy seguro de que lo encontrará más fácil esta vez. Ahora, en mi próximo blog, hablaré sobre Apache Hadoop HDFS Federation y High Availability Architecture.
Ahora que ha entendido la arquitectura de Hadoop, consulte la formación de Hadoop de Pentademy, una empresa de aprendizaje en línea de confianza con una red de más de 250.000 alumnos satisfechos repartidos por todo el mundo. El curso de formación de certificación de Pentademy Big Data Hadoop ayuda a los alumnos a convertirse en expertos en HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume y Sqoop utilizando casos de uso en tiempo real en el dominio de comercio minorista, redes sociales, aviación, turismo y finanzas.
Tienes una pregunta para nosotros? Menciónelo en la sección de comentarios y nos comunicaremos con usted.