Tema representativo de entrevista

Entrevista de ingeniería de datos: ¿Cómo usarías los deletion vectors de Iceberg para eliminaciones a nivel de fila?

DatosDifícil
Equipo editorial de Offer.ccPublicado Actualizado

Pregunta

Una tabla de Iceberg necesita la eliminación frecuente de filas de usuarios mientras las consultas permanecen disponibles. Explica los límites de los deletion vectors y otros archivos de eliminación a nivel de fila, los commits concurrentes y el filtrado de lectura, así como un plan de migración entre motores y limpieza física.

Prompt y contexto

Un event lake añade miles de millones de filas diariamente y recibe solicitudes continuas de eliminación de usuarios. El equipo desea usar deletion vectors de Iceberg v3 para evitar reescribir archivos de datos en cada eliminación. Explica en qué se diferencian de los position deletes y equality deletes, y diseña la consistencia de snapshots, la compatibilidad de lectores y la limpieza física final.

Qué evalúa el entrevistador

  • Comprender que un deletion vector es un marcador lógico de posición de fila, no el borrado inmediato de los bytes en el almacenamiento de objetos.
  • Comparar las tres representaciones de eliminación según la amplificación de escritura, el costo de lectura y el límite de alcance.
  • Diseñar commits atómicos de snapshots, fusiones concurrentes, mecanismos de reserva (fallback) para lectores antiguos y compactación.
  • Vincular la evidencia de privacidad con la corrección de consultas, las copias de seguridad y la retención de replicación.

Preguntas para clarificar

  1. ¿Todos los escritores, catálogos, motores de consulta y SDK admiten Iceberg v3 y deletion vectors?
  2. ¿Las eliminaciones se identifican mediante posiciones estables, claves de negocio o coincidencias a través de archivos?
  3. ¿Cuánto tiempo pueden permanecer las eliminaciones lógicas y cuándo expiran las versiones de objetos, las copias de seguridad y las réplicas?
  4. ¿Cómo carga el motor los archivos de eliminación y su clave de caché incluye el ID de snapshot?
  5. ¿Puede la compactación entrar en condición de carrera con escrituras en streaming, expiración de snapshots o eliminaciones por privacidad?

Respuesta de 30 segundos

Trataría un deletion vector como una capa lógica dentro de un snapshot: cada archivo de datos puede referenciar un vector que marca las posiciones de las filas eliminadas; las lecturas filtran esas filas, mientras que el archivo físico se reescribe más tarde mediante una compactación controlada. Los position deletes también identifican posiciones, pero comúnmente utilizan archivos de eliminación separados. Los equality deletes coinciden con valores de columna, lo cual es flexible pero puede escanear más datos. Verificaría el soporte para v3, usaría commits atómicos de snapshots, proporcionaría una vía de compatibilidad para lectores antiguos y alinearía la compactación, la expiración, las copias de seguridad y las réplicas con un único SLA de eliminación.

Respuesta detallada

Paso 1: Definir la semántica de eliminación

Un deletion vector es un mapa de bits o una estructura equivalente asociada a un archivo de datos que marca posiciones eliminadas. Oculta filas de un snapshot lógico, pero no prueba que los bytes del almacenamiento de objetos se hayan borrado, por lo que la eliminación por privacidad también requiere reescritura, expiración y gobernanza de copias de seguridad.

Paso 2: Comparar las tres representaciones

Los position deletes indican una posición en el archivo y son adecuados para escritores que ya conocen el archivo y la fila. Los equality deletes coinciden con valores de columna y son adecuados para CDC o eliminaciones por clave de negocio, pero los lectores pueden escanear más archivos. Un deletion vector concentra las marcas de posición por cada archivo de datos, reduciendo la cantidad de archivos de eliminación pequeños mientras traslada el costo del filtrado y el mantenimiento de vectores a la ruta de lectura.

Paso 3: Establecer el límite del snapshot

Las referencias a los vectores se confirman atómicamente con un snapshot de Iceberg y registran la ruta del archivo de datos, la ubicación del vector, el tamaño, la suma de comprobación (checksum) y la versión del formato. Un generador lee un snapshot de entrada fijo y nunca muta un vector existente in situ. Ante un conflicto concurrente, se fusiona a partir del snapshot más reciente en lugar de sobrescribir otra eliminación.

Paso 4: Diseñar la ruta de lectura

El planificador lee los manifiestos y los metadatos del snapshot, y luego carga los vectores aplicables. Si un vector falta, está corrupto o no es compatible, el resultado seguro es rechazar el snapshot o recurrir a una representación de eliminación confiable; tratar el error como "sin eliminaciones" filtra filas no deseadas. Una clave de caché incluye la tabla, el archivo de datos, el ID de snapshot y la versión del vector.

Paso 5: Planificar la compactación y la limpieza

Cuando la densidad de vectores, la amplificación de lectura aleatoria o la proporción de eliminaciones crucen un umbral medido, reescribe las filas sobrevivientes en nuevos archivos de datos y elimina los archivos antiguos y los vectores en un nuevo snapshot. El ciclo de vida del almacenamiento de objetos, las copias de seguridad, las réplicas y la expiración de snapshots deben cumplir con el mismo SLA de eliminación; eliminar un puntero de catálogo no es evidencia de borrado físico.

Paso 6: Migrar lectores antiguos

Haz un inventario de la versión de formato, el soporte de archivos de eliminación y el comportamiento de la caché de cada motor. Un lector antiguo puede consumir temporalmente snapshots de compatibilidad representados mediante position o equality deletes, o utilizar una vista materializada. No publiques un snapshot que contenga vectores a un lector que no pueda interpretarlo.

Paso 7: Verificar la corrección y el cumplimiento

Prueba eliminaciones concurrentes y duplicadas, actualizaciones posteriores a la eliminación, reversión (rollback) de snapshots, vectores corruptos y compactación interrumpida. Para cada snapshot, compara los hashes de resultados con y sin la optimización, realiza muestreos para comprobar que las filas eliminadas sean invisibles y registra el tiempo de retención final de los archivos de datos, copias de seguridad y réplicas.

Respuesta modelo

Primero demostraría que todos los lectores procesan Iceberg v3 y deletion vectors. Una transacción de eliminación fija un snapshot base, construye un vector de posiciones de fila por cada archivo de datos y confirma atómicamente las referencias con un nuevo snapshot; en caso de conflicto, vuelve a leer y fusiona el snapshot más reciente. Las lecturas cargan vectores según el ID de snapshot. Los vectores faltantes o no compatibles detienen la publicación o recurren a un archivo de eliminación confiable, nunca a un vector vacío. Una vez que la densidad supera un umbral medido, la compactación reescribe las filas sobrevivientes y los archivos antiguos, snapshots, copias de seguridad y réplicas expiran bajo un único SLA de eliminación. La aceptación abarca eliminaciones concurrentes, vectores corruptos, rollback y recuperación interrumpida, compara hashes de resultados y genera evidencia de limpieza física.

Errores comunes

  • Tratar un deletion vector como un borrado inmediato en el almacenamiento de objetos.
  • Sobrescribir un vector existente in situ sin control de versiones y snapshots.
  • Permitir que un lector exclusivo de v2 consuma un snapshot con vectores esperando que lo ignore.
  • Declarar una eliminación conforme a las normas tras borrar únicamente un puntero de catálogo.
  • Ejecutar la compactación sin comprobar los snapshots concurrentes, perdiendo escrituras o eliminaciones.

Preguntas y respuestas de seguimiento

Pregunta de seguimiento 1: ¿Por qué no usar siempre equality deletes?

Expresan bien la eliminación por claves de negocio, pero las lecturas pueden requerir comprobaciones en muchos archivos. Cuando se conocen las posiciones físicas y las eliminaciones son frecuentes, los vectores pueden reducir la sobrecarga de archivos de eliminación. Mide el soporte del lector y el costo de consulta antes de elegir.

Pregunta de seguimiento 2: ¿Puede un vector corrupto devolver datos no filtrados?

No. Eso expondría filas eliminadas. Valida la suma de comprobación y la versión, rechaza el snapshot o recurre a una representación confiable, y emite una alerta para su reparación.

Pregunta de seguimiento 3: ¿Cómo interactúan los vectores con las actualizaciones?

Una actualización suele escribir un nuevo archivo de datos y marcar la fila antigua como eliminada. Confirma el nuevo archivo y la referencia de eliminación en un solo snapshot para que los lectores vean la fila antigua o la nueva, nunca ambas.

Pregunta de seguimiento 4: ¿Cómo se define un umbral de compactación?

Mide la proporción de eliminaciones, el tamaño del vector, la amplificación de lectura aleatoria, la latencia de escaneo y el costo de almacenamiento bajo cargas de trabajo representativas. No elijas un umbral basándote únicamente en el recuento de archivos.

Pregunta de seguimiento 5: ¿Cómo se demuestra la eliminación por privacidad?

Proporciona comprobaciones de invisibilidad a nivel de fila, registros de snapshots expirados, manifiestos de archivos reescritos, resultados de eliminación de versiones de objetos, retención de copias de seguridad y réplicas, y escaneos por muestreo sin coincidencias.

Fuentes públicas

Preguntas relacionadas