El formato de tablas abierto Apache Iceberg sigue afianzándose como estándar de facto del lakehouse mientras su comunidad debate ya los detalles de la futura versión 4 del formato. En las listas de desarrollo de las últimas semanas, los contribuidores han abierto una propuesta formal para retirar los equality deletes de la especificación v4 y han discutido patrones de commit para cambios fila a fila y transacciones multitabla, señales de una comunidad muy activa alrededor del formato.
En paralelo, la adopción por parte de los grandes fabricantes refuerza el papel de Iceberg como capa neutral. Snowflake ha presentado el soporte de Iceberg v3 con escrituras bidireccionales a través de su catálogo Polaris, de modo que distintos motores pueden leer y escribir sobre las mismas tablas sin duplicar datos. Esa interoperabilidad entre motores es precisamente el argumento central del formato: separar el almacenamiento de los datos del motor que los consulta.
La actividad no se limita al formato de tablas. El catálogo Apache Polaris ha sido uno de los proyectos con más movimiento en las listas de desarrollo, con debates sobre las garantías de consistencia que debe ofrecer su capa de persistencia. A su alrededor ha surgido además Apache Ossie, el proyecto de interoperabilidad semántica recién incubado, con el que Polaris pretende alinear su API de modelo semántico. El ecosistema abierto del lakehouse gana así piezas complementarias: formato de tablas, catálogo y capa semántica.
Para un arquitecto de datos, la consolidación de Iceberg tiene una implicación práctica directa: elegir un formato de tablas abierto reduce el riesgo de quedar atado a un único motor de consulta. Si el almacenamiento vive en Iceberg, cambiar o combinar motores —Spark, Trino, DuckDB, Snowflake o Databricks— deja de exigir una migración de datos y se convierte en una decisión de configuración.
La contrapartida es que un estándar en plena evolución obliga a estar atento a las versiones del formato y a la compatibilidad entre motores, que no siempre avanzan al mismo ritmo. Conviene verificar qué versión de Iceberg soporta cada herramienta del stack antes de comprometerse con una arquitectura, sobre todo con la v4 en el horizonte y cambios de especificación aún en discusión. Aun así, la dirección del mercado es inequívoca: el futuro del lakehouse pasa por formatos y catálogos abiertos.
Relacionado en Dataprix: cuándo usar un data lake, un data warehouse o un lakehouse.
Fuente: Apache Iceberg