Agenda del Módulo

1. El "Porqué" de la Confianza: Superpoderes de Delta Lake (ACID y Auditoría).
2. El "Qué" del Modelo: Nuestro plano con la metodología Kimball.
3. El "Cómo" hacerlo Rápido: Optimización física con Particionamiento y Z-Ordering.
4. Taller Práctico: Construcción del modelo dimensional optimizado.

Garantías ACID: Confianza en tus Datos

Delta Lake trae la fiabilidad de las bases de datos tradicionales al Data Lake.

El Diario de Transacciones

Cada cambio en una tabla Delta queda registrado en un historial. Esto nos da dos capacidades increíbles.

Auditoría: `DESCRIBE HISTORY`

El primer paso para auditar es consultar el historial de la tabla.

-- Consultar el historial es así de simple:
DESCRIBE HISTORY curso_arquitecturas.pedidos_bronze;

-- Esto nos muestra cada versión, la operación, el usuario y la hora.

Time Travel: `VERSION AS OF`

Podemos consultar una "foto" pasada de la tabla usando su número de versión.

-- Comparar el número de filas antes (versión 1) y después (versión 2) de un borrado.
SELECT 'Version 1' AS v, COUNT(*) FROM pedidos_bronze VERSION AS OF 1
UNION ALL
SELECT 'Version 2' AS v, COUNT(*) FROM pedidos_bronze VERSION AS OF 2;

Recuperación: `RESTORE`

Si cometemos un error, `RESTORE` es la forma más segura de "deshacer" un cambio y volver a una versión anterior.

-- Deshacer todos los cambios y volver al estado de la versión 1.
RESTORE TABLE curso_arquitecturas.pedidos_bronze TO VERSION AS OF 1;

Auditoría a Nivel de Fila: CDF

Para ver las filas exactas que cambiaron, primero debemos habilitar el Change Data Feed (CDF).

-- 1. Habilitar CDF en la tabla (solo se hace una vez)
ALTER TABLE pedidos_bronze SET TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true');

-- 2. Realizar un cambio
DELETE FROM pedidos_bronze WHERE metodo_pago = 'PayPal';

-- 3. Ver las filas exactas que se borraron entre la versión 2 y 3
SELECT * FROM table_changes('pedidos_bronze', 2, 3) WHERE _change_type = 'delete';

Paso 1: Crear las Dimensiones

Las dimensiones son el "quién, qué, dónde, cuándo" de nuestros datos. Las creamos limpiando los datos de Bronce y declarando sus claves primarias (`PK`).

CREATE OR REPLACE TABLE usuarios_silver (
  id_usuario BIGINT NOT NULL,
  nombre_usuario STRING, ...
);
ALTER TABLE usuarios_silver ADD CONSTRAINT pk_usuarios PRIMARY KEY(id_usuario) NOT ENFORCED;

Paso 2: La Dimensión de Fecha

Una práctica fundamental de Kimball. Creamos una tabla `dim_fecha` con atributos de tiempo precalculados (año, mes, trimestre) para acelerar y simplificar las consultas.

CREATE OR REPLACE TABLE dim_fecha (
  id_fecha DATE NOT NULL,
  anio INT,
  mes INT, ...
);
ALTER TABLE dim_fecha ADD CONSTRAINT pk_dim_fecha PRIMARY KEY(id_fecha) NOT ENFORCED;

Paso 3: Crear las Tablas de Hechos

Las tablas de hechos contienen las métricas de negocio. Las conectamos a las dimensiones declarando sus claves foráneas (`FK`).

CREATE OR REPLACE TABLE pedidos_silver (
  id_pedido BIGINT NOT NULL,
  id_usuario BIGINT, -- Clave Foránea
  id_producto BIGINT, -- Clave Foránea
  ...
);
ALTER TABLE pedidos_silver ADD CONSTRAINT fk_pedidos_usuarios 
  FOREIGN KEY(id_usuario) REFERENCES usuarios_silver(id_usuario) NOT ENFORCED;

Optimización Macro: Particionamiento

CREATE TABLE pedidos_silver ( ... )
PARTITIONED BY (id_fecha);

-- Una consulta con este filtro solo leerá
-- los directorios de Enero 2025.
SELECT * FROM pedidos_silver
WHERE id_fecha >= '2025-01-01' AND id_fecha < '2025-02-01';

Optimización Micro: Z-Ordering

-- Después de insertar los datos...
OPTIMIZE pedidos_silver
ZORDER BY (id_usuario, id_producto);

-- Una consulta con este filtro ahora podrá
-- "saltarse" archivos y bloques de datos
-- de otros usuarios.
SELECT * FROM pedidos_silver
WHERE id_usuario = 1234;

Resumen del Módulo

• Empezamos con la confianza, entendiendo las garantías ACID y las capacidades de auditoría de Delta Lake.
• Luego, diseñamos el plano de nuestra capa Plata usando el modelo dimensional de Kimball.
• Finalmente, aprendimos a optimizar ese plano con Particionamiento y Z-Ordering para asegurar un alto rendimiento.