Databricks ha anunciado la disponibilidad en Public Preview de las funcionalidades de Apache Iceberg v3 sobre Unity Catalog. La nueva versión del estándar de tablas abiertas incorpora row lineage, deletion vectors y el tipo VARIANT para datos semiestructurados, marcando un avance significativo hacia la unificación del ecosistema lakehouse.
Iceberg v3 introduce mejoras estructurales que llevan dos años madurando en la comunidad Apache. Los deletion vectors permiten registrar borrados y actualizaciones sin reescribir ficheros completos, lo que reduce drásticamente el coste de las operaciones MERGE en tablas grandes. El row lineage añade metadatos por fila que facilitan auditoría, debugging y casos de uso de change data capture sin depender de patrones externos. El tipo VARIANT almacena JSON y otros formatos semiestructurados con compresión columnar nativa, eliminando la penalización de rendimiento típica de almacenar JSON como string.
La integración con Unity Catalog es la novedad más relevante para los clientes de Databricks. Las tablas Iceberg v3 gestionadas por Unity Catalog soportan estas tres nuevas características desde el primer día, manteniendo las políticas de gobernanza centralizadas que ya conocen los usuarios de la plataforma. Databricks ha indicado que ofrecerá detalles adicionales y demostraciones técnicas durante el Data and AI Summit de San Francisco, programado del 15 al 18 de junio de 2026.
El movimiento refuerza la convergencia hacia Iceberg como formato de referencia del lakehouse abierto. Snowflake, Google Cloud, AWS y la propia Databricks ofrecen ya soporte para el formato, y la llegada de v3 reduce las diferencias funcionales con Delta Lake. Para arquitectos de datos, esto facilita arquitecturas multi-cloud sin lock-in: los datos pueden vivir en S3 o GCS y ser consultados desde cualquier motor compatible, una flexibilidad que hace dos años requería costosos procesos de ingestión.
La preview abre la puerta a probar las nuevas características en entornos no productivos. La recomendación habitual del equipo Databricks es validar primero los deletion vectors en cargas de trabajo con muchos UPDATE/MERGE, donde el ahorro de I/O suele ser más visible.
Más en Dataprix: Plataformas de datos modernas y arquitectura lakehouse
Fuente: Databricks Blog — The Next Era of the Open Lakehouse