Apache Iceberg: tablas abiertas contra el lock-in de motor

Cualquier equipo que haya operado un data lake por más de dos años conoce el patrón: se eligió un motor de consulta, se construyó todo el pipeline alrededor de sus particularidades, y dos años después migrar a otro motor —o simplemente añadir uno nuevo para un caso de uso distinto— implica reescribir todo el almacenamiento. El problema no es el motor en sí. Es que el formato en el que viven los datos quedó acoplado a él. Apache Hive resolvió el problema original de los data lakes (poder correr SQL sobre archivos planos) pero lo hizo atando la organización física de los datos —carpetas por partición, listados de directorio para descubrir archivos— a un metastore que cada motor tenía que interpretar a su manera. Esa dependencia implícita entre motor y formato es exactamente lo que los formatos de tabla abiertos como Apache Iceberg vinieron a romper. La promesa no es "un motor mejor": es que el formato de la tabla deje de ser una decisión de infraestructura que amarra a un proveedor.

La arquitectura en capas: catálogo, metadatos, manifiestos y datos

Iceberg no almacena la definición de una tabla como una entrada en una base de datos que apunta a una carpeta. La construye como una cadena de archivos inmutables, cada uno con una responsabilidad concreta. Un catalog guarda, para cada tabla, un puntero al archivo de metadatos vigente. Ese archivo de metadatos (JSON) describe el esquema, el esquema de particionado y la lista de snapshots históricos de la tabla. Cada snapshot referencia una manifest list (en Avro), que a su vez enumera uno o más archivos manifest, y estos últimos listan los archivos de datos reales (típicamente Parquet) junto con estadísticas por columna: rangos de valores, conteos, nulos.

Esta cadena importa porque cambia por completo cómo un motor "encuentra" los datos. En Hive, saber qué archivos pertenecen a una tabla exige listar el sistema de almacenamiento subyacente —una operación costosa y, en object stores como S3, con garantías de consistencia poco predecibles bajo escritura concurrente. En Iceberg, el motor nunca lista directorios: recorre metadatos que ya conoce la ubicación exacta de cada archivo y, gracias a las estadísticas embebidas, puede descartar archivos completos antes de leer un solo byte de datos. El resultado práctico es doble: consultas más baratas (menos I/O) y, sobre todo, transacciones ACID reales. Una escritura sólo se considera "commiteada" cuando el puntero del catálogo se actualiza atómicamente al nuevo archivo de metadatos. Si el proceso falla a mitad de camino, los lectores siguen viendo el snapshot anterior, íntegro. Eso es algo que Hive, por diseño, no puede garantizar.

Particionado oculto y evolución de particiones

En un data lake Hive-style, el esquema de particionado es literalmente la estructura de carpetas: si la tabla está particionada por fecha, el usuario tiene que saber que existe una columna física llamada así y filtrar explícitamente por ella para que el motor aproveche el particionado. Si alguien escribe WHERE timestamp_evento BETWEEN ... en lugar de filtrar por la columna de partición derivada, el motor termina escaneando la tabla completa sin que nadie lo note hasta que llega la factura de cómputo.

Iceberg separa la columna que el usuario consulta de la transformación que define la partición. Se puede particionar por day(timestamp_evento) o month(fecha_creacion), y el motor aplica esa transformación automáticamente cada vez que detecta un filtro sobre la columna original, sin que el usuario tenga que conocer ni mencionar el detalle de partición. A esto se le llama hidden partitioning, y elimina una clase entera de errores de rendimiento silenciosos.

La segunda pieza es la evolución de particiones: se puede cambiar el esquema de particionado de una tabla —pasar de particionar por mes a particionar por día, por ejemplo— sin reescribir un solo archivo de datos existente. Los snapshots antiguos conservan su esquema de partición original; los nuevos usan el esquema actualizado. Ambos coexisten en la misma tabla porque el esquema de partición vive en los metadatos de cada snapshot, no en la estructura física de carpetas.

El particionado deja de ser una decisión que se toma una vez, al crear la tabla, y se convierte en un parámetro que se ajusta a medida que cambia el volumen o el patrón de consulta.

Evolución de esquema sin reescrituras

El mismo principio —metadatos como fuente de verdad, datos físicos como implementación de bajo nivel— aplica al esquema de columnas. Iceberg identifica cada campo por un ID interno único, no por su nombre ni su posición. Eso permite renombrar columnas, añadir columnas nuevas, eliminar columnas o incluso reordenarlas sin tocar los archivos Parquet subyacentes: el motor resuelve la correspondencia entre el ID lógico y la posición física al momento de leer. La evolución alcanza también a campos anidados en estructuras complejas, algo que en formatos más rígidos suele forzar una reescritura completa de la tabla.

Esta misma capacidad de versionar metadatos habilita el time travel: como cada transacción genera un snapshot nuevo sin destruir el anterior, se puede consultar el estado exacto de una tabla en cualquier punto de su historia, o incluso crear ramas (branches) y etiquetas (tags) sobre snapshots concretos con sus propias políticas de retención. Es una aproximación deliberadamente similar a git aplicada a datos, útil tanto para auditoría como para recuperarse de una carga errónea sin restaurar backups.

Catálogo agnóstico de motor: la verdadera defensa contra el lock-in

Todo lo anterior sería una mejora de formato interesante pero secundaria si no viniera acompañado de una decisión de diseño más profunda: Iceberg es una especificación, no una implementación atada a un runtime. Spark, Trino, Flink, Snowflake, DuckDB o Dremio pueden leer y escribir la misma tabla Iceberg sin coordinación previa entre ellos, porque todos implementan la misma especificación de formato de tabla. Esto contrasta con formatos que nacieron pensados primero para un motor específico y sólo después ganaron soporte de terceros: la interoperabilidad ahí es un añadido, no el diseño original.

El punto de fricción histórico fue el catálogo: cada implementación de catálogo (Hive Metastore, Glue, Nessie, catálogos propietarios) exigía que cada motor escribiera un cliente distinto en cada lenguaje. Eso llevaba de vuelta al mismo problema de acoplamiento, sólo que un nivel más arriba. La REST Catalog Specification resuelve esto estandarizando el protocolo de comunicación entre motor y catálogo: cualquier motor que hable el protocolo REST de Iceberg puede operar contra cualquier catálogo que lo exponga, sin importar en qué lenguaje esté escrito ninguno de los dos lados.

Cuándo usarlo en la práctica

• Si ya tienes más de un motor de consulta en producción (por ejemplo, Spark para batch y Trino o Snowflake para BI), Iceberg evita mantener copias duplicadas de los mismos datos en formatos distintos para cada motor.
• Si tus tablas reciben escrituras concurrentes frecuentes —CDC, backfills paralelos a ingestas incrementales— las garantías ACID de Iceberg eliminan una clase de bugs de datos duplicados o inconsistentes que en Hive-style requieren coordinación manual entre jobs.
• Si el esquema de tus tablas cambia con regularidad (nuevas columnas, renombrados, cambios de tipo), la evolución de esquema sin reescritura ahorra horas de mantenimiento cada vez que ocurre.
• Si sospechas que el motor de consulta que usas hoy no será el mismo dentro de dos o tres años —por costo, por capacidad, por decisión organizacional— construir sobre Iceberg con un catálogo REST es la forma de no pagar esa migración reescribiendo terabytes de datos.
• No lo introduzcas si tu volumen de datos es pequeño y un único motor cubre todas tus necesidades indefinidamente: la capa de metadatos añade complejidad operativa (compactación de snapshots, gestión de manifest files) que sólo se justifica cuando el volumen o la heterogeneidad de motores lo requiere.
• Evita el catálogo basado en sistema de archivos (version-hint.text) en producción: no ofrece garantías de escritura atómica consistentes en todos los backends de almacenamiento. Usa siempre un catálogo de servicio.