Hay infraestructura que no aparece en los titulares pero que sostiene buena parte de lo que sí los protagoniza. Apache Iceberg es un buen ejemplo. Es el formato de tabla abierto que permite que plataformas como Snowflake, Google BigQuery, AWS, Databricks y Apache Spark lean y escriban los mismos datos sin que cada sistema tenga que mantener su propia copia. Es la capa que convierte un conjunto de archivos en un lago de datos que se comporta como una base de datos relacional: con transacciones, versiones históricas y esquemas que evolucionan sin romper las consultas existentes.
El 27 de mayo de 2026, el equipo de lakehouse de Google —representado por Alex Stephen y Talat Uyarer en el blog de código abierto de la compañía— anunció la versión 1.11.0 de Apache Iceberg. Las novedades más significativas afectan a la seguridad de los datos sensibles, al rendimiento en tablas de escala masiva y a la compatibilidad con las últimas versiones de Apache Spark y Flink.
Cifrado nativo por tabla: el avance más relevante para los equipos de compliance
Hasta ahora, el cifrado de los datos en un lakehouse de Iceberg dependía de lo que ofrecía el proveedor de almacenamiento: cifrado a nivel de bucket en S3 o GCS, que protege los archivos si alguien accede físicamente al almacenamiento, pero deja los metadatos de las tablas —las listas de manifiestos que describen qué archivos existen y qué particiones los contienen— potencialmente expuestos.
Iceberg 1.11.0 introduce cifrado nativo por tabla con una arquitectura de clave jerárquica en tres niveles. Cada tabla tiene una clave maestra guardada en un KMS (Key Management Service) externo —Google KMS es el primero soportado de forma nativa—, que nunca toca el almacenamiento de Iceberg. Esa clave maestra envuelve claves de cifrado de clave (KEK), que se guardan en los metadatos de la tabla. Cada KEK envuelve a su vez una clave de datos (DEK) única por archivo. Cada archivo de datos y cada lista de manifiestos se cifra con AES-GCM bajo su propia DEK. El resultado:
- Si alguien accede directamente al bucket de almacenamiento sin pasar por el catálogo, los datos son ilegibles.
- Los manifiestos están cifrados, por lo que no se puede inferir información sensible desde las estadísticas de la tabla.
- Las claves rotan automáticamente sin necesidad de reescribir el dataset.
- Las etiquetas de autenticación AES-GCM protegen contra modificaciones no autorizadas.
Para los equipos de datos que manejan información de PII (datos personales identificables), registros financieros o datos clínicos, esta capacidad elimina una brecha de cumplimiento real. El cifrado a nivel de bucket protege contra amenazas externas; el cifrado a nivel de tabla protege incluso contra accesos internos no autorizados al almacenamiento.
Server-side scan planning: menos trabajo en el cliente, más velocidad a escala
La planificación de escaneos es una de las operaciones más costosas en un lakehouse grande. Antes de ejecutar una consulta, el motor tiene que recorrer los metadatos de la tabla —listas de manifiestos, archivos de datos— para determinar qué archivos son relevantes para la consulta. En tablas con miles de millones de filas y miles de archivos, ese recorrido de metadatos es caro.
Iceberg 1.11.0 traslada esa carga al catálogo REST mediante server-side scan planning. En lugar de que el driver del motor recorra los manifiestos desde el almacenamiento de objetos, envía una única petición POST .../plan al catálogo con los parámetros del escaneo. El catálogo devuelve las FileScanTasks ya optimizadas. Para escaneos grandes, el catálogo devuelve un plan-id que el cliente puede consultar de forma asíncrona, y para datasets masivos se pueden recuperar tareas en paralelo. El resultado práctico es que el tiempo de planificación de consultas se reduce significativamente en tablas muy grandes, sin que el equipo de datos tenga que cambiar el código de sus pipelines.
Soporte para Spark 4.1 y el DynamicIcebergSink de Flink
Iceberg 1.11.0 adopta Spark 4.1 como versión por defecto. La novedad más práctica: la operación MERGE INTO en Spark 4.1 acepta la cláusula WITH SCHEMA EVOLUTION, lo que permite que un merge que incorpora columnas nuevas en los datos de origen las añada automáticamente a la tabla de destino. Antes, eso requería un ALTER TABLE separado. Para pipelines de integración de datos donde el esquema de la fuente cambia frecuentemente, eso elimina un punto de fricción habitual.
En Flink 2.1, la novedad principal es el DynamicIcebergSink: un sink experimental que rompe el modelo antiguo de «un sink por tabla». Con el nuevo sink, un solo operador de Flink puede enrutar cada registro a la tabla que corresponde en tiempo de ejecución, creando tablas nuevas bajo demanda y evolucionando sus esquemas y especificaciones de partición sobre la marcha. Para pipelines de streaming multitenant donde los eventos de distintos clientes deben almacenarse en tablas separadas, eso simplifica drásticamente la arquitectura.
La alianza de Anthropic con Snowflake para llevar modelos Claude al corazón de los datos empresariales es el contexto empresarial que da relevancia a las mejoras técnicas de Iceberg: las consultas de IA sobre datos corporativos necesitan infraestructura de datos que sea segura, rápida y escalable. AWS re:Invent 2025 ya marcó la dirección con Graviton5 y las Data Zones para soberanía de datos en IA: los grandes proveedores de nube están construyendo la infraestructura que hace posible la IA empresarial, y Iceberg es el formato de datos que la conecta. La madurez del ecosistema de código abierto —del que Apache Iceberg forma parte junto a Spark, Flink y el ecosistema Hadoop— es uno de los activos más sólidos de la infraestructura tecnológica actual.
Mi valoración
He seguido la evolución del ecosistema de datos analíticos desde el Big Data de la primera ola, y el cifrado nativo por tabla de Iceberg 1.11.0 me parece la novedad más significativa del año en este espacio. No porque sea técnicamente compleja —la criptografía AES-GCM existe desde hace décadas— sino porque soluciona un problema real de compliance que frenaba la adopción de lakehouses en sectores regulados.
Lo que más me convence es la arquitectura de clave jerárquica. No cifrar a nivel de tabla sino a nivel de archivo individual, con rotación automática sin reescritura del dataset, es el tipo de diseño que permite adaptarse a los ciclos de auditoría sin coste operativo prohibitivo.
Lo que más me preocupa es la dependencia de KMS externo. Google KMS es el primer soporte nativo, y el equipo promete otros KMS en versiones futuras. Hasta que llegue el soporte para AWS KMS y Azure Key Vault de forma estándar, las organizaciones que no usan Google Cloud tienen que implementar adaptadores propios para aprovechar el cifrado nativo.
Preguntas frecuentes
¿Qué es Apache Iceberg y por qué lo usa Snowflake y BigQuery?
Apache Iceberg es un formato abierto de tabla para almacenamiento analítico masivo en sistemas de objetos como S3, GCS o Azure Blob. Define cómo se organizan los metadatos de una tabla (manifiestos, estadísticas, versiones históricas) de forma que múltiples motores —Spark, Flink, Trino, BigQuery, Snowflake— puedan leer y escribir la misma tabla sin copias ni traducciones. Snowflake y BigQuery lo adoptan porque permite interoperabilidad con el ecosistema de código abierto sin sacrificar las capacidades de gestión de sus plataformas.
¿Qué es el cifrado «envelope» que usa Iceberg 1.11.0?
El cifrado en sobre (envelope encryption) usa una jerarquía de claves donde una clave «envuelve» (cifra) a otra. Iceberg 1.11.0 usa tres niveles: la clave maestra en el KMS cifra las claves de cifrado de clave (KEK), que a su vez cifran las claves de datos (DEK), que son las que realmente cifran cada archivo de datos. Este diseño permite rotar la clave maestra sin tener que descifrar y volver a cifrar todos los datos: basta con envolver las KEK con la nueva clave maestra.
¿Qué ventaja tiene la planificación de escaneos en el servidor?
En tablas con millones de archivos, determinar qué archivos son relevantes para una consulta puede tardar tanto como la propia consulta. Con server-side scan planning, el catálogo REST hace ese trabajo de forma optimizada y devuelve al motor solo las tareas de escaneo que necesita, sin que el driver tenga que descargar y procesar listas de manifiestos desde el almacenamiento. Para tablas de escala exabyte, la diferencia de tiempo puede ser de minutos frente a segundos.