La carga de datos transformados a un data warehouse en Redshift es el paso que convierte tu trabajo de ETL en información lista para dashboards y reportes. Aquí verás cómo separar inserts y updates, exportar a S3 y ejecutar un copy con Pentaho.

¿Cómo separar registros para insert y update en Pentaho?

Después de aplicar las reglas de negocio en tu flujo de transformación, necesitas decidir qué registros entran como nuevos y cuáles actualizan información existente. Para eso usas un paso filter sobre el campo indicador que creaste antes [01:00].

La lógica es simple: si el indicador es -1, el registro es nuevo y va a un insert. Si no es -1, ya existe en la base y va a un update. Ese filtro divide tu flujo en dos caminos que se procesan distinto.

¿Por qué Redshift no maneja bien inserts directos? Redshift es una base de datos columnar optimizada para lectura analítica, no para operaciones fila por fila. Por eso conviene cargar inserts masivos vía archivo plano y copy, no con sentencias INSERT individuales.

¿Cómo configurar el update directo a la dimensión de clientes?

Para los registros que ya existen, un update directo funciona bien porque suelen ser pocos. Arrastras el paso de update, conectas tu conexión a Redshift y seleccionas el esquema del data warehouse y la tabla dim_clientes [04:30].

Dentro del paso configuras dos cosas clave:

• La condición de búsqueda: el id_cliente del flujo debe ser igual al id_cliente de la tabla destino.
• El mapeo de campos: qué campo de tu flujo actualiza qué campo en la tabla.

Entre los campos que sí pueden cambiar están nombre, apellido, nombre completo, número de celular, número de casa, teléfono de trabajo y ciudad. El id_cliente nunca cambia porque es la llave de cruce. El código del cliente tampoco se actualiza, porque si cambia significa que ya es un cliente distinto [06:30].

¿Por qué fecha de carga y fecha de actualización son distintas?

La fecha de carga guarda el momento en que el registro entró por primera vez al data warehouse. La fecha de actualización guarda la última modificación. En un update solo tocas la segunda, nunca la primera, porque romperías la trazabilidad histórica del dato [08:00].

¿Cómo exportar los registros nuevos a un archivo CSV en S3?

Para los registros marcados como nuevos, el camino eficiente es dejar un archivo CSV en un bucket de S3 y luego cargarlo con un copy a Redshift. Arrastras un paso de output tipo CSV y configuras la ruta dentro del bucket [09:30].

La ruta tiene esta forma: s3://tu-bucket/AdventureWorks/dim_clientes.csv. Importante: incluye los dos puntos después de s3 y valida con browse que la ruta sea correcta.

Algunas decisiones prácticas al configurar el archivo:

• Quita el encabezado del CSV para que el copy posterior no falle al leerlo.
• Define todos los campos como string, excepto las fechas, porque es un archivo plano.
• Mantén el mismo orden de columnas que tiene la tabla en base de datos.
• Usa el formato de fecha yyyy-MM-dd HH:mm:ss.sss en minúsculas.

El orden de columnas en este caso es: id, código, nombre, apellido, nombre completo, número celular, número casa, trabajo, ciudad, fecha carga y fecha actualización. Como son registros nuevos, ambas fechas llevan el mismo last date.

¿Qué pasa con los tamaños de los campos al exportar a CSV? Conviene quitarlos o ajustarlos a los de la tabla destino. Tamaños mal definidos generan errores de memoria o truncamientos silenciosos durante la ejecución.

¿Cómo ejecutar el copy de S3 a Redshift desde Pentaho?

Una vez generado el CSV, creas una nueva transformación con un paso de tipo Execute SQL script. Ahí pegas el comando copy que normalmente usas para cargar archivos planos a Redshift [14:00].

La estructura del script incluye:

• La tabla destino, en este caso dw_adventureworks.dim_clientes dentro de la base Analytics.
• La ruta del archivo en S3, idéntica a la que configuraste en el paso de exportación.
• Las variables de Access Key y Secret Access Key del bucket.

Al guardar el script, Pentaho pide validar la conexión. Como es una transformación nueva, creas una nueva conexión a Redshift con los mismos parámetros que usaste antes.

¿Qué falta para orquestar todo el proceso?

Tienes dos transformaciones separadas: la que limpia y exporta el CSV, y la que ejecuta el copy. Para que corran en orden, necesitas un job de Pentaho que las encadene. Eso permite que primero se genere el archivo y después se cargue, sin intervención manual [18:30].

Reto: replica el proceso para otras dimensiones

Aplica este mismo flujo a las dimensiones de producto, vendedores, territorio y fechas. Dos casos requieren atención especial:

• Fechas: no tiene fuente de datos. Debes generar un consecutivo de fechas dentro del flujo.
• Vendedores: es una dimensión lentamente cambiante tipo 2 (SCD2), así que debes mantener el historial de cambios en lugar de sobrescribir.

¿En qué dimensión crees que vas a tener más fricción al implementarla? Cuéntalo en los comentarios.