Delta Lake en Databricks: transacciones ACID y time travel

Hay un momento en el que todo ingeniero de datos agradece haber usado Delta Lake en vez de Parquet a secas: el día que alguien borra por error medio millón de filas y hay que recuperarlas sin restaurar un backup completo. Eso es posible gracias a dos ideas centrales de Delta Lake: las transacciones ACID y el time travel.

Qué es Delta Lake

Delta Lake es una capa de almacenamiento de código abierto que sirve de base optimizada para las tablas en un lakehouse de Databricks; de hecho, es el formato por defecto de todas las tablas en Azure Databricks. Su idea central es extender los ficheros Parquet, que por sí solos son solo datos, con un registro de transacciones basado en ficheros que aporta gestión fiable de metadatos y transacciones ACID a gran escala.

Cómo aporta transacciones ACID

Sobre un data lake de ficheros Parquet «planos», dos procesos escribiendo a la vez sobre la misma tabla es una receta para corromper datos. Delta Lake lo resuelve con control de concurrencia optimista en tres fases: primero lee la última versión de la tabla para saber qué ficheros tocan una operación, después escribe los ficheros de datos nuevos, y por último valida que no haya habido escrituras concurrentes en conflicto antes de comprometer (commit) la nueva versión en el log. Si hay conflicto, la escritura falla limpiamente en vez de dejar la tabla a medias.

Esto es exactamente lo que da a Delta Lake sus garantías ACID: atomicidad (la escritura se aplica entera o no se aplica), consistencia (el esquema se valida al escribir), aislamiento (lecturas con snapshot isolation, escrituras con isolation serializable) y durabilidad (heredada del almacenamiento de objetos en la nube donde viven los ficheros).

Time travel: consultar el pasado de una tabla

Como cada escritura queda registrada como una versión numerada en el transaction log, Delta Lake permite consultar exactamente cómo estaba una tabla en cualquier punto anterior. Hay dos sintaxis principales en SQL:

SELECT * FROM ventas VERSION AS OF 42 consulta la tabla tal como quedó tras la versión 42. SELECT * FROM ventas TIMESTAMP AS OF '2026-08-01T00:00:00Z' hace lo mismo pero referenciando una marca de tiempo en lugar de un número de versión. También se puede consultar el historial completo con DESCRIBE HISTORY ventas, que muestra cada operación, usuario, marca de tiempo y métricas asociadas.

Por defecto Delta Lake retiene el historial necesario para viajar en el tiempo durante un tiempo limitado (configurable mediante las propiedades delta.logRetentionDuration y delta.deletedFileRetentionDuration de la tabla); pasado ese periodo, y sobre todo tras ejecutar VACUUM, los ficheros de versiones antiguas pueden eliminarse físicamente y dejan de estar disponibles para time travel.

Casos de uso reales

Pensemos en un pipeline de pedidos de una plataforma de ventas genérica que cada noche actualiza la tabla gold.pedidos_diarios. Si una carga defectuosa introduce duplicados, basta con hacer RESTORE TABLE gold.pedidos_diarios TO VERSION AS OF la versión anterior a la carga fallida para volver al estado bueno, sin tocar backups externos. Si un analista necesita auditar quién modificó una fila de un cliente concreto y cuándo, DESCRIBE HISTORY da la traza completa. Y si un equipo de ciencia de datos necesita reproducir exactamente los resultados de un modelo entrenado hace tres semanas, puede consultar la tabla de entrenamiento con TIMESTAMP AS OF esa fecha exacta, garantizando que el experimento es reproducible byte a byte.

• Usa DESCRIBE HISTORY antes de un RESTORE para confirmar qué versión es realmente la buena.
• No confíes en time travel a largo plazo como sustituto de un backup: VACUUM elimina físicamente los ficheros antiguos.
• Ajusta delta.logRetentionDuration si tu caso de uso (auditoría, cumplimiento normativo) necesita ventanas de retención más largas que el valor por defecto.
• Aprovecha TIMESTAMP AS OF para reproducir de forma exacta el dataset de entrenamiento de un modelo de machine learning.
• Un MERGE contra una versión anterior de la misma tabla es una forma elegante de corregir actualizaciones incorrectas sin reprocesar todo el pipeline.