Cómo usar Time Travel en una tabla Delta en Databricks

João Barros 12 de July de 2026 5 min de lectura

El Time Travel en una tabla Delta en Databricks permite consultar los datos tal y como estaban en una versión anterior o en un momento concreto del pasado, sin copias de seguridad manuales. Es la red de seguridad ideal cuando un MERGE sale mal, un pipeline duplica filas o alguien pregunta qué números había la semana pasada. Con SQL y PySpark puedes revisar el historial, leer una versión antigua y restaurar la tabla en pocos minutos.

Requisitos previos

Acceso a un workspace de Databricks con un cluster o SQL Warehouse activo.
Una tabla en formato Delta (por ejemplo vendas) con al menos dos escrituras realizadas.
Permisos de lectura sobre la tabla y, para restaurar, permisos de escritura (MODIFY en Unity Catalog).
Nociones básicas de SQL. PySpark es opcional.

Paso 1: Confirmar que la tabla es realmente Delta

El Time Travel solo existe en tablas Delta. Antes de nada, comprueba el formato en un notebook o en el editor SQL:

DESCRIBE DETAIL vendas;

En la columna format debe aparecer delta. Si aparece parquet o csv, no hay historial de versiones y este ejemplo no aplica.

Paso 2: Ver el historial de versiones de la tabla

Cada escritura (INSERT, UPDATE, DELETE, MERGE, OPTIMIZE) crea una nueva versión. Este comando muestra esa lista:

DESCRIBE HISTORY vendas;

Las columnas más útiles son:

version: el número de versión (0, 1, 2, ...), que usarás en el Time Travel.
timestamp: cuándo se creó la versión.
operation: qué ocurrió (WRITE, MERGE, DELETE...).
operationMetrics: cuántas filas se insertaron, actualizaron o eliminaron.

Apunta el número de la última versión buena, es decir, la anterior al error.

Paso 3: Consultar una versión antigua con Time Travel

Hay dos formas de viajar en el tiempo: por número de versión o por fecha y hora.

-- Por versión
SELECT * FROM vendas VERSION AS OF 12;

-- Por fecha y hora
SELECT * FROM vendas TIMESTAMP AS OF '2026-07-11 09:00:00';

Lo mismo en PySpark, útil cuando quieres trabajar con el resultado en un DataFrame:

df_antigo = (spark.read
    .format("delta")
    .option("versionAsOf", 12)
    .table("vendas"))

df_antigo.count()

Un error habitual es pedir un TIMESTAMP AS OF más antiguo que la primera versión de la tabla. Databricks devuelve un error indicando que la versión no existe: en ese caso, usa DESCRIBE HISTORY para elegir un timestamp válido.

Paso 4: Comparar dos versiones para medir el daño

Antes de restaurar, conviene saber exactamente qué cambió. Empieza por los recuentos:

SELECT
  (SELECT count(*) FROM vendas VERSION AS OF 12) AS antes,
  (SELECT count(*) FROM vendas) AS agora;

Después, mira las filas que existen ahora pero no existían antes:

SELECT * FROM vendas
EXCEPT
SELECT * FROM vendas VERSION AS OF 12;

Si el resultado es exactamente el conjunto de filas duplicadas o erróneas, ya tienes el diagnóstico confirmado.

Paso 5: Restaurar la tabla a una versión anterior

Con la versión correcta identificada, restaurar es una sola línea:

RESTORE TABLE vendas TO VERSION AS OF 12;

-- Alternativa, por fecha y hora
RESTORE TABLE vendas TO TIMESTAMP AS OF '2026-07-11 09:00:00';

Fíjate en que RESTORE no borra el historial: crea una nueva versión cuyo contenido es igual al de la versión 12. Es decir, la restauración también es reversible. Si prefieres no tocar la tabla original, crea una copia:

CREATE TABLE vendas_backup
DEEP CLONE vendas VERSION AS OF 12;

Paso 6: Saber hasta dónde puedes viajar en el tiempo

El Time Travel depende de que los ficheros antiguos sigan existiendo. VACUUM elimina los ficheros que ya no se referencian (por defecto, con más de 7 días) y el log de transacciones tiene su propia retención. Para ampliar la ventana en una tabla crítica:

ALTER TABLE vendas SET TBLPROPERTIES (
  delta.logRetentionDuration = 'interval 90 days',
  delta.deletedFileRetentionDuration = 'interval 30 days'
);

Retenciones más largas significan más ficheros guardados y más coste de almacenamiento. Ajústalo solo en las tablas donde el historial tiene valor real.

Verificar el resultado

Tras la restauración, ejecuta de nuevo el historial:

DESCRIBE HISTORY vendas;

Deberías ver una nueva fila con operation = RESTORE en la parte superior. Confirma después que los datos han vuelto a lo esperado:

SELECT count(*) FROM vendas;

Si el recuento coincide con el de la versión 12 y la consulta del Paso 4 (EXCEPT) ya no devuelve filas, el Time Travel ha hecho su trabajo.

Conclusión

Con DESCRIBE HISTORY, VERSION AS OF y RESTORE TABLE tienes un mecanismo sencillo de auditoría y recuperación para cualquier tabla Delta. El siguiente paso natural es automatizar: una prueba de calidad al final del pipeline que, al detectar una anomalía, guarde el número de la versión anterior para una restauración rápida. Un consejo final: antes de cualquier carga arriesgada, ejecuta DESCRIBE HISTORY y anota la versión actual — es el equivalente Delta a abrocharse el cinturón. ¿Sabes cuál es la ventana de Time Travel de tus tablas más críticas?