Explicación de los formatos de tabla abiertos: Iceberg vs. Delta vs. Hudi

Los formatos de tabla abiertos son capas de metadatos que se ubican sobre los archivos de datos en el almacenamiento de objetos, lo que añade transacciones ACID, evolución del esquema y viaje en el tiempo a los datos almacenados en un data lake. Apache Iceberg, Delta Lake y Apache Hudi son los tres formatos de tabla abiertos principales en producción hoy en día, y cada uno convierte una colección de archivos Parquet u ORC en una tabla que se comporta como una base de datos: los lectores ven resultados consistentes, los escritores pueden actualizar y eliminar filas de forma segura, y se realiza un seguimiento de cada cambio para que las versiones anteriores sigan siendo consultables.

Esta descripción general explica cómo funcionan los principales formatos de tabla abiertos, cómo se comparan en cuanto al soporte de transacciones ACID y la evolución del esquema, y cómo se relacionan con la arquitectura de data lakehouse, aprovechando las innovaciones de la capa de almacenamiento como las transacciones coordinadas por catálogo, el linaje de filas y los metadatos unificados para mostrar dónde convergen Delta Lake y Apache Iceberg.

¿Qué es un data lake y por qué son importantes los formatos de tabla abiertos?

Un data lake es un repositorio centralizado creado en un almacenamiento de objetos de bajo costo (como Amazon S3, Azure Data Lake Storage o Google Cloud Storage) que contiene datos estructurados, semiestructurados y no estructurados en su formato original y nativo. Las organizaciones adoptaron los data lakes porque el almacenamiento de objetos escala de forma económica y separa el almacenamiento del procesamiento (compute), lo que permite que cualquier motor de consultas lea los mismos datos. Sin embargo, el almacenamiento de objetos nunca se diseñó para garantizar la consistencia: no tiene un concepto nativo de tabla, esquema o transacción.

Un data lakehouse añade una estructura similar a la de una tabla, gobernanza y rendimiento a ese almacenamiento sin procesar, combinando el bajo costo de un data lake con la confiabilidad de un data warehouse. El puente entre ambos es el formato de tabla abierto: convierte archivos sueltos en el almacenamiento de objetos en tablas gobernadas y consultables sin necesidad de copiar los datos a un warehouse propietario.

Antes de que existieran los formatos de tabla abiertos, realizar análisis en los data lakes tradicionales causaba problemas persistentes: los escritores concurrentes podían corromper los datos a mitad de la escritura, las actualizaciones y eliminaciones implicaban reescribir particiones enteras y no había una forma confiable de saber qué archivos representaban el estado actual y correcto de una tabla. Los formatos de tabla abiertos gestionan los metadatos de los archivos de datos en el almacenamiento de objetos, realizando un seguimiento exacto de qué archivos pertenecen a una tabla, la estandarización que finalmente permitió a los data lakes admitir funciones similares a las de una base de datos, como las actualizaciones a nivel de registro.

Los formatos de tabla y formatos de archivo abiertos que debes conocer

Apache Iceberg

Apache Iceberg, desarrollado originalmente en Netflix y ahora un proyecto de la Apache Software Foundation, fue diseñado para hacer que las tablas enormes y de cambio lento sean rápidas de consultar y seguras de evolucionar. Apache Iceberg utiliza una estructura de árbol para una gestión eficiente de los metadatos: los archivos de manifiesto (manifest files) y las listas de manifiestos (manifest lists) realizan un seguimiento de cada archivo de datos en una tabla, lo que permite a los motores de consulta descartar datos irrelevantes antes de que comience un escaneo. Las tablas de Iceberg admiten la evolución del esquema y la evolución de las particiones sin necesidad de reescribir los archivos subyacentes.

Delta Lake

Delta Lake, creado por Databricks y lanzado como código abierto, llevó las transacciones ACID a las cargas de trabajo de Apache Spark a través de un registro de transacciones de escritura anticipada (write-ahead transaction log). Delta Lake se originó en Databricks y se integra de forma nativa con Spark, aunque ahora admite un amplio conjunto de motores a través de conectores independientes. Las tablas de Delta Lake registran cada escritura como una entrada de registro ordenada y atómica, lo que ofrece a los lectores una vista consistente incluso mientras se escriben nuevos datos.

Apache Hudi

Apache Hudi, abreviatura de Hadoop Upserts Deletes and Incrementals, está diseñado en torno a actualizaciones rápidas y frecuentes a nivel de registro. Apache Hudi se optimiza para actualizaciones frecuentes y datos en streaming mediante el mantenimiento de índices que localizan el archivo exacto que contiene un registro determinado, lo que permite actualizaciones eficientes a nivel de registro sin necesidad de realizar un escaneo completo de la tabla. Este diseño hace de Hudi una opción común para pipelines de captura de datos modificados (change-data-capture o CDC) e ingesta casi en tiempo real.

Parquet y ORC

Parquet y ORC son formatos de archivo columnares, no formatos de tabla: definen cómo se organizan los archivos de datos individuales, no cómo los archivos se convierten en una tabla gobernada. Iceberg, Delta Lake y Hudi están basados en archivos Parquet (Iceberg y Hudi también admiten ORC), utilizando estadísticas a nivel de archivo que almacena Parquet para descartar datos antes de que un motor de consultas los lea. Esa distinción, formato de archivo frente a formato de tabla, aclara la mayor parte de la confusión empresarial sobre dónde comienzan las responsabilidades de cada capa.

Iceberg frente a Delta Lake frente a Hudi: comparación rápida

Los tres formatos de tabla abiertos principales ahora comparten más capacidades de las que los diferencian, pero la siguiente tabla destaca dónde se sigue notando su historial de diseño.

Por dentro de Apache Iceberg: tablas y metadatos

El árbol de metadatos de Iceberg

Una tabla de Iceberg se define mediante un árbol de metadatos, no por un solo archivo: un archivo de metadatos apunta a una lista de manifiestos, que a su vez apunta a archivos de manifiesto que enumeran los archivos de datos reales que componen una instantánea (snapshot). Esta estructura en capas permite que un motor de consultas descarte manifiestos y archivos de datos irrelevantes utilizando estadísticas de columnas almacenadas sin abrir un solo archivo, lo que mejora el rendimiento de las consultas en tablas con millones de archivos.

Instantáneas (snapshots) y viaje en el tiempo

Cada escritura en una tabla de Iceberg crea una nueva instantánea (snapshot), un registro inmutable de qué archivos de datos existían en ese momento, y el árbol de metadatos mantiene un historial de las instantáneas anteriores. Esto permite el viaje en el tiempo: los motores pueden consultar una tabla tal como existía en un ID de instantánea o marca de tiempo específicos, lo que facilita la auditoría, los conjuntos de entrenamiento de ML reproducibles y la restauración al último estado estable después de una escritura incorrecta.

Evolución de particiones

Iceberg desacopla la partición física de una tabla de sus patrones de consulta a través de la evolución de particiones, lo que permite a los equipos cambiar la forma en que se particionan los nuevos datos sin reescribir los archivos existentes ni romper las consultas contra el esquema antiguo. La partición oculta significa que los analistas no necesitan hacer referencia directa a las columnas de partición física para obtener el descarte de particiones (partition pruning).

Aspectos internos y mantenimiento de las tablas de Iceberg

Debido a que cada escritura produce una nueva instantánea con su propia lista de manifiestos, una tabla de Iceberg en la que se escribe activamente puede acumular miles de pequeños archivos de manifiesto y de datos si no se gestiona. Los motores de consulta aún tienen que abrir y evaluar cada archivo de manifiesto relevante, por lo que la proliferación de manifiestos erosiona las mejoras de rendimiento de las consultas para las que se diseñó el árbol de metadatos.

El remedio estándar es la compactación programada: una tarea de mantenimiento que reescribe archivos de datos pequeños en menos archivos de mayor tamaño y consolida los manifiestos, ejecutándose de forma nocturna o por horas según el volumen de ingesta. Combinar la compactación con la expiración periódica de instantáneas (eliminando los metadatos que superen una ventana de retención) mantiene bajo control el tamaño del almacenamiento y de los metadatos sin limitar el alcance del viaje en el tiempo.

Delta Lake y transacciones ACID

El registro de transacciones de Delta Lake

Las tablas de Delta Lake almacenan un registro de transacciones ordenado y de solo adición (append-only), que consiste en una secuencia de entradas JSON que registran cada adición, eliminación y cambio de metadatos, junto con archivos de punto de control (checkpoint) periódicos que resumen el registro para lecturas más rápidas. Históricamente, el propio sistema de archivos actuaba como coordinador de confirmaciones (commits), lo que significaba que cualquier cliente con acceso a nivel de archivo podía escribir directamente en una tabla Delta, sin pasar por un catálogo gobernado.

Cómo se comportan las transacciones ACID en Delta Lake

Las transacciones ACID garantizan la consistencia de los datos durante las escrituras concurrentes al requerir que cada escritor verifique la versión actual del registro, genere una nueva entrada y la confirme solo si no se produjo ningún cambio conflictivo en el intervalo; si se detecta un conflicto, el escritor vuelve a intentarlo. El cumplimiento de ACID evita la corrupción de datos porque un lector nunca ve una tabla de Delta Lake en un estado parcialmente escrito, y las transacciones ACID permiten operaciones de datos complejas sin conflictos en particiones superpuestas.

De nativo de Spark a soporte multimotor

Debido a que el modelo de confirmación original de Delta Lake dependía del acceso al sistema de archivos, los motores de terceros ajenos a Apache Spark tenían que acceder a las tablas a través de rutas de archivos estáticas en lugar de un catálogo gobernado, lo que dejaba esos accesos sin gobernanza y con la posibilidad de romper silenciosamente las relaciones de esquema. Databricks solucionó esto con las confirmaciones de catálogo (catalog commits), un estándar abierto que permite que un catálogo como Unity Catalog actúe como coordinador de confirmaciones, de modo que cada solicitud de lectura, escritura y descubrimiento se autorice de forma centralizada. Las confirmaciones de catálogo ya están disponibles de forma general, lo que alinea a Delta Lake con el enfoque orientado a catálogos que Iceberg ha utilizado desde el principio y desbloquea las transacciones multitabla.

Fundamentos de los formatos de archivo: cómo Parquet permite la omisión de datos (data skipping)

Un archivo Parquet organiza los datos tabulares por columnas en lugar de por filas, agrupando los valores de la misma columna en bloques contiguos llamados grupos de filas (row groups). El almacenamiento columnar permite que un motor de consultas lea solo las columnas a las que hace referencia una consulta, omitiendo el resto; una de las razones principales por las que Parquet supera a los formatos orientados a filas en cargas de trabajo con un alto volumen de escaneos.

Cada grupo de filas contiene estadísticas (valores mínimos y máximos, recuentos de nulos y distribuciones de valores por columna) escritas en el pie de página de metadatos del archivo. Estas estadísticas permiten que un motor determine, sin descomprimir ningún dato, si un grupo de filas podría coincidir con el filtro de una consulta.

Los formatos de tabla abiertos extienden este principio a un nivel superior: los archivos de manifiesto de Iceberg y el registro de transacciones de Delta Lake almacenan en caché las estadísticas a nivel de Parquet en la capa de metadatos, de modo que un motor puede omitir archivos de datos completos antes de enumerarlos desde el almacenamiento de objetos. Esta omisión de datos en dos niveles contribuye de manera importante a mejorar el rendimiento de las consultas en tablas grandes. Databricks también ha ampliado el modelo con el tipo de datos Variant (ahora parte de Parquet, Delta Lake e Iceberg), que almacena cargas útiles semiestructuradas en formato binario con tipo en lugar de JSON sin procesar, de modo que los motores extraen campos anidados sin necesidad de un análisis costoso.

Versionado de datos, viaje en el tiempo y procesamiento incremental

El versionado de datos es la capacidad de un formato de tabla abierto para conservar un registro de cada estado anterior de la tabla en lugar de sobrescribir los datos en el mismo lugar, y el viaje en el tiempo (time travel) lee cualquiera de esas versiones anteriores mediante el número de versión, el ID de la instantánea (snapshot) o la marca de tiempo. Los formatos de tabla abiertos permiten el viaje en el tiempo y el versionado de conjuntos de datos por diseño, ya que cada escritura ya crea una nueva instantánea o entrada de registro direccionable de forma independiente.

El procesamiento incremental lee solo las filas que cambiaron desde la última vez que se procesó una tabla en lugar de volver a escanear un conjunto de datos completo; este es el patrón detrás de Change Data Capture (CDC), donde las canalizaciones consumen solo las inserciones, actualizaciones y eliminaciones aplicadas a una tabla de origen. El linaje de filas y los vectores de eliminación, introducidos en Delta Lake y llevados a Iceberg a través de Iceberg v3, abarataron este proceso: el linaje de filas realiza un seguimiento de qué filas cambiaron desde el último escaneo de la tabla, y los vectores de eliminación representan las filas eliminadas como un mapa de bits compacto en lugar de tener que volver a escribir los archivos de datos.

Conservar todas las versiones históricas de forma indefinida es costoso, por lo que los formatos de tabla abiertos combinan el versionado con políticas de retención y una operación de vacuum o de expiración de instantáneas que elimina los datos que ya no se mencionan dentro de la ventana de retención. Ejecutar vacuum de forma demasiado agresiva puede romper las consultas de viaje en el tiempo que aún hacen referencia a versiones anteriores, por lo que las ventanas se configuran para que coincidan con la consulta de mayor duración que pueda necesitar una.

Una frecuencia razonable para las tablas de producción combina el procesamiento incremental en intervalos adaptados a la ingesta (a menudo cada 5 a 15 minutos para la ingesta de datos en streaming) con la ejecución diaria de vacuum y la expiración de instantáneas, fuera de las horas pico de consulta.

Gestión de metadatos y optimización del rendimiento

Los formatos de tabla abiertos mejoran el rendimiento de las consultas mediante una gestión de metadatos organizada en capas: los archivos de manifiesto o las entradas de registro describen archivos de datos individuales, las instantáneas o las versiones de registro describen el estado de la tabla en un momento dado, y un catálogo realiza un seguimiento de qué versión es la autoritativa en ese momento. Unity Catalog gobierna hoy en día más de 17 exabytes de datos en formatos de tabla abiertos en implementaciones empresariales, lo que da una idea de la cantidad de metadatos que gestiona actualmente un catálogo de lakehouse moderno.

A medida que las tablas crecen, los archivos de manifiesto y los puntos de control (checkpoints) del registro de transacciones pueden ralentizar la planificación de las consultas, por lo que el mantenimiento debe incluir la reescritura de los manifiestos en menos archivos y más grandes, así como el ajuste de los intervalos de los puntos de control según la frecuencia de escritura. Databricks y la comunidad de código abierto están desarrollando una estructura de metadatos unificada para Delta Lake e Iceberg, prevista en versión preliminar para el tercer trimestre, que combina el registro de escritura rápida de Delta Lake con el árbol de manifiestos de lectura rápida de Iceberg.

El almacenamiento en caché de metadatos (mantener en memoria los manifiestos, puntos de control o respuestas del catálogo a los que se ha accedido recientemente) reduce la latencia de las consultas repetidas al evitar un recorrido completo del árbol de metadatos en cada solicitud, lo que resulta de suma importancia para las cargas de trabajo de BI que realizan muchas consultas pequeñas en las mismas tablas grandes.

Transacciones ACID y control de concurrencia

Apache Iceberg, Delta Lake y Apache Hudi garantizan el aislamiento serializable o de instantánea para las escrituras en una sola tabla, de modo que los lectores concurrentes siempre ven una versión completa y coherente, y nunca una escritura parcial. En lo que difieren es en la coordinación: Iceberg siempre ha utilizado el catálogo como fuente de verdad, Hudi utiliza su propio servicio de línea de tiempo y Delta Lake dependía de la atomicidad del sistema de archivos antes de que las confirmaciones (commits) del catálogo lo alinearan con el modelo coordinado por el catálogo.

Los tres formatos utilizan un control de concurrencia optimista: en lugar de bloquear una tabla antes de escribir, un escritor lee la versión actual, prepara su cambio y lo confirma solo si ningún otro escritor ha confirmado un cambio en conflicto mientras tanto. Si se detecta un conflicto, la transacción falla de forma segura y se reintenta con la versión más reciente o se cancela, sin dejar nunca la tabla en un estado incoherente.

La forma más eficaz de reducir la contención de escritura es disminuir la superposición entre escritores concurrentes: particionar los trabajos de ingesta para que diferentes canalizaciones escriban en particiones distintas, agrupar las escrituras pequeñas en menos confirmaciones y más grandes, y limitar el alcance de las operaciones de fusión (merge) solo a las particiones que afectan. Las confirmaciones del catálogo también ayudan en este aspecto, ya que las transacciones multitabla permiten que las actualizaciones relacionadas se confirmen juntas en lugar de competir como escrituras independientes de múltiples procesos.

Cómo elegir un formato de tabla para su Data Lake

Apache Iceberg suele adaptarse mejor cuando el acceso de lectura multimotor es lo más importante: organizaciones que consultan las mismas tablas desde Trino, Snowflake, Flink y Spark de forma simultánea. Delta Lake es ideal para canalizaciones centradas en Spark que necesitan transacciones multitabla y una gobernanza detallada. Apache Hudi es el más adecuado para cargas de trabajo de upsert a nivel de registro y de alta frecuencia, como la replicación de CDC, donde su indexación diseñada específicamente supera a las operaciones de fusión (merge) de propósito general.

La compatibilidad del motor debe evaluarse en función de los motores de consulta que ya están en producción, no solo de una lista de características: un formato técnicamente superior que carece de un conector maduro para el motor principal de un equipo añade más riesgo del que elimina. Delta Kernel, una biblioteca de código abierto en Java y Rust, se ha convertido en una forma habitual en la que los motores añaden soporte para Delta Lake sin tener que volver a implementar el protocolo; ya impulsa las integraciones de DuckDB y ClickHouse, y ambas implementaciones están convergiendo en un núcleo compartido de Rust.

Antes de estandarizar un formato, realice una prueba de concepto con una tabla de producción representativa y moderadamente compleja: mida la latencia de escritura bajo una carga concurrente, confirme que los motores de destino leen el formato de forma nativa en lugar de a través de un conector lento, y valide que la evolución del esquema y el viaje en el tiempo se comporten como se espera.

Interoperabilidad, catálogos y consideraciones sobre proveedores

Opciones de catálogo e interoperabilidad entre formatos

Un catálogo es el sistema de registro que realiza un seguimiento de qué tablas existen, dónde residen sus datos y qué instantánea es la autoritativa; las opciones incluyen el Hive Metastore original, AWS Glue Data Catalog y Unity Catalog, que gobierna las tablas de Delta Lake y Apache Iceberg de forma conjunta bajo un único conjunto de políticas de acceso. Delta Lake UniForm va más allá, al permitir que una sola copia de los datos de Delta Lake se lea de forma nativa como una tabla de Iceberg sin duplicar el almacenamiento, lo que aborda la preocupación por la dependencia del formato que lleva a los equipos a retrasar la estandarización.

Riesgos de dependencia del proveedor y cómo mitigarlos

La forma más clara de mitigar el riesgo de dependencia del proveedor es elegir un formato con más de una implementación de motor independiente y confirmar que el acceso al catálogo —no solo el acceso a los archivos— sea portátil entre las plataformas que un equipo pueda necesitar más adelante. Dado que Iceberg y Delta Lake son de código abierto, almacenar datos en cualquiera de ellos no vincula por sí mismo a una organización a un único motor de procesamiento, aunque las capas de gobernanza creadas sobre ellos pueden variar en portabilidad.

Operaciones, monitoreo y mejores prácticas

El mantenimiento de las tablas debe codificarse como un runbook (manual de procedimientos), no como una tarea ad hoc: defina qué tablas necesitan compactación y con qué umbral de tamaño de archivo, establezca ventanas de retención para vacuum y la expiración de instantáneas en función de qué tan atrás consultan los datos los trabajos, y programe ambos procesos fuera de las ventanas pico de consulta.

El monitoreo del estado de las tablas debe realizar un seguimiento del recuento de archivos y el tamaño promedio de los archivos por tabla, las tasas de fallas de confirmación y la antigüedad del archivo de datos más antiguo en relación con un programa de compactación, alertando cuando se disparan los recuentos de archivos pequeños o las tasas de conflicto. Estas métricas detectan la saturación de metadatos y la contención de escritura antes de que cualquiera de ellas se manifieste como consultas lentas.

Debido a que los formatos de tabla abiertos admiten la evolución del esquema sin romper las consultas existentes, los cambios de esquema a menudo se aplican directamente a las tablas de producción, pero esa facilidad hace que sea sencillo omitir las pruebas. Los equipos deben validar los cambios con consultas representativas de flujo de salida (downstream) y ensayar periódicamente una reversión (rollback) a una instantánea anterior, de modo que recuperarse de un cambio erróneo sea un procedimiento practicado y no un primer intento bajo presión.

Conclusión: Ventajas y desventajas de los formatos de tabla abiertos y próximos pasos

Apache Iceberg, Delta Lake y Apache Hudi resuelven el mismo problema central (llevar transacciones ACID, evolución del esquema y viaje en el tiempo a los datos almacenados en un almacenamiento de objetos económico) a través de diseños de metadatos definidos por el punto de partida de cada uno: analítica multimotor para Iceberg, canalizaciones nativas de Spark para Delta Lake y upserts de alta frecuencia para Hudi. Parquet sigue siendo el formato de archivo común debajo de los tres, y las innovaciones recientes (vectores de eliminación, linaje de filas, Variant y confirmaciones coordinadas por el catálogo) están convergiendo entre los formatos en lugar de permanecer aisladas.

El siguiente paso práctico para la mayoría de los equipos es una prueba de concepto acotada: elegir el formato que coincida con la pila de motores existente, probarlo con volúmenes de datos de producción reales y confirmar que el catálogo que lo gobierna pueda extenderse a un segundo formato más adelante. El almacenamiento de lakehouse abierto e independiente del formato de Databricks permite a los equipos almacenar datos una sola vez y consultarlos de forma nativa como Delta Lake o Apache Iceberg, gobernados bajo un único catálogo, sin duplicar datos ni limitarse a un solo formato.

Preguntas frecuentes sobre los formatos de tabla abiertos

¿Qué es un formato de tabla abierto?

Un formato de tabla abierto es una capa de metadatos de código abierto que se ubica sobre los archivos de datos en el almacenamiento de objetos y agrega características similares a las de una base de datos (transacciones ACID, evolución del esquema y viaje en el tiempo) a un data lake. Apache Iceberg, Delta Lake y Apache Hudi son los tres formatos de tabla abiertos principales en uso de producción, y cada uno convierte una colección de archivos Parquet u ORC en una tabla que cualquier motor compatible puede leer y escribir de forma segura.

¿Cuál es la diferencia entre un formato de tabla y un formato de archivo?

Un formato de archivo como Parquet u ORC define cómo se comprime y organiza un archivo de datos individual en el disco, mientras que un formato de tabla como Apache Iceberg o Delta Lake define cómo varios de esos archivos juntos forman una tabla consistente y consultable. Los formatos de tabla abiertos se construyen sobre los formatos de archivo, agregando la capa de metadatos (manifiestos, registros de transacciones y catálogos) que los formatos de archivo por sí solos no proporcionan.

¿Pueden trabajar juntas las tablas de Delta Lake y Apache Iceberg?

Sí. Delta Lake UniForm permite que una sola copia de los datos de la tabla de Delta Lake se lea de forma nativa como una tabla de Apache Iceberg sin duplicar el almacenamiento, y los catálogos como Unity Catalog pueden gobernar ambos formatos de manera conjunta bajo un único conjunto de políticas de acceso. Esta interoperabilidad permite a las organizaciones estandarizar en una gobernanza compartida sin obligar a cada motor a usar el mismo formato de tabla.

¿Qué formato de tabla abierto debería elegir?

El mejor formato de tabla abierto depende de los motores de consulta y la carga de trabajo que ya estén en producción: Apache Iceberg es ideal para análisis multimotor en herramientas como Trino y Snowflake, Delta Lake es adecuado para pipelines centrados en Spark que necesitan transacciones multitabla, y Apache Hudi se adapta a cargas de trabajo de upsert a nivel de registro de alta frecuencia, como la replicación CDC. Una prueba de concepto con datos de producción reales confirmará la opción adecuada.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original