Entrevista de Data Engineering: ¿Cómo usarías los checksums de página de Parquet para contener la corrupción?

Prompt y contexto

Un trabajo de lakehouse lee Parquet desde el almacenamiento de objetos. Una pequeña cantidad de archivos se corrompen tras la replicación entre regiones, pero el pipeline actual solo reintenta el archivo completo. Diseña un plan de CRC a nivel de página: define los bytes comprobados, explica los límites de compresión, preserva la compatibilidad con lectores, aísla las páginas dañadas y elige métricas de aceptación. Esta es una pregunta de data sobre la integridad de archivos columnares.

Lo que evalúa el entrevistador

1. Distinguir el CRC de página de las comprobaciones a nivel de archivo y saber que el campo es opcional.
2. Establecer con precisión el alcance del checksum y el límite de compresión.
3. Diseñar un despliegue cuando los lectores más antiguos ignoran los campos de CRC.
4. Prevenir lecturas parciales silenciosas y separar el aislamiento, la recuperación por replicación y la reescritura.
5. Medir la corrección, el tiempo de localización y la sobrecarga de CPU/E/S.

Preguntas de clarificación para hacer

• ¿Las versiones de destino del writer y reader escriben y verifican los CRCs de página?
• ¿La corrupción es introducida por el almacenamiento de objetos, la replicación o una caché local?
• ¿Están habilitadas la compresión, el cifrado o los índices de página, y puede el reader localizar un column chunk?
• ¿Debe recuperarse cada fila, o se puede reconstruir la partición a partir de los datos ascendentes (upstream)?
• ¿Podrían los reintentos seguir almacenando en caché la misma versión defectuosa del objeto?

Una respuesta de 30 segundos

“Primero verificaría el soporte de CRC de página frente al formato Parquet y las versiones exactas del reader, registrando la versión del archivo, el row group, el column chunk, el tipo de página y la versión del objeto. Un fallo de verificación debería poner el objeto en cuarentena en lugar de omitir filas; la recuperación puede intentar con una réplica coincidente o reescribir desde upstream. Los lectores antiguos pueden ignorar los CRCs, por lo que siguen siendo legibles pero no pueden garantizar la verificación de integridad. Inyectaría corrupción en páginas de datos, páginas de diccionario, encabezados y colas de replicación, y luego compararía la tasa de detección, el tiempo de localización, el costo de reintento y la igualdad de resultados.”

Respuesta detallada

Paso 1: Establecer el límite del formato

Los encabezados de página de Parquet contienen un campo CRC de 32 bits opcional para tipos de página como páginas de datos y de diccionario. Confirma que el writer lo complete y que el reader lo verifique; un cambio de configuración solo en el writer no hace que las lecturas downstream sean seguras.

write page bytes -> compute CRC32 -> persist header and payload
read page -> read header -> verify payload CRC -> decode

Incluye la versión del objeto, el row group, el column chunk y el ordinal de página en los diagnósticos para que un reintento pueda demostrar que leyó los mismos bytes.

Paso 2: Fijar el orden de compresión y checksum

La especificación e implementación del formato definen los bytes exactos cubiertos por el CRC. Mantén una matriz de versiones de writer/reader y nunca inventes un checksum sobre valores lógicos decodificados. Un fallo de descompresión y una discrepancia de CRC son clases de error distintas y necesitan métricas separadas.

Paso 3: Aislar la corrupción de forma segura

Ante un fallo, marca como fallida la lectura del archivo y coloca el objeto en una cola de cuarentena con URI, versión, ubicación de página y tipo de error. No omitas la página silenciosamente. Lee una réplica coincidente cuando esté disponible; si todas las copias fallan, reescribe la partición o reproduce los datos de upstream en lugar de reintentar sobre los mismos bytes indefinidamente.

Paso 4: Manejar lectores antiguos

Un reader antiguo puede ignorar el campo CRC y devolver filas, por lo que una decodificación exitosa no demuestra integridad. Durante el despliegue, mantén una matriz de capacidades de lectores. Los lectores estrictos validan cargas de trabajo críticas; los lectores antiguos se etiquetan como carentes de verificación de integridad, y una comprobación complementaria (sidecar) muestreada puede exponer diferencias antes de la migración.

Paso 5: Relacionar CRC con cifrado e índices de página

La autenticación del cifrado, la compresión y el orden del CRC deben seguir la implementación de destino. Un CRC no es una etiqueta de autenticación y un índice de página no valida los bytes de carga útil. Completa la comprobación de integridad requerida por el formato antes de decodificar o aplicar poda (pruning), conservando al mismo tiempo las coordenadas del column chunk para el diagnóstico.

Paso 6: Construir pruebas de inyección de corrupción

Modifica un bit (flip) en una página de datos y luego daña por separado una página de diccionario, el encabezado de página, la cola del archivo y la versión del objeto replicado. Cubre páginas comprimidas, páginas con abundancia de nulos, páginas vacías y páginas grandes. Verifica la ubicación en el reader estricto y registra el comportamiento de los lectores antiguos.

Paso 7: Definir una aceptación repetible

Con la misma versión de objeto, concurrencia y caché fría, compara CRC activado y desactivado en cuanto a CPU, bytes leídos, p95, tasa de detección y tiempo de localización. Los resultados para entradas intactas deben coincidir exactamente; la corrupción inyectada debe fallar y entrar en cuarentena. Genera alertas ante fallos de checksum, reintentos repetidos y tasa de éxito de recuperación.

Respuesta modelo

“Comenzaría con el formato Parquet y la implementación del reader de destino para confirmar que el CRC de página es opcional, qué tipos de página lo llevan y el rango exacto de bytes cubierto. Las lecturas verifican el CRC antes de la descompresión y decodificación; los errores de descompresión y de checksum son métricas separadas. Una página dañada falla y pone en cuarentena el archivo; luego, la recuperación utiliza la misma versión del objeto de otra réplica o reescribe desde upstream. No debe omitir la página ni reintentar indefinidamente un objeto defectuoso.

Los lectores más antiguos pueden ignorar el CRC, por lo que publicaría una matriz de capacidades y migraría los trabajos críticos a lectores estrictos. Pruebas de alteración de bits, encabezados de página, páginas de diccionario y truncamiento de replicación miden la detección, la localización, la CPU, los bytes leídos, la tasa de recuperación y los hashes de resultados antes de ampliar el despliegue.”

Errores comunes

• Tratar el CRC como autenticación → El CRC detecta corrupción aleatoria, no manipulación malintencionada → agrega cifrado autenticado o firmas cuando sea necesario.
• Modificar únicamente el writer → los lectores downstream pueden ignorar el campo → prueba la matriz de versiones.
• Omitir una página dañada → genera filas faltantes silenciosas → falla y pon en cuarentena.
• Reintentar un objeto indefinidamente → amplifica el costo → fija la versión y limita los reintentos.
• Probar únicamente daños en el archivo completo → pasa por alto los límites de páginas y encabezados → inyecta corrupción por capas.
• Mezclar errores de decodificación y de checksum → oscurece la recuperación → separa métricas y runbooks.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Evita el CRC la manipulación malintencionada?

No. El CRC detecta corrupción accidental. Utiliza cifrado autenticado, firmas o verificación de almacenamiento confiable para resistencia contra manipulaciones.

Pregunta de seguimiento 2: ¿Rompen la compatibilidad los lectores antiguos?

Por lo general, siguen siendo capaces de decodificar el formato, pero no pueden garantizar que se haya verificado el CRC. Los trabajos críticos deben usar lectores estrictos.

Pregunta de seguimiento 3: ¿Se puede releer solo la página dañada?

Intenta una lectura por rango (range read) o una réplica coincidente, pero valida el resultado completo. Si no existe una copia verificada, reescribe o reproduce los datos de upstream.

Pregunta de seguimiento 4: ¿Por qué registrar las versiones de los objetos?

Un objeto puede sobrescribirse durante un reintento. Los identificadores de versión vinculan el error y la acción de recuperación a una secuencia de bytes específica.

Pregunta de seguimiento 5: ¿Cómo se controla la sobrecarga?

Evalúa mediante benchmarks la CPU, el throughput y el p95 con tamaños de página y concurrencia realistas, y luego realiza un despliegue canary en particiones de alto riesgo antes del despliegue general.