Construir un proceso ETL completo que cargue dimensiones y una tabla de hechos requiere decisiones técnicas precisas sobre paralelismo, manejo de variables y estrategias de carga según el volumen de datos. Aquí se explica paso a paso la propuesta de solución para este reto, desde la orquestación de las cargas hasta la verificación final en la base de datos.
¿Cómo se orquesta la carga en paralelo de las dimensiones?
El flujo comienza con un start y un dummy que permite lanzar ejecuciones en paralelo [0:06]. Sin embargo, hay un detalle crítico: cuando todas las dimensiones comparten la misma transformación para generar máximos IDs, pueden solaparse y enviar variables de manera incorrecta.
Para evitar ese problema se utilizan bloques wait con intervalos de aproximadamente cinco segundos entre cada ejecución [0:25]. Como la transformación de generación de IDs es rápida, ese tiempo es suficiente para que una termine antes de que la siguiente inicie su cálculo. Así, aunque las cargas de clientes, productos, territorios y vendedores corren casi al mismo tiempo, no hay conflicto de variables.
¿Por qué se deshabilita la carga de la dimensión tiempo?
La dimensión tiempo se ejecuta una sola vez y luego se deshabilita [1:10]. La razón es sencilla: los datos de tiempo no cambian. Generalmente se carga con varios años hacia el futuro y no requiere modificaciones posteriores, así que no tiene sentido ejecutarla en cada corrida del proceso.
¿Qué estrategia de carga se usa para clientes versus productos?
Para clientes se aplican dos transformaciones encadenadas [1:27]:
- La primera ejecuta reglas de negocio, crea campos nuevos y genera un archivo CSV.
- La segunda toma ese CSV y lo carga mediante un comando copy.
Esta estrategia responde a que Redshift no es eficiente para inserciones directas, pero con copy carga millones de registros de forma muy rápida [1:53].
En cambio, para productos, territorios y vendedores, como son pocos registros, la carga se hace directamente a base de datos sin pasar por CSV [1:48]. El rendimiento es aceptable dado el bajo volumen.
¿Cómo se manejan las variables entre múltiples jobs?
Cada carga recibe la asignación de sus propias variables: nombre de tabla, campo identificador y demás parámetros [2:15]. Un punto importante es el manejo del caché de variables. Cuando trabajas con varios proyectos, las variables pueden cruzarse. La solución es indicarle al job que use exclusivamente las variables definidas en su contexto [2:30], evitando así lecturas incorrectas de valores residuales.
¿Cómo se carga la tabla de hechos de ventas?
La carga de la tabla de hechos (FAQ) es más simple en su orquestación porque es una sola tabla [2:50]. No necesita dummy ni wait. El flujo sigue estos pasos:
- Setear las variables correspondientes: ID, nombre de tabla y campo para identificar registros nuevos.
- Calcular el máximo ID existente para generar consecutivos a partir de ahí.
- Transformar los datos de ventas.
- Exportar a CSV y cargar con copy, igual que clientes, debido al alto volumen de registros [3:18].
Es fundamental que las dimensiones se carguen antes que la tabla de hechos [4:28]. Durante la transformación de ventas se cruza cada registro con las dimensiones usando el código de negocio (código de vendedor, de producto, de cliente) para obtener el ID correspondiente en el data warehouse.
¿Cómo se verifican los resultados en la base de datos?
Al consultar la tabla de vendedores, cada registro tiene su ID consecutivo, los campos definidos en el modelo de datos y las fechas de inicio y fin de vigencia [3:40]. Esta es la implementación de la dimensión lentamente cambiante tipo dos (SCD tipo 2): cuando un registro se modifica en la base transaccional, se cierra la vigencia del anterior y se abre una nueva para el registro actualizado [3:55].
La tabla de clientes usa una dimensión lentamente cambiante tipo uno (SCD tipo 1) [4:08]: cada actualización sobreescribe directamente el registro sin guardar historial.
La tabla de productos incluye campos como color, tamaño, categoría y fechas de carga y actualización [4:20].
Finalmente, la tabla de hechos de ventas contiene los IDs de cada dimensión, el código de factura, cantidades, valores, descuentos y fechas de inserción [4:35]. Con este modelo completo ya es posible conectar herramientas de visualización como Power BI, MicroStrategy, Tableau o Superset para construir tableros y aportar valor al negocio.
¿Tu solución fue diferente? Comparte en los comentarios cómo resolviste el reto y qué enfoque utilizaste para la carga de dimensiones y la tabla de hechos.
