El proyecto Apache Iceberg publicó el 30 de septiembre la versión 1.12.0, con más de 800 cambios fusionados. Es la primera entrega que incorpora trabajo sustancial de la especificación del formato v4, aunque el propio proyecto avisa de que eso no equivale a una v4 lista para producción y recomienda no migrar cargas reales todavía. La votación de la release salió adelante en la segunda candidatura: la primera cayó por un fallo de auditoría de licencias.
Los cambios que rompen compatibilidad son los que marcan el calendario de actualización. Desaparece el soporte de Spark 3.4 —las versiones compatibles pasan a ser 3.5.9, 4.0.4, 4.1.3 y 4.2— y se retira Flink 2.0, con 1.20, 2.1, 2.2 y 2.3 como versiones vivas. Los escritores Java dejan de generar ficheros de position delete con valores de fila embebidos: los que ya existen siguen siendo legibles, pero las operaciones de mantenimiento rewrite_position_delete_files y rewrite_table_path los rechazan para no alterar la semántica. También se eliminan APIs marcadas como obsoletas en Core, Data, Spark, Flink y Kafka Connect.
En el apartado funcional, las capacidades de la v3 maduran: el tipo variant gana lectura vectorizada de Parquet en Spark, soporte Avro en Flink y shredding de Parquet en varios motores; los tipos geometry y geography se mapean a tipos lógicos de Parquet con serialización WKB y métricas de caja envolvente. El catálogo REST añade endpoint para desregistrar tablas sin borrar ficheros, listado y carga de funciones, delegación del purgado en el catálogo mediante rest.catalog-purge y etiquetas de metadatos. En streaming, Flink evita los commits duplicados cuando se reinicia un trabajo y Kafka Connect deja de tragarse en silencio los fallos de commit, que ahora afloran con métricas y reintentos acotados. Spark suma agrupación por curva de Hilbert como alternativa a bin-packing y Z-order en rewrite_data_files.
Para quien opera un lakehouse, la lectura es de planificación más que de novedades. Iceberg es la pieza sobre la que se apoyan los catálogos REST y las plataformas de Snowflake, Databricks y Fabric, así que una versión que retira motores y cambia el comportamiento de los position deletes obliga a escalonar la subida por riesgo de escritor: primero los lectores sin estado, después los escritores de bajo volumen, luego los trabajos de streaming y al final las tareas de mantenimiento. Los equipos que sigan en Spark 3.4 o Flink 2.0 tienen deberes previos. Y conviene mirar ya hacia la v4: la comunidad votó prohibir los nuevos equality deletes en ese formato, lo que simplifica el diseño para quien construye motores pero cambia las reglas de los escritores de streaming.
Más en Dataprix: guía de arquitectura de datos
Fuente: Apache Iceberg (notas de la versión 1.12.0)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.