Entrevista de ingeniería de datos: uso seguro de deletion vectors en Iceberg

Planteamiento y alcance

Una tabla de Apache Iceberg almacena registros de usuarios y debe admitir el borrado por GDPR, así como correcciones frecuentes. El equipo planea actualizar de v2 a v3 y está considerando deletion vectors. Explique las compensaciones entre los tres formatos de eliminación a nivel de fila y cómo mantendría seguros a los lectores antiguos, los escritores concurrentes, el rollback y la compactación.

Esta pregunta evalúa el protocolo de lectura/escritura del formato de tabla, no un simple flag de funcionalidad. La especificación de Iceberg define un deletion vector (DV) como un mapa de bits de posiciones para un archivo de datos referenciado; su alcance, metadatos y obligaciones de mantenimiento difieren de los archivos de equality deletes y position deletes.

Qué evalúa el entrevistador

• Si distingue entre eliminaciones basadas en valores, en posiciones de archivo y en mapas de bits.
• Si sabe que los deletion vectors son una capacidad de Iceberg v3 y no tienen soporte nuevo en v2.
• Si puede explicar las condiciones de ruta de archivo, partición y número de secuencia para las lecturas de snapshots.
• Si toma en cuenta el límite de como máximo un DV por archivo de datos y la fusión de position deletes más antiguos.
• Si conecta la elección del formato con la amplificación de lectura, la amplificación de escritura, la densidad de eliminaciones, la compatibilidad y el presupuesto de mantenimiento.
• Si diseña observabilidad, simulacros de rollback y una ruta segura para lectores antiguos.

Aclaraciones que conviene hacer primero

Confirme:

1. ¿La tabla es Iceberg v2 o v3, y qué versiones de cada lector y escritor están desplegadas?
2. ¿Las solicitudes de eliminación contienen valores de clave de negocio, o ya identifican un archivo de datos y una posición de fila?
3. ¿Cuáles son la densidad de eliminaciones, la tasa de actualizaciones, el objetivo de latencia de consultas y el presupuesto de compactación?
4. ¿Siguen presentes motores v2 de solo lectura, y se requieren time travel y rollback de snapshots?
5. ¿Las eliminaciones deben alimentar un flujo CDC descendente, o basta con la invisibilidad en el snapshot actual?

Si faltan detalles, asuma que la mayoría de los lectores admiten v3, queda una pequeña población de lectores v2 y un commit exitoso debe hacer que la eliminación sea visible en el snapshot confirmado.

Estructura de respuesta en treinta segundos

Elegiría según la semántica: los equality deletes coinciden con valores de columna, los position deletes identifican una ruta de archivo y una posición de fila y pueden servir para la compatibilidad con v2, y una tabla v3 puede consolidar position deletes frecuentes para un único archivo de datos en un deletion vector. Los lectores deben validar el archivo referenciado, la partición y el alcance del número de secuencia en lugar de mirar únicamente el mapa de bits.

Los escritores deben mantener como máximo un DV por archivo de datos en un snapshot y fusionar los position deletes existentes en él. Los commits utilizan verificaciones de concurrencia de snapshots de Iceberg. Dado que los lectores v2 no pueden interpretar DVs, construiría una matriz de capacidades, una comparación de lectura dual y un plan de rollback antes de habilitar las escrituras. Las pruebas de aceptación cubren visibilidad de eliminaciones, snapshots antiguos, conflictos, compactación y rendimiento.

Análisis detallado paso a paso

1. Definir la semántica de cada formato

Un equality delete hace coincidir filas en cualquier archivo de datos aplicable mediante uno o más valores de columna, como id = 5. Un position delete identifica una ruta de archivo y una posición de fila basada en cero. Un deletion vector almacena un mapa de bits de posiciones para un archivo de datos referenciado; un bit establecido significa que esa fila está eliminada.

No se trata simplemente de niveles de compresión. Los equality deletes se adaptan a eventos basados en claves, pero requieren coincidencia de predicados durante los escaneos. Los position deletes son precisos y compatibles con v2, pero pueden acumular muchos archivos. Los DVs consolidan muchas posiciones para un solo archivo de datos en un objeto binario directamente direccionable.

2. Manejar versiones y capacidad de los lectores

Iceberg ubica las eliminaciones a nivel de fila después de v1, mientras que los deletion vectors se añaden en v3. Una tabla v3 no debe agregar nuevos archivos de position deletes, pero los position deletes existentes de una tabla v2 actualizada siguen siendo válidos y deben fusionarse cuando se crea un DV.

Por lo tanto, una actualización de catálogo es insuficiente. Haga un inventario de si cada lector puede analizar los metadatos v3, el blob Puffin deletion-vector-v1 y los manifiestos de eliminación. Un lector no compatible necesita un snapshot compatible o una migración completada; no se puede esperar que ignore silenciosamente los DVs recién escritos.

3. Respetar el alcance de lectura de snapshots

Un lector aplica un DV a un archivo de datos solo cuando la ruta del archivo de datos es igual a referenced_data_file, el número de secuencia del archivo de datos es menor o igual al número de secuencia del DV, y la especificación de partición y sus valores coinciden. Hacer coincidir solo la ruta podría aplicar una eliminación a un archivo reescrito; ignorar los números de secuencia rompe la semántica de ordenamiento.

Los metadatos de eliminación también registran el archivo contenedor, el desplazamiento del blob y la longitud. Los lectores deben localizar el blob a través de los metadatos del snapshot, no tratar un archivo de almacenamiento de objetos con un nombre familiar como autoritativo.

4. Diseñar la fusión del escritor y commits concurrentes

Un snapshot permite como máximo un DV para un archivo de datos. Al anexar eliminaciones, un escritor lee el estado de eliminación actual, fusiona las nuevas posiciones con el DV antiguo y los archivos de position deletes, y escribe un DV de reemplazo. Si el archivo de datos se elimina, las entradas de DV aplicables deben eliminarse de los manifiestos de eliminación.

Los commits siguen utilizando la concurrencia optimista de snapshots de Iceberg. Un reintento por conflicto debe releer los metadatos actuales y los manifiestos de eliminación; no puede reutilizar un mapa de bits generado durante el primer intento. Registre los recuentos de reintentos, las causas de conflicto y el id del snapshot final.

5. Equilibrar la amplificación de lectura y escritura

Para eliminaciones dispersas y distribuidas, los equality deletes evitan localizar los archivos originales, pero añaden trabajo de coincidencia durante los escaneos. Para eliminaciones frecuentes concentradas en pocos archivos, los DVs pueden reducir la gestión de archivos de position deletes y el trabajo de fusión. Para una eliminación amplia o un archivo que ya requiere reescritura, reescribir los datos y limpiar los archivos de eliminación puede ser más económico.

No afirme que los DVs siempre son más rápidos. Compare los bytes escaneados, el recuento de archivos de eliminación, el tamaño del mapa de bits, el tiempo de lectura de manifiestos, la CPU de compactación y la latencia de extremo a extremo en varias densidades de eliminación.

6. Planificar mantenimiento, rollback y evidencia de cumplimiento

El mantenimiento debe fusionar archivos de eliminación antiguos, reescribir archivos de datos con alta densidad de eliminación y eliminar blobs no referenciados en una ventana segura. Las reglas de retención para time travel deben respetarse, o los snapshots históricos se volverán ilegibles. Para GDPR, demuestre que la fila objetivo está ausente del snapshot válido actual y de las copias descendentes.

Los simulacros de rollback deben cubrir un rollback tras un commit de DV, la disponibilidad continua de su archivo Puffin, la aplicación de position deletes más antiguos y las garantías de eliminación en el nuevo snapshot. Conserve el id de solicitud, el id de snapshot confirmado y los resultados de verificación en el registro de auditoría sin incluir datos personales en los logs.

7. Establecer controles de compatibilidad y observabilidad

Antes del lanzamiento, construya una matriz para lectores v2, lectores v3, trabajos por lotes, lectores de streaming y herramientas de mantenimiento. Pruebe el comportamiento de equality, position y DV para cada uno. Rastree fallas en la aplicación de DV, archivos de datos sin coincidencia, crecimiento de manifiestos de eliminación, reintentos por conflicto, fallas en snapshots antiguos y acumulación de trabajo de compactación pendiente.

Durante el despliegue, compare los resultados de lectores antiguos y nuevos en el mismo snapshot: recuentos de filas, conjuntos de claves y valores muestreados. Si un lector antiguo no puede interpretar una eliminación v3, detenga las escrituras de DV o cambie a un formato compatible en lugar de expandir el radio de impacto.

Ejemplo de respuesta de alta calidad

Comenzaría con la semántica de eliminación y la matriz de lectores. Las eliminaciones basadas en claves usan equality deletes. Si la solicitud ya identifica un archivo de datos y una posición de fila y se requiere compatibilidad con v2, los position deletes son adecuados. Una vez que la tabla es v3 y las eliminaciones se concentran en un archivo de datos, consolidaría las posiciones en un deletion vector. Un DV es un mapa de bits por archivo, con como máximo un DV para ese archivo de datos en un snapshot, y crear uno nuevo debe fusionar los position deletes existentes.

Los lectores no pueden depender únicamente de la ruta del archivo. Deben validar referenced_data_file, la especificación de partición y sus valores, y que el número de secuencia del archivo de datos no sea mayor que el número de secuencia del DV; el desplazamiento y la longitud del blob deben provenir del manifiesto de eliminación. Los escritores utilizan concurrencia optimista de snapshots, releen los metadatos actuales ante conflictos y nunca reintentan con un mapa de bits obsoleto.

Antes de la migración, verificaría el soporte para v3, Puffin y DV en cada lector y mantendría un interruptor de apagado para las escrituras de DV. La aceptación cubre visibilidad en el snapshot actual, time travel, eliminaciones concurrentes, rollback, compactación, comparación con lectores antiguos y evidencia de cumplimiento. El rendimiento compara bytes escaneados, tiempo de manifiestos, tamaño de DV, CPU de compactación y latencia de extremo a extremo. Con una alta densidad de eliminaciones, reescribir el archivo de datos puede ser mejor que acumular más DVs.

Errores comunes

• Tratar un DV como un equality delete comprimido e ignorar la semántica de coincidencia.
• Afirmar que Iceberg v2 puede escribir deletion vectors.
• Aplicar un DV solo por la ruta del archivo, sin comprobaciones de partición y número de secuencia.
• Mantener múltiples DVs para un archivo de datos o no fusionar position deletes más antiguos.
• Actualizar el catálogo sin probar cada lector y herramienta de mantenimiento.
• Usar una sola ejecución de compactación como respuesta universal sin comparar la amplificación de lectura y escritura.
• Limpiar manifiestos de eliminación de una manera que rompa los snapshots retenidos de time travel.
• Poner datos personales en logs y llamarlo evidencia de eliminación.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no permitir que los lectores v2 ignoren los DVs?

Ignorar los metadatos de eliminación puede devolver filas que ya fueron eliminadas, creando un fallo silencioso de corrección. Complete primero una matriz de capacidades y una comparación de resultados, luego elija migración, escrituras compatibles o una pausa en las escrituras de DV.

Pregunta de seguimiento 2: ¿Cuándo se debe reescribir un archivo cuyas eliminaciones siguen aumentando?

Establezca un umbral utilizando densidad de eliminación, tamaño del mapa de bits, CPU de escaneo, latencia de consultas y presupuesto de compactación. Por encima de este, reescriba el archivo de datos, elimine su DV aplicable en un nuevo snapshot y verifique la directiva de retención de time travel.

Pregunta de seguimiento 3: ¿Qué es lo más fácil de pasar por alto durante un reintento de conflicto?

Releer los manifiestos de eliminación más recientes y el número de secuencia de datos. Cada reintento debe fusionarse contra los metadatos actuales de la tabla y registrar el conflicto junto con el id del snapshot final.

Pregunta de seguimiento 4: ¿Cómo se demuestra la eliminación regulatoria?

Conserve el alcance de la solicitud, el id del snapshot confirmado, el resultado de la consulta en el snapshot actual, las comprobaciones de copias descendentes y el estado de mantenimiento. Indique explícitamente el período de retención de time travel y mantenga los datos personales fuera de los logs.

Pregunta de seguimiento 5: ¿Cuándo es preferible un equality delete?

Cuando los eventos contienen únicamente claves de negocio, los archivos se reescriben con frecuencia o un solo predicado debe cubrir muchos archivos, los equality deletes son más directos. Aun así, mida el costo de coincidencia durante el escaneo y defina una política de reescritura.