Time travel y versionado: volver al pasado de tus datos

Imagina que es lunes por la mañana. El CEO te llama furioso: "el dashboard de ventas muestra números absurdos desde el viernes". Tu pipeline del sábado hizo algo mal — corrompió datos, duplicó registros, o aplicó una transformación incorrecta. Sin time travel, tu único recurso es buscar backups, rezar para que sean recientes, y restaurar manualmente. Con time travel, simplemente dices: "muéstrame los datos como estaban el viernes a las 18:00" y haces rollback. Problema resuelto en 30 segundos.

### Qué es time travel en el contexto de data lakes

Time travel es la capacidad de consultar los datos de una tabla tal y como estaban en un momento anterior. No es magia — funciona porque los table formats como Iceberg y Delta Lake mantienen un historial de snapshots inmutables. Cada vez que haces un commit (INSERT, UPDATE, DELETE), se crea un nuevo snapshot. Los snapshots anteriores NO se borran — se mantienen accesibles para consultas históricas.

La analogía perfecta es Git para código. Cada commit en Git crea un snapshot del código. Puedes hacer checkout de cualquier commit anterior para ver el código como estaba en ese momento. Time travel es exactamente lo mismo pero para datos. Y así como Git no duplica archivos sin cambios (usa punteros), Iceberg tampoco duplica data files — solo crea nuevos manifests que apuntan a los archivos existentes más los nuevos.

### Consultas temporales: snapshot-id y timestamp

1-- Time travel por timestamp: ¿cómo estaba la tabla el viernes?
2SELECT * FROM lake.ventas
3FOR SYSTEM_TIME AS OF TIMESTAMP '2024-01-19 18:00:00';
4
5-- Time travel por snapshot ID: volver a un snapshot específico
6SELECT * FROM lake.ventas
7FOR SYSTEM_VERSION AS OF 1001;
8
9-- Ver el historial completo de snapshots
10SELECT snapshot_id, committed_at, operation, summary
11FROM lake.ventas.snapshots
12ORDER BY committed_at DESC;
13
14-- Comparar dos snapshots: ¿qué cambió?
15SELECT * FROM lake.ventas FOR SYSTEM_VERSION AS OF 1002
16EXCEPT
17SELECT * FROM lake.ventas FOR SYSTEM_VERSION AS OF 1001;

### Rollback: deshacer el desastre

Rollback es la operación más valiosa en producción. Cuando un pipeline corrupto escribe datos malos, puedes "rebobinar" la tabla a un estado anterior conocido como bueno. No reescribe datos — simplemente actualiza el puntero del catalog para que apunte a un snapshot anterior. Es instantáneo sin importar el tamaño de la tabla.

1-- Rollback a un snapshot específico (instantáneo)
2CALL lake.system.rollback_to_snapshot('lake.ventas', 1001);
3
4-- Rollback a un timestamp
5CALL lake.system.rollback_to_timestamp('lake.ventas', TIMESTAMP '2024-01-19 18:00:00');
6
7-- Verificar que el rollback funcionó
8SELECT snapshot_id, committed_at, operation
9FROM lake.ventas.snapshots
10ORDER BY committed_at DESC
11LIMIT 5;

### Auditoría temporal: quién hizo qué y cuándo

Time travel no solo sirve para rollback. Es una herramienta de auditoría increíblemente poderosa. Cada snapshot registra: quién lo creó, cuándo, qué operación fue (append, overwrite, delete), cuántos archivos se añadieron/eliminaron, y cuántas filas cambiaron. Esto te da un log completo de la vida de la tabla.

• ▹Regulación: "demuestra que los datos del informe financiero de Q4 no se han modificado desde que se generó" — consulta el snapshot exacto de esa fecha.
• ▹Debugging: "los números del lunes eran correctos pero los del martes no" — compara los snapshots del lunes y martes para ver exactamente qué cambió.
• ▹Reproducibilidad: "entrena el modelo ML con los datos exactos del 15 de enero" — time travel al snapshot de esa fecha, garantizando reproducibilidad.
• ▹Reconciliación: "el pipeline del viernes falló y se reejecutó el sábado — ¿perdimos datos?" — compara snapshots pre y post fallo.

### Retención de snapshots y expire

Los snapshots en sí son metadata y pesan poco (unos pocos KB cada uno). Lo que cuesta de verdad retenerlos no es ese metadata — es que cada snapshot mantiene vivos los ficheros de datos que referencia. Cuando solo haces appends, los snapshots comparten los mismos data files y el coste extra es mínimo. Pero cuando reescribes datos (un UPDATE en copy-on-write, por ejemplo), cada commit genera una copia nueva del fichero modificado, y el snapshot antiguo mantiene viva la copia anterior. Diez reescrituras con diez snapshots retenidos son diez copias vivas del mismo dato en disco. Por eso expire_snapshots es la operación que de verdad libera espacio: no borra metadata, borra los ficheros de datos que ya ningún snapshot necesita.

1-- Expirar snapshots más antiguos de 7 días
2CALL lake.system.expire_snapshots(
3    table => 'lake.ventas',
4    older_than => TIMESTAMP '2024-01-20 00:00:00',
5    retain_last => 10  -- mantener siempre al menos 10 snapshots
6);
7
8-- Ver qué archivos se pueden limpiar (orphan files)
9CALL lake.system.remove_orphan_files(
10    table => 'lake.ventas',
11    older_than => TIMESTAMP '2024-01-15 00:00:00'
12);

### Branching y tagging: Git para datos

Iceberg v2 introdujo branching y tagging — funcionalidades directamente inspiradas en Git. Un branch es una referencia con nombre a un snapshot que puede avanzar independientemente. Un tag es una referencia inmutable a un snapshot concreto.

1-- Crear un tag para marcar un snapshot importante
2ALTER TABLE lake.ventas
3  CREATE TAG reporte_q4_2024
4  AS OF VERSION 1050
5  RETAIN 365 DAYS;
6
7-- Crear un branch para experimentación
8ALTER TABLE lake.ventas
9  CREATE BRANCH experimental
10  AS OF VERSION 1050;
11
12-- Escribir al branch sin afectar main
13INSERT INTO lake.ventas.branch_experimental
14SELECT * FROM staging.ventas_nuevas;
15
16-- Consultar el branch
17SELECT count(*) FROM lake.ventas VERSION AS OF 'experimental';
18
19-- Si todo OK, hacer fast-forward merge (conceptual)
20-- En la práctica: cherry-pick o WAP — Write-Audit-Publish

El patrón Write-Audit-Publish (WAP) es la aplicación más importante del branching: escribes datos a un branch, ejecutas validaciones de calidad sobre ese branch, y solo si pasan TODAS las validaciones, publicas (merge) al main. Si fallan, simplemente borras el branch. Los lectores nunca vieron datos incorrectos.