Si manejás un data lakehouse, ya sabés que los point releases de Iceberg suelen ser tranquilos — un bump de dependencias por acá, un bugfix por allá. La 1.11.0 (lanzada el 19 de mayo) no es ese release. Esta trae cambios estructurales que tocan cómo consultás, cómo asegurás, y — esto es clave — qué JVM tenés permitido correr.
Vamos a recorrer qué cambia de verdad para vos, y después el problema de migración que tenés que planear antes de actualizar.
Spark 4.1 y Flink 2.1 ahora son los targets por defecto
El titular: Spark 4.1 y Flink 2.1 ahora son los build targets por defecto. Y la mejora más práctica viene con el MERGE INTO de Spark 4.1.
Ahora podés correr un MERGE con una cláusula WITH SCHEMA EVOLUTION. Si tu data de origen trae columnas que tu tabla destino todavía no tiene, el MERGE agrega esas columnas a la tabla en la misma sentencia — sin un ALTER TABLE aparte. Para cualquiera que mantenga pipelines de ingesta donde los esquemas upstream cambian todo el tiempo, eso es una pieza móvil menos para estar cuidando.
El connector de Spark también se moderniza contra las APIs más nuevas de DataSource V2 y suma un planner de micro-batch asíncrono que acelera el Structured Streaming.
Del lado de Flink, la pieza central es el experimental DynamicIcebergSink: en lugar de un sink por tabla, un solo sink rutea cada record a una tabla elegida en runtime — creando tablas on demand y evolucionando sus esquemas y partition specs sobre la marcha. Es experimental, así que tratalo como tal, pero rompe un modelo que viene molestando a los usuarios de Flink+Iceberg desde hace años.
Scan planning del lado del servidor: el trabajo de metadata sale de tu engine
Hasta ahora, tu query engine hacía el trabajo pesado del scan planning — el driver recorría el árbol de metadata de la tabla, trayendo manifest lists y archivos desde el object storage para filtrar contra tus particiones.
La 1.11.0 mueve ese trabajo hacia el catálogo. El engine manda un solo request POST .../plan y el catálogo REST devuelve FileScanTasks optimizados. Escala por diseño: los scans chicos devuelven resultados al instante, los más grandes devuelven un plan-id que vas consultando, y los datasets enormes vuelven a través de plan-tasks en paralelo.
En criollo: tu query engine deja de ser el cuello de botella del planning, y ese trabajo vive donde se puede optimizar de forma centralizada.
Cifrado de tablas integrado con Google KMS
El cifrado a nivel bucket nunca alcanzó para un lakehouse que guarda PII o data financiera — y la 1.11.0 por fin trae el cifrado a nivel tabla.
Iceberg usa envelope encryption con una jerarquía de claves de tres niveles: una table master key vive en tu KMS y nunca toca el storage de Iceberg; esa clave envuelve las key-encryption keys (KEKs) guardadas en la metadata de la tabla; y cada KEK envuelve una data-encryption key (DEK) única por archivo. Cada archivo de datos y cada manifest list se cifra con AES-GCM bajo su propia DEK.
La parte que importa para los equipos de compliance: también cifra los manifest lists, no solo la data cruda. Eso cierra una fuga real — un atacante con acceso al bucket antes podía leer la metadata de los manifests y sacar paths de archivos, nombres de columnas, partition bounds y conteos exactos de nulls sin tocar nunca un archivo de datos. Las claves además rotan automáticamente a medida que envejecen, así que cumplís con los mandatos de rotación sin tener que reescribir datasets enormes.
El breaking change: Java 11 se fue
Acá está el que tenés que planear. La 1.11.0 elimina el soporte para Java 11 — ahora necesitás Java 17 o 21. El soporte para Spark 3.4 también queda deprecado.
Esto no es algo “negativo” — es el costo de mantenerte al día, y conviene saberlo antes de agendar el upgrade y no después. Si tu plataforma todavía corre sobre Java 11 o quedó pegada a Spark 3.4, tu migración tiene un prerequisito: subí tu runtime primero, después actualizá Iceberg. Intentar hacer las dos cosas en la misma ventana sobre un lakehouse en producción es la receta para arruinarte el fin de semana.
Una secuencia práctica:
- Auditá sobre qué engines y JVMs corren hoy tus workloads de Iceberg.
- Movete a Java 17/21 y salí de Spark 3.4 en un entorno de staging.
- Validá tus pipelines actuales contra el nuevo connector de Spark (la modernización a DSv2 puede sacar a la luz casos borde).
- Recién ahí subí Iceberg a 1.11.0.
Qué tener en cuenta
Un par de salvedades honestas: DynamicIcebergSink y partes del soporte de Flink 2.1 son experimentales — útiles para pilotear, no para apostarle un pipeline de producción todavía. El cifrado KMS integrado salió con soporte para Google KMS, así que si estás en otro provider, verificá el soporte actual antes de asumir que está a la par. Y el upgrade de JVM/engine es trabajo operativo real — presupuestalo.
Nada de eso le saca mérito al release. Para un equipo de plataforma de datos, la 1.11.0 es uno de los drops de Iceberg más sustanciales en un buen tiempo: un cambio real en la arquitectura de query planning, cifrado a nivel tabla que cierra una fuga de metadata, y un MERGE de Spark que por fin maneja el schema drift por su cuenta.
¿Y vos? ¿Ya tenés tu stack en Java 17/21, o el salto desde Java 11 te va a frenar la migración a la 1.11.0? Contanos cómo viene tu lakehouse.