Cargar dimensiones y tabla de hechos en Redshift requiere un orden estricto y un manejo cuidadoso de las variables para evitar colisiones entre transformaciones. Aquí encontrarás una propuesta de solución al reto, pensada para quienes construyen procesos ETL con Pentaho y necesitan poblar un modelo dimensional listo para BI.

¿Cómo orquestar la carga de dimensiones en paralelo?

La propuesta arranca con un start y un dummy para habilitar la ejecución en paralelo de varias dimensiones a la vez. Mientras se transforma clientes, también corren productos, territorios y vendedores.

El detalle fino está en los wait. Como todas las dimensiones reutilizan la misma transformación de cálculo de máximo ID, conviene espaciar el arranque unos cinco segundos entre cada una. Así evitas que dos ejecuciones se solapen y terminen enviando variables incorrectas al calcular el ID consecutivo [02:00].

¿Por qué usar wait entre transformaciones paralelas? Porque al compartir una misma transformación de generación de IDs, dos ejecuciones simultáneas pueden pisarse las variables. Un retraso de cinco segundos basta para serializar ese paso crítico sin perder paralelismo en el resto del flujo.

¿Qué dimensiones cargar y con qué estrategia?

No todas las dimensiones se comportan igual, así que la estrategia de carga cambia según el volumen y la frecuencia de actualización.

¿Por qué deshabilitar la carga de tiempo después de ejecutarla?

La dimensión de tiempo se carga una sola vez, normalmente con cinco años hacia el futuro, y se deshabilita. Los tiempos no cambian, así que volver a ejecutarla es desperdicio de recursos [02:30].

¿Cuándo usar CSV con copy y cuándo carga directa a Redshift?

Aquí está la decisión clave del diseño. Redshift no rinde bien con cargas fila por fila, pero es magnífico cuando usas un copy desde un archivo plano.

• Clientes y ventas: muchos registros, conviene exportar a CSV y luego cargar con copy.
• Productos, territorios y vendedores: pocos registros, puedes enviarlos directo a la base de datos sin penalización.
• Tiempo: carga única, deshabilitada después de la primera ejecución.

La transformación de clientes, por ejemplo, se divide en dos pasos: primero aplica la regla de negocio y genera el CSV, y después un load separado lo sube a Redshift [03:30].

¿Cómo evitar conflictos de variables entre jobs?

Cuando construyes muchos proyectos en Pentaho, las variables pueden cruzarse por caché. La recomendación es indicarle al job que use únicamente las variables definidas en ese job, ignorando cualquier variable previa que haya quedado en memoria [05:00].

En el flujo, cada dimensión recibe su propio bloque de asignación: variables de productos para productos, de territorios para territorios y de vendedores para vendedores. Cada bloque incluye el ID, el nombre de la tabla y el campo que permite identificar registros nuevos.

¿Qué es una dimensión tipo 2? Es una dimensión que conserva el histórico: cuando un registro cambia, se cierra la vigencia del anterior y se abre una nueva con la fecha actual. Así puedes consultar cómo era ese dato en cualquier momento del pasado.

¿Cómo se carga la tabla de hechos sin romper el modelo?

La carga de la fact sigue una lógica parecida a la de clientes, pero más simple porque solo cargas una tabla. No necesitas dummy ni wait [06:00].

El flujo es: setear variables de la fact con su ID, nombre de tabla y campo de control, calcular el máximo ID para generar consecutivos, transformar las ventas y finalmente cargarlas. Por volumen, también va por CSV más copy.

La fact depende por completo de las dimensiones. Cada registro de ventas se cruza contra las dimensiones usando los códigos de negocio (código de vendedor, de cliente, de producto) para obtener el ID sustituto que quedó almacenado. Por eso el orden es innegociable: primero dimensiones, después hechos.

¿Qué resultado obtienes en la base de datos?

Al ejecutar los select sobre cada tabla, ves el modelo dimensional completo y listo para análisis.

• Vendedores: ID consecutivo, nombres, campos del modelo y fechas de inicio y fin de vigencia. Si modificas un registro en la transaccional, se cierra la vigencia anterior y se abre una nueva, comportamiento típico de tipo 2 [07:30].
• Clientes: ID consecutivo más atributos, configurada como dimensión lentamente cambiante tipo 1, donde cada cambio sobrescribe el registro.
• Productos: incluye color, tamaño, categoría, fecha de carga y fecha de actualización [08:30].
• Ventas (fact): ID de venta, código de factura, IDs de territorio, cliente, vendedor y producto, cantidad, valores, descuento y fechas de inserción.

Con el modelo poblado, ya puedes conectar herramientas como Power BI, Superset o Tableau para construir tableros y entregar valor al negocio [09:30].

Cuéntame en los comentarios cómo resolviste tú el reto, qué decisiones tomaste distinto y qué parte te costó más trabajo.