Curso
¿Qué es Time Travel en Snowflake?
Así como los ingenieros de software usan Git para el control de versiones, los ingenieros de datos cuentan con Time Travel en las bases de datos de Snowflake. La función Time Travel permite a los administradores de bases de datos consultar datos históricos, clonar tablas antiguas y restaurar objetos eliminados en el pasado.
Sin embargo, dado el tamaño masivo que pueden alcanzar las bases de datos, Time Travel no es un sustituto directo del control de versiones de código. Cada vez que se modifica una tabla (se borran o actualizan registros), Snowflake toma una instantánea del estado de los datos antes de la actualización. Esa instantánea solo vive durante un número de días determinado, conocido como el período de retención de datos.
En las cuentas Snowflake Standard, el período máximo de retención es de un solo día. En las cuentas Enterprise, puede estar entre 0 y 90 días. Un período de retención de 0 desactiva de facto Time Travel, que está habilitado por defecto para todas las tablas.
Snowflake Time Travel vs. Fail-safe
Al leer la documentación de Snowflake, puede que te encuentres también con el término «Fail-safe». Por el nombre, podría parecer que Time Travel y Fail-safe hacen lo mismo, pero no es así.
Cuando un objeto agota su período de retención, pasa a Snowflake Fail-safe. En Fail-safe no puedes:
- Consultar datos históricos
- Clonar objetos pasados
- Restaurar objetos pasados que se eliminaron
Fail-safe conserva los datos durante un período no configurable de 7 días. Durante ese tiempo, solo Snowflake puede recuperar los datos. Esta función actúa como un servicio de recuperación y está pensada como último recurso cuando fallan todos los demás métodos de recuperación. Se utiliza únicamente cuando los datos se han dañado o borrado por fallos operativos.
Por tanto, no puedes pedir a Snowflake que recupere versiones anteriores de tus objetos una vez que hayan agotado su período de retención. Ten presente esta regla mientras sigues este tutorial.
Preparación del entorno
Snowflake ofrece dos interfaces para interactuar con la plataforma: SnowSight (la interfaz web) y Snowflake CLI (el cliente de terminal). Seguiremos con SnowSight porque es más fácil de configurar. Si eres nuevo en Snowflake, puedes leer este tutorial completo, que también cubre cómo usar Snowflake CLI.
Primero, crea una cuenta gratuita desde la página principal de Snowflake. Podrás acceder a funciones Enterprise durante una prueba gratuita de 30 días.

Cuando tu cuenta esté lista, accederás a la página Worksheets del panel. Puedes considerar cada hoja como un entorno independiente para ejecutar SQL o incluso Python.

Ahora, crea una nueva hoja con el botón «+» de la esquina superior derecha:

A continuación, vamos a crear algunas bases de datos y tablas y a llenarlas con datos.
Creación de la base de datos y las tablas
Primero, crearemos una base de datos llamada ecommerce_db. Pega el siguiente código y pulsa "Ctrl + Enter" (Cmd + Enter) para ejecutarlo ("Ctrl + Shift + Enter" ejecuta todas las sentencias de la hoja).
CREATE DATABASE IF NOT EXISTS ecommerce_db;
Usaremos esta base de datos hipotética para vender merchandising relacionado con IA. Ejecuta el siguiente comando para establecerla como predeterminada:
USE DATABASE ecommerce_db;
Ahora crearemos una tabla llamada inventory con tres columnas:
CREATE OR REPLACE TABLE inventory (
product_id INT PRIMARY KEY,
name VARCHAR(255),
stock_level INT,
last_updated TIMESTAMP_TZ DEFAULT CURRENT_TIMESTAMP
);
Después añadiremos algunos productos iniciales:
INSERT INTO inventory (product_id, name, stock_level)
VALUES (1, Llama hoodie', 10), (2, Falcon cap', 20);
También crearemos una tabla para los pedidos:
CREATE OR REPLACE TABLE orders (
order_id INT PRIMARY KEY,
product_id INT REFERENCES inventory(product_id),
quantity INT,
order_date TIMESTAMP_TZ DEFAULT CURRENT_TIMESTAMP
);
-- Assume some time passes after this table was created
Después de publicar una web para vender nuestro merchandising, llegan algunos pedidos. Por la mañana recibimos dos pedidos de ambos productos:
INSERT INTO orders (order_id, product_id, quantity)
VALUES (1, 1, 5), (1, 2, 3);
Por la tarde, recibimos otro:
-- Simulate a system glitch causing an extra order for product 1
INSERT INTO orders (order_id, (product_id, quantity)
VALUES (3, 1, 100); -- This might cause negative stock
Pero debido a un fallo del sistema, el pedido se registra con más unidades de las que tenemos. Supongamos que no nos damos cuenta hasta dentro de dos semanas.
Ten en cuenta que hice algunas otras actualizaciones en las tablas por detrás.
Control del período de retención
Nuestra primera tarea es definir un período de retención. Mi prueba gratuita ha terminado, así que solo puedo establecerlo en un día:
ALTER TABLE inventory SET DATA_RETENTION_TIME_IN_DAYS=1;
ALTER TABLE orders SET DATA_RETENTION_TIME_IN_DAYS=1;
Si la tuya no ha terminado, intenta ponerlo en cuatro semanas, ya que tu prueba caducará después de ese tiempo.
Uso de las cláusulas AT y BEFORE
Snowflake implementa Time Travel mediante estas extensiones de SQL:
- Cláusulas
ATyBEFOREpara usar en sentenciasSELECTy así precisar el punto (o período) exacto en el tiempo que quieres consultar. Admiten estos parámetros para lograrlo: TIMESTAMPOFFSET: diferencia horaria en segundos respecto al momento actualSTATEMENT: ID único de la consulta- Comando
UNDROPpara restaurar tablas, esquemas y bases de datos
Veamos cómo usar estas extensiones en nuestra base de datos de ejemplo.
Consulta de datos históricos
Primero, comprobemos qué tenemos en inventory:
-- Check current stock level (might show negative value)
SELECT * FROM inventory;

Ahora, combinemos los pedidos y el inventario que tenemos:
SELECT i.name, i.stock_level, o.quantity as "order_amount"
FROM inventory as i
JOIN orders as o
ON i.product_id = o.product_id;

¡Vaya! Parece que hay un error: la cantidad de pedidos del Llama hoodie es superior a nuestro stock. Probemos a retroceder 17,5 horas para localizar el momento exacto en que se ejecutó la sentencia errónea:
SELECT * FROM orders AT(OFFSET => -60*60*17.5); -- Go back 17.5

Así que el pedido incorrecto se registró a las 4:54 p. m. del 6 de marzo. Esto significa que necesitamos el estado de la tabla antes de esa hora. Es fácil consultarlo con la cláusula BEFORE:
-- Change the timezone
ALTER SESSION SET TIMEZONE = 'UTC';
-- Select the table state before the error
SELECT * FROM orders BEFORE(TIMESTAMP => '2024-03-06 04:54:00 -0800'::timestamp_tz);
No olvides añadir timestamp_tz como tipo de datos para la marca de tiempo. tz significa zona horaria.

Estos ejemplos muestran cómo usar las cláusulas AT y BEFORE con marcas de tiempo y desplazamientos. Si no quieres calcular el momento exacto de las consultas, puedes usar los IDs de sentencia.
Por ejemplo, la siguiente consulta hace lo mismo que la anterior: consultar el estado de la tabla antes de que se registrara el pedido incorrecto:
SELECT * FROM orders BEFORE(STATEMENT => '01b2ce86-0000-95e2-0000-000669127035');
Así puedes encontrar el ID de consulta de cualquier sentencia:

Filtrando por tipo de consulta, podrás encontrar mucho más rápido la que buscas en SnowSight.
Clonado de objetos históricos
Tenemos un pedido incorrecto en nuestra tabla, ¿cómo lo eliminamos?
Una opción es clonar la tabla sin la fila errónea:
CREATE OR REPLACE TABLE orders_clone AS
SELECT * FROM orders WHERE quantity != 100;
SELECT * FROM orders_clone;

Ha funcionado y no hemos tenido que recurrir a Time Travel para corregir el problema. Pero cuando necesites clonar estados pasados de una tabla, puedes seguir esta sintaxis:
-- Clone an object as it existed 2 days ago
CREATE TABLE old_table_clone CLONE olt_table
AT(OFFSET => -2 * 24 * 60 * 60); -- Offset for 2 days
Clonar bases de datos es similar:
CREATE DATABASE cloned_db CLONE my_db
BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
Eliminación y restauración de objetos
Imagina que acabamos de contratar a una persona en prácticas y le hemos asignado el problema del pedido incorrecto.
Intentando eliminar ese registro, la persona en prácticas borra por accidente la tabla de pedidos en producción:
-- Simulate accidentally dropping the orders table
DROP TABLE orders
SELECT * FROM orders;;

La persona en prácticas viene hecha un manojo de nervios y nos cuenta lo ocurrido. Así que, con calma, ejecutamos el comando UNDROP:
-- Recover the dropped table using UNDROP
UNDROP TABLE orders
SELECT * FROM orders;;
Y recuperamos la tabla. También perdonamos a la persona en prácticas y (por supuesto) decidimos no despedirla por su error.
Conclusión
En este tutorial hemos aprendido una función clave de Snowflake: Time Travel. Con Time Travel puedes consultar y restaurar información pasada, una capacidad muy valorada en las herramientas de gestión de bases de datos.
En producción puede pasar de todo, y contar con una copia de seguridad de tu base de datos antes de cada actualización aporta mucha tranquilidad.
Creo que Snowflake es la mejor herramienta de gestión de bases de datos que existe. Es una plataforma enorme, y dominarla es una habilidad muy demandada en perfiles de datos. Si quieres profundizar, echa un vistazo al curso Introduction to Snowflake en DataCamp.
Si ya te manejas bien y quieres poner a prueba tus habilidades, revisa las mejores certificaciones de Snowflake disponibles en 2024.
Soy creador de contenidos sobre ciencia de datos con más de 2 años de experiencia y uno de los mayores seguimientos en Medium. Me gusta escribir artículos detallados sobre IA y ML con un toque sarcástico, porque hay que darle algo de vidilla al tema. He publicado más de 130 artículos y un curso en DataCamp, y tengo otro en marcha. Mis contenidos han sido vistos por más de 5 millones de personas; 20.000 de ellas se convirtieron en seguidores tanto en Medium como en LinkedIn.

