Entrevista de ingeniería de datos: ¿Cómo preserva el linaje de filas de Iceberg v3 la identidad de las filas?

Prompt y alcance

Una tabla de eventos de Iceberg v3 debe admitir CDC, recálculo y auditoría entre snapshots. El equipo desea una identidad de fila rastreable y el commit que actualizó por última vez cada fila. Explique los campos de linaje de filas, los tiempos de herencia, los reintentos de commits, los límites de equality-delete y la verificación.

Qué está evaluando el entrevistador

• Si comprende la herencia de _row_id y _last_updated_sequence_number en lugar de inventar valores en el momento de la escritura.
• Si puede conectar first-row-id, next-row-id y los manifiestos.
• Si maneja reintentos de commits optimistas, escritores concurrentes y lectores antiguos.
• Si separa el linaje de filas, las claves de negocio, los equality deletes y la limpieza física.

Preguntas de clarificación para hacer

1. ¿Necesitamos identidad física de fila, identidad de entidad de negocio o ambas?
2. ¿Todos los lectores admiten Iceberg v3 y cuál es el mecanismo de fallback para motores antiguos?
3. ¿Las actualizaciones son copy-on-write, merge-on-read o equality deletes?
4. ¿Se requiere auditoría a través de snapshots o solo en la versión actual de la tabla?

Estructura de respuesta de 30 segundos

Iceberg v3 utiliza _row_id para la identidad de fila de la tabla y _last_updated_sequence_number para el commit de la última actualización. Los lectores los heredan a partir del first-row-id de un archivo de datos, la posición de la fila y el número de secuencia del manifiesto. Los escritores pueden emitir campos nulos antes del commit, por lo que un reintento debe volver a leer los metadatos y asignar un nuevo first-row-id. El linaje de filas no es una clave de negocio, y los equality deletes no preservan el ID de fila anterior. Establezca una matriz de capacidades v2/v3 y luego pruebe snapshots, conflictos y reintentos.

Análisis detallado paso a paso

1. Separar las identidades

Una clave de negocio indica qué entidad representa un registro; _row_id identifica una fila en esta tabla. Si una entidad se elimina y se escribe de nuevo, su clave de negocio puede repetirse mientras que su linaje de fila no debe tratarse como un ID de entidad permanente. La auditoría debe conservar la clave de negocio, el ID de snapshot y el ID de fila juntos.

2. Comprender la herencia de campos

El _row_id y _last_updated_sequence_number de una nueva fila pueden ser nulos en el archivo de datos. En la lectura, el ID de fila se deriva del first-row-id del archivo más la posición de la fila, mientras que la secuencia de actualización proviene de la entrada del manifiesto. Esto permite que los escritores eviten reescribir archivos de datos antes de que un commit tenga éxito.

row_id = data_file.first_row_id + row_position
last_updated = manifest_entry.data_sequence_number

3. Manejar los reintentos de commit

Después de un conflicto optimista, el next-row-id de la tabla puede haber cambiado. Un reintento debe volver a leer los metadatos actuales, asignar un nuevo first-row-id y reconstruir la lista de manifiestos; no puede reutilizar el rango del primer intento. Registre el intento, el motivo del conflicto y el ID de snapshot final.

4. Límite de equality-delete

Un motor de equality-delete comúnmente escribe cambios sin leer las filas de datos antiguas, por lo que no puede proporcionar el ID original de la fila reemplazada. La especificación trata dicha actualización como la eliminación de la fila antigua y la adición de una nueva fila única. Conserve las claves de negocio y los eventos de cambio por separado cuando la identidad de la entidad sea importante.

5. Compatibilidad y lecturas

El linaje de filas es una capacidad de v3, y es posible que los lectores antiguos no comprendan sus campos reservados. Antes de actualizar, cree una matriz de motores y verifique si un lector antiguo ve nulos, ignora los campos o falla. Las exportaciones no deben depender de que todos los lectores deriven los ID de fila; un servicio compatible con v3 puede materializar primero los campos de auditoría.

6. Verificación, rollback y limpieza

Pruebe una escritura única, commits concurrentes, reintentos de conflicto, lecturas de snapshots, eliminación y reescritura, y compactación. Verifique la unicidad del ID de fila en cada snapshot, la no reutilización de un rango obsoleto y la alineación entre los números de secuencia y el snapshot final. El rollback cambia la referencia del snapshot en lugar de reescribir los ID históricos; la limpieza física sigue perteneciendo a la expiración de snapshots y la limpieza de huérfanos.

Respuesta modelo de alta calidad

Mantendría las claves de negocio separadas del linaje de filas de Iceberg. En v3, _row_id y _last_updated_sequence_number proporcionan la identidad de la fila de la tabla y el orden de commit, heredados de first-row-id, la posición de la fila y el número de secuencia del manifiesto en el momento de la lectura. Los escritores dejan los campos nulos antes del commit; los reintentos por conflicto vuelven a leer los metadatos y asignan un nuevo rango en lugar de reutilizar un manifiesto antiguo. Los equality deletes no garantizan el ID de la fila anterior, por lo que los datos de auditoría también almacenan claves de negocio, ID de snapshots y eventos de cambio. Antes del despliegue, pruebe lectores v2/v3, conflictos, lecturas de snapshots, compactación y limpieza, limitando el rollback a cambiar referencias de snapshots.

Errores comunes

• Tratar el ID de fila como una clave de negocio → la semántica de eliminación y reescritura se rompe → conserve ambas identidades.
• Asignar ID de fila permanentes mientras se escriben archivos → los reintentos pueden duplicar o desperdiciar rangos → confíe en la herencia en el momento del commit.
• Reutilizar un manifiesto en conflicto → contiene un next-row-id obsoleto → vuelva a leer los metadatos en cada reintento.
• Asumir que los equality deletes preservan los ID de fila → la especificación no lo garantiza → rastree entidades con eventos de negocio.
• Validar solo la consulta actual → los snapshots y los lectores antiguos siguen siendo un riesgo → pruebe el comportamiento entre snapshots y las capacidades.

Preguntas de seguimiento y respuestas

¿Por qué no reemplazar _row_id con una clave de negocio?

Las claves de negocio pueden repetirse, cambiar o no ser únicas entre tablas. El linaje de filas es la identidad de la fila de la tabla; ambos responden a diferentes preguntas de auditoría y deben conservarse juntos.

¿Pueden los reintentos por conflicto dejar brechas en los ID de fila?

Pueden existir rangos no utilizados, dependiendo de la implementación. La regla de seguridad es nunca reutilizar ID expuestos por un snapshot exitoso y mantener los ID únicos en el snapshot final.

¿La compactación cambia los ID de fila?

Una implementación correcta preserva la identidad a través de la herencia de linaje. Verifique el mapeo de auditoría antes y después de la compactación para la misma semántica de snapshot; las rutas de archivos por sí solas son insuficientes.