principio de hdfs
arquitectura hdfs
destinado a
Almacene los metadatos de los archivos, como el nombre del archivo, la estructura del directorio del archivo, los atributos del archivo (tiempo de generación, número de copias, permisos de archivo), así como la lista de bloqueo de cada archivo y el nodo de datos donde se encuentra el bloque.
①fsimage: archivo espejo de metadatos. Almacene la información de metadatos de la memoria de NameNode durante un cierto período de tiempo.
②edits: archivo de registro de operaciones.
Tiempo: guarda el tiempo del último punto de control. El
nodo de
datos almacena los datos del bloque de archivos en el sistema de archivos, así como la suma de control de los datos.
El nodo de nombre secundario
es un demonio auxiliar que se usa para monitorear el estado de los hdfs y obtiene instantáneas de los metadatos de los hdfs a intervalos regulares.
Persistencia de la metainformación
El archivo que almacena metainformación en NameNode es fsimage. Durante el funcionamiento del sistema, todas las operaciones de metainformación se almacenan en la memoria y se conservan en otras ediciones de archivos. Y el archivo de ediciones y el archivo fsimage serán fusionados periódicamente por SecondaryNameNode (el proceso de fusión se describirá en detalle en SecondaryNameNode).
Características de NameNode
La ejecución de NameNode consume mucha memoria y recursos de E / S. Generalmente, NameNode no almacena datos de usuario ni ejecuta tareas de MapReduce.
Para simplificar el diseño del sistema, Hadoop tiene solo un NameNode, lo que conduce al problema del punto único de falla del clúster de Hadoop. Por lo tanto,
la tolerancia a fallas del nodo NameNode es particularmente importante. Hadoop proporciona los siguientes dos mecanismos para resolverlo:
Al escribir metadatos de Hadoop en el sistema de archivos local, se sincroniza con un sistema de archivos de red (NFS) montado de forma remota en tiempo real.
Ejecute un NameNode secundario. Su función es interactuar con el NameNode y fusionar periódicamente la
duplicación del espacio de nombres editando el archivo de registro . Cuando el NameNode falla, se recuperará a través de su copia duplicada del espacio de nombres fusionada. Cabe señalar que el
estado guardado por el nodo de nombre secundario siempre va por detrás del de nodo de nombre, por lo que este método inevitablemente conducirá a la pérdida de algunos datos (más sobre esto más adelante).
SecondaryNameNode
Cabe señalar que SecondaryNameNode no es una copia de seguridad del NameNode. Como sabemos por la introducción anterior, la metainformación de todos los archivos HDFS se almacena en la memoria del NameNode. Cuando se inicia NameNode, primero carga fsimage en la memoria. Durante la operación del sistema, todas las operaciones en el NameNode también se almacenan en la memoria. Al mismo tiempo, para evitar la pérdida de datos, estas operaciones continuarán persistiendo en el archivo de ediciones local. en. El propósito del archivo de ediciones es mejorar la eficiencia operativa del sistema El NameNode escribirá operaciones en el archivo de ediciones antes de actualizar la metainformación en la memoria. En el proceso de reinicio de NameNode, las ediciones y fsimage se fusionarán, pero el proceso de fusión afectará la velocidad de reinicio de Hadoop. SecondaryNameNode nació para resolver este problema.
La función de SecondaryNameNode es combinar periódicamente las ediciones y los archivos fsimage. Echemos un vistazo a los pasos de combinación:
Antes de fusionar, dígale al NameNode que escriba todas las operaciones en el nuevo archivo de ediciones y asígnele el nombre edits.new.
SecondaryNameNode solicita la fsimage y edita los archivos del NameNode.
SecondaryNameNode fusiona la fsimage y edita los archivos en un nuevo archivo fsimage. El
NameNode obtiene la nueva fsimage combinada del SecondaryNameNode y reemplaza la antigua, y reemplaza las ediciones con el archivo edits.new creado en el primer paso. Reemplace los puntos de control en el archivo fstime actualizado y finalmente resuma los archivos relacionados en el NameNode involucrados en todo el proceso.
Fsimage: guarde la metainformación del HDFS de las últimas
ediciones del punto de control : guarde lo que pasó desde el último punto de control Información de cambio de estado de metainformación de HDFS
fstime: se guarda la marca de tiempo del último punto de control
operación de lectura hdfs
1. Primero llame al método open del objeto FileSystem, que en realidad es una instancia de DistributedFileSystem.
2. El DistributedFileSystem obtiene las ubicaciones del primer bloque del archivo a través de rpc. El mismo bloque devolverá múltiples ubicaciones según el número de repeticiones. Estas ubicaciones se ordenan según la topología hadoop, y la más cercana al cliente se clasifica en primer lugar.
3. Los dos primeros pasos devolverán un objeto FSDataInputStream, que será encapsulado por un objeto DFSInputStream. DFSInputStream puede administrar fácilmente flujos de datos de nodo de datos y nodo de nombre. El cliente llama al método de lectura y DFSInputStream encontrará el nodo de datos más cercano al cliente y se conectará.
4. Los datos fluyen continuamente desde el nodo de datos al cliente.
5. Si se lee el primer bloque de datos, la conexión del nodo de datos al primer bloque se cerrará y luego se leerá el siguiente bloque. Estas operaciones son transparentes para el cliente y el punto de vista del cliente es simplemente leer un flujo continuo.
6. Si se ha leído el primer lote de bloques, DFSInputStream irá a namenode para obtener las ubicaciones de un lote de bloques y luego continuará leyendo. Si se leen todos los bloques, todos los flujos se cerrarán en este momento.
Si la comunicación entre DFSInputStream y el nodo de datos es anormal al leer los datos, intentará el nodo de datos con el segundo tipo más cercano del bloque que se está leyendo, registrará qué nodo de datos tiene un error y omitirá el nodo de datos directamente al leer los bloques restantes. . DFSInputStream también verificará la suma de comprobación de los datos del bloque. Si se encuentra un bloque defectuoso, se informará primero al nodo namenode y luego DFSInputStream leerá la imagen del bloque en otros nodos de datos.
El diseño es que el cliente se conecta directamente al nodo de datos para recuperar datos y el nodo de nombre es responsable de proporcionar el nodo de datos óptimo para cada bloque. El nodo de nombre solo procesa la solicitud de ubicación del bloque y la información se carga en la memoria del nodo de nombre. HDFS puede soportar una gran cantidad de datos a través del clúster de nodo de datos Acceso concurrente por parte del cliente.
operación de escritura hdfs
1. El cliente crea un nuevo archivo llamando al método create de DistributedFileSystem.
2. DistributedFileSystem llama a namenode a través de RPC para crear un nuevo archivo que no está asociado con bloques. Antes de la creación, namenode realizará varias comprobaciones, como si el archivo existe, si el cliente tiene permiso para crearlo, etc. Si pasa la verificación, namenode registrará el nuevo archivo; de lo contrario, lanzará una excepción de E / S.
3. Después de los dos primeros pasos, se devolverá el objeto de FSDataOutputStream. Similar a cuando se leen archivos, FSDataOutputStream se encapsula en DFSOutputStream. DFSOutputStream puede coordinar namenode y datanode. El cliente comienza a escribir datos en DFSOutputStream, DFSOutputStream cortará los datos en pequeños paquetes y luego los organizará en una cola de datos.
4. El DataStreamer procesará y aceptará la cola de datos. Primero pregunta qué nodos de datos es más adecuado para el almacenamiento del nuevo bloque de nodo de nombre (por ejemplo, si el número de repeticiones es 3, entonces encontrará los 3 nodos de datos más adecuados) y los organizará en Un oleoducto. DataStreamer envía paquetes en una cola al primer nodo de datos de la canalización, y el primer nodo de datos envía paquetes al segundo nodo de datos, y así sucesivamente.
5. DFSOutputStream también tiene una columna de contador llamada ack quene, que también se compone de paquetes, esperando que el nodo de datos reciba una respuesta. Cuando todos los nodos de datos en la canalización indican que se han recibido, akc quene moverá el paquete de paquetes correspondiente Deshacerse de.
Si ocurre un error en un nodo de datos durante el proceso de escritura, se seguirán los siguientes pasos:
- La canalización está cerrada;
2) Para evitar la pérdida de paquetes, los paquetes de la cola de ack se sincronizarán con la cola de datos;
3) Eliminar el bloque escrito actualmente pero sin terminar en el nodo de datos que causó el error;
4) La parte restante del bloque Se escribe en los dos nodos de datos normales restantes;
5) Namenode busca otro nodo de datos para crear una copia de este bloque. Por supuesto, estas operaciones son imperceptibles para el cliente.
6. Una vez que el cliente termine de escribir datos, llame al método close para cerrar la secuencia de escritura.
7. DataStreamer descarga los paquetes restantes a la canalización y luego espera el mensaje de confirmación. Después de recibir la última confirmación, notifica al nodo de datos que marque el archivo como completado.
Nota: Después de que el cliente ejecuta la operación de escritura, el bloque escrito es visible. El bloque que se está escribiendo no es visible para el cliente. Solo llamando al método de sincronización, el cliente puede asegurarse de que la operación de escritura del archivo se haya completado. Cuando el cliente llama al método de cierre, se llama al método de sincronización de forma predeterminada. La necesidad de realizar una llamada manualmente depende del equilibrio entre la solidez de los datos y la tasa de rendimiento de acuerdo con las necesidades del programa.
eliminación de archivos hdfs
El proceso de eliminación de archivos hdfs generalmente requiere los siguientes pasos:
- Al comienzo de la eliminación del archivo, NameNode simplemente cambia el nombre del archivo eliminado al directorio / trash. Debido a que la operación de cambio de nombre es solo un cambio de metainformación, todo el proceso es muy rápido. Los archivos en / trash se mantendrán durante un cierto intervalo de tiempo (configurable, el valor predeterminado es 6 horas). Durante este período, los archivos se pueden restaurar fácilmente. La restauración solo necesita eliminar los archivos de / trash.
- Cuando llegue la hora especificada, NameNode eliminará el archivo del espacio de nombres
- Marque bloques de archivos eliminados para liberar espacio y aumenta el espacio de visualización del sistema de archivos HDFS
recuperación de archivos hdfs
Al igual que el diseño de la papelera de reciclaje del sistema Linux, HDFS creará un directorio de papelera de reciclaje para cada usuario: /user/username/.Trash/, y cada archivo / directorio eliminado por el usuario a través de Shell tendrá uno en la papelera de reciclaje del sistema. Ciclo, es decir, cuando el archivo / directorio en la papelera de reciclaje del sistema no es respondido por el usuario después de un período de tiempo, HDFS eliminará automáticamente el archivo / directorio por completo, después de lo cual el usuario nunca encontrará el archivo / directorio. . La implementación específica dentro de HDFS es iniciar un subproceso en segundo plano más vacío en el NameNode. Este subproceso administra y monitorea específicamente todos los archivos / directorios bajo la papelera de reciclaje del sistema. Para archivos / directorios que han excedido su ciclo de vida, este subproceso los eliminará automáticamente. Ellos, pero la granularidad de esta gestión es muy grande. Además, los usuarios también pueden vaciar manualmente la papelera de reciclaje. La operación de vaciar la papelera de reciclaje es lo mismo que eliminar un directorio de archivos común, pero HDFS detectará automáticamente si el directorio de archivos es una papelera de reciclaje. Si lo es, HDFS, por supuesto, no lo volverá a colocar. En la papelera del usuario
De acuerdo con la introducción anterior, el usuario elimina un archivo a través de la línea de comando, es decir, el comando de shell de HDFS, pero el archivo no se elimina de HDFS inmediatamente. En su lugar, HDFS cambia el nombre del archivo y lo transfiere al directorio de la papelera de reciclaje del usuario operativo (como /user/hdfs/.Trash/Current, donde hdfs es el nombre de usuario operativo). Si el archivo / directorio actualmente eliminado por el usuario ya existe en la papelera de reciclaje del usuario, HDFS cambiará el nombre del archivo / directorio actualmente eliminado. La regla de nomenclatura es muy simple, seguida del nombre del archivo / directorio eliminado. Número (desde 1 hasta que sepa que no hay nombre duplicado).
Cuando el archivo aún está en el directorio /user/hdfs/.Trash/Current, el archivo se puede restaurar rápidamente. La hora a la que se guarda el archivo en /user/hdfs/.Trash/Current es configurable. Cuando se excede este tiempo, Namenode eliminará el archivo del espacio de nombres. Eliminar un archivo también liberará el bloque de datos asociado con el archivo. Tenga en cuenta que existe una demora de tiempo de espera entre el archivo que el usuario elimina y el aumento de la inactividad de HDFS.
Cuando el archivo eliminado permanece en el directorio /user/hdfs/.Trash/Current, si el usuario desea restaurar el archivo, puede buscar y explorar el directorio /user/hdfs/.Trash/Current y recuperar el archivo. El directorio /user/hdfs/.Trash/Current solo guarda la copia más reciente del archivo eliminado. El directorio /user/dfs/.Trash/Current no es diferente de otros directorios de archivos, excepto por una cosa: HDFS aplica una política especial en este directorio para eliminar archivos automáticamente. La política predeterminada actual es eliminar los archivos que se han retenido durante más de 6 horas. Esta estrategia se definirá como una interfaz configurable en el futuro.
Además, NameNode usa un hilo de fondo (el predeterminado es org.apache.Hadoop.fs.TrashPolicyDefault.Emptier, o puede especificar la clase TrashPolicy a través de fs.trash.classname) para vaciar periódicamente todos los archivos / directorios en la papelera de reciclaje del usuario. La papelera de reciclaje del usuario se vacía cada intervalo de minutos. Los pasos específicos de la operación son primero verificar todos los directorios en forma de yyMMddHHmm bajo el directorio de la papelera de reciclaje del usuario /user/username/.Trash, luego eliminar los directorios cuya vida útil excede el intervalo, y finalmente guardar el directorio de la papelera de reciclaje donde los archivos / directorios eliminados están almacenados actualmente / user / username / .Trash / current se renombra a /user/username/.Trash/yyMMddHHmm.
A partir de la implementación de este hilo de reciclaje (Vacío), se puede ver que los archivos eliminados por el usuario con comandos pueden estar en su papelera de reciclaje como máximo Se pueden guardar 2 * minutos de intervalo en el medio, se pueden guardar al menos minutos de intervalo, después de este período de validez, los archivos eliminados por el usuario nunca se restaurarán
Configuración
Papelera de reciclaje de Hadoop, que está cerrada de forma predeterminada
1. Modifique conf / core-site.xml y agregue
<property>
<name>fs.trash.interval</name>
<value>1440</value>
<description>Number of minutes between trash checkpoints.
If zero, the trash feature is disabled.
</description>
</property>
El valor predeterminado es 0. Minutos unidad. Lo que configuro aquí es 1 día (60 * 24)
después de eliminar los datos rm, los datos se moverán al directorio .Trash debajo de la carpeta actual