{"id":1493,"date":"2025-09-11T12:50:43","date_gmt":"2025-09-11T12:50:43","guid":{"rendered":"https:\/\/cloudlab.urv.cat\/catedracloud\/?p=1493"},"modified":"2025-09-11T12:50:50","modified_gmt":"2025-09-11T12:50:50","slug":"apache-iceberg-tablas-flexibles-acid-e-independientes-del-query-engine-para-el-data-lakehouse-moderno","status":"publish","type":"post","link":"https:\/\/cloudlab.urv.cat\/catedracloud\/2025\/09\/11\/apache-iceberg-tablas-flexibles-acid-e-independientes-del-query-engine-para-el-data-lakehouse-moderno\/","title":{"rendered":"Apache Iceberg: Tablas flexibles, ACID e independientes del query engine para el data lakehouse moderno"},"content":{"rendered":"\n

Despu\u00e9s de conocer Deltalake y Apache Hudi en publicaciones anteriores, en este blog cerramos la tr\u00edada de formatos abiertos de tablas con Apache Iceberg. Originalmente desarrollado en Netflix y ahora convertido en un proyecto de nivel superior dentro de Apache, Iceberg se ha consolidado como una de las opciones m\u00e1s populares para los data lakehouses modernos. Al igual que Deltalake y Apache Hudi, Apache Iceberg es un formato abierto de tabla dise\u00f1ado para aportar orden y fiabilidad a los data lakes, transformando un conjunto de archivos en almacenamiento de objetos en una verdadera tabla SQL, con metadatos, evoluci\u00f3n de esquemas y garant\u00edas transaccionales.<\/p>\n\n\n\n

Sin embargo, adopta un enfoque distinto en algunas decisiones clave de dise\u00f1o respecto a sus competidores. Mientras que Delta y Hudi suelen estar estrechamente ligados a motores de procesamiento (query engine) espec\u00edficos (Delta con Spark, Hudi con su enfoque propio en ingesta y streaming), Iceberg fue concebido desde el inicio para ser independiente del query engine. Su especificaci\u00f3n est\u00e1 estrictamente definida, lo que permite que query engines como Spark, Trino, Flink, Presto y Hive interact\u00faen con la misma tabla sin depender de comportamientos espec\u00edficos de cada query engine.<\/p>\n\n\n\n

Otra diferencia radica en c\u00f3mo Iceberg gestiona los metadatos y el particionado. En lugar de apoyarse en estructuras de directorios o convenciones del motor, Iceberg administra todos los metadatos en sus propios archivos. Esto permite el particionado oculto, la evoluci\u00f3n de particiones y una planificaci\u00f3n de consultas r\u00e1pida, sin las suposiciones fr\u00e1giles que derivan de dise\u00f1os basados en directorios.<\/p>\n\n\n\n

Iceberg se distingue por ser independiente del motor, centrado en los metadatos y amigable con la evoluci\u00f3n \u2014 lo que lo convierte en una opci\u00f3n popular para equipos que buscan un formato de tabla con flexibilidad a largo plazo en plataformas de datos multi-motor. Vamos a profundizar en Iceberg para comprender todo su potencial.<\/p>\n\n\n\n

Snapshots, ramas y etiquetas<\/h2>\n\n\n\n

Uno de los pilares de Iceberg es su modelo de versionado y viaje en el tiempo, basado en snapshots, ramas y etiquetas. Estos elementos permiten rastrear, aislar y revertir cambios de forma segura.<\/p>\n\n\n\n

Un snapshot de tabla representa una vista consistente de la tabla en un momento determinado. Cada operaci\u00f3n de escritura (insertar, actualizar, eliminar o sobrescribir) genera un nuevo snapshot. Los snapshots referencian el conjunto exacto de archivos de datos y metadatos en ese instante, lo que permite: consultar la tabla \u201ca partir de\u201d un snapshot anterior, revertir a un estado previo y reproducir datos hist\u00f3ricos para depuraci\u00f3n o auditor\u00eda. Los snapshots son inmutables y se identifican mediante un ID \u00fanico, lo que los convierte en bloques confiables para construir el historial de la tabla.<\/p>\n\n\n\n

Sobre los snapshots, Iceberg introduce las ramas. Piensa en ellas como Git para los datos: se puede crear una rama desde un snapshot, ejecutar experimentos o pruebas de pipelines sobre ella, sin afectar el resto de los flujos de trabajo. Esto permite a los equipos aislar cambios sin riesgo de corromper datos en producci\u00f3n, y abre la puerta a entornos de staging o desarrollo\/pruebas que operan sobre el mismo conjunto de datos subyacente.<\/p>\n\n\n\n

Finalmente, est\u00e1n las etiquetas, que son marcadores ligeros que se pueden adjuntar a cualquier snapshot. A diferencia de las ramas, las etiquetas no cambian \u2014 son etiquetas permanentes que se pueden usar para marcar puntos importantes en la historia, como una versi\u00f3n de dataset para entrenamiento de modelos de machine learning o un punto de control de auditor\u00eda.<\/p>\n\n\n\n

En conjunto, los snapshots, ramas y etiquetas proporcionan a Iceberg un modelo de historial robusto. Permiten seguridad operativa y flexibilidad anal\u00edtica \u2014 todo mientras se mantiene una gesti\u00f3n de metadatos ligera y una planificaci\u00f3n de consultas eficiente.<\/p>\n\n\n\n

Gesti\u00f3n de metadatos y dise\u00f1o de almacenamiento<\/h3>\n\n\n\n

Iceberg organiza sus tablas mediante una jerarqu\u00eda de metadatos en capas. Esta estructura permite manejar tablas a escala de petabytes sin escaneos lentos ni listados costosos de archivos en almacenamiento de objetos.<\/p>\n\n\n\n

En la parte superior, cada tabla tiene un archivo de metadatos. Este archivo registra informaci\u00f3n de alto nivel: el esquema actual de la tabla, la especificaci\u00f3n de particionado, propiedades y, lo m\u00e1s importante, un puntero al snapshot actual. Cuando ocurre un nuevo commit, Iceberg no sobrescribe este archivo; escribe una nueva versi\u00f3n y actualiza el puntero de forma at\u00f3mica para referenciarla. Este mecanismo garantiza la atomicidad entre lectores y escritores.<\/p>\n\n\n\n

Un snapshot es una vista l\u00f3gica de la tabla en un momento dado. Cada snapshot se representa mediante una peque\u00f1a entrada de metadatos dentro del archivo de metadatos de la tabla, y apunta a un archivo de lista de manifiestos. Esta lista es un \u00edndice compacto de los manifiestos que pertenecen a ese snapshot.<\/p>\n\n\n\n

Cada manifiesto, a su vez, lista los archivos de datos incluidos en ese snapshot. Un manifiesto no es solo un listado de archivos \u2014 tambi\u00e9n almacena estad\u00edsticas detalladas (conteo de filas, valores de partici\u00f3n, valores m\u00ednimos\/m\u00e1ximos por columna, m\u00e9tricas a nivel de archivo). Estas estad\u00edsticas permiten a los motores de consulta omitir archivos desde el inicio, reduciendo dr\u00e1sticamente los costes de escaneo.<\/p>\n\n\n\n

Para ilustrarlo:<\/p>\n\n\n\n

    \n
  1. Cuando un trabajo escribe nuevos datos, se generan nuevos archivos de datos.<\/li>\n\n\n\n
  2. Se escribe un nuevo manifiesto para rastrearlos.<\/li>\n\n\n\n
  3. Se crea una nueva lista de manifiestos que referencia tanto los nuevos como los existentes.<\/li>\n\n\n\n
  4. Finalmente, se realiza un commit de un nuevo archivo de metadatos que apunta al nuevo snapshot.<\/li>\n<\/ol>\n\n\n\n
    \"\"<\/figure><\/div>\n\n\n\n

    Este dise\u00f1o garantiza la inmutabilidad en cada nivel (archivos de datos, manifiestos, listas de manifiestos), mientras que el puntero de metadatos de la tabla act\u00faa como fuente \u00fanica de verdad. Los lectores siempre saben exactamente qu\u00e9 archivos pertenecen a una tabla sin escanear directorios, y los escritores pueden hacer commits de forma segura mediante el intercambio at\u00f3mico del puntero.<\/p>\n\n\n\n

    El rol del data catalog en Apache Iceberg<\/h3>\n\n\n\n

    Una parte clave del dise\u00f1o de Iceberg es su dependencia de un data catalog. A diferencia de Delta Lake o Hudi, que almacenan registros de transacciones dentro del directorio de la tabla, Iceberg requiere un cat\u00e1logo que act\u00fae como fuente autorizada del estado actual de la tabla.<\/p>\n\n\n\n

    En el centro de esto est\u00e1 el puntero del cat\u00e1logo. B\u00e1sicamente, el cat\u00e1logo almacena la ubicaci\u00f3n del archivo de metadatos actual de la tabla. Cada vez que se realiza un commit, Iceberg escribe un nuevo archivo JSON de metadatos de tabla (que contiene el nuevo snapshot, el esquema y la especificaci\u00f3n de particionado). El commit se finaliza \u00fanicamente cuando el puntero del cat\u00e1logo se actualiza para referenciar este nuevo archivo.<\/p>\n\n\n\n

    En Hive Metastore, una implementaci\u00f3n com\u00fan de data catalog, este puntero se almacena como una propiedad de la tabla en la entrada del metastore. Esa propiedad simplemente mapea el identificador de la tabla (por ejemplo, mi_base_datos.mi_tabla_iceberg<\/code>) a la ruta del archivo metadata.json<\/code> actual en el almacenamiento de objetos.<\/p>\n\n\n\n

    Cada commit en Iceberg genera un nuevo archivo JSON de metadatos. Para publicarlo, el escritor solicita al metastore que actualice el puntero:<\/p>\n\n\n\n

    UPDATE table_params\nSET current_metadata = 's3:\/\/bucket\/db\/table\/metadata\/metadata-Y.json'\nWHERE current_metadata = 's3:\/\/bucket\/db\/table\/metadata\/metadata-X.json';<\/code><\/pre>\n\n\n\n
    Esto funciona como una operaci\u00f3n de comparaci\u00f3n e intercambio (CAS). La actualizaci\u00f3n solo tiene \u00e9xito si el puntero a\u00fan referencia el archivo de metadatos desde el cual comenz\u00f3 el escritor (metadata-X.json<\/code>). Si otro trabajo hizo commit primero, el puntero ya habr\u00e1 cambiado, y la actualizaci\u00f3n fallar\u00e1. Entonces, el escritor reintenta leyendo los metadatos m\u00e1s recientes y construyendo un nuevo commit.<\/p>\n\n\n\n
    Este puntero es la \u00fanica parte mutable del sistema. Todos los dem\u00e1s archivos \u2014 archivos de datos, manifiestos, listas de manifiestos y archivos de metadatos anteriores \u2014 son inmutables. Los lectores siempre consultan primero el cat\u00e1logo para resolver el puntero, y luego siguen la cadena de metadatos hasta el conjunto exacto de archivos de datos que componen la tabla.<\/p>\n\n\n\n
    Este mecanismo es, en esencia, un control de concurrencia optimista<\/strong>. Los escritores no bloquean la tabla, pero solo una actualizaci\u00f3n del puntero puede tener \u00e9xito a la vez. Los lectores se benefician porque siempre ven un snapshot limpio y completamente comprometido. Esta regla simple \u2014 todos los archivos son inmutables, el puntero es la \u00fanica referencia mutable \u2014 es lo que le da a Iceberg atomicidad<\/strong>. Los lectores siempre resuelven el estado de la tabla preguntando al cat\u00e1logo cu\u00e1l es el archivo de metadatos actual. Eso garantiza que vean el snapshot anterior o el nuevo, pero nunca un estado a medio escribir.<\/p>\n\n\n\n
    Aqu\u00ed explicamos los detalles de implementaci\u00f3n con Hive Metastore, pero el cat\u00e1logo puede implementarse en varios backends (AWS Glue, bases de datos JDBC o el cat\u00e1logo REST de Iceberg). Aunque difieren en la implementaci\u00f3n, el principio es el mismo: el puntero es la \u00fanica referencia mutable que define el estado activo de la tabla, y se actualiza de forma at\u00f3mica cuando se crean nuevos snapshots.<\/p>\n\n\n\n
    En contraste, Delta Lake mantiene su registro de transacciones en archivos _delta_log<\/code> dentro del directorio de la tabla, y Hudi hace algo similar con su carpeta .hoodie<\/code>. Iceberg separa deliberadamente estas responsabilidades: los metadatos inmutables capturan el historial, mientras que el puntero del cat\u00e1logo proporciona coordinaci\u00f3n y atomicidad.<\/p>\n\n\n\n
    Evoluci\u00f3n de la tabla: esquema y particionado oculto<\/h3>\n\n\n\n
    Evoluci\u00f3n del esquema<\/h4>\n\n\n\n
    Una de las funcionalidades destacadas de Iceberg es su manejo robusto de cambios en el esquema. A diferencia de los formatos tradicionales de tabla que dependen del orden o nombre de las columnas, Iceberg asigna un ID \u00fanico a cada campo de la tabla. Este ID permanece constante incluso si la columna se renombra, se elimina o se promueve su tipo de forma compatible. Por ejemplo, renombrar una columna de user_id<\/code> a customer_id<\/code> no rompe las consultas, ya que el sistema la sigue rastreando mediante el ID original. Las columnas eliminadas se eliminan l\u00f3gicamente pero permanecen en los archivos de datos subyacentes, lo que permite que las consultas sobre snapshots antiguos sigan siendo correctas. Las promociones de tipo \u2014 como convertir un entero en un long o un float en un double \u2014 se admiten autom\u00e1ticamente, aunque los cambios incompatibles (por ejemplo, entero \u2192 string) deben realizarse con precauci\u00f3n y se rechazan si no son seguros.<\/p>\n\n\n\n
    Este seguimiento basado en IDs es lo que hace que la evoluci\u00f3n del esquema en Iceberg sea verdaderamente segura y predecible. Se puede evolucionar una tabla durante meses o a\u00f1os, a\u00f1adiendo nuevos campos, renombrando columnas o eliminando las que ya no se usan, sin preocuparse por romper consultas hist\u00f3ricas o corromper pipelines anal\u00edticos.<\/p>\n\n\n\n
    Particionado oculto<\/h4>\n\n\n\n
    Iceberg tambi\u00e9n introduce un enfoque moderno para el particionado de datos, eliminando muchas de las limitaciones de los sistemas tradicionales basados en directorios. En formatos como Hive, el particionado se refleja directamente en la estructura de carpetas del sistema de archivos, lo que puede generar problemas de rendimiento, errores en la planificaci\u00f3n de consultas y dificultades para evolucionar el esquema de partici\u00f3n.<\/p>\n\n\n\n
    Iceberg, en cambio, gestiona el particionado de forma interna mediante metadatos. Esto permite lo que se conoce como particionado oculto<\/strong>, donde los detalles del particionado no se exponen en la ruta de los archivos, sino que se almacenan en los manifiestos y listas de manifiestos. Gracias a esto, se pueden realizar cambios en la estrategia de particionado \u2014como agregar nuevas columnas de partici\u00f3n o modificar las existentes\u2014 sin necesidad de reorganizar f\u00edsicamente los datos ni romper compatibilidad con snapshots anteriores.<\/p>\n\n\n\n
    Adem\u00e1s, este enfoque permite una evoluci\u00f3n del particionado<\/strong>, lo que significa que una tabla puede tener diferentes esquemas de partici\u00f3n a lo largo del tiempo, y cada snapshot conserva el esquema que ten\u00eda en el momento de su creaci\u00f3n. Esto es especialmente \u00fatil en entornos donde los patrones de acceso cambian o donde se requiere flexibilidad para optimizar el rendimiento de las consultas.<\/p>\n\n\n\n
    El resultado es una planificaci\u00f3n de consultas m\u00e1s r\u00e1pida, una mayor robustez frente a errores de dise\u00f1o y una experiencia mucho m\u00e1s fluida para los equipos que gestionan grandes vol\u00famenes de datos.<\/p>\n\n\n\n
    Conclusi\u00f3n<\/h3>\n\n\n\n
    Apache Iceberg est\u00e1 dise\u00f1ado para los data lakehouses modernos, donde la flexibilidad, la precisi\u00f3n y la escalabilidad son fundamentales. Su arquitectura centrada en los metadatos garantiza que las tablas sean completamente consultables y consistentes entre distintos motores, mientras que los snapshots, las ramas y las etiquetas proporcionan un historial robusto y capacidades de viaje en el tiempo. La evoluci\u00f3n del esquema y el particionado oculto permiten a\u00f1adir, renombrar o eliminar columnas, as\u00ed como modificar estrategias de particionado, sin necesidad de reescribir los datos ni romper las consultas existentes.<\/p>\n\n\n\n
    La dependencia de un cat\u00e1logo, con su puntero at\u00f3mico al archivo de metadatos actual de la tabla, asegura que los commits sean completamente consistentes y con propiedades similares a ACID, incluso en entornos concurrentes con m\u00faltiples motores. Al mismo tiempo, el dise\u00f1o basado en manifiestos y las estad\u00edsticas de partici\u00f3n permiten a los motores de consulta eliminar archivos irrelevantes de forma eficiente, soportando tablas con millones de archivos sin degradaci\u00f3n del rendimiento.<\/p>\n\n\n\n
    Todas estas caracter\u00edsticas se combinan para hacer de Iceberg un formato independiente del motor. Spark, Flink, Trino, Presto, Hive y otros motores pueden compartir de forma segura las mismas tablas, aprovechando los metadatos de Iceberg para interpretar correctamente los datos, aplicar cambios de esquema y respetar los snapshots. La clave de esta flexibilidad es su dise\u00f1o centrado en los metadatos. Las tablas Iceberg almacenan toda la informaci\u00f3n que un motor de consulta necesita \u2014 esquema, particionado, snapshots, manifiestos y estad\u00edsticas a nivel de archivo \u2014 en archivos de metadatos bien definidos e inmutables. Los archivos de datos en s\u00ed utilizan formatos est\u00e1ndar como Parquet, ORC o Avro, por lo que cualquier motor que pueda leer estos formatos puede participar.<\/p>\n\n\n\n
    Dado que toda la informaci\u00f3n hist\u00f3rica est\u00e1 capturada en los metadatos, los motores no necesitan asumir nada sobre estructuras de directorios ni registros internos. Simplemente leen los metadatos de la tabla para determinar exactamente qu\u00e9 datos pertenecen a un snapshot. Incluso operaciones como el viaje en el tiempo, la ramificaci\u00f3n o la evoluci\u00f3n del esquema funcionan de manera consistente entre motores gracias a la estandarizaci\u00f3n del formato de metadatos.<\/p>\n\n\n\n
    En resumen, Iceberg ofrece un formato de tabla no solo escalable y eficiente, sino tambi\u00e9n flexible, confiable y preparado para el futuro. Permite a los equipos evolucionar sus datos, experimentar de forma segura y consultar desde distintos motores \u2014 todo mientras se mantiene la precisi\u00f3n, la eficiencia y la simplicidad. Para las organizaciones que est\u00e1n construyendo data lakehouses modernos, Iceberg representa un camino claro hacia una gesti\u00f3n de datos robusta y sostenible a largo plazo.<\/p>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    Despu\u00e9s de conocer Deltalake y Apache Hudi en publicaciones anteriores, en este blog cerramos la tr\u00edada de formatos abiertos de tablas con Apache Iceberg. Originalmente desarrollado en Netflix y ahora convertido en un proyecto de nivel superior dentro de Apache, Iceberg se ha consolidado como una de las opciones m\u00e1s populares para los data lakehouses […]<\/p>\n","protected":false},"author":6,"featured_media":1495,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","_swt_meta_header_display":false,"_swt_meta_footer_display":false,"_swt_meta_site_title_display":false,"_swt_meta_sticky_header":false,"_swt_meta_transparent_header":false,"footnotes":""},"categories":[34,41,113,38,31],"tags":[],"class_list":["post-1493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-almacenamiento","category-big-data","category-cloud-computing","category-ia-y-big-data","category-tecnologias"],"jetpack_featured_media_url":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr.png","uagb_featured_image_src":{"full":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr.png",1472,704,false],"thumbnail":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr-150x150.png",150,150,true],"medium":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr-300x143.png",300,143,true],"medium_large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr-768x367.png",768,367,true],"large":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr-1024x490.png",1024,490,true],"1536x1536":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr.png",1472,704,false],"2048x2048":["https:\/\/cloudlab.urv.cat\/catedracloud\/wp-content\/uploads\/2025\/09\/Gemini_Generated_Image_lwmr8clwmr8clwmr.png",1472,704,false]},"uagb_author_info":{"display_name":"Aitor Arjona","author_link":"https:\/\/cloudlab.urv.cat\/catedracloud\/author\/aitor\/"},"uagb_comment_info":5,"uagb_excerpt":"Despu\u00e9s de conocer Deltalake y Apache Hudi en publicaciones anteriores, en este blog cerramos la tr\u00edada de formatos abiertos de tablas con Apache Iceberg. Originalmente desarrollado en Netflix y ahora convertido en un proyecto de nivel superior dentro de Apache, Iceberg se ha consolidado como una de las opciones m\u00e1s populares para los data lakehouses…","_links":{"self":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/comments?post=1493"}],"version-history":[{"count":1,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1493\/revisions"}],"predecessor-version":[{"id":1496,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/posts\/1493\/revisions\/1496"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media\/1495"}],"wp:attachment":[{"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/media?parent=1493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/categories?post=1493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudlab.urv.cat\/catedracloud\/wp-json\/wp\/v2\/tags?post=1493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}