Las 10 mejores prácticas para la optimización del rendimiento de los dashboards de IA/BI (Parte 1)

Los problemas de rendimiento del dashboard rara vez provienen de un solo lugar. Suelen ser el efecto combinado del diseño del dashboard, la concurrencia y el almacenamiento en caché del warehouse y el diseño de los datos en su lakehouse. Si optimiza una sola capa (SQL, el dimensionamiento de la computación o el diseño de la tabla), a menudo verá ganancias parciales, pero el dashboard puede seguir sintiéndose lento o impredecible en condiciones de uso real.

En esta publicación, adoptamos un enfoque holístico para el rendimiento de AI/BI de Databricks. Seguiremos una interacción con el dashboard de principio a fin: desde el navegador y la capa de orquestación de AI/BI, pasando por la admisión de Databricks SQL y el comportamiento del almacenamiento en caché, hasta el escaneo de archivos y la omisión de datos en el Lakehouse. En el camino, destacaremos los patrones que con mayor frecuencia provocan picos de latencia, esperas en cola y costos a escala, especialmente cuando muchos usuarios interactúan con los mismos dashboards de forma simultánea.

La anatomía de la actualización de un dashboard de IA/BI

Para optimizar el rendimiento, primero debe comprender el recorrido que hace un solo clic a través del stack. Cuando un usuario abre un dashboard o cambia un filtro, se produce una reacción en cadena en varias capas. Si alguna capa está mal configurada, el usuario siente el retraso.

• El navegador (del lado del cliente): Esta es la primera línea de defensa. Para los datasets de menos de 100 000 filas y 100 MB, el navegador actúa como un motor local, gestionando los filtros de campo y las interacciones entre gráficos al instante en la memoria. Si sus datos superan este umbral, cada interacción debe regresar al warehouse.
• El diseño del dashboard (el orquestador): El servicio de AI/BI determina qué consultas deben ejecutarse. Un diseño de "página única" envía la consulta de cada widget simultáneamente, lo que crea un pico de concurrencia masivo. Un diseño de "varias páginas" solo solicita datos para la pestaña visible, lo que da forma eficaz a la demanda en su computación.
• Databricks SQL (el motor): Su SQL Warehouse (idealmente Serverless) recibe la ráfaga. Comprueba la caché, que tiene varias capas, para ver si el trabajo ya se ha hecho. De lo contrario, la Administración inteligente de cargas de trabajo (IWM) admite la consulta y escala automáticamente los clústeres en segundos para gestionar la carga sin necesidad de ponerla en cola.
• El Lakehouse (el almacenamiento): Finalmente, el motor llega a los datos. Escanea archivos Delta en el almacenamiento de objetos en la nube. Aquí, Liquid Clustering y los tipos de datos determinan la eficiencia de E/S. El objetivo es omitir la mayor cantidad de datos posible utilizando estadísticas y metadatos a nivel de archivo para devolver el conjunto de resultados a la cadena.

Al optimizar cada uno de estos cuatro puntos de contacto, te alejas del cómputo de fuerza bruta y te acercas a una arquitectura optimizada que escala con tus usuarios.

Prerrequisito: comprender sus datos y su dashboard

Antes de optimizar cualquier cosa, primero debe definir para qué está optimizando. El rendimiento del dashboard no es un concepto único y las mejoras solo tienen sentido cuando están vinculadas a un objetivo claro. Los objetivos comunes incluyen reducir el tiempo hasta el primer elemento visual, mejorar la latencia de la interacción, mantener el rendimiento estable bajo simultaneidad o reducir el costo por vista de dashboard.

Una vez que el objetivo esté claro, debe comprender los parámetros que le dan forma. Estos incluyen el tamaño y el crecimiento de los datos, la cantidad de usuarios y sus patrones de acceso, y cómo se comportan las consultas en la práctica: cuántas se activan al cargar la página, cuántos datos escanean y si los resultados se reutilizan o se recalculan constantemente. Sin este contexto, la optimización se basa en suposiciones y, a menudo, traslada el costo o la latencia de una capa a otra.

Por lo tanto, la optimización eficaz del dashboard es intencional: elija un objetivo medible, comprenda los datos y los patrones de uso que influyen en él y solo entonces aplique las optimizaciones técnicas que se describen a continuación.

Optimización n.º 1: Organice el dashboard en páginas (pestañas) 

Cada mosaico visible es un posible activador: se ejecuta en la primera carga y puede volver a ejecutarse cuando cambian los filtros o parámetros, al actualizarse y cuando los usuarios vuelven a una página. Las pestañas limitan esas reejecuciones a la página activa, lo que reduce las ráfagas y el bloqueo de cabecera de línea.

Los dashboards de IA/BI le permiten crear informes de varias páginas. Agrupe los elementos visuales en páginas que se ajusten a la intención del usuario (Visión general → Investigar → Análisis profundo), para que solo se ejecute la página actual. Esto reduce el bloqueo de cabecera de línea, modula la concurrencia en ráfagas más pequeñas y aumenta las tasas de acierto de caché para consultas deterministas repetidas.

Tipos de página recomendados:

• Resumen: contadores rápidos y líneas de tendencia para la primera renderización, mantenga las uniones/ventanas pesadas fuera de la página de destino.
• Investigar: exploración centrada en entidades (cliente/producto/región) con filtros que envían predicados a SQL (parámetros) cuando se necesita una reducción previa a la agregación.
• Análisis profundo: agregaciones costosas impulsadas por actualizaciones programadas o vistas materializadas/de métricas (puede exportar un conjunto de datos de un dashboard a una vista materializada).

Prefiera los mosaicos determinísticos (evite NOW()) para maximizar los aciertos de la caché de resultados, supervise el pico de consultas en cola y aumente el tamaño del clúster o el número máximo de clústeres si es persistentemente > 0. 

La función de análisis detallado en los dashboards de AI/BI permite la navegación desde elementos visuales de alto nivel a páginas detalladas mientras se mantiene el contexto seleccionado. Es una estrategia útil para aplicar un diseño basado en páginas al aplazar las consultas costosas hasta que la intención del usuario sea clara, lo que mejora el rendimiento de la primera renderización y reduce los picos de simultaneidad innecesarios.

Aclaración: por qué esto ayuda en cualquier tipo de warehouse: Las ráfagas más pequeñas y predecibles hacen que el IWM sin servidor reaccione rápidamente y evite el sobreescalamiento, y evitan que Pro/Classic sature las ranuras del clúster durante las cargas de página. 

Para obtener más detalles, consulte: https://www.databricks.com/blog/whats-new-in-aibi-dashboards-fall24 

Optimización n.º 2: Optimice la "primera visualización" con valores predeterminados inteligentes

La primera impresión de un dashboard se define por su primera visualización, es decir, el tiempo que transcurre desde que se abre el dashboard hasta que se ven resultados significativos. Los valores de filtro predeterminados desempeñan un papel fundamental aquí, porque determinan qué consultas se ejecutan inmediatamente al cargar la página y cuántos datos deben procesar esas consultas.

Cuando los filtros no tienen valores predeterminados, los dashboards de IA/BI a menudo cargan el conjunto de datos completo la primera vez que se abren. Esto maximiza el volumen de escaneo, aumenta el fan-out de las consultas entre los mosaicos y retrasa el momento en que los usuarios ven información útil. El resultado es una primera experiencia lenta e impredecible, especialmente dolorosa durante los picos de concurrencia cuando muchos usuarios abren el mismo dashboard.

Los valores predeterminados inteligentes solucionan esto al restringir la forma de la consulta inicial. Algunos ejemplos comunes son:

• Establecer filtros de fecha predeterminados para un período reciente (por ejemplo, los últimos 7 o 30 días).
• Preseleccionar una región, una unidad de negocio o una entidad de nivel superior comunes.
• Elegir un "Todo" sensato que siga siendo selectivo (por ejemplo, el año fiscal actual en lugar de todo el historial).

Técnicamente, los filtros predeterminados reducen la cantidad de datos escaneados, mejoran las tasas de acierto de la caché y permiten la reutilización de resultados entre los usuarios que abren el panel con el mismo estado inicial. Esto mejora directamente el tiempo hasta el primer elemento visual y hace que el rendimiento sea mucho más consistente.

El principio de diseño clave es simple: optimizar para la experiencia de llegada. Haz que la primera visualización sea rápida e informativa y, luego, permite que los usuarios amplíen el alcance intencionalmente mientras exploran. Un "first paint" rápido genera confianza, fomenta la adopción y establece la base de rendimiento para cada interacción posterior.

Para más detalles, consulte: https://docs.databricks.com/aws/en/dashboards/filters#-set-default-filter-values

Optimización n.º 3: Usar parámetros para segmentar datasets grandes

Los parámetros son una de las formas más eficaces de escalar los dashboards de IA/BI porque le dan forma a la consulta antes de que se ejecute. Al inyectar valores directamente en el SQL, desplazan los predicados hacia abajo de forma temprana, para que Databricks pueda podar los datos antes y realizar mucho menos trabajo por consulta (idealmente, filtrando antes de las uniones y agregaciones).

Los filtros de campo se comportan de forma diferente. Si el dataset subyacente es lo suficientemente pequeño como para almacenarse en la caché del navegador (≤ 100 000 filas y ≤ 100 MB), los filtros de campo y las interacciones entre filtros pueden evaluarse del lado del cliente sin un viaje de ida y vuelta al warehouse. Una vez que los datasets superan ese umbral, los filtros de campo suelen enviarse al warehouse envolviendo la consulta del dataset (a menudo a través de una CTE), lo que desencadena la ejecución de SQL del backend y puede no reducir el costo de escaneo con tanta eficacia como los predicados parametrizados que se aplican antes de las uniones y la agregación.

Los parámetros son especialmente eficaces para segmentar por rangos de fechas, regiones, unidades de negocio u otras dimensiones que reducen significativamente el volumen de datos. También hacen que el rendimiento sea más predecible: cada mosaico ejecuta consultas más económicas y los picos de concurrencia son más fáciles de absorber para el warehouse.

Existe una contrapartida. Como los diferentes valores de los parámetros producen diferentes firmas de consulta, la reutilización de la caché puede ser menor cuando los usuarios eligen constantemente valores únicos. En la práctica, esta suele ser la solución de compromiso adecuada: una consulta pequeña y económica sin un acierto de caché es mucho mejor que una consulta grande y costosa que depende del almacenamiento en caché para sobrevivir. Puede equilibrar esto aún más si utiliza valores predeterminados sensatos y un conjunto limitado de valores de parámetros comunes, de modo que las rutas populares sigan beneficiándose de la caché de resultados.

Una regla práctica es: mantener los datasets lo suficientemente pequeños como para que quepan en la caché del navegador y usar filtros de campo para la interactividad (en el mejor de los casos: no hay viajes de ida y vuelta al warehouse). Si no está seguro de que el dataset se mantendrá de forma fiable dentro de los límites de la caché del navegador, utilice parámetros para reducir el dataset de forma temprana, de modo que el warehouse lea menos datos por adelantado, y luego aplique filtros para una exploración más profunda. Esto convierte los dashboards de "escanear todo y filtrar después" en consultas selectivas y escalables que se mantienen rápidas a medida que crecen los datos y los usuarios.

Para obtener más detalles, consulte:

• https://medium.com/@andrea0pica/databricks-ai-bi-caching-explained-0c4de1aa946b

Optimización n.º 4: Use la caché del navegador

El almacenamiento en caché del navegador es más útil cuando las interacciones se basan en filtros de campo en conjuntos de datos pequeños. Una vez que los parámetros modifican el SQL, o los conjuntos de datos superan el umbral del navegador, las interacciones vuelven a la ejecución del warehouse.

Los dashboards de AI/BI de Databricks pueden almacenar en caché los resultados del conjunto de datos directamente en el navegador del usuario, lo que permite que muchas interacciones se manejen por completo del lado del cliente sin viajes de ida y vuelta al almacén de SQL.

Cuando un conjunto de datos tiene menos de aproximadamente 100 000 filas, el navegador se convierte en un motor de ejecución local. El filtrado cruzado, la clasificación y las agregaciones simples se pueden resolver instantáneamente en la memoria, lo que produce interacciones con una latencia casi nula y elimina por completo la presión de simultaneidad del backend. Es por eso que las páginas de resumen bien diseñadas a menudo se sienten “instantáneas”, incluso bajo un uso intensivo.

La memoria caché del navegador se utiliza automáticamente cuando:

• El conjunto de datos es lo suficientemente pequeño como para cargarse de forma segura en el navegador.
• Las interacciones se basan en filtros de campo o selecciones entre gráficos que se pueden evaluar del lado del cliente.
• Ningún cambio de parámetro fuerza una nueva ejecución de SQL en el warehouse.

Una vez que los datasets superan este umbral, o cuando los parámetros modifican el SQL subyacente, la interacción se devuelve al warehouse y el almacenamiento en caché del navegador ya no se aplica.

La conclusión clave del diseño es el dimensionamiento intencional del conjunto de datos. Mantenga los conjuntos de datos de la página de destino y de la visión general compactos, preagregados y centrados en los KPI comunes para que califiquen para el almacenamiento en caché del navegador. Esto proporciona un "first paint" instantáneo, reduce el fan-out de las consultas y preserva la capacidad del almacén para las páginas de investigación más profundas donde la ejecución del backend es inevitable.

Para obtener más detalles, consulte: https://docs.databricks.com/aws/en/dashboards/caching#dataset-optimizations

Optimización n.º 5: Maximizar el uso de la caché de resultados

La consulta más barata y rápida es la que no se ejecuta. 

El almacenamiento en caché de resultados de Databricks SQL convierte las interacciones repetidas del dashboard en respuestas casi instantáneas, al servir los resultados desde la caché en lugar de volver a calcularlos.

Cómo funciona el almacenamiento en caché de resultados (qué se almacena en caché, dónde y durante cuánto tiempo)

Databricks SQL comprueba los resultados almacenados en caché antes de ejecutar una consulta:

• Caché de resultados local (todos los warehouses): caché por clúster.
   
• Caché de resultados remota (Serverless): en todo el workspace y persiste a través de los reinicios del warehouse.

Ambas cachés tienen un TTL de aproximadamente 24 horas y se invalidan cuando las tablas subyacentes cambian, por lo que se mantiene la actualización de los datos mientras se beneficia de la reutilización.

Diseña los paneles para que los aciertos de caché sean probables.

Los aciertos de caché no son automáticos, son el resultado de un diseño. Se obtiene el máximo valor cuando muchos usuarios le hacen al warehouse la misma pregunta de la misma manera.

1) Haga que los mosaicos sean determinísticos
Evite las funciones no determinísticas (p. ej., NOW() / current_timestamp()), porque cambian el resultado de la consulta e impiden la reutilización. Prefiera parámetros explícitos de fecha/hora y mantenga estable el texto de la consulta para que las selecciones idénticas se puedan servir desde la caché.

2) Reutilice conjuntos de datos y mantenga la "forma" de la consulta consistente
El almacenamiento en caché y la reutilización mejoran drásticamente cuando los mosaicos comparten la misma lógica del conjunto de datos y una forma consistente de predicado / GROUP BY. Cuando varios elementos visuales pueden obtener respuesta con la misma consulta de backend (o el mismo conjunto de datos canónico), reduces la cantidad de sentencias enviadas y aumentas las tasas de acierto de la caché.

3) Tenga en cuenta la identidad y la suplantación
La reutilización de la caché de resultados es más eficaz cuando la misma consulta se ejecuta en el mismo contexto de acceso. Si su configuración usa la suplantación por espectador, es posible que se reduzca la reutilización de la caché porque los resultados no siempre se pueden compartir de forma segura entre identidades.
Mejor práctica: cuando sea aceptable desde una perspectiva de seguridad y gobernanza, prefiera una identidad de ejecución compartida para los dashboards publicados (por ejemplo, una entidad de servicio o un contexto de acceso compartido) para que las vistas repetidas puedan beneficiarse de la reutilización de la caché. Si debe usar la suplantación por usuario, compénselo maximizando la reutilización del dataset y centrándose en rutas comunes deterministas y parametrizadas.

Prefiera Serverless para interacciones repetidas

El modo sin servidor agrega la caché de resultados remota, que es compartida en todo el workspace, sobrevive a los reinicios y también es utilizada por los clientes ODBC/JDBC y la API de sentencias SQL. Para los dashboards que se abren repetidamente y con rutas de filtro comunes, esto suele producir la mayor ganancia de rendimiento "gratuita".

Precaliente las cachés de forma proactiva

Para los dashboards publicados, agregue una programación. Las ejecuciones programadas ejecutan la lógica del conjunto de datos antes de las horas pico y llenan las cachés, mejorando la primera visualización y suavizando las ráfagas de principio de hora.

Verifique los aciertos (y evite benchmarks engañosos)

Use:

• Historial de consultas: from_result_cache y cache_origin_statement_id
• EXPLAIN EXTENDED para entender la elegibilidad de la caché

Notas:

• La caché local no insertará resultados de más de ~500 MiB (la caché remota no tiene restricciones de tamaño).
• La caché remota requiere clientes con compatibilidad con Cloud Fetch (es posible que los controladores más antiguos no la tengan).

Para la evaluación comparativa, deshabilite el almacenamiento en caché solo durante las pruebas controladas:
SET use_cached_result = false
… y vuelva a habilitarlo para el uso real, de modo que los dashboards se beneficien del almacenamiento en caché en producción.

Higiene operativa: evite la contaminación de la memoria caché

No mezcle cargas de trabajo no relacionadas en el mismo warehouse de BI. Los warehouses de BI sin servidor dedicados por dominio/carga de trabajo ayudan a que la caché remota se llene con las consultas repetidas que son importantes para esos dashboards.

Para obtener más detalles, consulte: https://www.databricks.com/blog/understanding-caching-databricks-sql-ui-result-and-disk-caches 

Perspectiva: Parte 2

Esta parte se centró en cómo el diseño del dashboard y los patrones de interacción influyen en el rendimiento, incluso antes de que el warehouse y los datos se vean involucrados. Al reducir el fan-out, optimizar la primera visualización y maximizar la reutilización de la caché, a menudo puede obtener grandes ganancias sin cambiar los datos subyacentes. En la segunda parte, completamos el panorama profundizando en la plataforma: cómo elegir y dimensionar el SQL warehouse adecuado, cómo el modelado de datos y el diseño de archivos afectan la eficiencia del escaneo, y cómo la precomputación, la materialización y los tipos de datos mantienen los dashboards rápidos y estables a medida que el uso se escala.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original