Tu dashboard es lento, y el problema no es el dashboardTu dashboard es lento, y el problema no es el dashboard

Alguien pregunta por qué el dashboard de ventas tarda cuatro minutos en cargar. La herramienta de BI es lo que se ve, así que la herramienta de BI se lleva la culpa. Se habla de una licencia más rápida. A veces incluso se compra.

Rara vez ayuda, porque esos cuatro minutos no se dedicaron a dibujar gráficos. Se dedicaron a hacer trabajo que debería haberse hecho horas antes, y que se repite en cada actualización.

Qué suele estar haciendo un dashboard lento

Abre la consulta que hay detrás de un informe lento y lo normal es encontrar los mismos patrones. Une cinco tablas de origen en el momento de la lectura. Convierte columnas de texto en fechas porque nadie corrigió los tipos aguas arriba. Filtra por una expresión calculada, así que ningún índice puede ayudar. Elimina filas duplicadas, lo que significa que el origen tiene duplicados que nunca se resolvieron. Y vuelve a hacer todo esto para cada usuario, cada mañana, a la misma hora.

Nada de eso es un problema de visualización. Es un problema de preparación de datos que se ha ido empujando aguas abajo hasta hacerse visible.

Mueve el trabajo, no lo repitas

El enfoque por capas que se llama Bronze, Silver y Gold no tiene nada de glamuroso, y es aquí donde se gana su sitio. Bronze es lo que llegó, guardado tal como llegó. Silver son esos datos limpios, tipados y sin duplicados, una sola vez. Gold es la forma que la pregunta necesita de verdad: una tabla de hechos con sus dimensiones, ya agregada al nivel de detalle por el que pregunta la gente.

Lo importante no son los nombres. Lo importante es que cada operación cara ocurre una vez, de forma programada, en lugar de una vez por usuario y por actualización. Un informe que lee una tabla Gold apenas trabaja: filtra, agrega, dibuja.

Si un cálculo es el mismo para todos los usuarios, no debería ejecutarse una vez por usuario.

La cuestión incremental

Lo segundo que vuelve lentos los informes es reprocesar el histórico. Un pipeline que cada noche reconstruye tres años de pedidos para añadir los de ayer será más lento cada noche, para siempre, por cómo está construido.

La carga incremental lo resuelve, y se trata sobre todo de poder responder a dos preguntas: qué hay de nuevo desde la última vez, y qué significa ejecutar esto dos veces. La primera necesita una marca de agua: una columna updated-at fiable, un feed de cambios, una secuencia. La segunda necesita que la carga sea idempotente, un tema lo bastante amplio como para tener su propio artículo.

Qué comprobar de verdad

• ¿Cuánto tarda por sí sola la consulta más lenta del informe, fuera de la herramienta de BI?
• ¿Lee una tabla preparada, o une fuentes en bruto en el momento de la lectura?
• ¿El proceso nocturno reprocesa todo, o solo lo que ha cambiado?
• ¿Los tipos se corrigen una vez aguas arriba, o se convierten en cada consulta que toca la columna?
• ¿Cuántas personas lanzan la misma actualización costosa en los mismos diez minutos?

Si las respuestas apuntan aguas arriba, y suelen hacerlo, ningún ajuste del dashboard te salvará. La buena noticia es que la solución perdura. El trabajo que se traslada a un pipeline se queda allí.