Resumen de la lista de desarrollo de Apache Iceberg 8–12 sept 2025: durante esa semana la comunidad centró debates técnicos y decisiones de gobernanza clave mientras avanzaba la preparación y el lanzamiento de la serie 1.10.0.
V1 manifests y tablas V3 Christian Thiel reportó un caso no controlado al actualizar tablas V1 a V3 en la implementación Rust: algunos manifiestos antiguos no contienen existing_rows_count ni added_rows_count y al agregarlos a un snapshot en una tabla V3 provocaban NullPointerException. Christian y Russell Spitzer propusieron que Iceberg valide y falle claramente ante cuentas de filas faltantes en lugar de lanzar NPEs. Se comentó que el problema solo afecta tablas muy antiguas, pues los clientes V1 modernos ya escriben esos campos. La recomendación fue emitir un error claro y priorizar la funcionalidad RepairMetadata para reescribir manifiestos afectados, sin necesidad de cambiar la especificación.
API FileFormat continuaron las discusiones sobre el diseño de la nueva API FileFormat. Renjie Liu apoyó la primera aproximación basada en writers específicos de formato y opinó que el API converter para escrituras vectorizadas era innecesario. Péter Vár explicó que el converter solo se necesita para escribir position-delete en tablas V2 y que no hay planes para soportar escrituras vectorizadas, proponiendo retirar el converter tras la deprecación de position-delete-with-row-data. Se debatió si mantener dos firmas distintas o una sola con excepciones para position-deletes. Péter propuso finalmente cuatro métodos para un FormatModelRegistry: un builder genérico y builders para datos, equality deletes y position deletes, y abrió la pregunta de cuánto debe delegar cada motor en lógica específica.
FGAC OpenAPI Robert Stupp resumió el consenso sobre el control de acceso fino REST OpenAPI: la comunidad acordó usar expresiones de Iceberg y funciones definidas por el usuario como el único mecanismo para devolver instrucciones de protección. Esto separa definición de políticas y aplicación, evita especificar planes de consulta dentro de políticas y exige que los catálogos ofrezcan instrucciones de protección específicas por usuario y consulta. Robert indicó que actualizaría la propuesta OpenAPI acorde al consenso.
Limpieza de issues en Iceberg Rust Micah Kornfield propuso copiar la configuración de PyIceberg para marcar y cerrar automáticamente issues inactivos en el repositorio Iceberg-Rust. La propuesta recibió apoyo y sugerencias para probar la configuración también en pull requests. Se solicitó a un committer revisar y fusionar el PR para activar el bot.
Dependencias opcionales en PyIceberg André Luis Anastácio señaló problemas por las dependencias opcionales de terceros en PyIceberg como pandas, polars, duckdb y ray. Estas integraciones y helpers de conversión enlazan PyIceberg a versiones concretas de bibliotecas, provocando conflictos de versiones en ecosistemas con dependencias diferentes. Fokko Driesprong defendió que PyIceberg busca ser una capa de conveniencia y que Arrow es una dependencia central, pero reconoció la tensión entre actualizar agresivamente y soportar usuarios con versiones antiguas.
Deprecación de position deletes con row data Péter Vár llamó a votación para deprecar los position-delete que incluyen row data, una característica de V2 poco usada. La comunidad mayoritariamente apoyó la deprecación: se eliminaría la escritura de row-data deletes en Iceberg 2.0 mientras se mantendría lectura para compatibilidad hacia atrás. Se abrió un hilo de votación específico para aprobar la deprecación.
Iceberg 1.10.0 RC5 y lanzamiento El 11 de septiembre Steven Wu pidió votar la RC5 de Apache Iceberg 1.10.0 y en pocas horas la votación pasó con varios +1 vinculantes y sin objeciones, oficializando RC5. Steven publicó luego el anuncio de lanzamiento agradeciendo a los contribuyentes y destacando novedades como soporte de formato V3, mejoras en lecturas vectorizadas y nuevos endpoints REST para catálogos. La comunidad celebró y alentó a actualizar.
Reintroducción de added_rows en snapshots Steven Wu abrió un debate sobre volver a incluir el campo added_rows en metadata de snapshots. Había sido eliminado en RC5 para reducir el tamaño de los manifiestos, pero algunos desarrolladores defienden su utilidad para escaneos incrementales. La discusión se centró en si la información puede derivarse de los manifiestos o debe permanecer como campo top level y quedó abierta al finalizar la semana.
Evolución del tipo DECIMAL y mejoras REST rice Zhang propuso ampliar las reglas de promoción de tipos de Iceberg para soportar evolución DECIMAL conforme a SQL 2011, por ejemplo cambiar precisión y escala sin reescribir archivos de datos. Se analizó la compatibilidad hacia atrás y cómo Iceberg maneja actualmente esos cambios. Paralelamente Prashant Singh propuso que la respuesta loadTable incluya opcionalmente una lista referenced-by para ver qué tablas referencian una tabla, útil para análisis de dependencias. Alex Stephen sugirió publicar los modelos REST generados por OpenAPI como paquete Python para que PyIceberg y otros clientes importen modelos oficiales en lugar de mantener copias propias.
Acelerador de analítica S3 y otras actualizaciones Michael Stubbs resumió avances en la integración del Amazon S3 Analytics Accelerator: se planificó crear un epic en JIRA, evaluar lecturas vectorizadas, medir uso de heap con y sin el acelerador y colaborar con proveedores de almacenamiento. Hubo además revisiones solicitadas al API de metadata y anuncios de meet ups comunitarios como el encuentro en Dublín asociado al Arrow y Iceberg Summit.
Conclusión y aprendizaje para empresas La segunda semana de septiembre 2025 mostró a la comunidad refinando la línea 1.10.0, votando RC5, planificando deprecaciones y discutiendo decisiones de diseño API y evolución de tipos. Los debates sobre gobernanza, gestión de dependencias en PyIceberg y nuevas capacidades de aceleración en S3 reflejan el crecimiento del ecosistema y la necesidad de equilibrar conveniencia con flexibilidad técnica.
En Q2BSTUDIO, como empresa de desarrollo de software y aplicaciones a medida, seguimos de cerca estas evoluciones porque impactan directamente en proyectos que requieren integración con data lakes modernos, procesos ETL y arquitecturas lakehouse. Si busca soluciones personalizadas podemos ayudarle a diseñar e implementar pipelines que aprovechen formatos avanzados como Apache Iceberg y a integrar capacidades de inteligencia artificial y agentes IA que optimicen sus flujos de datos. Conozca nuestras ofertas de software a medida y aplicaciones a medida y nuestros servicios de inteligencia artificial y IA para empresas.
Palabras clave: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.
.jpg)