Planteamiento y alcance
Tu data lake utiliza tablas Iceberg y está migrando de 1.10.1 a 1.10.2. Las tablas contienen equality deletes, eliminaciones v2 y escritores concurrentes, mientras que la versión incluye correcciones de seguridad. Diseña la actualización, validación, reversión y limpieza.
Apache Iceberg registra 1.10.2 como lanzada el 18 de mayo de 2026, con correcciones para el ordenamiento de esquemas en equality deletes, la carga de instantáneas después del commit, la limpieza no segura de archivos, las actualizaciones de formato concurrentes y vulnerabilidades en dependencias. La entrevista evalúa la capacidad de convertir las notas de la versión en evidencia de corrección de datos.
Lo que evalúa el entrevistador
- Separar la especificación de la tabla, la implementación del motor, Catalog, FileIO y las dependencias de tiempo de ejecución.
- Explicar equality deletes, position deletes, delete vectors y la visibilidad de instantáneas.
- Diseñar validación en paralelo (shadow validation), pruebas de escritura concurrente, protección de limpieza y una ventana de reversión.
- Reconocer que el hecho de que una actualización de dependencias sea exitosa no es prueba de la corrección en consultas históricas.
- Definir métricas auditables, líneas de parada (stop lines) y compuertas de limpieza posteriores a la actualización.
Preguntas aclaratorias
- ¿Qué motores, Catalog, almacenamiento de objetos y entornos de ejecución de Iceberg están implementados? ¿Los escritores son multilingües?
- ¿Qué versiones de formato, tipos de archivos de eliminación, particionamiento, retención de instantáneas y tasas de commit aplican?
- ¿Se trata solo de un reemplazo de dependencias del cliente, o también cambian los escritores, lectores y servicios de Catalog?
- ¿Cuáles escritores en streaming y consultas posteriores (downstream) no pueden pausarse?
Matriz de versiones y compatibilidad
Bloquea el árbol de dependencias real y las versiones implementadas. Construye una matriz para lectores, escritores, Catalog, FileIO, almacenamiento de objetos y trabajos de limpieza. Una corrección en 1.10.2 no demuestra que un motor antiguo entienda los nuevos metadatos; utiliza las guías oficiales de compatibilidad más pruebas de reproducción (replay tests). Despliega en etapas: lectores de solo lectura, escritores fuera de línea, escritores en línea y limpieza.
En un entorno canario, copia instantáneas de producción, archivos de eliminación y commits concurrentes. Registra los ID de instantáneas, recuentos de manifiestos, recuentos de archivos de eliminación y las versiones de formato de tabla leídas por cada componente. Marca la compatibilidad desconocida como un bloqueador en lugar de tratar el hecho de que "puede leer" como evidencia.
Semántica de eliminaciones y validación de corrección
Crea un conjunto de datos maestro (golden dataset) con claves de igualdad repetidas, múltiples versiones de filas, position deletes, delete vectors y actualizaciones concurrentes. Compara lectores previos y posteriores a la actualización en la misma instantánea, consultas de time-travel y escaneos incrementales. Verifica el recuento de filas, conjuntos de claves primarias, agregaciones y ordenamiento de esquemas; registra las filas filtradas y las eliminaciones no coincidentes.
No valides únicamente la tabla actual: una eliminación incorrecta puede salir a la luz después de la compactación. Conserva los manifiestos originales, archivos de eliminación y registros de instantáneas, y realiza verificaciones cruzadas con SQL independiente o una implementación exacta pequeña. Ante una falla, preserva las instantáneas y no las expires de inmediato.
Commits concurrentes y protección de instantáneas
Ejecuta pruebas de anexado (append), sobrescritura (overwrite), eliminación a nivel de fila y compactación durante la actualización. Inyecta conflictos de commit, tiempos de espera en Catalog y errores 503 transitorios en el almacenamiento de objetos. Confirma que las transacciones fallidas no puedan limpiar archivos referenciados por instantáneas activas y que los commits exitosos expongan una sola instantánea consistente. Establece una línea de parada dedicada para eliminaciones v2 concurrentes con actualizaciones de formato.
La limpieza calcula los candidatos a partir de la retención, consultas activas, referencias de ramas o etiquetas y el tiempo de commit. Los candidatos ingresan a una cola retrasada y se eliminan solo después de una segunda confirmación. Durante la reversión, prohíbe la limpieza irreversible para que el historial legible permanezca disponible.
Despliegue, reversión y gobernanza
Lanza en lotes: servicios de solo lectura, escritores de bajo volumen y luego todos los trabajos. Cada lote registra errores, latencia de commit de instantáneas, diferencias en resultados de consultas, omisiones de eliminación (delete misses), errores 404 de almacenamiento de objetos, candidatos de limpieza y costo de recursos. La reversión cambia a un cliente compatible mientras retiene las instantáneas creadas por la nueva versión para su revisión; eliminar metadatos no es una reversión.
Bloquea y analiza dependencias transitivas en los artefactos de compilación. Si 1.10.2 elimina o cambia un fixture de prueba o artefacto de tiempo de ejecución, valida el empaquetado, classpaths y licencias en la matriz de compilación antes de producción. Registra excepciones manuales con fechas de expiración.
Simulacros de fallas y compuertas de lanzamiento
Realiza simulacros de cambios en el orden de esquema de equality deletes, actualizaciones de formato concurrentes, fallas al cargar instantáneas, limpieza recibiendo errores 503, lectores antiguos cargando nuevas instantáneas, latencia en el almacenamiento de objetos y commits duplicados durante la recuperación. Las compuertas incluyen cero diferencias no explicadas en los resultados, omisiones de eliminación dentro del presupuesto, ningún archivo de instantánea activa limpiado, historial legible después de la reversión y análisis de dependencias aprobados.
Si solo difiere el ordenamiento, determina si el ordenamiento no estaba especificado. Si los conjuntos de claves primarias o la visibilidad de eliminación difieren, detén la expansión inmediatamente. Después de las ventanas de retención y observación, restablece la limpieza gradualmente; la presión de espacio en disco no justifica omitir la retención de evidencia.
Preguntas de seguimiento y respuestas de referencia
¿Por qué no es suficiente comparar solo el recuento de filas más reciente?
Pasa por alto time-travel, lecturas incrementales, la aplicación de archivos de eliminación y la limpieza histórica. Compara múltiples instantáneas, conjuntos de claves primarias, agregaciones y omisiones de eliminación en el conjunto de datos maestro.
¿Cómo demuestras que la reversión es segura?
Conserva las instantáneas previas y posteriores, detén la limpieza irreversible, verifica que los lectores antiguos puedan leer la ventana de retención y ensaya la recuperación después de conflictos de commit y fallas en el almacenamiento de objetos.
¿Cómo entran las correcciones de seguridad de dependencias en la validación de datos?
Bloquea las dependencias transitivas y analiza los artefactos, luego ejecuta pruebas de matriz de classpath, licencias y lectores/escritores. Un escaneo de seguridad limpio no demuestra la semántica de eliminaciones.