Cuando copias o mueves datos entre distintos sistemas de almacenamiento, como varios clústeres del sistema de archivos distribuido Hadoop (HDFS) de Apache o entre HDFS y Cloud Storage, es una buena idea realizar algún tipo de validación para garantizar la integridad de los datos. Esta validación es fundamental para asegurarse de que los datos no se alteraron durante la transferencia.
Si bien varios mecanismos ya garantizan la integridad punto a punto de los datos en tránsito (como TLS para toda la comunicación con Cloud Storage), la validación explícita de la integridad de los datos de extremo a extremo aumenta la protección en los casos que pueden pasar desapercibidos por los mecanismos típicos en tránsito. Esto puede ayudarte a detectar una posible corrupción de datos causada, por ejemplo, por vínculos de red contaminados, errores de memoria en computadoras del servidor y routers a lo largo de la ruta o errores de software (como en una biblioteca que usan los clientes).
En Cloud Storage, esta validación ocurre de manera automática en el lado del cliente con comandos como gsutil, cp y rsync. Esos comandos calculan sumas de verificación de archivos locales, que luego se validan en función de las sumas de verificación que calcula Cloud Storage al final de cada operación. Si las sumas de verificación no coinciden, gsutil borra las copias no válidas y, luego, muestra un mensaje de advertencia.
Esta desigualdad no suele suceder y, si ocurre, puedes intentar llevar a cabo la operación una vez más.
Actualmente existe también una manera de realizar automáticamente una validación integral del lado del cliente en Apache Hadoop a través de sistemas de archivos heterogéneos compatibles con Hadoop, como HDFS y Cloud Storage. En este artículo, se describe cómo la nueva característica te permite comparar de manera eficiente y precisa las sumas de verificación de archivos.
Cómo HDFS realiza sumas de verificación de archivos
HDFS usa CRC32C, una verificación de redundancia cíclica (CRC) de 32 bits basada en el polinomio de Castagnoli, para mantener la integridad de los datos en diferentes contextos:
- En reposo, los DataNodes de Hadoop verifican continuamente los datos en función de las CRC almacenadas para detectar y reparar la corrupción silenciosa.
- En tránsito, los DataNodes envían CRC conocidas junto con los datos masivos correspondientes y las bibliotecas cliente de HDFS calculan cooperativamente las CRC por fragmento para compararlas con las CRC recibidas de los DataNodes.
- Con fines administrativos de HDFS, las sumas de verificación a nivel de bloque se usan para las verificaciones de integridad manuales de bajo nivel de archivos de bloque individuales en DataNodes.
- Para los casos prácticos de la capa de la aplicación arbitraria, la interfaz
FileSystemdefinegetFileChecksumy la implementación de HDFS usa sus CRC detalladas almacenadas a fin de definir la suma de verificación a nivel de archivo.
Para la mayoría de los usos diarios, las CRC se usan de manera transparente con respecto a la capa de aplicación. Las únicas CRC usadas son las CRC32Cs por fragmento, que ya están calculadas con anterioridad y almacenadas en archivos de metadatos junto con los datos de bloque. El tamaño del fragmento está definido por dfs.bytes-per-checksum y tiene un valor predeterminado de 512 bytes.
Deficiencias del tipo de suma de verificación del archivo predeterminado de Hadoop
La configuración predeterminada cuando se usa Hadoop es que todas las sumas de verificación expuestas a la API toman la forma de un MD5 de una concatenación de CRC32Cs de fragmento, ya sea a nivel de bloque a través de DataTransferProtocol de bajo nivel o al nivel de archivo mediante la interfaz FileSystem de nivel superior. Una suma de verificación a nivel de archivo se define como el MD5 de la concatenación de todas las sumas de verificación de bloques, cada una de las cuales es un MD5 de una concatenación de CRC de fragmentos y, por lo tanto, se denomina MD5MD5CRC32FileChecksum. En la práctica, esto es un árbol de Merkle de tres capas a pedido.
Esta definición de la suma de verificación a nivel de archivo es sensible a los detalles de implementación y de capa de datos de HDFS, es decir, el tamaño de fragmento (valor predeterminado de 512 bytes) y el tamaño de bloque (valor predeterminado de 128 MB). Por lo tanto, esta suma de verificación del archivo predeterminado no es adecuada en ninguna de las siguientes situaciones:
- Dos copias diferentes de los mismos archivos en HDFS, pero con diferentes tamaños de bloque por archivo configurados.
- Dos instancias diferentes de HDFS con diferentes tamaños de fragmentos o bloques configurados.
- Una combinación de sistemas de archivos compatibles con Hadoop (HCFS), que sean de HDFS y que no sean de HDFS, como Cloud Storage.
En el siguiente diagrama, se muestra cómo el mismo archivo puede terminar con diferentes sumas de verificación según la configuración del sistema de archivos:
Puedes mostrar la suma de verificación predeterminada para un archivo en HDFS con el comando de Hadoop fs -checksum:
hadoop fs -checksum hdfs:///user/bob/data.bin
En un clúster de HDFS que tenga un tamaño de bloque de 64 MB (dfs.block.size=67108864), este comando muestra un resultado similar al siguiente:
hdfs:///user/bob/data.bin MD5-of-131072MD5-of-512CRC32C 000002000000000000020000e9378baa1b8599e50cca212ccec2f8b7
Para el mismo archivo en otro clúster que tenga un tamaño de bloque de 128 MB (dfs.block.size=134217728), verás un resultado diferente:
hdfs:///user/bob/data.bin MD5-of-0MD5-of-512CRC32C 000002000000000000000000d3a7bae0b5200ed6707803a3911959f9
Puedes ver en estos ejemplos que dos sumas de verificación difieren para el mismo archivo.
Cómo funciona la nueva suma de verificación del archivo de CRC compuesto de Hadoop
Se lanzó en Apache Hadoop 3.1.1 un tipo de suma de verificación nuevo, rastreado en HDFS-13056, para abordar estas deficiencias. El tipo nuevo, que configura dfs.checksum.combine.mode=COMPOSITE_CRC, define nuevas CRC de bloque compuestas y CRC de archivo compuestas como las CRC redactadas de forma matemática a través de las CRC de fragmento almacenadas. El uso de este tipo reemplaza el uso de un MD5 de las CRC de componente para calcular una sola CRC que represente el archivo o bloque entero y es independiente del nivel de detalle de bajo nivel de CRC de fragmento.
La composición de CRC tiene varios beneficios: es eficiente, permite que las sumas de verificación resultantes sean completamente agnósticas de fragmento/bloque y permite la comparación entre archivos segmentados y replicados, entre diferentes instancias de HDFS y entre HDFS y otros sistemas de almacenamiento externos. (Puedes obtener más detalles sobre el algoritmo de CRC si descargas este PDF).
El siguiente diagrama muestra cómo una suma de verificación de archivo es coherente después de la transferencia a través de las opciones de configuración heterogéneas de sistema de archivos:
Esta función es apenas invasiva: se puede agregar para que sea compatible con los metadatos de bloque existentes y no es necesario cambiar la ruta usual de verificación de fragmentos. Esto también significa que, incluso las implementaciones de HDFS grandes preexistentes, pueden adoptar esta característica para sincronizar datos de forma retroactiva. Para obtener más detalles, puedes descargar el documento de PDF de diseño completo.
Cómo usar el nuevo tipo de suma de verificación de CRC compuesto
Para usar el nuevo tipo de suma de verificación de CRC compuesto en Hadoop, establece la propiedad dfs.checksum.combine.mode como COMPOSITE_CRC (en lugar del valor predeterminado MD5MD5CRC). Cuando se copia un archivo de una ubicación a otra, el tipo de suma de verificación de nivel de fragmento (es decir, la propiedad dfs.checksum.type que es CRC32C por defecto) también debe coincidir en ambas ubicaciones.
Puedes mostrar el nuevo tipo de suma de verificación para un archivo en HDFS si pasas el argumento -Ddfs.checksum.combine.mode=COMPOSITE_CRC al comando de Hadoop fs -checksum:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Sin importar la configuración del tamaño de bloque del clúster de HDFS, verás el mismo resultado, como el siguiente:
hdfs:///user/bob/data.bin COMPOSITE-CRC32C c517d290
En Cloud Storage, debes configurar de manera explícita la propiedad fs.gs.checksum.type del conector de Cloud Storage como CRC32C. De lo contrario, el valor predeterminado de esta propiedad es NONE, lo que causa que las sumas de verificación de archivos se inhabiliten de manera predeterminada. Este comportamiento predeterminado del conector de Cloud Storage es una medida preventiva para evitar un problema con distcp, en el que se plantea una excepción si los tipos de suma de verificación no coinciden en vez de fallar de forma ordenada. El comando se ve de la siguiente manera:
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin
El comando muestra el mismo resultado que en el ejemplo anterior en HDFS:
gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C c517d290
Puedes ver que las sumas de verificación de CRC compuestas que se muestran en los comandos anteriores coinciden, independientemente del tamaño de bloque, así como entre HDFS y Cloud Storage. Si usas las sumas de verificación de CRC compuestas, puedes garantizar que se conserve la integridad de los datos cuando se transfieren archivos entre todos los tipos de opciones de configuración de clúster de Hadoop.
Si estás ejecutando distcp, como en el siguiente ejemplo, la validación se realiza de manera automática:
hadoop distcp -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C hdfs:///user/bob/* gs://[BUCKET]/user/bob/
Si distcp detecta una desigualdad de la suma de verificación de archivo entre la fuente y el destino durante la copia, la operación tendrá errores y mostrará una advertencia.
Accede a la función
La nueva característica de suma de verificación de CRC compuesta está disponible en Apache Hadoop 3.1.1 (consulta las notas de la versión) y los backports para las versiones 2.7, 2.8 y 2.9 están en proceso. Se incluyó de forma predeterminada en versiones submenores de Cloud Dataproc 1.3 desde finales del 2018.