Time travel

¿Qué es?

Time travel es la capacidad de consultar una tabla tal como estaba en un momento anterior, sin haber guardado copias manuales. El motor conserva las versiones sucesivas de la tabla y permite dirigir la consulta a una de ellas, identificándola por marca de tiempo o por número de versión.

No es un backup ni un histórico modelado a mano: es una propiedad del formato de tabla, que funciona sobre los datos de producción.

Cómo funciona

Los formatos de tabla abiertos del data lakehouse —Apache Iceberg, Delta Lake, Apache Hudi— no sobrescriben ficheros cuando cambia un dato. Cada escritura genera ficheros nuevos y añade una entrada al log de metadatos que describe qué ficheros componen la tabla a partir de ese momento. Esa entrada es un snapshot.

La consecuencia es directa: si el log conserva los snapshots anteriores y sus ficheros no se han eliminado, leer la tabla “de ayer” consiste en leer la lista de ficheros que el snapshot de ayer declaraba.

Por eso el time travel tiene un límite práctico: las tareas de mantenimiento que borran ficheros huérfanos y caducan snapshots antiguos —necesarias para que el almacenamiento no crezca sin control— son también las que marcan hasta dónde se puede retroceder. La ventana disponible es una decisión de configuración, no una propiedad infinita.

¿Para qué sirve?

• Reproducir un resultado: volver a ejecutar un informe con los datos que había cuando se calculó, en vez de discutir por qué hoy sale otra cifra.
• Depurar una carga: comparar el antes y el después de un proceso que ha dejado la tabla mal, para ver exactamente qué tocó.
• Recuperarse de un error: restaurar la tabla a un snapshot previo tras un borrado o una actualización equivocada, sin restaurar un backup completo.
• Auditoría: demostrar qué contenía una tabla en una fecha concreta.
• Entrenamiento de modelos: fijar el conjunto de datos de entrenamiento a una versión concreta para que el experimento sea repetible.

Ejemplo

Un equipo detecta que el informe de ventas del cierre mensual no cuadra con el que se presentó hace dos semanas. En vez de reconstruir el histórico, consultan la tabla de hechos en el snapshot correspondiente a la fecha de aquel informe y comparan ambos resultados. Aparece la causa: una carga posterior corrigió con retraso pedidos de un almacén. El informe antiguo no estaba mal calculado, estaba calculado con menos datos.

Sin time travel, esa conversación habría acabado en “algo habrá pasado”.

No confundir con CDC

El CDC y el time travel se usan a veces con el mismo objetivo —saber cómo estaban los datos antes— pero funcionan al revés. El CDC captura los cambios según ocurren en el sistema origen y los propaga a otro sistema: hay que tenerlo montado de antemano para tener el histórico. El time travel no captura nada: aprovecha las versiones que el formato de tabla ya genera al escribir, y se consulta a posteriori.

Son complementarios. El CDC alimenta la tabla del lakehouse; el time travel permite consultar los estados que esa tabla fue teniendo.

Tampoco es lo mismo que una dimensión histórica

Una dimensión de cambio lento guarda el histórico dentro del modelo de datos, con columnas de vigencia, porque el negocio necesita consultarlo: a qué comercial pertenecía un cliente cuando se firmó el pedido. El time travel es una propiedad técnica de la plataforma y no aparece en el modelo. Si el histórico forma parte de las preguntas de negocio, se modela; el time travel no lo sustituye.

Más información

• Almacenamiento de datos: data lakes, data warehouses y lakehouses — capítulo de la guía práctica de arquitectura de datos de Dataprix.
• Compara plataformas de datos en el directorio de software de Dataprix.