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

Esta publicación es la segunda parte de una serie de dos partes sobre cómo optimizar el rendimiento de los dashboards de IA/BI de Databricks a escala. 

En la publicación anterior, nos centramos en cómo el diseño, los filtros, los parámetros y el almacenamiento en caché determinan la cantidad de trabajo que realiza el sistema por cada clic. Esas optimizaciones suelen ser suficientes para que los dashboards se sientan rápidos. 

En esta publicación, nos enfocamos en los cimientos de la plataforma que garantizan su rapidez a medida que crece el uso. Analizaremos la selección y el dimensionamiento del warehouse, el modelado de datos y las elecciones de esquemas, el diseño de archivos y el clustering, y cuándo depender de la materialización en lugar del recálculo para lograr un rendimiento estable y predecible.

Optimización n.º 6: elige la configuración del warehouse que coincida con el diseño 

Ajuste la forma de su dashboard (páginas, mezcla de consultas, picos de actividad de los usuarios) al tipo y tamaño del DBSQL warehouse para que el sistema acepte el trabajo rápidamente sin ponerlo en cola.

Debido a que los widgets visibles se envían juntos, los dashboards generan naturalmente picos de concurrencia de corta duración. Si el warehouse no puede absorber la ráfaga, verá encolamiento (Peak Queued Queries > 0) y tiempos de carga de paneles inconsistentes, especialmente en las horas pico.

Cómo funciona la simultaneidad del warehouse de DBSQL

• Serverless + IWM: Serverless utiliza la Administración inteligente de cargas de trabajo (Intelligent Workload Management) para predecir costos, admitir y priorizar consultas, y autoescalar rápidamente. El inicio típico es de 2 a 6 segundos, por lo que las ráfagas mantienen una baja latencia sin necesidad de ajustes manuales.
• Pro/Classic: Límite fijo de “10 consultas simultáneas por clúster”, el escalado automático agrega clústeres en umbrales de minutos y el inicio tarda varios minutos. Planifique la capacidad según la simultaneidad esperada y evite picos en la carga de la página.
• Supervise y ajuste el tamaño: observe Peak Queued Queries y el Query History; si los picos persisten por encima de 0, aumente el tamaño del clúster (especialmente si el Query Profile muestra un volcado a disco) o aumente el número máximo de clústeres. 

¿Por qué Serverless primero?

• Serverless recomendado para BI interactiva: inicio más rápido, concurrencia dinámica a través de IWM y E/S más eficiente.

Heurísticas prácticas de dimensionamiento

• Empiece con un tamaño más grande (tamaño de clúster) y redúzcalo después de las pruebas, deje que el autoescalado sin servidor (Serverless) gestione los picos de simultaneidad y aumente el máximo de clústeres solo cuando persistan los picos en la cola.
• Mantén separados los procesos pesados de ETL y BI: dedica almacenes sin servidor por carga de trabajo/dominio (evita la contaminación de la caché y permite que IWM aprenda el patrón de la carga de trabajo).
• Priorice las consultas pequeñas y frecuentes: Serverless IWM protege las interacciones cortas y escala rápidamente durante cargas de trabajo mixtas; diseñe las páginas de modo que la vista general (Overview) ejecute primero los mosaicos más ligeros. 

Para obtener más detalles, consulte: https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior 

Optimización #7: Aplicar las mejores prácticas de modelado de datos

Los modelos de datos bien diseñados son una característica de rendimiento fundamental para los paneles de IA/BI. El esquema de estrella sigue siendo el patrón de modelado más eficaz y predecible para el análisis interactivo porque se alinea directamente con la forma en que se escriben y optimizan las consultas de BI.

En un esquema de estrella, una tabla de hechos central contiene eventos medibles (ventas, transacciones, clics) y se une a las tablas de dimensiones circundantes (fecha, cliente, producto, región). Esta estructura minimiza la complejidad de las uniones, reduce la duplicación de datos y permite agregaciones eficientes con patrones de consulta simples y estables. Como resultado, los dashboards ejecutan menos joins, escanean menos datos y se benefician de forma más consistente del almacenamiento en caché y la optimización de consultas.

Un detalle crítico, pero que a menudo se pasa por alto, son los tipos de datos de las claves de join. Los joins de las tablas de dimensiones y de hechos deben usar claves subrogadas basadas en enteros, no cadenas de texto. Los joins de enteros son significativamente más rápidos, requieren menos memoria, mejoran la eficiencia de la memoria caché y permiten que Photon ejecute los joins mediante rutas vectorizadas altamente optimizadas. Los joins basados en cadenas de texto aumentan el costo de la CPU y pueden convertirse en un cuello de botella oculto a medida que aumentan los datos y la simultaneidad.

En Databricks, este patrón encaja de forma natural con la arquitectura Lakehouse. La capa gold debe modelarse como hechos y dimensiones almacenados como tablas de Unity Catalog, lo que proporciona una base semántica gobernada y reutilizable para dashboards de IA/BI, vistas de métricas y vistas materializadas.

La conclusión es simple: modele según cómo se ejecutan realmente las consultas de BI. Un esquema de estrella con claves de unión de tipo entero en la capa gold ofrece un SQL más simple, uniones más rápidas y un rendimiento más predecible a escala.

Optimización n.º 8: técnicas de optimización de Parquet

Diseñe la disposición de sus datos para que los dashboards lean muchos menos datos por consulta; luego, deje que el motor aproveche las estadísticas de Parquet y las lecturas selectivas. 

Considere el diseño de archivos como una característica de rendimiento

Databricks SQL es más rápido cuando puede:

• podar archivos completos utilizando metadatos (estadísticas mín./máx.),
• leer fragmentos grandes y contiguos de manera eficiente,
• y evita abrir miles de archivos pequeños.

Por lo tanto, las dos mayores ventajas son: compactar archivos a tamaños óptimos y
agrupar los datos en clústeres para que los predicados descarten archivos.

Hay más detalles disponibles aquí: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

Un antipatrón clásico: un filtro de dashboard como WHERE customer_id = ? parece selectivo, pero si los datos no están agrupados, el motor sigue accediendo a una gran parte de los archivos porque las filas que coinciden están dispersas por todas partes.

Técnicas

• Use Photon para aprovechar el Predictive IO integrado en Parquet: Photon aplica la lectura selectiva asistida por IA y E/S paralela para omitir bloques no coincidentes y enumerar menos archivos, lo que proporciona exploraciones selectivas rápidas sin indexación manual.
• Habilite las optimizaciones predictivas para las tablas administradas: Databricks puede programar y ejecutar automáticamente el mantenimiento de las tablas basándose en los patrones de carga de trabajo observados —OPTIMIZE (compactación para mantener los tamaños de archivo en buen estado), ANALYZE (estadísticas actualizadas), VACUUM (limpieza) y Liquid Clustering (diseño adaptable)—, lo que lo libera del ajuste manual mientras mejora el precio/rendimiento de la lectura a escala. En la práctica, esto ayuda a mantener los tamaños de archivo en buen estado compactando proactivamente los archivos pequeños (mediante OPTIMIZE) para que los metadatos de Parquet (pies de página + estadísticas mín./máx.) sigan siendo eficaces para el salto de datos, los análisis selectivos y los análisis/simultaneidad de BI.
• Desencadene las mismas operaciones manualmente cuando sea necesario: puede seguir ejecutándolas usted mismo cuando necesite un control más estricto o un tiempo más rápido para obtener beneficios (p. ej., después de grandes ingestas o backfills, cambios de esquema o antes de un pico de informes conocido) mediante la ejecución de comandos como OPTIMIZE y ANALYZE. La clave es ser intencional: alinee la cadencia de mantenimiento con la frecuencia con la que cambia la tabla y asegúrese de que el costo de computación se justifique por las ganancias posteriores en concurrencia, latencia y eficiencia de escaneo.
• Adopte Liquid Clustering en lugar de un particionamiento pesado. Liquid agrupa los datos de forma incremental para búsquedas puntuales y escaneos selectivos, y usted puede cambiar las columnas de agrupamiento en cualquier momento (incluso de alta cardinalidad) sin una reescritura completa; el diseño se adapta a medida que evoluciona el uso.
• Alinee el diseño con los predicados del dashboard. Elija columnas de Liquid clustering que reflejen las dimensiones comunes de filtrado/agrupación (p. ej., fecha, cliente, región) para que Predictive IO pueda omitir grandes franjas de datos para las páginas de “Investigación” y “Análisis profundo”. 

Resultado: menos archivos accedidos, más bloques omitidos y menor tiempo de reloj de pared para la misma información, sin índices frágiles ni ajustes manuales. 

Para más detalles, consulte: 

• https://www.databricks.com/blog/faster-lakeview-dashboards-materialized-views
• https://docs.databricks.com/aws/en/compute/photon
• https://docs.databricks.com/aws/en/delta/data-skipping
• https://docs.databricks.com/aws/en/delta/optimize 

Optimización n.º 9: Utilice la materialización de vistas de métricas

En Optimización n.º 7: Aplicar las mejores prácticas de modelado de datos, nos centramos en la importancia del esquema de estrella con hechos, dimensiones y KPI claramente definidos. Las Metric Views son una continuación directa de estos principios en Databricks AI/BI.

Las vistas de métricas están diseñadas en torno a la semántica de BI: se componen de medidas y dimensiones, lo que las convierte en una abstracción natural para modelar KPI. Permiten que los equipos definan las métricas de negocio una vez y reutilicen los mismos KPI de forma coherente en múltiples dashboards, agentes y otras herramientas de cliente. Esto reduce la duplicación, evita la desviación de los KPI y mantiene la lógica analítica alineada a medida que crece la adopción.

Con la materialización para las Metric Views, Databricks precalcula y mantiene automáticamente los agregados de uso frecuente. Estos agregados se actualizan de forma incremental y, en el momento de la consulta, el optimizador reescribe de forma transparente las consultas del panel al resultado precalculado que mejor coincida. Como resultado, las consultas de los paneles analizan muchos menos datos por interacción, sin que los equipos deban administrar tablas de agregación separadas o canalizaciones personalizadas.

Si no se usan las Vistas de métricas, se puede aplicar el mismo enfoque con Vistas materializadas. Por ejemplo, se puede precalcular y almacenar una versión agregada de una tabla de hechos grande, lo que permite a los dashboards consultar un conjunto de datos mucho más pequeño y optimizado. Esto mejora significativamente el rendimiento al reducir la cantidad de datos escaneados y evita volver a calcular repetidamente agregaciones costosas para cada interacción del usuario.

Todas estas técnicas optimizan lo mismo: escanear menos datos. Al definir los KPI una sola vez y precalcular los agregados de uso frecuente con Vistas de métricas (Metric Views) o Vistas materializadas (Materialized Views), los dashboards evitan la agregación repetida de grandes tablas de hechos. Menos bytes escaneados se traducen directamente en consultas más rápidas, una latencia más predecible y un mejor rendimiento a escala.

Para más detalles, consulte: 

• https://docs.databricks.com/aws/en/metric-views/materialization

Optimización n.º 10: optimizar los tipos de datos

Los tipos de datos influyen directamente en la cantidad de datos que Databricks SQL debe leer, mover y procesar para cada consulta del dashboard. Incluso con un SQL y un almacenamiento en caché perfectos, los tipos de datos ineficientes aumentan silenciosamente la E/S (IO), la presión sobre la memoria y el costo de la CPU, lo que se traduce en mosaicos más lentos y una menor simultaneidad.

Internamente, Databricks SQL opera en archivos Parquet columnares. Tipos de datos más pequeños y bien elegidos significan lo siguiente:

• Menos datos escaneados del almacenamiento (columnas más estrechas),
• Mejor densidad de caché (más valores caben en la memoria y en la caché de resultados),
• Ejecución vectorizada más rápida en Photon (diseños compatibles con SIMD),
• Omisión de datos más eficaz, porque las estadísticas mín./máx. son más ajustadas.

Algunos mecanismos son los más importantes:

• Use INT / BIGINT en lugar de STRING para los identificadores siempre que sea posible. Las cadenas (strings) son costosas de escanear, comparar y almacenar en caché; las claves numéricas son órdenes de magnitud más baratas.
• Prefiera DATE o TIMESTAMP en lugar de fechas basadas en cadenas. Los tipos temporales nativos permiten el empuje de predicados, comparaciones eficientes y una mejor poda.
• Usa el tipo numérico más pequeño que se ajuste (INT frente a BIGINT, FLOAT frente a DOUBLE) para reducir el ancho de la columna y el consumo de memoria.
• Evite el uso excesivo de DECIMAL con una precisión excesiva en las tablas orientadas a BI, a menos que sea necesario; los decimales de alta precisión aumentan el costo de la CPU durante la agregación.
• Mantenga los esquemas limpios y estables. Las conversiones implícitas (por ejemplo, de STRING → INT en el momento de la consulta) inhabilitan las optimizaciones y agregan cómputo innecesario en cada ejecución.

En las cargas de trabajo de BI, estas elecciones se acumulan rápidamente: una página del dashboard puede ejecutar docenas de consultas, y cada una de ellas escanea millones de filas. Las columnas estrechas y bien tipadas reducen el tiempo de escaneo, mejoran las tasas de aciertos de caché y permiten que Photon funcione con la máxima eficiencia.

Regla de oro: trata el diseño del esquema como una característica de rendimiento. Optimice los tipos de datos una vez en el Lakehouse y todos los dashboards, actuales y futuros, se beneficiarán automáticamente.

Conclusión

El tema central de las diez prácticas recomendadas es simple: deje de pagar el precio completo de una interacción con el dashboard cada vez. Haga que el sistema trabaje menos por cada vista (menos fan-out, menos datos escaneados), y haga que el trabajo que realiza sea reutilizable (datasets compartidos, consultas deterministas, cachés y agregados precalculados). Cuando todos estos elementos encajan, el rendimiento se vuelve estable bajo simultaneidad y el costo se vuelve predecible.

En la práctica, debería poder responder “sí” a estas preguntas para sus dashboards más utilizados:

• ¿Los usuarios obtienen un primer renderizado rápido (vista de aterrizaje ligera + valores predeterminados razonables)?
• ¿Una interacción típica desencadena un número reducido de consultas baratas (los parámetros se filtran pronto, no después del análisis)?
• ¿Las vistas repetidas se están convirtiendo en aciertos de caché (mosaicos deterministas, reutilización entre mosaicos, precalentamiento programado)?
• ¿Puede el warehouse absorber la carga máxima sin poner en cola o desbordar (las consultas en cola máximas (Peak Queued Queries) se mantienen cerca de cero, el perfil de consulta (Query Profile) no se desborda)?
• ¿Está optimizado el Lakehouse para las lecturas (tamaños de archivo saludables, Liquid Clustering, tipos de datos limpios y agregados calientes precalculados)?

Elija un dashboard con adopción real, ejecute una línea de base rápida (primer renderizado, latencia de interacción, consultas en cola máximas, desbordamiento, tasa de aciertos de caché), aplique un par de los cambios de mayor impacto y vuelva a medir. Haga eso de manera consistente y pasará de un AI/BI “a veces rápido” a uno confiablemente rápido a medida que crecen los datos y los usuarios.

Referencias y lecturas adicionales

• Dimensionamiento, escalado, puesta en cola y monitoreo del SQL warehouse, Serverless IWM frente al escalado automático Pro/Classic. https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior
• Creación/configuración de warehouses, guía de clústeres por concurrencia.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/create
• Ventajas de serverless y por qué se recomienda.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/
• Tipos de warehouse y características de rendimiento (Photon, Predictive IO, IWM, inicio de 2 a 6 s para Serverless).
  https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types
• Almacenamiento en caché de resultados (por clúster y caché de resultados remota sin servidor [Serverless]).
  https://docs.databricks.com/aws/en/lakehouse-architecture/performance-efficiency/best-practices https://learn.microsoft.com/es-mx/azure/databricks/sql/user/queries/query-caching
• Dashboards de IA/BI: páginas/lienzo/modelo de datos y componentes.
  https://docs.databricks.com/aws/en/dashboards
• Parámetros frente a filtros de campo, parámetros basados en consultas.
  https://docs.databricks.com/aws/en/dashboards/parameters
• Exporte un conjunto de datos del dashboard a una vista materializada para acelerar las cargas de trabajo pesadas.
  https://docs.databricks.com/aws/en/ai-bi/release-notes/2025
• Ejecuciones de consultas del panel en los registros de auditoría (verifique qué se ejecuta al cargar).
  https://docs.databricks.com/aws/en/admin/account-settings/audit-logs

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