Pregunta y escenario
Diseñe una extensión de búsqueda vectorial para una tabla de Iceberg. Los archivos de datos conservan los datos de las filas y el motor de consultas lee un snapshot; el índice vectorial reside en archivos sidecar de Puffin y se referencia mediante los metadatos del snapshot. El diseño debe admitir consultas de vecinos más cercanos aproximados sin romper el aislamiento de snapshots, el time travel ni el mantenimiento de los archivos de datos.
Asuma adiciones por lotes (batch appends) diarias y pequeñas actualizaciones. Los resultados aproximados solo son aceptables cuando la versión del índice es visible para el emisor de la consulta. Distinga las capacidades del formato de archivo Apache Puffin de una estructura de ANN particular propuesta por investigaciones; un diseño de grafo experimental no constituye automáticamente el comportamiento nativo de Iceberg.
Qué está evaluando el entrevistador
Consistencia entre snapshots e índices
Una respuesta sólida vincula el snapshot de datos, el blob de Puffin y los metadatos del índice en un único commit visible. Subir un archivo de índice por sí solo no lo hace consultable.
Búsqueda aproximada y poda de archivos
Explique que el índice vectorial recupera candidatos, mientras que las comprobaciones finales de distancia y visibilidad siguen leyendo las filas de datos. Maneje explícitamente los índices faltantes, obsoletos y con bajo recall.
Mantenimiento incremental y eliminaciones
Cubra adiciones, actualizaciones, eliminaciones, fusiones (merges) y compactaciones. No se limite únicamente a una construcción offline puntual.
Operabilidad con cómputo y almacenamiento desagregados
Indique cómo el almacenamiento de objetos guarda Puffin, cómo un coordinador programa los shards, cómo se limita la acumulación de basura y cómo se monitorean la frescura y los mecanismos de fallback.
Preguntas de aclaración antes de responder
- ¿Cuáles son la dimensión de los embeddings, la función de distancia, la latencia de consulta y el recall mínimo?
- ¿Debe una consulta usar el snapshot más reciente o es aceptable un retraso de índice delimitado?
- ¿Son las actualizaciones y eliminaciones CDC de solo adición (append-only), equality deletes de Iceberg o reescrituras de archivos de datos?
- ¿Hay un solo motor construyendo el índice o deben compartirlo Spark, Flink y Trino?
- ¿Son sensibles los vectores y quién gestiona el control de acceso y el cifrado?
- ¿Deben las consultas de time-travel reutilizar índices históricos o solo se requiere indexar para el snapshot actual?
Marco de respuesta de 30 segundos
“Mantendría separados los archivos de datos de Iceberg, los blobs de índice de Puffin y los metadatos de snapshots, pero publicaría la vinculación en un único commit para un solo snapshot ID. Una consulta elige un snapshot visible, lee sus referencias de índice, realiza la recuperación aproximada de candidatos mediante ANN y luego valida las versiones de fila y las distancias exactas a partir de los archivos de datos. Los índices faltantes u obsoletos recurren a escaneos de particiones o archivos y exponen el estado de calidad. Las adiciones pueden crear índices delta; las actualizaciones y eliminaciones se filtran mediante tombstones o capas de borrado; la compactación reconstruye una línea base. Los trabajos de indexación utilizan commits optimistas de snapshot, y monitoreamos la frescura, muestras de recall, tasa de fallback y la basura de Puffin”.
Respuesta detallada paso a paso
Paso 1: Estimar los límites de datos e índices
Como suposición ilustrativa, 1000 millones de vectores con 768 dimensiones float32 requieren 1000 millones por 768 por 4 bytes, aproximadamente 3 TB para los vectores en bruto antes de la compresión columnar o la sobrecarga del índice. La estimación descarta colocar el índice en un solo manifiesto o en la memoria del coordinador; debe particionarse (shard) en el almacenamiento de objetos y cargarse según la partición de la consulta.
Paso 2: Vincular Puffin a un snapshot
Puffin almacena blobs de índices o estadísticas que un manifiesto de Iceberg no puede transportar directamente. Cada blob incluye metadatos como tipo, campos, partición o referencias a archivos de datos. Un constructor de índices escribe Puffin y luego confirma un nuevo snapshot de Iceberg cuyo resumen registra la ubicación del índice, la versión y la cobertura. Un lector acepta una referencia solo cuando es visible con ese snapshot.
snapshot S42
data files: D100, D101
summary:
vector.index.version = v7
vector.index.puffin = s3://table/metadata/puffin-v7
vector.index.covers = D100,D101Paso 3: Diseñar la ruta de consulta
Resuelva la rama actual o la solicitud de time-travel hacia el snapshot S, luego seleccione los blobs de Puffin según la cobertura. Un grafo o shard de ANN devuelve identificadores de fila candidatos y distancias aproximadas. El motor lee esos archivos de datos, comprueba la visibilidad de las filas en S, aplica la autorización y los predicados, y recalcula las distancias exactas. Devuelva snapshotid e indexversion para que los emisores puedan razonar sobre la frescura.
Paso 4: Manejar adiciones, actualizaciones y eliminaciones
Las adiciones pueden escribir un índice delta de Puffin y declarar sus archivos en el mismo commit de snapshot. Antes de una reconstrucción, las actualizaciones o eliminaciones filtran los candidatos antiguos con equality deletes, position deletes o un tombstone delta; una consulta nunca debe devolver una fila eliminada. Fusione los índices delta en una nueva línea base en segundo plano y luego publique atómicamente una nueva vinculación de snapshot. En caso de fallo, mantenga el índice anterior y la ruta de fallback.
Paso 5: Manejar commits concurrentes y compactación
Un trabajo de indexación lee la línea base S42 y construye v7. Si un commit de datos avanza la tabla a S43, la concurrencia optimista decide si reintentar, fusionar un delta o descartar v7. Cuando la compactación cambia las rutas de los archivos de datos, el índice antiguo no puede reclamar cobertura sobre los nuevos archivos. Construya un nuevo blob vinculado al conjunto de archivos reescrito y luego recolecte la basura del blob antiguo después del seguimiento de referencias y un período de gracia.
Paso 6: Operar, aislar y realizar fallback
El almacenamiento de objetos guarda Puffin; un coordinador programa las construcciones por partición o conjunto de archivos; los nodos de consulta almacenan en caché estructuras pequeñas de enrutamiento o centroides. Blobs faltantes, versiones incompatibles, fallos de autorización o muestras de bajo recall desencadenan un fallback a escaneo de archivos o una respuesta que contiene únicamente candidatos verificados y un motivo. Rastree la frescura del índice, el retraso de construcción, el p95 de consultas, muestras de recall, bytes de Puffin, tasa de fallback y blobs sin referenciar.
Ejemplo de respuesta de alta calidad
“Mantendría las columnas vectoriales en los archivos de datos de Iceberg, escribiría las estructuras de ANN en Puffin y publicaría sus referencias como parte de un snapshot. Con una suposición ilustrativa de 1000 millones de vectores float32 de 768 dimensiones, los vectores en bruto ocupan unos 3 TB, por lo que el índice debe particionarse en almacenamiento de objetos en lugar de mantenerse en un coordinador.
El constructor lee S42, crea Puffin v7 cubriendo D100 y D101, y utiliza un commit optimista para publicar un nuevo snapshot. Una consulta fija el snapshot para una solicitud de time-travel, lee solo los índices declarados para ese snapshot y valida la visibilidad de los candidatos, la autorización y la distancia exacta leyendo los archivos de datos. Mientras el índice esté desactualizado, las adiciones usan índices delta y las actualizaciones o eliminaciones se filtran mediante archivos de eliminación o tombstones; la compactación reconstruye posteriormente la línea base.
Si la tabla ha avanzado a S43, v7 no puede considerarse actual sin un reintento o un marcador explícito de obsolescencia. Blobs faltantes, formatos incompatibles o bajo recall desencadenan un fallback a escaneo, con snapshotid, indexversion y el motivo en las métricas. Reclame el Puffin antiguo solo después de que ningún snapshot o rama histórica lo referencie”.
Errores comunes
- Tratar a Puffin como un nuevo formato de tabla principal → la consulta no puede demostrar qué versión de datos cubre un índice → vincule la cobertura a un snapshot.
- Hacer que un índice subido sea inmediatamente legible → los archivos de datos y el índice pueden pertenecer a diferentes snapshots → publique la referencia en un único commit optimista.
- Devolver candidatos de ANN directamente → eliminaciones, permisos o errores de distancia filtran filas incorrectas → vuelva a comprobar la visibilidad y recalcule la distancia exacta.
- Seguir utilizando el grafo antiguo tras actualizaciones → pueden recuperarse filas eliminadas → filtre con capas de borrado, fusione deltas y reconstruya una línea base.
- Reutilizar rutas de archivos antiguas después de la compactación → el índice afirma cubrir archivos que ya no existen → construya un nuevo blob y snapshot para el conjunto reescrito.
- Tratar una disposición de grafo de investigación como estándar de Puffin → los motores no pueden interoperar → use Puffin para almacenamiento y metadatos, manteniendo reemplazable el algoritmo de grafo.
- Fallar cada consulta cuando falta un índice → el servicio no está disponible durante el despliegue de una nueva partición → use escaneo como fallback y exponga la frescura y el motivo.
- Eliminar Puffin sin seguimiento de referencias → se rompen las lecturas de time-travel o de ramas → espere a que cada snapshot, rama y período de gracia lo liberen.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cómo garantiza el índice correcto para time travel?
Almacene la referencia en el resumen del snapshot correspondiente junto con su cobertura de archivos y versión. Fije primero el snapshot, rechace los blobs que cubran archivos posteriores o diferentes, y escanee ante la ausencia en lugar de usar silenciosamente el índice actual.
Pregunta de seguimiento 2: ¿Creará un flujo grande de actualizaciones índices delta ilimitados?
Establezca un límite de capas delta por partición o conjunto de archivos y programe una reconstrucción de fusión cuando se supere. Cambie atómicamente a un nuevo snapshot tras la fusión, conservando los deltas antiguos hasta que los snapshots históricos dejen de referenciarlos.
Pregunta de seguimiento 3: ¿Pueden dos motores intercambiar sus índices ANN?
Solo cuando el tipo de blob, la función de distancia, la codificación de vectores, el identificador de fila y el protocolo de versiones sean compatibles. Puffin define el contenedor y el límite de metadatos; el grafo necesita una declaración de capacidades. De lo contrario, ignórelo y aplique fallback.
Pregunta de seguimiento 4: ¿Cómo mide el recall sin escanear toda la tabla?
Tome muestras de un pequeño conjunto de consultas en vivo y compute offline una aproximación de ground truth con búsqueda exacta o una línea base confiable. Compare recall@k por partición, versión de vector y función de distancia. Marque un índice como obsoleto cuando las muestras caigan por debajo del umbral en lugar de limitarse a vigilar el p95.
Pregunta de seguimiento 5: ¿Qué sucede si un archivo Puffin o el almacén de objetos no están disponibles temporalmente?
Verifique los checksums y metadatos de los blobs, reintente desde una réplica y luego escanee o rechace la búsqueda aproximada con un estado explícito tras agotar el tiempo de espera (timeout). Nunca publique un nuevo snapshot que referencie un blob corrupto.
Fuente 1: Especificación de Apache Puffin
La especificación de Puffin define un formato de archivo para índices y estadísticas que no se pueden almacenar directamente en los manifiestos de Iceberg, incluidos metadatos de blobs y referencias a archivos de datos. Eso respalda el límite de sidecar, cobertura y snapshot en esta respuesta.
Fuente 2: Investigación sobre índices vectoriales respaldados por Puffin
El artículo de 2026 propone adjuntar estructuras de vecinos más cercanos aproximados a snapshots de Iceberg y analiza la desagregación de cómputo y almacenamiento, la gestión de índices a nivel de snapshot y entornos de miles de millones de vectores. Esta respuesta lo trata como una implementación de investigación reemplazable y añade límites de eliminación, fallback y commits concurrentes.
Fuente 3: Guía de preparación para entrevistas de ingeniería de datos
La guía pública de ingeniería de datos destaca SQL, modelado de datos, pipelines, sistemas por lotes y de streaming, y confiabilidad. La respuesta asigna esas señales a la consistencia de snapshots, mantenimiento de índices, particionamiento (sharding), verificación y fallback ante fallos.