Bienvenidos. Hoy vamos a continuar con la explicación de HDFS, el sistema de ficheros de Hadoop, y vamos a entrar en lo que es la descripción de la arquitectura de este sistema de ficheros. Como ya sabemos, los tres niveles básicos de Hadoop serían, por un lado, este nivel de almacenamiento HDFS, un gestor de recursos Yarn y lo que es el modelo de programación MapReduce que es el núcleo básico de programación de Hadoop. Vamos a centrarnos en este video en lo que es la explicación de la arquitectura de HDFS. En un video anterior comentamos las características que debería cumplir este sistema de almacenamiento y comentamos que se iba a utilizar hardware común, lo que denominábamos "commodity hardware". Es decir, que vamos a tener toda una serie de ordenadores formando un cluster, distribuidos entre uno o varios racks y vamos a dedicar uno de los nodos de este cluster para ejecutar lo que denominamos el "NameNode" o "NameNode", que va a ser el gestor del espacio de nombres y, en definitiva, el gestor del sistema de archivos. Va a almacenar todos los metadatos referentes a este sistema de archivos y va a tener lo que sería un repositorio de los datos referentes al sistema de archivos. Después, en cada uno de los nodos del sistema, vamos a tener otro proceso que denominamos "DataNode", que este DataNode vamos a tener, como les comentamos, uno por cada uno de los nodos del sistema y va a gestionar el almacenamiento local en cada uno de los nodos, es decir, de los discos locales de cada uno de los sistemas de los que se compone nuestro cluster. Entonces, tanto el NameNode como el DataNode están programados en Java y habitualmente corren sobre sistemas GNU/Linux, de modo que pueden ser transferidos a distintos sistemas, ejecutándose en muchos sistemas de cómputo diferentes de los que tenemos actualmente, permitiendo así una gran portabilidad del sistema. Cuando nosotros tenemos un fichero, este fichero lo vamos a dividir en un conjunto de bloques. El tamaño habitual de los bloques sería de unos 64 megas, 64 megabytes, pero este tamaño podría llegar a configurarse según las necesidades del usuario. Cuando tenemos estos bloques de los distintos archivos, se va a realizar una asignación por parte del NameNode, de los distintos bloques a los distintos nodos del sistema. Es decir, que van a estar distribuidos, un fichero va a estar distribuido físicamente entre bloques repartidos entre los distintos nodos del cluster. De esta manera, cuando queramos aplicar el modelo MapReduce para procesar los distintos nodos, ya tenemos los datos divididos y así, de esta manera, podemos ya aprovechar el paralelismo sin necesidad de hacer mayores movimientos. Una vez que tenemos esta asignación realizada, el NameNode no va a gestionar ya los datos de los archivos propiamente, sino que se va a hacer toda la gestión directamente desde los DataNodes. Es decir, que los clientes pueden realizar operaciones de escritura sobre los ficheros, pidiendo escribir datos en los distintos bloques de los ficheros, o pueden pedir realizar lecturas de los distintos bloques de los archivos. Pero estas peticiones, tanto de lectura como de escritura se dirigirán al DataNode sin pasar por el NameNode, de modo que el NameNode únicamente se encarga de gestionar lo que sería el sistema de ficheros desde un punto de vista organizativo, no tanto del punto de vista del acceso. Así, los clientes van accediendo a los distintos ficheros y pueden introducir peticiones para introducir lo que se denomina un "factor de replicación", es decir, que los archivos estén replicados. Entonces, la petición de replicación mediante este factor de replicación, se va a enviar a lo que será el NameNode y el NameNode va a mandar a los DataNodes la petición para que realicen la replicación, y se va a realizar la replicación de los distintos bloques para mandarlos a otros nodos del sistema y así, tener varias copias de los distintos bloques almacenadas en nuestro sistema de archivos. De esta manera, como que ya hemos comentado que vamos a utilizar hardware común con muchos nodos y es posible de que algún nodo se nos estropee, caiga, tenga algún fallo, entonces cuando se produzca algún fallo tendremos réplicas que nos va a permitir poder recuperar los datos de estos nodos que han caído. Esto, la manera de controlarlo es mediante unas señales que periódicamente van mandando los DataNodes hacia el NameNode, indicándole que están activos y mandándole un listado con todos los bloques que dispone ese DataNode en ese momento y que está gestionando ese DataNode. Este mensaje que les está enviando tradicionalmente se denomina un "Heartbeat", como un latido, diciendo "estoy funcionando y esta es la información de los bloques que tengo almacenados en este nodo". Cuando por algún motivo algún nodo falla, ese DataNode va a dejar de funcionar y va a dejar de enviar ese Heartbeat hacia el nodo NameNode. Entonces, cuando transcurrido un cierto tiempo el deadline, el NameNode detecta que no le ha llegado, el Heartbeat interpreta que ese nodo ha caído y que tiene que recuperar la información que había en ese nodo concreto, como que mantiene la lista de los bloques que había asignados en este mismo nodo, va a buscar los bloques que había, va a buscar donde están replicados y va a mandar peticiones a los nodos que mantienen la réplica para que realicen una nueva réplica que se asigne a otro nodo funcional del sistema, de modo que ahora volvamos a tener dos copias activas de los ficheros, como mínimo, y así, en caso de que vuelva a caer otro nodo podamos recuperar los datos. Como comentábamos, el número de réplicas puede ser establecido por el usuario. Cuantas más réplicas tengamos, evidentemente mayor seguridad tendrá el sistema, ya que podría soportar un mayor número de caídas simultáneas, pero también va a estar consumiendo un mayor espacio de almacenamiento. De esta manera, conseguimos mantener un sistema de réplicas que nos garantizan una de las características que le pedíamos al sistema de ficheros que era la tolerancia a fallos. HDFS puede ser accedido mediante un API Java que nos permite acceder a los archivos que quieren gestionar nuestras aplicaciones y también tenemos un Wrapper para acceder a este API Java desde "C" y así, poder gestionar, acceder, leer, escribir los ficheros desde nuestras aplicaciones. Asimismo, HDFS también nos ofrece un sistema de Shell denominado "FS Shell" que nos va a permitir ejecutar unos comandos habituales, como sería el de un sistema de archivos tradicional en Linux. Así, en este caso podemos tener algunos ejemplos de comandos de FS Shell, como sería un "mkdir" para crear un directorio, un "rm" para eliminar un archivo o un "cat" para visualizar un archivo. De hecho, tenemos todos los comandos más habituales de un sistema de archivos que nos van a permitir gestionar el sistema de archivos de HDFS y realizar las operaciones habituales con los archivos.
