Apache Iceberg: transacciones ACID sobre el lago

Hasta ahora has construido un data lake con zonas claras, archivos Parquet y particionado inteligente. Parece perfecto, ¿verdad? Pues tiene un problema gordo que solo se revela cuando operas en producción: NO tienes transacciones. Si tu pipeline falla a mitad de una escritura, dejas archivos basura en el lake. Si dos pipelines escriben a la misma tabla simultáneamente, pueden corromperse mutuamente. Si quieres saber cómo estaban los datos hace una hora, no puedes. Bienvenido al problema que Apache Iceberg resuelve.

### El problema: archivos sueltos no son una tabla

Un directorio con archivos Parquet NO es una tabla de base de datos. Le faltan propiedades fundamentales que cualquier base de datos tiene desde los años 70:

• ▹Atomicidad: si escribes 10 archivos y fallas en el 7°, te quedan 6 archivos "fantasma" que los lectores ven pero no deberían.
• ▹Consistencia: dos queries simultáneas pueden ver estados diferentes si un pipeline está escribiendo mientras otro lee.
• ▹Aislamiento: dos escritores simultáneos pueden producir resultados corruptos.
• ▹Durabilidad: no hay garantía de que una escritura "committada" sea visible para todos los lectores.
• ▹Esquema: no hay un lugar central que diga qué columnas tiene la tabla, qué tipos son, ni cuál es la versión actual del esquema.
• ▹Time travel: no puedes ver cómo estaban los datos ayer, porque los archivos se sobrescriben.

Apache Iceberg resuelve TODOS estos problemas añadiendo una capa de metadata sobre los archivos Parquet existentes. No reemplaza Parquet — lo complementa. Los datos siguen siendo archivos Parquet en S3. Iceberg añade un sistema de "contabilidad" que sabe exactamente qué archivos componen la tabla en cada momento.

### Breve historia: de dónde sale Iceberg

Iceberg nació en Netflix en 2017. Ryan Blue y su equipo estaban frustrados con Apache Hive: su metastore era lento, las queries sobre tablas grandes tardaban minutos solo en planificarse, y las operaciones de particionado requerían reescribir tablas enteras. Crearon Iceberg como "un table format que escala" — diseñado desde cero para tablas de petabytes con miles de particiones. En 2018 se donó a Apache Foundation y en 2020 se graduó como proyecto top-level. Hoy lo usan Netflix, Apple, LinkedIn, Airbnb y la mayoría de empresas con data lakes serios.

### Arquitectura de metadata de Iceberg

Iceberg funciona con una jerarquía de archivos de metadata que apuntan a los archivos de datos. Nunca se modifican los archivos de datos directamente — se crean nuevos archivos de metadata que "redeclaran" qué archivos son válidos. Esta inmutabilidad es la clave de todo:

1. 01.Catalog: un puntero a la ubicación del metadata file actual. Es lo que dice "la tabla ventas está en s3://lake/metadata/v3.metadata.json". Puede ser AWS Glue Catalog, Hive Metastore, REST catalog, etc.
2. 02.Metadata File: un JSON que describe el estado completo de la tabla — esquema actual, esquema histórico, configuración de particionado, y una lista de snapshots.
3. 03.Snapshot: una "foto" del estado de la tabla en un momento concreto. Cada commit (INSERT, UPDATE, DELETE) crea un nuevo snapshot. Los snapshots anteriores se mantienen para time travel.
4. 04.Manifest List: un archivo que lista todos los manifest files que pertenecen a un snapshot.
5. 05.Manifest File: un archivo Avro que lista archivos de datos con sus estadísticas (min/max por columna, count, nulls). Esto permite partition pruning SIN listar el filesystem.
6. 06.Data Files: los archivos Parquet con los datos reales. Estos NUNCA se modifican — solo se crean nuevos o se marcan como "borrados" en un nuevo manifest.

### ACID en el lago: cómo Iceberg logra transacciones

El truco es elegante: un commit en Iceberg es simplemente un "atomic swap" del puntero del catalog. El escritor crea nuevos data files, crea nuevos manifests, crea un nuevo metadata file con un nuevo snapshot, y atómicamente actualiza el catalog para que apunte al nuevo metadata. Si falla en cualquier paso intermedio, el catalog sigue apuntando al metadata anterior — los archivos nuevos quedan como basura (se limpian después) pero los lectores nunca los ven.

Esto da transacciones ACID reales: los lectores siempre ven un snapshot consistente (isolation), las escrituras son todo-o-nada (atomicity), el esquema se valida antes de commit (consistency), y una vez committado es duradero (durability).

### Merge-on-read vs Copy-on-write

Cuando haces un UPDATE o DELETE en Iceberg, hay dos estrategias posibles:

• ▹Copy-on-write (COW): reescribe el archivo Parquet completo con la fila modificada. Escrituras lentas, lecturas rápidas. Bueno si actualizas poco frecuentemente.
• ▹Merge-on-read (MOR): escribe solo los cambios en un archivo "delta". Al leer, fusiona los datos originales con los deltas. Escrituras rápidas, lecturas un poco más lentas. Bueno si actualizas frecuentemente.

La mayoría de implementaciones usan COW por defecto porque las lecturas son más frecuentes que las escrituras en un data lake. MOR se usa cuando tienes muchas actualizaciones incrementales (ej: CDC de una base operacional).

### Schema evolution: cambiar sin romper

Iceberg permite evolucionar el esquema de la tabla sin reescribir datos: añadir columnas, renombrar columnas, cambiar tipos (con promoción segura: int → long, float → double). Los archivos antiguos siguen siendo válidos — al leerlos, Iceberg rellena las columnas nuevas con null. Esto es fundamental en producción porque los esquemas SIEMPRE cambian.

1-- Schema evolution en Iceberg (vía Spark SQL)
2ALTER TABLE lake.ventas ADD COLUMN canal STRING;
3ALTER TABLE lake.ventas RENAME COLUMN monto TO importe;
4ALTER TABLE lake.ventas ALTER COLUMN cantidad TYPE bigint;
5
6-- Hidden partitioning: no necesitas columna explícita
7CREATE TABLE lake.eventos (
8    ts TIMESTAMP,
9    user_id STRING,
10    event_type STRING
11) USING iceberg
12PARTITIONED BY (days(ts));  -- Particiona por día sin columna extra
13
14-- Partition evolution: cambiar estrategia sin reescribir
15ALTER TABLE lake.eventos
16  ADD PARTITION FIELD hours(ts);  -- Añadir partición por hora

### Por qué Iceberg ganó la batalla de los table formats

En 2024, Iceberg ha emergido como el ganador de facto en la guerra de table formats. Las razones: es vendor-neutral (no pertenece a Databricks ni a ninguna empresa), tiene soporte universal (Spark, Trino, Flink, Dremio, StarRocks, DuckDB, AWS, Snowflake), y su diseño de metadata escala a petabytes sin problemas. Incluso Databricks — creadores de Delta Lake — ha añadido soporte nativo para Iceberg.