Solución ETL con dimensiones en paralelo en Redshift

Curso de Data Warehousing y Modelado OLAP

Contenido del curso

No sé dónde empezar

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

26
De datos crudos a modelo dimensional listo
01:18 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:27

Solución ETL con dimensiones en paralelo en Redshift

Curso de Data Warehousing y Modelado OLAP

Clase 25 de 26

Clase 25 / 26

Recursos

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.

Mario Alexander Vargas Celis

Hace 2 años

Para realizar una revisión exhaustiva de tu proceso ETL en Pentaho, es importante considerar las siguientes áreas clave:

1. Validación de Parámetros y Variables

Revisión:
- Confirma que las variables usadas (${CONSECUTIVO}, ${TABLA}, etc.) estén definidas y que se pasen correctamente al Job o a las transformaciones.
- Usa el paso de "Set Variables" en el Job si es necesario definir variables globales.
Prueba:
- Ejecuta un paso de prueba para asegurarte de que las variables se están resolviendo correctamente.

2. Extracción de Datos

Revisión:
- Verifica las consultas SQL para garantizar que:
  - Tengan la sintaxis correcta.
  - Devuelvan los resultados esperados.
  - Se adapten al tipo de base de datos (PostgreSQL, Redshift, etc.).
- Revisa conexiones en "Database Connections":
  - Dirección del servidor.
  - Credenciales.
  - Puerto y esquema correcto.
Prueba:
- Ejecuta cada consulta en un cliente de base de datos externo antes de incluirla en el ETL.

3. Transformaciones

Revisión:
- Analiza cada transformación (.ktr) incluida en el Job:
  - Los pasos tienen configuraciones válidas y conexiones entre ellos.
  - Se manejan excepciones o datos inválidos adecuadamente.
  - Las salidas son coherentes con los requisitos del proceso.
Prueba:
- Ejecuta cada transformación por separado y valida sus salidas antes de integrarlas al Job.

4. Limpieza y Enriquecimiento de Datos

Revisión:
- Asegúrate de que los pasos de transformación manejen:
  - Nulls y valores faltantes (IfNull, Replace Value, etc.).
  - Tipos de datos correctos para las operaciones posteriores.
  - Enriquecimiento basado en reglas de negocio.
Prueba:
- Revisa ejemplos de datos antes y después de los pasos críticos (usa "Preview Rows").

5. Carga en Destino

Revisión:
- Valida que las tablas de destino:
  - Existan y sean accesibles.
  - Coincidan con la estructura esperada por el ETL.
  - Sean gestionadas correctamente (truncar, insertar, actualizar).
- Revisa configuraciones de pasos como "Table Output" o "Insert/Update".
Prueba:
- Ejecuta cargas de prueba con datos controlados.

6. Manejo de Errores

Revisión:
- Configura logs y pasos de salida de errores:
  - Define "Error Handling" en pasos clave.
  - Registra errores en un archivo o tabla.
- Usa condiciones en los hops para manejar errores y redirigir el flujo del Job.
Prueba:
- Simula errores para comprobar que el Job se comporta adecuadamente.

7. Rendimiento

Revisión:
- Evalúa tiempos de ejecución.
- Optimiza pasos pesados (filtros, transformaciones complejas, etc.).
- Configura paralelización si es necesario.
Prueba:
- Ejecuta el ETL en condiciones de producción y monitorea tiempos y uso de recursos.

8. Documentación

Revisión:
- Añade descripciones claras en cada paso del Job y transformaciones.
- Documenta dependencias, rutas de archivos y credenciales.

9. Pruebas End-to-End

Revisión:
- Ejecuta el Job completo con datos reales (o simulados) y verifica:
  - La integridad de los datos en cada paso.
  - Que los datos cargados en el destino cumplan con las expectativas.
- Compara los resultados con un conjunto de datos esperado.

10. Plan de Mantenimiento

Revisión:
- Diseña estrategias para:
  - Gestionar cambios en las estructuras de datos de origen o destino.
  - Monitorear errores en ejecución.
  - Escalar el proceso ETL si crece el volumen de datos.

Introducción a BI y Data Warehouse

Qué es Business Intelligence y Data Warehousing

Niveles de analítica y jerarquía de datos

Qué son data warehouse, data mart y dimensiones

OLTP vs OLAP: diferencias clave

Inmon, Kimball y Hefesto en BI

Modelos dimensionales

Data Warehouse, Data Lake y Lakehouse

Modelo estrella vs copo de nieve en datos

Tipos de dimensiones lentamente cambiantes

Dimensión tipo 1: sobrescribir sin guardar historia

Dimensión tipo 2

Dimensión tipo 3: historia en columnas

Tabla de hechos (fact)

Configuración de herramientas para Data Warehouse y ETL

Cómo extraer dimensiones de preguntas de negocio

Diseño de tablas en un modelo dimensional

ETL para inserción en Data Warehouse

Documento de mapeo en ETL para data warehouse

Creando tablas dimensionales en Redshift

Extracción: querys en SQL

Cruce de fuentes en Pentaho con Stream Lookup

Transformación ETL con Pentaho paso a paso

Carga de datos transformados a Redshift con Pentaho

Cómo cargar la tabla de hechos con Pentaho

Cómo calcular MaxID y MaxDate en Pentaho

Orquestar ETL en Pentaho: job

Solución ETL con dimensiones en paralelo en Redshift

Cierre

De datos crudos a modelo dimensional listo

Solución ETL con dimensiones en paralelo en Redshift

Progreso del curso

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

Recursos

Recursos