Conectar Pentaho con tu base de datos transaccional y tu data warehouse es el paso que separa una consulta SQL de un proceso ETL real. Aquí verás cómo llevar tu query a Pentaho, configurar conexiones a Postgres y Redshift, y cruzar fuentes para identificar registros nuevos antes de cargarlos en una dimensión.

¿Cómo crear una transformación y un Table Input en Pentaho?

Todo arranca con una transformación nueva. En Pentaho haces clic en el ícono de más, eliges transformación y se abre el lienzo de trabajo en blanco.

Desde ahí, el primer paso es traer los datos desde la base transaccional. Para eso usas un Table Input, que es el step encargado de ejecutar una consulta SQL contra una conexión definida y devolver el resultado como un flujo de filas.

• Buscas Table Input en la lista de steps disponibles [01:00].
• Lo arrastras y lo sueltas en el lienzo.
• Pegas el query que ya tenías construido desde la clase anterior.
• Lo renombras como Input clientes para identificarlo.

Ese query es el mismo que escribiste en SQL, así que no cambias la lógica: solo la trasladas al motor de Pentaho para que se ejecute como parte del flujo.

¿Cómo configurar la conexión a Postgres y a Redshift?

Un Table Input sin conexión no sirve. Necesitas decirle a Pentaho dónde vive la base de datos.

Para la fuente transaccional, creas una conexión nueva y eliges Postgres como motor. Llenas el host (en este caso localhost), el nombre de la base, el usuario y la contraseña. El nombre de la base aquí es adventureworks, todo en minúsculas, y ese detalle importa: si pones la W en mayúscula, el test de conexión falla.

¿Por qué falla la conexión a Postgres en Pentaho? Casi siempre es por el nombre de la base de datos mal escrito o por mayúsculas y minúsculas. Postgres distingue entre AdventureWorks y adventureworks, así que revisa la grafía exacta.

Una convención útil es nombrar la conexión como con_postgres_adventureworks, porque cuando tengas varias conexiones en el mismo proyecto vas a agradecer poder distinguirlas de un vistazo.

Para la fuente del data warehouse repites el proceso, pero eliges Redshift como motor [05:30]. Le pones un nombre tipo con_redshift_wh, ingresas servidor, base, usuario y password, y haces Test para validar.

¿Cómo extraer los datos del data warehouse para compararlos?

No basta con traer el transaccional. También necesitas leer la dimensión que ya existe en el warehouse, porque ahí está la verdad sobre qué registros son nuevos y cuáles ya viven en el modelo dimensional.

Agregas un segundo Table Input, lo conectas a Redshift y apuntas al esquema wh_adventureworks sobre la tabla de dimensión cliente. Si escribir el SQL a mano se complica, Pentaho te deja usar el botón Get SQL select statement, que recorre las tablas disponibles y arma la estructura por ti [08:45].

De todos los campos disponibles, te quedas solo con los que necesitas para el cruce:

• El ID de la dimensión, para reutilizarlo en registros existentes.
• El código del cliente, que es la llave de negocio.
• La fecha de actualización, para saber cuándo cambió el registro por última vez.

Al hacer preview, la tabla puede venir vacía si es la primera carga. Eso es esperable y no rompe el flujo.

¿Cómo cruzar dos fuentes con Stream Lookup en Pentaho?

Con las dos extracciones listas, una desde Postgres y otra desde Redshift, llega el momento de cruzarlas. Para eso usas un Stream Lookup, que toma un flujo principal y lo enriquece buscando coincidencias contra un flujo de referencia.

La lógica es directa: el flujo principal es el Input clientes del transaccional, y el flujo de referencia es la dimensión del warehouse. La llave de comparación es el código del cliente en ambos lados.

¿Qué es un Stream Lookup? Es un step que cruza dos flujos por una llave común y devuelve campos del flujo de referencia. Si no encuentra coincidencia, puedes definir un valor por defecto.

Cuando configures el lookup, le pides que traiga el campo ID de la dimensión. Y aquí está la jugada inteligente: si ese ID viene nulo, le asignas un valor por defecto de -1 y lo defines como tipo entero [13:20].

Ese -1 es una bandera. Te dice, sin ambigüedad, que ese registro no existe todavía en la dimensión y que en el siguiente paso del ETL habrá que generarle un ID nuevo. Los que sí trajeron un ID real conservarán ese mismo identificador, porque ya están en el warehouse.

Habilidades, conceptos y datos clave de la clase

La lectura técnica de lo que acabas de hacer se apoya en varios conceptos que conviene tener nombrados.

• Table Input es el step de Pentaho que ejecuta SQL contra una conexión y entrega filas al flujo [01:00].
• Conexión a base de datos se configura por motor (Postgres, Redshift) con host, base, usuario y password [03:15].
• Esquema en Redshift, en este caso wh_adventureworks, agrupa las tablas del modelo dimensional [07:50].
• Stream Lookup cruza dos flujos por una llave y trae campos del flujo de referencia [12:10].
• Valor por defecto -1 marca registros nuevos que no existen en la dimensión [13:20].
• Fecha de actualización permite rastrear cuándo cambió por última vez un registro en la dimensión.

Con el cruce resuelto, ya tienes separados los registros viejos de los nuevos. El siguiente paso será aplicar las transformaciones y cargar todo en la base de datos dimensional. ¿Tú cómo nombras tus conexiones en Pentaho cuando manejas varios entornos? Cuéntalo en los comentarios.