Planteamiento y alcance
Un trabajo por lotes (batch) realiza el backfill de 90 días de dimensiones de pedidos y posteriormente se descubre que su lógica de transformación era errónea. Las escrituras en streaming continuaron durante la ejecución. Diseñe cómo localizar el snapshot defectuoso, reproducir las consultas afectadas, aislar una corrección, manejar conflictos de commit y configurar la retención. Las habilidades centrales son el versionado en formatos de tabla, el linaje y las operaciones recuperables, por lo que pertenece a la ingeniería de datos.
Qué evalúa el entrevistador
La respuesta debe explicar que un snapshot es un puntero de metadatos, no una simple copia de archivos, y que el time travel depende de la retención. Cubra commits concurrentes, efectos del rollback, consistencia de lecturas posteriores (downstream), expiración de snapshots y limpieza de archivos huérfanos. Decir simplemente "restaurar al día de ayer" no demuestra seguridad.
Preguntas para clarificar primero
- ¿Qué catálogo, motor y bloqueo de commit se utilizan, y cómo se auditan los IDs de snapshot?
- ¿Qué particiones, snapshots y tablas downstream se vieron afectados?
- ¿Los trabajos de streaming hicieron commit durante el backfill erróneo? ¿Pueden pausarse o reproducirse desde un snapshot?
- ¿El negocio solicita un rollback de toda la tabla, una reescritura de particiones o una tabla de reemplazo para validación?
- ¿Durante cuánto tiempo se retienen los snapshots y los archivos de datos? ¿Podría una limpieza eliminar la evidencia de recuperación?
Marco de respuesta en 30 segundos
“Primero identifico el commit del backfill a partir del historial de la tabla y los logs de ejecución, luego comparo su snapshot con el padre usando consultas de time-travel para delimitar las particiones afectadas. Aíslo las entradas correctas, vuelvo a ejecutar la validación y elijo una reescritura de particiones, un snapshot de reparación o un rollback únicamente cuando no haya commits válidos posteriores que deban conservarse. Antes de cambiar el puntero, verifico los commits y lectores concurrentes; después de cambiarlo, reconstruyo las tablas downstream. Retraso la expiración de snapshots y la limpieza de huérfanos hasta que se cierre la ventana de recuperación, y monitoreo métricas de snapshots, archivos y calidad de datos.”
Solución paso a paso
Lea el historial de la tabla, la lista de snapshots y los resúmenes de commits. Registre los IDs de snapshot, marcas de tiempo de commit, IDs de ejecución, rangos de partición y versiones de entrada. No infiera el objetivo basándose únicamente en la hora de reloj, ya que los commits concurrentes pueden intercalarse. Compare el snapshot defectuoso con su padre en metadatos y archivos de datos, y luego use logs de trabajos, alertas de calidad y estadísticas de partición para delimitar el impacto.
Utilice consultas de time-travel para reproducir las mismas métricas de negocio antes y después de la escritura incorrecta. Un snapshot proporciona una vista de lectura consistente, pero no retiene un historial infinito; finalice las consultas antes de la expiración o exporte muestras de validación y referencias de metadatos cuando sea necesario.
Si las escrituras de streaming siguen activas, pause las particiones en conflicto o cree una rama aislada o tabla temporal. Lea las entradas correctas a partir del snapshot adecuado, corrija la transformación y realice el commit de la reparación solo después de verificar que el snapshot padre sigue siendo la versión esperada. Ante un conflicto, vuelva a leer el snapshot más reciente y recalcule en lugar de sobrescribir a la fuerza escrituras válidas.
Un rollback a nivel de toda la tabla solo es apropiado cuando no debe preservarse ningún commit válido posterior y los lectores aceptan una regresión temporal. Con mayor frecuencia, se reescriben las particiones afectadas o se publica una tabla reparada y se cambian las referencias downstream. Mover el puntero de metadatos no repara los datos que ya han sido materializados en otras tablas.
Después de la reparación, vuelva a ejecutar verificaciones de unicidad, conteos, montos, latencia y conciliación de negocio. Compare el snapshot defectuoso, el snapshot de reparación y los eventos sin procesar (raw). Recalcule las tablas downstream a partir de la versión reparada y registre el nuevo snapshot y la versión del código para que la ejecución sea reproducible.
La retención debe cubrir los plazos de backfill, revisión, recalculación downstream y auditoría. Expirar snapshots demasiado pronto puede provocar que el time travel falle. Solo deben eliminarse los archivos que ya no estén referenciados por snapshots retenidos después de confirmar que ningún lector los necesita; la limpieza de huérfanos no debe eliminar archivos que aún estén referenciados por un trabajo no confirmado o concurrente.
Monitoree la antigüedad de los snapshots, conflictos de commit, cantidad de rollbacks, recuento de archivos huérfanos, fallas de expiración, calidad de particiones, retraso en la recalculación downstream y discrepancias de conciliación. Escriba los IDs de snapshot, IDs de ejecución, versiones de código y particiones de entrada en una tabla de auditoría para que un resultado pueda rastrearse hasta su commit.
Respuesta modelo de alta calidad
“Preservo el historial de la tabla, los IDs de snapshot y el ID de ejecución, identifico el commit del backfill y utilizo consultas de time-travel entre su padre y su hijo para delimitar las particiones afectadas. Si las escrituras de streaming continúan, pauso el rango en conflicto o escribo la reparación en una tabla aislada, valido el snapshot padre en el momento del commit y vuelvo a leer en caso de conflicto en lugar de forzar una sobrescritura.
Si no se debe retener ningún commit válido posterior, puedo hacer rollback del puntero de metadatos; de lo contrario, reescribo las particiones y publico un snapshot de reparación. El rollback no repara las tablas materializadas downstream, por lo que las recalculo desde la versión de reparación y vuelvo a ejecutar las verificaciones de calidad y conciliación. La expiración de snapshots y la limpieza de huérfanos se posponen más allá de la ventana de auditoría, y se registran cada snapshot, versión de código y rango de entrada.”
Errores comunes
- Suponer un snapshot a partir de su marca de tiempo → los commits concurrentes pueden intercalarse → use el historial, la genealogía (parentage) y los IDs de ejecución.
- Tratar un snapshot como un respaldo de archivos → el rollback puede no solucionar las tablas downstream → inventaríe los punteros de metadatos y los datos derivados.
- Sobrescribir a la fuerza el snapshot más reciente → perder escrituras concurrentes válidas → verifique el padre y reintente ante conflictos.
- Limpiar snapshots antiguos de inmediato → desaparecen el time travel y la evidencia de auditoría → retenga una ventana de recuperación.
- Validar únicamente filas de muestra → persisten los errores agregados → revise particiones, métricas, unicidad y conciliación.
- Hacer rollback únicamente de la tabla principal → los resultados downstream siguen siendo erróneos → recalcule las tablas derivadas a partir de la versión reparada.
- Asumir que la limpieza de huérfanos es inocua → los trabajos concurrentes aún pueden referenciar archivos → limpie considerando el estado de commits y lectores.
- Omitir versiones de código y de entrada → la reparación no se puede reproducir → vincule snapshots, ejecuciones y versiones en datos de auditoría.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuándo es un rollback de tabla mejor que una reescritura de particiones?
Solo cuando no deba conservarse ningún commit válido posterior al punto de rollback y los lectores acepten una regresión temporal. De lo contrario, reescriba las particiones o publique una tabla reparada.
Pregunta de seguimiento 2: ¿Por qué puede fallar el time travel?
Es posible que el snapshot de destino haya expirado o que sus archivos hayan sido eliminados. La retención debe cubrir la investigación y la recalculación, y la limpieza debe monitorearse.
Pregunta de seguimiento 3: ¿Cómo se evita sobrescribir nuevos datos de streaming?
Limite la reparación a las particiones afectadas, pause los escritores en conflicto o aísle el trabajo, valide el snapshot padre y recalcule a partir de la versión más reciente tras un conflicto.
Pregunta de seguimiento 4: ¿El rollback revierte los eventos downstream?
No. Cambia el puntero de metadatos de la tabla. Los eventos enviados, las tablas materializadas y los efectos externos requieren compensación o recalculación por separado.
Pregunta de seguimiento 5: ¿En qué se diferencia un snapshot de un respaldo completo?
Un snapshot suele ser una vista de metadatos de un conjunto de archivos y depende de la retención de los mismos. Un respaldo completo también requiere copias entre almacenamientos, el estado del catálogo y un procedimiento de recuperación.
Pregunta de seguimiento 6: ¿Cómo demuestra que la reparación del backfill es correcta?
Fije el snapshot de entrada y la versión del código, vuelva a ejecutar las particiones, compare los eventos sin procesar y las métricas de negocio, verifique la unicidad y los montos, concilie y retenga el snapshot de reparación para su revisión.
Pregunta de seguimiento 7: ¿Por qué son importantes los conflictos de commit?
Los commits de Iceberg se actualizan a partir de un snapshot padre. Ignorar los conflictos y forzar una escritura puede descartar el commit válido de otro trabajo; el conflicto debe activar una nueva lectura, una recalculación o una decisión humana.