Delta Lake, por contraste

Descripción

Esta es la única lección de las ocho guías de este ecosistema —y de las sesenta y cuatro lecciones de esta guía— donde vas a encontrar el nombre Delta Lake. No vas a instalarlo, no vas a crear una sola tabla Delta, no vas a correr una línea de código sobre él. Vas a hacer algo distinto: mirar el mismo problema exacto que las lecciones 3 a 6 de este módulo acaban de resolver sobre Iceberg —snapshots que acumulan costo, archivos que hay que compactar, limpieza que hay que hacer con seguridad— y confirmar, citando la documentación oficial de Delta Lake, que ese formato resuelve el mismo problema con un mecanismo de metadata completamente distinto por debajo, y una sintaxis de time travel casi idéntica por arriba.

Conexión con el módulo. Todo lo que viste en las lecciones 2 a 6 de este módulo —catálogos, expire_snapshots, compactación, remove_orphan_files— tiene, en Delta Lake, un equivalente directo. Esta lección no repite ese trabajo: lo contrasta, una sola vez, con evidencia citada.

Por qué el mercado nombra los dos casi en la misma frase

La auditoría de mercado que valida esta guía completa —citada en el DISEÑO— encontró algo concreto: ofertas de trabajo reales que piden, literalmente, "Apache Iceberg or Delta Lake table formats", sin distinguir entre uno y otro como si fueran alternativas intercambiables para el mismo puesto. Esto no es casualidad ni descuido de quien redactó la oferta — es un reflejo preciso del estado del mercado en 2026: dos formatos de tabla de código abierto, ambos construidos sobre Parquet, ambos resolviendo el mismo techo que Parquet solo nunca pudo resolver (el problema que el módulo 1 de esta guía abrió negando: transacciones ACID, snapshots, time travel, evolución de esquema segura). Un ingeniero de datos que solo conoce uno de los dos, en 2026, conoce la mitad del vocabulario que su propio mercado usa indistintamente.

Una analogía: dos sistemas de archivo judicial, un mismo tribunal

El módulo 2 de esta guía comparó la cadena metadata → manifest list → manifest files → data files de Iceberg con el expediente de un caso judicial: la carátula apunta al índice de pruebas de esta audiencia, que apunta a las carpetas de evidencia, que apuntan a las fotos concretas — un árbol, con varios niveles de indirección. Delta Lake resuelve el mismo problema de "reconstruir cómo se veía el caso en cualquier momento del pasado" con un archivo distinto: un libro de actas, una lista estrictamente secuencial de entradas ("acta N: se agregó la prueba X, se retiró la prueba Y"), donde reconstruir el estado en cualquier punto significa leer todas las actas desde el principio hasta ese punto —o, para no tener que leer miles de actas viejas, consultar un resumen periódico que alguien ya preparó cada diez actas—. Los dos sistemas responden exactamente la misma pregunta —"¿cómo se veía esto en el instante X?"—; uno lo hace navegando un árbol de referencias, el otro reproduciendo una secuencia de eventos.

El mecanismo de metadata: árbol vs. log plano

El módulo 2 de esta guía ya enseñó, a fondo, el árbol de Iceberg: metadata.json (con la lista completa de snapshots) apunta a un manifest list (Avro, uno por snapshot), que apunta a uno o más manifest files (Avro, cada uno enumerando archivos de datos), que apuntan, finalmente, a los archivos Parquet. Cada nivel existe para que una consulta no tenga que abrir más de lo estrictamente necesario — la Profundización del módulo 2, lección 7, ya explicó por qué existen varios métodos de inspección con costos distintos, precisamente por esta estructura de árbol.

Delta Lake resuelve el mismo problema con una estructura deliberadamente más simple: el _delta_log, un directorio con una secuencia estrictamente ordenada de archivos JSON, uno por cada commit —00000000000000000000.json, 00000000000000000001.json, 00000000000000000002.json, y así sucesivamente—, donde cada archivo describe, en JSON plano, qué archivos de datos se agregaron (add) y cuáles se retiraron (remove) en esa transacción exacta. Para no tener que reconstruir el estado leyendo miles de archivos JSON desde el commit cero, Delta Lake genera, automáticamente, un checkpoint: cada diez commits (por defecto), escribe un archivo Parquet con el estado completo consolidado hasta ese punto, así que reconstruir cualquier versión reciente solo exige leer el último checkpoint más un puñado de archivos JSON posteriores a él.

	Apache Iceberg	Delta Lake
Estructura de metadata	Árbol: metadata.json → manifest list → manifest files	Log plano: secuencia de commits JSON (_delta_log/*.json)
Formato de los archivos de metadata	JSON (metadata) + Avro (manifest list, manifest files)	JSON (cada commit) + Parquet (checkpoints periódicos)
Cada escritura crea	Un snapshot nuevo	Una versión nueva (mismo concepto, otro nombre)
Resumen periódico	No aplica igual — cada manifest list ya es autocontenido	Checkpoint Parquet cada 10 commits, por defecto

La distinción no es cosmética: un árbol permite que una consulta que solo necesita saber "qué archivos tiene el snapshot vigente" nunca tenga que tocar el historial completo de commits — exactamente la razón por la que table.inspect.files() (lección 3 de este módulo) siguió respondiendo instantáneo, sin importar cuántas noches redundantes se hubieran acumulado. Un log plano necesita, en cambio, el mecanismo de checkpoints para lograr algo parecido — sin checkpoints, reconstruir el estado vigente de una tabla con miles de commits significaría leer miles de archivos JSON, uno por uno, en orden.

Time travel: sintaxis casi idéntica, mecanismo distinto por debajo

Acá es donde el contraste se vuelve, para cualquiera que ya sepa Iceberg, sorprendentemente cómodo. La documentación oficial de Delta Lake, en "Table batch reads and writes", documenta exactamente dos formas de time travel, en SQL:

-- (representativo -- sintaxis de Delta Lake, no ejecutada en esta guia)
SELECT * FROM kiosko.dim_product VERSION AS OF 3;
SELECT * FROM kiosko.dim_product TIMESTAMP AS OF '2026-08-14 00:00:00';

Y su equivalente en DataFrame:

# (representativo -- API de Delta Lake, no ejecutada en esta guia)
df_v3 = spark.read.format("delta").option("versionAsOf", 3).load("/warehouse/kiosko/dim_product")
df_at = spark.read.format("delta").option("timestampAsOf", "2026-08-14 00:00:00").load(...)

Compáralo con lo que ya ejecutaste de verdad en el módulo 3 y el módulo 6 de esta guía:

# Iceberg -- PyIceberg, ejecutado de verdad en el modulo 3
v1_rows = table.scan(snapshot_id=snap_v1).to_arrow()

# Iceberg -- Spark SQL, sintaxis equivalente (documentacion oficial)
# SELECT * FROM local.kiosko.dim_product VERSION AS OF <snapshot-id>;
# SELECT * FROM local.kiosko.dim_product TIMESTAMP AS OF '2026-08-15 00:00:00';

Iceberg también soporta, en Spark SQL, exactamente las mismas dos palabras clave —VERSION AS OF y TIMESTAMP AS OF— con la diferencia de que "versión" en Iceberg es el snapshot-id (un entero largo, asignado por el sistema, nunca predecible de antemano, la misma regla dura que esta guía repite desde el módulo 3) y en Delta Lake es un número de versión secuencial, 0, 1, 2, 3, ..., uno por cada commit del _delta_log — más fácil de predecir a simple vista, pero exactamente igual de inútil para hardcodear en un pipeline real: la versión correcta a recuperar sigue dependiendo de cuántos commits ocurrieron antes, información que solo el propio sistema conoce con certeza.

Mantenimiento: OPTIMIZE y VACUUM, los mismos dos problemas de este módulo

Delta Lake nombra sus operaciones de mantenimiento distinto, pero resuelven, con precisión, los mismos dos problemas que las lecciones 4 a 6 de este módulo trabajaron sobre Iceberg:

Problema de este módulo	Operación en Iceberg	Operación en Delta Lake
Archivos pequeños fragmentando el snapshot/versión vigente (lección 4)	rewrite_data_files (Spark, representativo en esta guía)	OPTIMIZE <tabla>
Snapshots/versiones viejas que ya nadie necesita (lección 3)	expire_snapshots (PyIceberg, ejecutado de verdad en la lección 5)	VACUUM <tabla> [RETAIN num HOURS]
Archivos huérfanos en disco (lección 6)	remove_orphan_files (Spark, representativo en esta guía)	(el propio VACUUM cubre este caso también)

VACUUM de Delta Lake combina, en una sola operación, lo que Iceberg separa en dos —expire_snapshots (metadata) y remove_orphan_files (filesystem)—: elimina directamente los archivos de datos que ya no pertenecen a ninguna versión dentro de la ventana de retención. Su valor por defecto de retención es de siete días —más conservador todavía que los tres días por defecto de remove_orphan_files en Iceberg—, con la misma lógica de seguridad exacta que ya viste en la lección 6 de este módulo: una ventana demasiado corta arriesga borrar archivos que una escritura en curso todavía necesita.

La convergencia de 2026: la pregunta "¿cuál formato?" ya no es de funcionalidad

Hasta acá, el contraste de esta lección podría leerse como "dos formatos distintos, cada uno con su propia implementación cerrada". La evidencia de 2026 dice lo contrario. Databricks —la empresa detrás de Delta Lake, y el motor original de todo el ecosistema Spark— construyó Delta UniForm: una función que, sobre los mismos archivos Parquet de una tabla Delta, genera también metadata compatible con Iceberg, para que un cliente que solo sabe leer Iceberg pueda leer esa misma tabla sin conversión. Y, más allá de UniForm, Databricks propuso formalmente que Delta Lake 5.0 adopte el árbol de metadata de Iceberg v4 como su estructura nativa de contenido — una sola estructura en disco, legible y escribible por clientes de ambos formatos, sin ninguna capa de traducción entre medio. Como lo resume un reportaje técnico de 2026 sobre el estado de los formatos de lakehouse: "Read that plainly: the largest Delta stakeholder proposing that Delta's next major version converge onto Iceberg's next metadata design."

Esto no es un detalle de nicho. El mismo reportaje confirma que, en 2026, tanto Databricks como Snowflake —los dos motores comerciales más grandes del ecosistema, cada uno con su propio formato de origen— "leen y escriben [Iceberg] de forma nativa" ("Databricks and Snowflake both read and write it natively"), y concluye, sobre qué formato elegir para un proyecto nuevo en 2026: "Iceberg, and in 2026 this is barely a debate" — no porque Delta Lake haya dejado de funcionar o de tener adopción real, sino porque "the engine breadth, the neutral governance, the catalog ecosystem, and the fact that every other format now builds bridges to it make it the lowest-regret default". Y la lección 2 de este mismo módulo ya adelantó la pieza que cierra el círculo: Unity Catalog, el catálogo de gobierno de Databricks, implementa de forma nativa el protocolo REST Catalog de Iceberg — el mismo proveedor que inventó Delta Lake construyó su catálogo de nueva generación sobre el protocolo abierto de su competidor histórico.

La conclusión honesta, y la razón exacta por la que esta guía enseña Iceberg como su vehículo principal sin construir una segunda implementación paralela de Delta: en 2026, la pregunta "¿Iceberg o Delta Lake?" dejó de ser una pregunta de qué es capaz de hacer cada uno —ambos resuelven, con evidencia citada en esta misma lección, el mismo problema de ACID, snapshots, time travel y mantenimiento— y se convirtió en una pregunta de qué catálogo y qué motor ya tiene tu organización, sabiendo que los puentes entre ambos formatos —UniForm, la convergencia propuesta para Delta 5.0, Unity Catalog hablando REST— siguen creciendo cada trimestre.

Diagrama: mismo problema, dos caminos que convergen

flowchart TB
    P["El mismo problema:\nACID, snapshots/versiones,\ntime travel, mantenimiento"]
    P --> I["Apache Iceberg\narbol: metadata -> manifest list -> manifest files\nVERSION AS OF (snapshot-id)\nexpire_snapshots + rewrite_data_files + remove_orphan_files"]
    P --> D["Delta Lake\nlog plano: _delta_log/*.json + checkpoints\nVERSION AS OF (version secuencial)\nOPTIMIZE + VACUUM"]
    I -.->|"UniForm: metadata Iceberg\nsobre archivos Delta"| D
    D -.->|"Delta 5.0 propuesto:\narbol de metadata Iceberg v4\nnativo, sin traduccion"| I
    I -.->|"Unity Catalog:\nimplementa REST Catalog\n(leccion 2 de este modulo)"| D

Errores comunes

Pensar que, porque esta lección cita mucho a Delta Lake, esta guía "también enseña Delta Lake un poco". Qué pasa: alguien, después de leer esta lección, cree que ya sabe usar Delta Lake en la práctica, o busca ejercicios de código Delta en el resto de esta guía. Por qué pasa: la cantidad de detalle técnico citado en esta lección —sintaxis exacta, mecanismos de metadata, operaciones de mantenimiento— puede sentirse como suficiente para "saber usarlo". Cómo detectarlo: si buscas un bloque de código Delta Lake marcado como ejecutado (no representativo) en cualquier lección de esta guía, no lo vas a encontrar — ni en esta lección ni en ninguna otra. Cómo corregirlo: esta lección te da el vocabulario y el mapa conceptual para reconocer Delta Lake cuando lo encuentres en el mercado —una oferta de trabajo, un proyecto existente, una discusión técnica—, no la práctica de construirlo. Aprender a operarlo de verdad, con código ejecutado, es trabajo de una fuente dedicada a Delta Lake, fuera del alcance de esta guía.

Asumir que la convergencia de 2026 significa que "ya no importa cuál elegir, son lo mismo". Qué pasa: alguien concluye, de la sección de convergencia, que Iceberg y Delta Lake son intercambiables hoy, sin ninguna diferencia práctica. Por qué pasa: la evidencia de convergencia es real y contundente, y es fácil sobre-generalizarla. Cómo detectarlo: si tu conclusión es "no hace falta saber cuál es cuál", relee la sección de mecanismo de metadata — hoy, en 2026, siguen siendo dos estructuras en disco genuinamente distintas (árbol vs. log plano), y la propuesta de convergencia para Delta 5.0 sigue siendo, al momento de escribir esta lección, una propuesta, no un hecho consumado. Cómo corregirlo: la lectura correcta de la convergencia no es "ya da igual" — es "la decisión de cuál usar depende cada vez menos de qué es técnicamente capaz cada uno, y cada vez más de qué catálogo y qué motor ya tiene tu organización", exactamente la frase que cierra la sección de convergencia de esta lección.

Ejercicios

Ejercicio 1 — Completa la tabla de equivalencias tú mismo, de memoria, sin mirar atrás. Para cada fila —estructura de metadata, sintaxis de time travel, archivos pequeños, snapshots/versiones viejas—, escribe el nombre exacto del concepto o comando en Iceberg y en Delta Lake.

Ver solución

Estructura de metadata: árbol (metadata.json → manifest list → manifest files) en Iceberg, log plano (_delta_log/*.json + checkpoints Parquet) en Delta Lake. Time travel: VERSION AS OF <snapshot-id> / TIMESTAMP AS OF en ambos, con snapshot-id (entero largo, asignado por el sistema) en Iceberg y número de versión secuencial (0, 1, 2, ...) en Delta Lake. Archivos pequeños: rewrite_data_files en Iceberg, OPTIMIZE <tabla> en Delta Lake. Snapshots/versiones viejas: expire_snapshots + remove_orphan_files en Iceberg (dos operaciones separadas), VACUUM <tabla> [RETAIN num HOURS] en Delta Lake (una sola operación que cubre ambos casos).

Ejercicio 2 — Explica, en tus propias palabras, por qué Delta Lake necesita checkpoints Parquet y el árbol de Iceberg no necesita un mecanismo equivalente. Piensa en qué tendría que hacer cada sistema para responder "¿cuáles son los archivos de datos vigentes de esta tabla, ahora mismo?".

Ver solución

En Iceberg, la pregunta "¿cuáles son los archivos vigentes?" se responde leyendo un solo metadata.json (que apunta al manifest list del snapshot vigente, que apunta a los manifest files, que enumeran los archivos) — sin importar cuántos snapshots existan en el historial completo de la tabla, la respuesta siempre está a la misma distancia de lectura, porque cada snapshot es autocontenido. En Delta Lake, sin un checkpoint, la única forma de reconstruir el estado vigente sería leer, en orden, todos los archivos JSON del _delta_log desde el commit cero, acumulando cada add y cada remove — un trabajo que crece sin límite a medida que la tabla acumula commits. El checkpoint Parquet, generado cada diez commits, es la forma en que Delta Lake evita ese costo creciente: en vez de leer miles de archivos JSON, un lector solo necesita el checkpoint más reciente y, como mucho, los pocos archivos JSON posteriores a él — un mecanismo que Iceberg no necesita replicar, porque su estructura de árbol ya tiene esa propiedad de "distancia de lectura constante" incorporada desde el diseño.

Ejercicio 3 — Predicción: si Delta 5.0 efectivamente adopta el árbol de metadata de Iceberg v4, como propuso Databricks, ¿qué le pasaría a la fila "Estructura de metadata" de la tabla comparativa de esta lección? Piensa en qué significaría, en términos concretos, que ambos formatos compartan la misma estructura en disco.

Ver solución

Esa fila dejaría de tener dos respuestas distintas — pasaría a describir una sola estructura en disco (el árbol de metadata de Iceberg v4), legible y escribible por clientes de ambos formatos sin ninguna capa de traducción entre medio, tal como cita textualmente la sección de convergencia de esta lección ("one on-disk structure readable and writable by both formats' clients with no translation layer"). En ese escenario, la diferencia real entre "una tabla Delta" y "una tabla Iceberg" dejaría de estar en cómo se organiza la metadata en disco, y pasaría a estar, casi por completo, en qué catálogo la registra y qué ecosistema de herramientas específicas de cada proveedor la rodea — el mismo punto que la sección de convergencia ya adelanta sobre por qué la elección, cada vez más, depende del catálogo y el motor, no de la capacidad técnica del formato.

Resumen y siguiente paso

En esta lección nombraste, por primera y única vez en toda esta guía, Delta Lake — sin instalar nada, sin ejecutar una sola línea de código sobre él. Contrastaste su mecanismo de metadata (log plano de commits JSON + checkpoints Parquet) contra el árbol de Iceberg que el módulo 2 de esta guía ya enseñó a fondo, confirmaste que su sintaxis de time travel (VERSION AS OF/TIMESTAMP AS OF) es, en espíritu, casi idéntica a la de Iceberg, y mapeaste sus operaciones de mantenimiento (OPTIMIZE, VACUUM) contra las tres que este módulo trabajó sobre Iceberg. Cerraste con la evidencia de convergencia de 2026 —Delta UniForm, la propuesta de Delta 5.0, Unity Catalog hablando REST— que confirma por qué "¿cuál formato?" dejó de ser, en 2026, una pregunta de funcionalidad.

Antes de avanzar deberías poder: nombrar la diferencia central entre el mecanismo de metadata de Iceberg y el de Delta Lake; y explicar, con la evidencia citada en esta lección, por qué el mercado nombra los dos formatos casi indistintamente en 2026.

La lección 8 cierra este módulo con un proyecto que integra las operaciones reales de las lecciones 3 a 6 —reconstrucción del historial acumulado, expire_snapshots real, verificación de archivos huérfanos— en un solo script con assert automáticos, más un resumen final de qué corrió de verdad y qué quedó documentado como representativo en este módulo completo.

Recursos

• Delta Lake — documentación oficial, "Table batch reads and writes", fuente de la sintaxis exacta de VERSION AS OF/TIMESTAMP AS OF y option("versionAsOf", ...)/option("timestampAsOf", ...). docs.delta.io/latest/delta-batch.html. En inglés.
• Delta Lake — documentación oficial, "Table utility commands", fuente de la sintaxis de OPTIMIZE y VACUUM ... RETAIN num HOURS, incluido el valor de retención por defecto. docs.delta.io/delta-utility. En inglés.
• Alex Merced (DEV Community) — "Lakehouse Table Formats in 2026: Iceberg, Delta Lake, Hudi, Paimon, and DuckLake", fuente de las citas textuales sobre Delta UniForm, la propuesta de Delta 5.0, y el veredicto de convergencia de esta lección. dev.to/alexmercedcoder/lakehouse-table-formats-in-2026. En inglés.
• Esta misma guía, módulo 2, lección completa — fuente de la cadena metadata → manifest list → manifest files → data files de Iceberg que esta lección contrasta contra el _delta_log de Delta. workbook/module-02-anatomy-of-an-iceberg-table/. En español.
• src/paths/data-engineering-ecosystem/VALIDACION.md — la auditoría de mercado que cita, literal, la oferta de trabajo que pide "Apache Iceberg or Delta Lake" sin distinguir entre ambos. Documento interno del repo. En español.
• DISEÑO de esta guía — la sección del módulo 7, "Delta Lake nombrado una sola vez, por contraste". src/guides/lakehouse-and-iceberg-guide/DISENO.md. En español.