Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
History, time travel y VACUUM
Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
- Duración
- 17 min aprox.
- Objetivo
- Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Delta Lake: ACID, esquema, historial y DML
Usa el transaction log para construir tablas fiables, auditables e idempotentes.
- Explicar snapshots y concurrencia optimista
- Aplicar MERGE, UPDATE y DELETE correctamente
- Diferenciar tipos de tabla, conversión, schema evolution y time travel
05Decisión de diseñoHistory, time travel y VACUUM
Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
+
History, time travel y VACUUM
Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
Mostrar prerrequisitos
- Dificultad
- Associate + Professional
- Prerrequisitos
- m05
VERSION AS OF y TIMESTAMP AS OF permiten reproducir una lectura anterior si existen log y archivos. RESTORE crea un nuevo commit que devuelve la tabla al estado elegido.
VACUUM recupera almacenamiento, pero limita time travel y puede afectar lectores de larga duración si se reduce la retención sin criterio. History no garantiza que los archivos históricos sigan disponibles.
Modelo mental
Time travel, RESTORE y VACUUM operan sobre dimensiones distintas del historial. Time travel lee un snapshot anterior por versión o timestamp, siempre que log y archivos necesarios sigan retenidos. RESTORE crea un nuevo commit cuyo estado lógico referencia el contenido de una versión elegida; no borra versiones posteriores del historial. VACUUM elimina físicamente archivos que ya no están activos y superan el umbral seguro, reduciendo la ventana real de time travel. OPTIMIZE, en cambio, reorganiza layout y no es una limpieza de historial. La retención se diseña con recuperación, lectores concurrentes y normativa; DESCRIBE HISTORY por sí solo no garantiza que un snapshot antiguo siga materializable.
Lectura de un snapshot histórico de Delta mediante versión o timestamp disponible.
Permite auditoría, reproducción y validación antes de una recuperación.Operación que publica un nuevo commit para devolver el estado lógico a un snapshot anterior.
Recupera sin reescribir manualmente archivos ni borrar el historial posterior.Eliminación física de archivos obsoletos que superan la política de retención.
Ahorra almacenamiento, pero limita recuperación y time travel reales.SELECT count(*) FROM main.silver.orders VERSION AS OF 42;
RESTORE TABLE main.silver.orders TO VERSION AS OF 42;Valida el snapshot antes de restaurar; RESTORE no borra el historial posterior.
Puntos clave
- Time travel depende de retención
- RESTORE añade un commit
- VACUUM no es compactación
Evita
- Usar VACUUM para compactar archivos
- Reducir retención ignorando lectores concurrentes
Recuerdo activo