DWH multi-tenant hasta Power BI

Construí una plataforma analítica multi-tenant que consolida datos de varios clientes y los lleva hasta Power BI. Dar de alta o de baja un cliente pasó a ser un procedimiento documentado, no algo que dependía de quién lo supiera hacer.

El punto de partida

Hacía falta una base analítica para varios clientes, con un patrón de operación repetible, trazable y mantenible. El reto no era solo técnico: el sistema tenía que crecer con nuevos tenants sin depender de conocimiento implícito.

Qué hice

Diseñé la arquitectura analítica y el flujo ETL multi-tenant. Desarrollé y mantuve los procesos SSIS, diseñé y operé el data warehouse en SQL Server y di soporte a la explotación en Power BI.

También definí los checks de QA y documenté la operación. Esa parte fue la que más valor dio al proyecto.

Cómo lo hice

Configuración por tenant

Una tabla de control dentro del propio DWH guarda los tenants y sus parámetros, y permite activar o desactivar cada uno. La conexión al origen se construye en tiempo de ejecución.

Carga repetible

El proceso maestro itera tenant a tenant, de forma aislada. Cada carga sigue el patrón stg -> MERGE -> TRUNCATE stg, con una marca de carga para no reprocesar de más.

Incremental y full sync

Combiné la carga incremental por updated_at con un full sync controlado. Este último, solo en las tablas de relación N-N, donde había que preservar la consistencia entre tenants.

Runbooks

Documenté la operación paso a paso:

• revisar los registros de ejecución ETL y lanzar el job a mano cuando aplica;
• dar de alta y de baja tenants en el proceso analítico;
• programar la actualización en Power BI;
• un catálogo de consultas SQL por dominio: ETL, clientes, mantenimiento, reporting y vistas.

Resultado

Incorporar un cliente nuevo dejó de depender del conocimiento no documentado.

Los checks de QA verifican que staging queda limpio tras el MERGE, detectan duplicados por claves lógicas y validan el comportamiento incremental. El troubleshooting documentado cubre drivers, metadatos SSIS, tablas de relación con full sync y zonas horarias. Eso redujo el tiempo de diagnóstico y el riesgo operativo, y dejó el pipeline trazable y mantenible.

Arquitectura

Orígenes relacionales en cloud (MySQL por tenant) → paquetes SSIS → DWH en SQL Server (staging e histórico) → datasets e informes en Power BI.

Qué me llevo

Una ETL que solo sabe operar quien la construyó sigue siendo un riesgo. Los runbooks y los checks de QA son parte del entregable, no un extra para el final.