sql >> Base de Datos >  >> RDS >> Database

Comprender el sistema de entrada y salida de Hadoop

A diferencia de cualquier subsistema de E/S, Hadoop también viene con un conjunto de primitivas. Estas consideraciones primitivas, aunque de naturaleza genérica, también van con el sistema Hadoop IO con alguna connotación especial, por supuesto. Hadoop se ocupa de varios terabytes de conjuntos de datos; una consideración especial sobre estas primitivas dará una idea de cómo Hadoop maneja la entrada y salida de datos. Este artículo repasa rápidamente estas primitivas para dar una perspectiva del sistema de entrada y salida de Hadoop.

Integridad de datos

Integridad de los datos significa que los datos deben permanecer precisos y consistentes en todas sus operaciones de almacenamiento, procesamiento y recuperación. Para garantizar que no se pierdan ni dañen datos durante la persistencia y el procesamiento, Hadoop mantiene estrictas restricciones de integridad de datos. Cada operación de lectura/escritura ocurre en discos, más aún a través de la red es propensa a errores. Y el volumen de datos que maneja Hadoop solo agrava la situación. La forma habitual de detectar datos corruptos es mediante sumas de comprobación. Una suma de comprobación se calcula cuando los datos ingresan por primera vez al sistema y se envían a través del canal durante el proceso de recuperación. El extremo de recuperación vuelve a calcular la suma de comprobación y la compara con las recibidas. Si coincide exactamente, entonces los datos se consideran libres de errores; de lo contrario, contienen errores. Pero el problema es:¿qué sucede si la suma de verificación enviada está corrupta? Esto es muy poco probable porque es un dato pequeño, pero no una posibilidad innegable. El uso del tipo correcto de hardware, como la memoria ECC, se puede usar para aliviar la situación.

Esto es mera detección. Por lo tanto, para corregir el error, se utiliza otra técnica, llamada CRC (Cyclic Redundancy Check).

Hadoop va más allá y crea una suma de verificación distinta para cada 512 bytes (predeterminados) de datos. Debido a que CRC-32 es solo de 4 bytes, la sobrecarga de almacenamiento no es un problema. Todos los datos que ingresan al sistema son verificados por los nodos de datos antes de ser enviados para su almacenamiento o procesamiento posterior. Los datos enviados a la canalización del nodo de datos se verifican a través de sumas de verificación y cualquier daño encontrado se notifica inmediatamente al cliente con ChecksumException . El cliente leído del nodo de datos también pasa por el mismo ejercicio. Los nodos de datos mantienen un registro de verificación de suma de verificación para realizar un seguimiento del bloque verificado. El registro es actualizado por el nodo de datos al recibir una señal de éxito de verificación de bloque del cliente. Este tipo de estadísticas ayuda a mantener a raya los discos dañados.

Aparte de esto, se realiza una verificación periódica en el almacén de bloques con la ayuda de DataBlockScanner ejecutándose junto con el subproceso del nodo de datos en segundo plano. Esto protege los datos de la corrupción en los medios de almacenamiento físico.

Hadoop mantiene una copia o réplicas de los datos. Esto se usa específicamente para recuperar datos de corrupción masiva. Una vez que el cliente detecta un error al leer un bloque, inmediatamente informa al nodo de datos sobre el bloque defectuoso del nodo de nombre antes de lanzar ChecksumException . El namenode luego lo marca como un bloque defectuoso y programa cualquier referencia adicional al bloque a sus réplicas. De esta forma, la réplica se mantiene con otras réplicas y el bloque marcado como defectuoso se elimina del sistema.

Para cada archivo creado en Hadoop LocalFileSystem , un archivo oculto con el mismo nombre en el mismo directorio con la extensión ..crc es creado. Este archivo mantiene la suma de comprobación de cada porción de datos (512 bytes) en el archivo. El mantenimiento de metadatos ayuda a detectar errores de lectura antes de lanzar ChecksumException por el LocalFileSystem .

Compresión

Teniendo en cuenta el volumen de datos que maneja Hadoop, la compresión no es un lujo sino un requisito. Hay muchos beneficios obvios de la compresión de archivos utilizados correctamente por Hadoop. Reduce los requisitos de almacenamiento y es una capacidad imprescindible para acelerar la transmisión de datos a través de la red y los discos. Hay muchas herramientas, técnicas y algoritmos comúnmente utilizados por Hadoop. Muchos de ellos son bastante populares y se han utilizado en la compresión de archivos a lo largo de los años. Por ejemplo, a menudo se utilizan gzip, bzip2, LZO, zip, etc.

Serialización

El proceso que convierte los objetos estructurados en un flujo de bytes se llama serialización . Esto se requiere específicamente para la transmisión de datos a través de la red o la persistencia de datos sin procesar en discos. Deserialización es solo el proceso inverso, donde un flujo de bytes se transforma en un objeto estructurado. Esto es particularmente necesario para la implementación de objetos de los bytes sin procesar. Por lo tanto, no sorprende que la computación distribuida utilice esto en un par de áreas distintas:comunicación entre procesos y persistencia de datos.

Hadoop utiliza RPC (llamada a procedimiento remoto) para promulgar la comunicación entre procesos entre nodos. Por lo tanto, el protocolo RPC usa el proceso de serialización y deserialización para entregar un mensaje al flujo de bytes y viceversa y lo envía a través de la red. Sin embargo, el proceso debe ser lo suficientemente compacto para utilizar mejor el ancho de banda de la red, además de ser rápido, interoperable y flexible para adaptarse a las actualizaciones del protocolo a lo largo del tiempo.

Hadoop tiene su propio formato de serialización compacto y rápido, Writables , que utilizan los programas de MapReduce para generar claves y tipos de valores.

Estructura de datos de archivos

Hay un par de contenedores de alto nivel que elaboran la estructura de datos especializada en Hadoop para contener tipos especiales de datos. Por ejemplo, para mantener un registro binario, el SequenceFile container proporciona la estructura de datos para persistir pares binarios clave-valor. Entonces podemos usar la clave, como una marca de tiempo representada por LongWritable y valor por Escribible , que se refiere a la cantidad registrada.

Hay otro contenedor, una derivación ordenada de SequenceFile , llamado MapFile . Proporciona un índice para búsquedas convenientes por clave.

Estos dos contenedores son interoperables y se pueden convertir entre sí.

Conclusión

Esta es solo una descripción general rápida del sistema de entrada/salida de Hadoop. Profundizaremos en muchos detalles intrincados en artículos posteriores. No es muy difícil comprender el sistema de entrada/salida de Hadoop si se tiene un conocimiento básico de los sistemas de E/S en general. Hadoop simplemente le puso un poco de jugo adicional para mantenerse al día con su naturaleza distribuida que funciona en una escala masiva de datos. Eso es todo.

Referencia

Blanco, Tom. Hadoop, la guía definitiva, 2009 . Publicaciones de O'Reilly.