Por qué tu Data Warehouse es lento (y casi nunca es por falta de servidores)

La primera reacción cuando un reporte tarda minutos en cargar es pedir más cómputo: una instancia más grande, más núcleos, más memoria. A veces sí es necesario. Pero en la mayoría de los Data Warehouse lentos que hemos revisado, el cuello de botella no es la infraestructura — es el modelo de datos.

Un Data Warehouse que junta todas las fuentes en un esquema plano, sin un modelo dimensional claro (esquema estrella o copo de nieve, según el caso), obliga a cada reporte a hacer cruces complejos entre tablas que no fueron diseñadas para relacionarse entre sí. Cada consulta reinventa la lógica de negocio desde cero, y cada analista la escribe un poco distinto — lo que además de ser lento, produce números que no siempre coinciden entre reportes.

El diagnóstico que hacemos antes de tocar infraestructura es revisar cómo está modelada la información: ¿existen tablas de hechos y dimensiones claras? ¿la lógica de negocio (qué cuenta como 'venta', qué cuenta como 'cliente activo') vive en un solo lugar o se repite, ligeramente distinta, en cada consulta? Esa segunda pregunta es la que más veces revela el problema real.

Con MUFG, por ejemplo, el reto no era que el reporte regulatorio tardara — era que cinco personas partían de cinco versiones ligeramente distintas de los mismos datos, generando errores. La solución no fue más cómputo, fue una arquitectura centralizada donde todas las aplicaciones y usuarios de negocio extraen información del mismo lugar, con la lógica de negocio modelada una sola vez.

Cuando el modelo ya está bien diseñado, ahí sí tiene sentido optimizar: índices correctos, particionamiento por fecha en tablas grandes, materializar las consultas que se repiten todos los días. Pero optimizar cómputo sobre un modelo mal diseñado es como comprarle un motor más potente a un coche con las llantas desalineadas — se siente que avanza más rápido por un rato, hasta que el problema de fondo se vuelve a notar.