Registros de aprendizaje HDFS (comparación de unidades de datos, proceso de lectura y escritura)

1. La arquitectura general de HDFS

• Explicación de vocabulario vago:

1. Client： Cualquier extremo que acceda a HDFS a través de API o comandos HDFS puede considerarse un cliente.
2. Rack： Rack, la estrategia de colocación de la copia está relacionada con el rack.
3. Block Size：Predeterminado Hadoop2.7.3 empezar 128 M , el siguiente defecto Hadoop2.7.3 64 H .

2. La relación entre bloque, paquete y fragmento

• Bloque, paquete y fragmento son todas unidades de almacenamiento de datos involucradas en HDFS.
• Archivo XML en nuestra propia Hadoop puede configurar: core-site.xml, hdfs-site.xmly así, cuando no sé cómo hacer cambios, se puede ver core-default.xml, hdfs-site.xmly otros documentos.

① bloque

• Bloque es la unidad de partición de archivos en HDFS. Un archivo que no tiene 64 M. ocupará un bloque. El tamaño es el tamaño real del archivo y el tamaño de bloque es el tamaño del bloque.
• Puede modificar el tamaño de bloque predeterminado a hdfs-site.xmltravés de dfs.block.sizeelementos de configuración en el archivo .
• La relación entre el tiempo de direccionamiento de bloque y disco y el tiempo de transmisión:

1. Cuanto mayor sea el bloque, menor será el tiempo de direccionamiento del disco y mayor será el tiempo de transmisión de datos.
2. Cuanto más pequeño sea el bloque, mayor será el tiempo de direccionamiento del disco y menor el tiempo de transmisión de datos.

• La configuración del bloque es demasiado pequeña:

1. Sobrecarga de memoria de NameNode: si la configuración del bloque es demasiado pequeña, NameNodese almacena una gran cantidad de información de metadatos de archivos pequeños en la NameNodememoria , lo que provocará una sobrecarga de la memoria.
2. El tiempo de direccionamiento es demasiado largo: si el bloque se configura demasiado pequeño, el tiempo de direccionamiento del disco aumentará, haciendo que el programa busque siempre el comienzo del bloque.

• El bloque es demasiado grande:

1. El tiempo de la tarea del mapa es demasiado largo: MapReduce Medio Map generalmente solo procesa las tareas en un bloque de datos a la vez. Si el bloque es demasiado grande, el tiempo de procesamiento de las tareas del mapa será demasiado largo.
2. El tiempo de transmisión de datos es demasiado largo: si el bloque se establece demasiado grande, el tiempo de transmisión de datos excederá con creces el tiempo de direccionamiento de datos, lo que afectará la velocidad de procesamiento de datos.

② paquete

• El paquete es la segunda unidad más grande. Es la unidad básica de transmisión de datos entre DFSClient y DataNode o la tubería de DataNode . El tamaño predeterminado es 64 kb .
• Puede modificar el tamaño de paquete predeterminado a hdfs-site.xmltravés de dfs.write.packet.sizeelementos de configuración en el archivo .

③ trozo

• chunk es la unidad más pequeña, es DFSClientpara DataNode, o DataNodese Pipelinelleva a cabo entre la unidad básica de verificación de datos , el valor predeterminado es 512 bytes .
• Puede modificar el tamaño de fragmento predeterminado a core-site.xmltravés de io.bytes.per.checksumelementos de configuración en el archivo .
• Como unidad básica de verificación de datos, cada fragmento debe contener 4 bytes de información de verificación . Por lo tanto, cuando se escribe realmente en el paquete, es de 516 bytes y la relación entre los datos reales y los datos de verificación es 128 : 1.
• Ejemplo: un archivo de 128M se puede dividir en 256 fragmentos y 256 * 4 byte = 1 Mla información de verificación debe llevarse en total .
• Resumen de los tres:

1. trozo es DFSClientde DataNodeo DataNodese Pipelinelleva a cabo entre los datos de verificación unidades básicas, cada trozo de 4 bytes necesidad de llevar la información de paridad.
2. paquete es DFSClienta DataNodeo DataNodese Pipelinelleva a cabo entre la transmisión de datos la unidad de base, cuando el tamaño real de la porción se escribe en el paquete como 516 byte.
3. El bloque es la unidad del bloque de archivos, innumerables paquetes forman un bloque. Los archivos pequeños tienen menos del tamaño de un bloque, pero ocuparán una ranura de metadatos, lo que provocará NameNodeuna sobrecarga de memoria.

④ Búfer de tres capas en el proceso de escritura

• El proceso de escritura implica DataQueuecachés de tres niveles de fragmentos, paquetes y tres granularidades:

1. Cuando los datos fluyen DFSOutputStream, habrá un búfer del tamaño de un fragmento. Cuando los datos llenan este búfer, o cuando flush()se encuentra una operación forzada , se calcula una suma de control.
2. El fragmento y la suma de comprobación se escriben juntos en el paquete.Cuando varios fragmentos llenan el paquete, el paquete entrará en la DataQueuecola.
3. DataQueueEl subproceso saca el paquete y lo envía a DataNode, y el paquete que no se confirma que se haya escrito correctamente se moverá a AckQueue para su confirmación.
4. Si recibe DataNodeel ack (escritura exitosa), por el ResponseProcessorpaquete responsable de la AckQueueeliminación; de lo contrario, se moverá a DataQueuela reescritura.
   
   Búfer de tres capas

3. Conocimientos básicos

NameNode

• Administre la información de metadatos (metadatos) Tenga en cuenta que solo se almacena la información de metadatos.
• El nodo de nombre administra la información de metadatos y coloca una copia en la memoria para acceso y consulta, y también conserva la información de metadatos en el disco a través de los archivos fsimage y edita.
• La versión 1.0 de Hadoop usa SecondaryNamenode para fusionar fsimage y edita archivos, pero este mecanismo no puede lograr el efecto de copia de seguridad en caliente. El namenode de Hadoop 1.0 tiene un solo punto de falla.
• Los metadatos se dividen aproximadamente en dos niveles: la capa de administración del espacio de nombres , responsable de administrar la estructura de directorios en forma de árbol en el sistema de archivos y la relación de mapeo entre archivos y bloques de datos. La capa de administración de bloques es responsable de administrar la relación de mapeo BlocksMap entre los bloques físicos de los archivos en el sistema de archivos y la ubicación de almacenamiento real.
  

nodo de datos

• Nodo de datos, utilizado para almacenar bloques de archivos.
• Para evitar la pérdida de datos causada por el nodo de datos colgando, se debe hacer una copia de seguridad de un bloque de archivos y un bloque de archivos tiene por defecto tres copias.

estante

• Rack, HDFS utiliza una estrategia de reconocimiento de racks para colocar réplicas.
• La primera copia: si el escritor es un dataNode, colóquelo directamente localmente; de ​​lo contrario, seleccione aleatoriamente un dataNode para el almacenamiento.
• La segunda copia: un dataNode en el rack remoto
• Tercera copia: otro dataNode en el mismo bastidor remoto que la segunda copia.
• Esta estrategia de ubicación reduce el tráfico de escritura entre bastidores y mejora el rendimiento de escritura.
• Más de 3 copias: Los requisitos de colocación de las copias restantes cumplen las siguientes condiciones:
• Un dataNode solo puede tener una copia del bloque
• El número máximo de copias de un clúster de Hadoop es el número total de dataNodes

Enlace de referencia: Política de ubicación de réplicas de HDFS

cliente

• Cliente, cualquier extremo que se opere a través de API o comandos se puede considerar como cliente

tamaño de bloque

• Los bloques de datos generalmente tienen un tamaño predeterminado, que se puede configurar en el archivo hdfs-site.xml dfs.blocksize.
• Hadoop1.0 ： 64 MB。 Hadoop2.0 ： 128 MB。
• El problema del tamaño del bloque: desde la perspectiva del procesamiento de big data, cuanto más grande sea el bloque, mejor. Por lo tanto, a partir del desarrollo de la tecnología, los bloques futuros serán cada vez más grandes, porque el tamaño del bloque reducirá el número de direcciones de disco, reduciendo así el tiempo de direccionamiento.

4. Proceso de lectura y escritura de HDFS

① Proceso de lectura de HDFS

1. El cliente llama al método DistributedFileSystem.open () para obtener el objeto de flujo de entrada (FSDataInputStream) del bloque de datos a leer.
2. Cuando se está ejecutando el método open (), DistributedFileSystem usa RPC para llamar a NameNode para obtener las direcciones de dataNode de todas las copias del bloque. Una vez que se ejecuta el método open (), devuelve el objeto FSDataInputStream, que encapsula el flujo de entrada DFSInputStream.
3. Llame al método FSDataInputStream.read () del flujo de entrada, de modo que DFSInputStream se conecte automáticamente a un dataNode adecuado para la lectura de datos (la distancia de la topología de la red) de acuerdo con el principio de proximidad.
4. El método read () se llama en un bucle para transferir datos desde el dataNode al cliente.
5. Después de leer el bloque actual, cierre la conexión con el dataNode actual. Establezca una conexión con el dataNode del siguiente bloque para continuar leyendo el siguiente bloque.

Este proceso es transparente para el cliente, desde la perspectiva del cliente, parece que solo se lee un flujo continuo.

6. Una vez que el cliente termina de leer todos los bloques, llama a FSDataInputStream.close () para cerrar el flujo de entrada, finalizando así el proceso de lectura del archivo.
   

• Error de lectura:
• Si ocurre un error durante el proceso de lectura, DFSInputStream intentará leer el bloque en el DataNode adyacente. Al mismo tiempo, el dataNode que tiene el problema quedará registrado y no se comunicará con él en el proceso de solicitud de datos posterior.
• Cada vez que se lee un bloque, DFSInputStream verificará la integridad de los datos. Si hay daños, el cliente notificará al NameNode y continuará leyendo la copia de otros DataNodes.

② Proceso de escritura HDFS

1. El cliente del sistema de archivos distribuido llama al DistributedFileSystem.create( )método envía una solicitud para crear un NameNode de archivo.
2. Cuando se ejecuta el método create (), DistributedFileSystemenvía una solicitud RPC al NameNode y NameNode completa la verificación antes de la creación del archivo. Si pasa la verificación, primero registre la operación de escritura en EditLog y luego devuelva el objeto de flujo de salida FSDataOutputStream(encapsulado internamente DFSOutputDtream).
3. El cliente llama a la FSOutputStream.write()función, escribiendo datos en el archivo correspondiente.
4. Al escribir un archivo, el DFSOutputDtreamarchivo se divide en paquetes y los paquetes se escriben en DataQueue. DataStreamerResponsable de administrar DataQueue, le pedirá al NameNode que asigne nuevos bloques adecuados para almacenar copias. Se forma una canalización entre DataNodes y los paquetes se transmiten a través de la canalización.

• DataStreamer Transmita el paquete a DataNode1 a través de la canalización
• DataNode1 transmite el paquete recibido a DataNode2
• DataNode2 transmite el paquete recibido a DataNode3 para formar un almacenamiento de copia triple del paquete.

5. Para garantizar la coherencia de la copia, el DataNode que ha recibido el paquete debe devolver un paquete ack al remitente. Después de recibir suficientes respuestas, el paquete se eliminará de la cola interna.
6. Una vez escrito el archivo, el cliente llama al FSOutputStream.close()método para cerrar el flujo de entrada del archivo.
7. Llame al DistributedFileSystem.complete()método para notificar al NameNode que el archivo se ha escrito correctamente.