Apache Iceberg

Cómo funciona

Iceberg mantiene snapshots y metadatos que describen qué archivos pertenecen a una tabla. Los motores consultan ese estado mediante un catálogo. Esto permite cambios de esquema, particionado evolutivo y escrituras coordinadas sin tratar la tabla como una carpeta sin estructura.

Ejemplo: consultar un estado histórico

Con el conector Iceberg configurado en Trino, esta consulta utiliza un snapshot conservado por la tabla:

SELECT count(*)
FROM lakehouse.ventas.operaciones
FOR TIMESTAMP AS OF TIMESTAMP '2026-10-01 00:00:00';

Sustituye catálogo, esquema y tabla por los de tu entorno. La consulta histórica depende de que no se hayan eliminado los snapshots necesarios.

Capas de metadatos

Catálogo  ──► metadata.json (esquema, particionado, snapshots)
                 └── snapshot actual ──► manifest list
                                           └── manifests ──► archivos de datos (Parquet)
                                                            └── archivos de borrado

Una escritura crea nuevos archivos y un nuevo metadata.json; el catálogo cambia el puntero de forma atómica. Por eso los lectores siempre ven un snapshot consistente y las escrituras concurrentes se resuelven con concurrencia optimista.

Funciones clave

Función	Qué permite
Particionado oculto	PARTITIONED BY (day(fecha)): el usuario filtra por fecha sin conocer las particiones
Evolución de particionado	Cambiar de diario a horario sin reescribir datos antiguos
Evolución de esquema	Añadir, renombrar o reordenar columnas de forma segura (por ID, no por nombre)
Time travel	Consultar un snapshot o un instante anterior
Branches y tags	Ramas para escrituras de prueba (write-audit-publish) y etiquetas para versiones de auditoría
Borrados a nivel de fila	MERGE, UPDATE, DELETE, en modo copy-on-write o merge-on-read

Copy-on-write frente a merge-on-read

Modo	Escritura	Lectura	Adecuado para
Copy-on-write	Reescribe los archivos afectados	Rápida	Pocos cambios, muchas lecturas
Merge-on-read	Escribe archivos de borrado	Combina datos y borrados al leer	Cambios frecuentes (CDC)

En merge-on-read, la compactación periódica es imprescindible para mantener el rendimiento de lectura.

Mantenimiento

-- Trino
ALTER TABLE lakehouse.ventas.operaciones EXECUTE optimize(file_size_threshold => '128MB');
ALTER TABLE lakehouse.ventas.operaciones EXECUTE expire_snapshots(retention_threshold => '7d');
ALTER TABLE lakehouse.ventas.operaciones EXECUTE remove_orphan_files(retention_threshold => '7d');

-- Spark
CALL lakehouse.system.rewrite_data_files(table => 'ventas.operaciones');
CALL lakehouse.system.expire_snapshots(table => 'ventas.operaciones', older_than => TIMESTAMP '2026-10-10 00:00:00');

Programa estas tareas: sin ellas, se acumulan archivos pequeños y metadatos, y las consultas se degradan.

Catálogos

Tipo	Ejemplos
REST (recomendado)	Apache Polaris, Lakekeeper, Nessie, Unity Catalog, catálogos de nube
Servicios de nube	AWS Glue, Google BigLake metastore
Heredados	Hive Metastore, JDBC

El catálogo REST desacopla motores y almacenamiento: Spark, Trino, Flink, Snowflake, BigQuery o DuckDB leen las mismas tablas. Esa interoperabilidad es la razón principal para elegir Iceberg frente a formatos ligados a una plataforma.

Criterios de implementación

Elige catálogo y motores compatibles con las funciones que vas a usar. Programa compactación y expiración de snapshots; evita acumular archivos pequeños. Define retención según las necesidades de recuperación y auditoría.