1. Prompt y contexto
Un data lake recibe archivos de almacenamiento de objetos todos los días, los escribe como Parquet y confirma snapshots de tablas para paneles y modelos. Al equipo le preocupan las transferencias truncadas, los objetos reemplazados, los metadatos que ya no coinciden con el contenido y las escrituras duplicadas tras reintentos. Diseña verificaciones que ubiquen el límite del fallo en lugar de comparar únicamente un conteo final de filas.
2. Qué está evaluando el entrevistador
- Separar la integridad de transporte, la corrupción de archivos, la consistencia de tablas y la corrección de negocio.
- Explicar que un checksum detecta cambios accidentales de bytes, pero no demuestra la corrección semántica ni detiene por sí solo una reescritura maliciosa.
- Distinguir verificaciones en tiempo de escritura, en tiempo de lectura y en segundo plano, con sus respectivos costos y coberturas.
- Proporcionar un flujo de trabajo de alerta, reparación y auditoría que sea aislable y reproducible.
3. Preguntas para aclarar primero
- ¿Estamos previniendo errores de transferencia, detectando corrupción silenciosa o generando evidencia de cumplimiento? Cada objetivo cambia los algoritmos y la retención.
- ¿Los archivos son inmutables? Si se permite el reemplazo en el lugar, la versión del objeto o el resumen del contenido (digest) debe formar parte del snapshot de la tabla.
- ¿Qué retraso de detección y tasa de falsos positivos son aceptables? Las verificaciones en tiempo real y los escaneos completos diarios tienen presupuestos diferentes.
- ¿Existen múltiples formatos, almacenes o copias entre regiones? Cada límite necesita una nueva verificación.
4. Estructura de respuesta en treinta segundos
“Utilizaría cuatro capas: verificar un checksum del objeto durante la carga, verificar los CRC de página de Parquet durante las lecturas, verificar el manifiesto de archivos y los metadatos al confirmar un snapshot, y conciliar conteos de filas, rangos de particiones y métricas críticas en la capa de negocio. Almacenar el algoritmo, el digest, la versión del objeto, el ID del job y la marca de tiempo para cada verificación. Poner en cuarentena los archivos fallidos y reconstruirlos a partir de una fuente ascendente o una réplica confiable. Combinar el muestreo basado en riesgos con escaneos completos, y clasificar las alertas por conjunto de datos y radio de impacto. Finalmente, escribir los resultados en una tabla auditable en lugar de dejar los fallos únicamente en los registros.”
5. Razonamiento paso a paso
Primero, proteger la transferencia. El productor calcula un digest antes de la carga y el servicio de almacenamiento lo valida; una discrepancia rechaza el objeto y desencadena un reintento. Amazon S3 admite checksums para cargas de una sola parte y de varias partes (multipart), y permite a los clientes solicitar un checksum durante la descarga. Un ETag de multipart no debe tratarse como un MD5 de todo el objeto.
Segundo, proteger el archivo. Parquet puede calcular el checksum de cada página de datos con CRC32, lo que permite al lector encontrar corrupción antes de la descompresión. Los checksums de página reducen el área dañada pero no hacen cumplir las reglas de negocio, por lo que el manifiesto también debe almacenar la ruta, el tamaño, la versión del formato y el digest del contenido.
Tercero, proteger el snapshot. En el momento de la confirmación (commit), crea un manifiesto de archivos inmutable que contenga la versión o digest del objeto, la partición, el conteo de filas y el ID del job escritor. Rechaza un snapshot cuando falte un archivo, esté duplicado o tenga un digest diferente; de lo contrario, un archivo defectuoso puede ingresar a las lecturas posteriores.
Cuarto, conciliar señales de negocio. Para particiones críticas, calcula el conteo de filas, la tasa de nulos, los totales de importes y los conteos de claves distintas, y luego compáralos con un libro mayor ascendente o una versión anterior. Métricas iguales no demuestran un contenido igual, por lo que la conciliación es una señal independiente más allá de los checksums.
Quinto, patrullar y reparar. Verifica los datos calientes durante la lectura y muestrea los datos fríos según el riesgo; ejecuta verificaciones completas en conjuntos de datos de alto valor o regulados. Amazon S3 Batch Operations puede generar de forma asíncrona informes de checksums de objetos completos o compuestos para grandes conjuntos de objetos en reposo. Pon en cuarentena las anomalías con el digest original, la hora de detección y la referencia del snapshot, reconstruye a partir de una réplica confiable y confirma nuevamente solo después de la verificación.
6. Respuesta de muestra de alta calidad
“No trataría un checksum como todo el plan de calidad de datos. La capa de carga verifica un digest de transporte, el lector de Parquet habilita los CRC de página, la confirmación del snapshot almacena un manifiesto inmutable con versiones de objetos e IDs de escritores, y la capa de negocio concilia conteos, claves e importes para particiones críticas. Cada verificación registra su algoritmo, digest y hora. Un fallo en la lectura o patrullaje pone en cuarentena el archivo y evita que un nuevo snapshot haga referencia a él. Verificaría los datos calientes sincrónicamente, cubriría los datos ordinarios con muestreo basado en riesgo y escanearía los datos regulados por completo de forma programada. Las reparaciones se reconstruyen a partir de una réplica confiable y conservan la evidencia de fallo original. Las capas distinguen los fallos de transferencia, almacenamiento, snapshot y lógica de negocio, al tiempo que explicitan su costo y sus puntos ciegos.”
7. Errores comunes
- Error → Comparar únicamente el total de filas → el reemplazo o las filas duplicadas aún pueden pasar desapercibidos → añade digests de objetos, verificaciones de claves distintas y conciliaciones críticas.
- Error → Tratar un ETag de multipart como el MD5 del archivo → la semántica del algoritmo no se cumple → almacena el tipo de checksum declarado y la versión del objeto.
- Error → Realizar una verificación fuerte y completa en cada lectura → la latencia y el costo se vuelven ilimitados → verifica los datos calientes sincrónicamente y patrulla los datos fríos según el riesgo.
- Error → Reejecutar todo el pipeline después de un archivo defectuoso → los archivos confirmados como correctos pueden escribirse dos veces → pon en cuarentena, localiza por ID de job y reconstruye solo los archivos afectados.
- Error → Usar un checksum como prueba de corrección de negocio → un digest demuestra que los bytes cambiaron o no cambiaron → mantén reglas de calidad de negocio independientes.
8. Preguntas de seguimiento
¿Qué pasa si un atacante reemplaza un archivo y también actualiza su digest?
Un checksum normal maneja la corrupción accidental. Añade firmas protegidas, control de acceso, bloqueo de versiones de objetos y una cadena de auditoría. Mantén el digest confiable en un almacenamiento de metadatos separado de los permisos de escritura y registra quién aprobó una nueva versión.
Solo tienes una hora al día para escaneos completos. ¿Cómo la asignas?
Puntúa las particiones según el valor de los datos, los cambios recientes, los fallos históricos y las rutas de replicación. Escanea primero las de mayor riesgo y cubre el resto con verificaciones en tiempo de lectura, muestreo y ventanas móviles. Informa la cobertura y las ventanas no verificadas en lugar de afirmar que todo el lago está verificado.
¿Cómo evitas que un job de reparación duplique datos?
Usa el ID de archivo original, el snapshot de destino y una clave de escritura idempotente. Antes de confirmar, verifica si el manifiesto ya contiene el mismo digest de contenido y luego actualiza atómicamente el puntero del snapshot. Los reintentos reconstruyen solo los archivos fallidos y nunca anexan archivos ya confirmados.