Consigna y contexto
Esta pregunta evalúa si usted puede transformar «¿durante cuánto tiempo debemos conservarlo?» en un sistema del ciclo de vida de los datos que sea ejecutable, explicable y recuperable. Las versiones, instantáneas (snapshots), réplicas, copias de seguridad y exportaciones downstream no comparten una única semántica de eliminación; la expiración de snapshots en Apache Iceberg también requiere comprobar que los archivos no sigan estando referenciados por snapshots retenidos. Abarque las fuentes de las políticas, la precedencia, los ejecutores, el descubrimiento de dependencias, la evidencia de eliminación y la recuperación ante fallas. Los períodos de retención dependen de leyes y contratos específicos, por lo que el sistema debe dar soporte a la revisión legal en lugar de sustituir el criterio legal.
Qué evalúa el entrevistador
- Si distingue entre retención del negocio, retención legal (legal hold), solicitud de eliminación, ventana de respaldo y limpieza técnica.
- Si diseña políticas versionadas, acotadas en alcance, aprobadas y conscientes de las excepciones, en lugar de codificar de forma rígida un único TTL.
- Si gestiona referencias ocultas en snapshots, réplicas, cachés, exportaciones, tablas downstream y archivos huérfanos.
- Si proporciona ejecuciones de prueba (dry runs), ejecución observable, evidencia de eliminación, reintentos, límites de reversión (rollback boundaries) y pistas de auditoría.
Preguntas de aclaración para hacer primero
Confirme las clases de datos, el alcance del titular o inquilino (tenant), el propósito comercial, la región, el contrato y la fuente legal. ¿Aplica una política a una tabla, columna, registro, objeto o evento? ¿Quién aprueba y libera una retención legal cuando entra en conflicto con una solicitud de eliminación? ¿Qué copias y rutas de recuperación existen para los snapshots del lakehouse, los temas, el almacenamiento de objetos, las copias de seguridad y los índices de búsqueda? ¿Debe el sistema demostrar la eliminación física, o bien demostrar la remoción de las superficies de consulta en línea mientras los respaldos expiran de forma natural? En caso de falla, ¿puede la ejecución pausarse, reintentar o revertir metadatos?
Un marco de respuesta de 30 segundos
Modelaría las políticas con fuente, versión, alcance, precedencia y validez, separando la retención ordinaria, las retenciones legales, las solicitudes de eliminación y las excepciones de respaldo. Un compilador asigna las entidades del catálogo a ejecutores de snapshots, temas, objetos, índices y respaldos, y primero genera una ejecución de prueba que muestra el impacto y los conflictos. La ejecución utiliza un grafo de dependencias y verificaciones de referencias para que los archivos necesarios para snapshots o recuperación no se eliminen, confirma los cambios en lotes y registra cada paso. La evidencia resultante cubre el alcance, los tiempos, las fallas y la ventana de respaldo restante. Cualquier incertidumbre pausa el plan para su revisión en lugar de omitirlo silenciosamente.
Análisis detallado paso a paso
1. Modelar las fuentes de las políticas y la precedencia
Una política debe incluir el alcance del sujeto, las etiquetas de datos, el propósito del procesamiento, la duración de la retención, el evento de inicio, la región, la fuente, la versión, el aprobador y las excepciones. Represente las solicitudes de eliminación, las retenciones legales, los períodos contractuales y la expiración natural de respaldos como restricciones distintas con una ruta documentada de conflicto y escalamiento. Persista el snapshot de entrada utilizado para cada cálculo a fin de que el sistema pueda explicar por qué un registro se conserva.
2. Construir un catálogo de entidades y referencias
El catálogo vincula tablas, particiones, snapshots, objetos, temas, índices, exportaciones y copias de seguridad con sus propietarios y su linaje. Para un lakehouse, identifique los archivos referenciados por snapshots, ramas o etiquetas retenidos; para canalizaciones asíncronas, registre si los eventos de eliminación llegaron a los consumidores downstream. Cuando no se pueda establecer una referencia, conserve los datos y cree un elemento de trabajo en lugar de hacer suposiciones.
3. Compilar un plan ejecutable
El compilador crea un tiempo de expiración, una acción, comprobaciones de condiciones previas, un requisito de aprobación y un límite de reversión para cada entidad. Las acciones pueden bloquear nuevas escrituras, ocultar datos a las consultas, expirar snapshots, eliminar archivos huérfanos, emitir eventos de eliminación downstream o esperar una ventana de respaldo. Incluya una versión del plan y una clave de idempotencia para que los reintentos no dupliquen efectos secundarios; la ejecución de prueba reporta conflictos, recuento estimado de objetos y riesgo.
4. Diseñar la ejecución por lotes y las medidas de protección
Particione la ejecución por inquilino, región, tabla o partición, y limite la concurrencia y la eliminación por lote. Antes de la eliminación física, vuelva a verificar los snapshots activos, los trabajos de recuperación, las retenciones legales y las escrituras recientes; las acciones de alto riesgo necesitan aprobación dual o una breve ventana de congelamiento. Admita pausar, reanudar y retroceso exponencial (exponential backoff) para no sobrecargar los servicios de almacenamiento o catálogo. Registre la versión del plan, el resumen (digest) de entrada, el resultado y la clase de error para cada lote.
5. Generar evidencia de eliminación verificable
La evidencia es más que un registro de «trabajo exitoso». Enumera la versión de la política, las entidades cubiertas, la hora de inicio y finalización, los recuentos procesados y fallidos, las comprobaciones de referencias, los acuses de recibo downstream, la expiración de respaldos y los límites no verificables. Registre la expiración de snapshots, la eliminación de archivos y la limpieza de índices por separado. Si una copia de seguridad no se puede eliminar físicamente de inmediato, indique que la superficie en línea se eliminó, cuándo expira la copia de seguridad y quién aprobó ese límite.
6. Manejar fallas, recuperación y auditoría continua
Confirme los cambios de metadatos y la eliminación física en etapas, reteniendo los snapshots necesarios o una ventana de eliminación suave (soft-delete) para la recuperación. Si una política es incorrecta, detenga los lotes posteriores, marque las entidades afectadas y ejecute un plan compensatorio. No se puede fingir que los datos eliminados físicamente son reversibles; recupérelos a partir de una réplica permitida o una reconstrucción upstream. Supervise el trabajo acumulado de expiración, los bloqueos de eliminación, el retraso en la confirmación downstream, los residuos de respaldos y los conflictos de políticas, y revise periódicamente las fuentes de las políticas y los permisos.
Respuesta modelo de alta calidad
Modelaría las etiquetas de datos, el propósito, el alcance del sujeto, el evento de inicio, la retención, la región, la fuente, la versión, el aprobador y las excepciones, para luego definir los conflictos entre la retención ordinaria, la retención legal, la solicitud de eliminación y la ventana de respaldo. El catálogo vincularía tablas, particiones, snapshots de lakehouse, temas, índices, exportaciones y copias de seguridad; las referencias desconocidas permanecen protegidas. Un compilador crea planes idempotentes y versionados, y realiza una ejecución de prueba antes de agrupar por inquilino y partición. Antes de la eliminación, vuelve a verificar los snapshots activos, los trabajos de recuperación, las retenciones legales y las escrituras recientes, y registra cada resultado. La evidencia enumera el alcance, la versión de la política, la eliminación y el acuse de recibo downstream, las fallas y la expiración de respaldos, distinguiendo la remoción en línea de la eliminación física. Cualquier anomalía pausa los lotes posteriores para compensación o aprobación. Las auditorías continuas rastrean el trabajo acumulado, las eliminaciones bloqueadas, los residuos y los permisos.
Errores comunes
- Tratar cada sistema de almacenamiento como un único almacén clave-valor con un TTL.
- Conservar únicamente una fecha final de expiración perdiendo el contexto de propósito, fuente, versión, aprobación y conflicto.
- Ignorar snapshots, ramas, respaldos, índices y copias downstream antes de la eliminación.
- Calificar un trabajo exitoso como prueba de eliminación sin límites de alcance ni de fallas.
- Omitir ejecuciones de prueba, pausas, procesamiento por lotes, idempotencia y medidas de protección basadas en aprobación humana.
- Afirmar que la eliminación física es inmediatamente reversible o ignorar la expiración natural de las copias de seguridad.
- Presentar la configuración del sistema como asesoramiento legal y perder la fuente legal o contractual.
Preguntas de seguimiento y respuestas
¿Qué ocurre si una retención legal entra en conflicto con una solicitud de eliminación?
Modélelas como restricciones independientes, aplique la precedencia confirmada por la política legal y registre el aprobador, el motivo, y la hora de inicio y de liberación. El sistema puede congelar la eliminación o restringir el acceso en línea, pero no debe inventar una excepción legal.
¿Cómo demuestra que la expiración de snapshots no eliminará archivos referenciados?
Lea los snapshots activos, las ramas, las etiquetas y las referencias de trabajos de recuperación antes de la ejecución, y procese únicamente los snapshots y archivos que estén fuera del conjunto retenido. Vuelva a escanear después del envío y registre la verificación. Las referencias desconocidas permanecen protegidas y se convierten en elementos de trabajo.
¿Qué pasa si las copias de seguridad no se pueden eliminar de inmediato?
Represente la remoción en línea, la no disponibilidad de la copia de seguridad y la expiración en medios físicos como estados separados. Registre la retención del respaldo, los planes de destrucción de cifrado o expiración natural, y las restricciones de acceso. La evidencia debe declarar el límite y el responsable de los datos que aún no han sido eliminados físicamente.
¿Qué sucede después de una eliminación accidental?
Detenga la política y los lotes posteriores, congele la versión del plan y la evidencia de auditoría, y evalúe las entidades afectadas. Recupere a partir de un snapshot permitido, una copia de seguridad o una reconstrucción upstream; luego aplique la política corregida y registre la remediación, la aprobación y la notificación.