Punteros de BI Serving; Maximizando el Rendimiento y el TCO

Tus paneles de BI son lentos y optimizarlos te cuesta demasiado tiempo y dinero.

Es un patrón familiar. Una consulta de panel tarda 30 segundos, así que alguien crea una tabla agregada para acelerarla. Esa tabla necesita un pipeline de actualización. El pipeline necesita monitorización. Luego, una segunda herramienta de BI necesita los mismos datos en una forma ligeramente diferente, así que alguien crea otra tabla agregada utilizando un pipeline separado. En poco tiempo, estás gestionando una proliferación de agregados, extractos y capas semánticas específicas de la herramienta, cada una con su propia ventana de desactualización, sus propias lagunas de gobernanza y su propia línea en la factura de cómputo.

Las cargas de trabajo de BI son diferentes de otras cargas de trabajo analíticas. Son de alta concurrencia, sensibles a la latencia y repetitivas en sus patrones de consulta. Esa combinación exige un enfoque deliberado para modelar, almacenar, optimizar y servir datos. La buena noticia: Databricks proporciona una pila completa para el servicio de BI, desde la disposición física de los datos hasta una capa semántica gobernada, y cada capa potencia las ganancias de rendimiento de la capa inferior.

Esta publicación recorre esa pila de abajo hacia arriba, con orientación práctica sobre dónde centrarse para obtener las mayores mejoras en el rendimiento y el costo de las consultas.

La Pila de Servicio de BI

Antes de profundizar en cada capa, aquí está la imagen completa:

Unity Catalog proporciona gobernanza en toda la pila: linaje y control de acceso desde los datos brutos hasta la semántica y el consumo. Cada capa aborda un aspecto diferente del rendimiento y el costo. Vamos a repasarlas.

Optimizar la Capa Física

La capa física es donde se gana o se pierde la mayor parte del rendimiento de BI. Si aciertas aquí, cada consulta se beneficia, antes de haber tocado la capa semántica.

Comenzar con el Modelado Dimensional

Los esquemas en estrella siguen siendo el estándar de oro para el rendimiento de las consultas de BI. Las tablas de dimensiones amplias y desnormalizadas unidas a tablas de hechos a través de claves sustitutas proporcionan al optimizador de consultas rutas de unión limpias y predecibles.

Databricks soporta completamente las construcciones de modelado relacional que necesitas: restricciones de clave primaria y foránea (con RELY para pistas del optimizador), columnas de identidad para claves sustitutas y restricciones de CHECK y NOT NULL. Si sigues una arquitectura Medallion, mantén tus modelos normalizados o Data Vault en Silver y crea esquemas en estrella desnormalizados en Gold para el consumo de BI.

Para patrones de implementación detallados —manejo de SCD Tipo-1 y Tipo-2, ETL de tablas de hechos con MERGE, dimensiones que llegan tarde— consulta la serie de blogs Implementación de un Data Warehouse Dimensional en Databricks SQL.

Usar Tablas Administradas

Las tablas administradas de Unity Catalog son la base de todo lo demás en esta pila. Unity Catalog gestiona todas las responsabilidades de lectura, escritura, almacenamiento y optimización para las tablas administradas. Esto desbloquea características automáticas que no obtienes con tablas externas: Optimización Predictiva (cubierta a continuación) está habilitada por defecto. Clustering líquido automático selecciona claves de clustering que se adaptan a medida que cambian los patrones de consulta. El caché de metadatos está siempre activo, reduciendo las solicitudes de almacenamiento en la nube y acelerando la planificación de consultas.

Utiliza tablas administradas en toda la plataforma, no solo para el servicio de BI, sino en todas las capas Bronze, Silver y Gold. Son el tipo de tabla predeterminado en Unity Catalog, y los beneficios de rendimiento y gobernanza se acumulan con cada otra optimización en esta pila.

Aplicar Clustering Líquido

Clustering líquido reemplaza la partición estática y el Z-ORDER manual, y a diferencia de esos enfoques, puedes redefinir las claves de clustering sin reescribir los datos existentes. Añade CLUSTER BY (col1, col2) al crear la tabla o utiliza ALTER TABLE en tablas existentes. Si no estás seguro de qué columnas elegir, CLUSTER BY AUTO permite que la Optimización Predictiva seleccione claves basadas en los patrones de consulta observados.

Para cargas de trabajo de BI, agrupa por tus columnas de filtro y unión más comunes: claves de fecha, región, categoría de producto. Puedes seleccionar hasta cuatro columnas, y si dos columnas están muy correlacionadas, incluye solo una. Cuando los paneles filtran por columnas de clúster, el clustering líquido mejora el rendimiento de las consultas mediante el salto de datos.

Deja que la Optimización Predictiva se encargue del resto

La Optimización Predictiva ejecuta automáticamente OPTIMIZE, VACUUM y la recopilación de estadísticas en tablas que se beneficiarían de estas operaciones, para que no necesites programar estos trabajos tú mismo. Recopila estadísticas de salto de datos de Delta y estadísticas del optimizador de consultas durante las escrituras de Photon, y rellena estadísticas para tablas existentes. En cargas de trabajo observadas, esto proporcionó una mejora de rendimiento promedio del 22%. Para cargas de trabajo de BI con patrones de filtro repetitivos, el impacto es especialmente significativo: mejores estadísticas significan mejor salto de datos y planes de consulta más eficientes.

Habilita la Optimización Predictiva a nivel de catálogo y deja que se ejecute. Usar la Optimización Predictiva es una de las optimizaciones de mayor retorno y menor esfuerzo que puedes hacer.

El resultado: Las consultas de BI escanean menos datos, se unen de manera más eficiente y cuestan menos de ejecutar, y aún no has tocado la capa semántica.

Vistas de Métricas: Define tus Métricas una Vez

Aquí es donde las cosas se ponen interesantes. La mayoría de las organizaciones tienen las mismas métricas de negocio definidas en varios lugares: un cálculo de ingresos en una herramienta de BI, uno ligeramente diferente en otra, una tercera variante en un notebook SQL que alguien escribió el trimestre pasado. Cada definición diverge de forma independiente. Nadie está seguro de cuál es la correcta.

Vistas de Métricas en Unity Catalog resuelven esto proporcionando una capa de BI sin cabeza: una capa semántica única y gobernada donde defines tu modelo de datos y KPIs una vez, independientemente de cualquier herramienta de BI específica. Las defines centralmente en SQL o en la interfaz de usuario de apuntar y hacer clic en Unity Catalog Explorer. Los paneles de IA/BI, Genie, los notebooks SQL y las herramientas de BI de terceros resuelven las métricas a partir de las mismas definiciones. Define una métrica una vez, y cada consumidor, humano o IA, obtiene la misma respuesta.

Las Vistas de Métricas van más allá de las definiciones de métricas centralizadas: los metadatos semánticos son lo que las distingue. Campos como display_name, comment y synonyms dan a los sistemas de IA el contexto que necesitan para interpretar correctamente las preguntas de negocio. Cuando un usuario le pregunta a Genie "¿cuáles fueron nuestros ingresos la semana pasada?", esas anotaciones son cómo Genie mapea el lenguaje natural a la medida y las dimensiones correctas. Sin prompts personalizados, sin glosario separado. Lo mismo se aplica a los agentes de IA construidos sobre Databricks: cualquier agente con acceso a Unity Catalog puede descubrir y consultar métricas gobernadas a través de la capa semántica en lugar de SQL codificado. Cuanto más ricos sean tus metadatos, más precisamente la IA servirá la respuesta correcta.

Aquí tienes un ejemplo usando una tabla del sistema, ya que todos los clientes de Databricks tienen acceso, pero el mismo patrón se aplica a KPIs de negocio como ingresos, volumen de pedidos o retención de clientes. Esta Vista de Métricas calcula métricas de almacén DBSQL:

Los consumidores consultan la Vista de Métricas usando MEASURE() para hacer referencia a las definiciones de métricas gobernadas:

Las métricas se definen una vez en la Vista de Métricas. Cualquier panel, espacio Genie o notebook que consulte metv_dbsql_metrics obtiene el mismo resultado. A continuación se muestra un panel que utiliza la vista de métricas como fuente.

Aquí está Genie usando la misma vista de métricas.

Para equipos con definiciones de métricas dispersas en múltiples herramientas de BI, las Vistas de Métricas proporcionan una forma de consolidar la capa semántica en Databricks. En lugar de mantener lógica de métricas separada en cada herramienta, la defines una vez en Unity Catalog y conectas tus herramientas de BI a esa fuente gobernada.

La implementación principal es de código abierto en Apache Spark™ (SPARK-54119), con soporte OSS de Unity Catalog próximamente, por lo que estás construyendo sobre un estándar abierto sin dependencia del proveedor. Esa apertura es más importante a medida que la IA asume más carga de trabajo de BI. Los agentes que consultan tus datos necesitan una definición consistente y legible por máquina de lo que significa cada métrica, y un estándar abierto permite que cualquier herramienta o agente, no solo los específicos del proveedor, razone sobre las mismas métricas gobernadas.

Materialización de Vistas de Métricas: Rendimiento OLAP sin la Sobrecarga

Tradicionalmente, cuando los dashboards de BI eran demasiado lentos, la respuesta era construir tablas de agregados. Creabas vistas materializadas o tablas de pre-agregación personalizadas sobre tu esquema de estrella, configurabas pipelines de actualización y re-apuntabas tus herramientas de BI a las nuevas tablas. Funcionaba, pero añadía toda una capa de objetos y pipelines para mantener, y cada vez que la lógica de agregación cambiaba, tenías que actualizar las consultas de las herramientas de BI para que coincidieran.

La materialización de Vistas de Métricas ofrece una alternativa más simple. Cuando habilitas la materialización en una Vista de Métricas, la plataforma mantiene automáticamente los resultados pre-agregados detrás de las mismas definiciones de métricas que tus herramientas de BI ya consultan, sin tablas de agregados separadas que construir ni consultas de herramientas de BI que refactorizar. Esto es lo que sucede internamente:

• Pre-agregación automática: Los resultados de las métricas se pre-calculan y almacenan
• Actualización incremental: Las métricas se mantienen actualizadas sin recomputación completa
• Reescritura inteligente de consultas: El motor dirige las consultas a la mejor materialización disponible
• Enrutamiento transparente: Los usuarios consultan las métricas de la misma manera; el sistema sirve la ruta más rápida

Las consultas de dashboards que anteriormente escaneaban tablas de hechos completas ahora acceden a materializaciones pre-agregadas, con menor latencia y menor costo de cómputo. Los ejemplos de dashboards y Genie anteriores consultaron la misma Vista de Métricas, y ambos tuvieron sus consultas dirigidas transparentemente a una materialización. El plan de consulta a continuación de Genie muestra esto en acción.

Punteros Prácticos de TCO

Consultas más rápidas y menor costo no son objetivos que compiten; cada optimización que reduce los datos escaneados también reduce el cómputo por el que pagas. Y cada optimización en la pila se acumula. El clustering líquido y las mejores estadísticas mejoran el salto de datos y los planes de consulta. Las materializaciones se pueden actualizar incrementalmente, reduciendo el cómputo que los almacenes SQL necesitan para servir dashboards. Aquí hay algunas formas más de reducir costos:

• Ajusta el tamaño de tu almacén SQL. Usa almacenes SQL sin servidor con escalado automático para ráfagas de concurrencia de BI. Pagas por lo que usas, no por la capacidad máxima.
• Aprovecha los niveles de caché de DBSQL. La caché de disco mantiene los datos "calientes" localmente en el almacén, y la caché de resultados de consultas (QRC) sirve consultas repetidas sin re-ejecución. Para dashboards con patrones de consulta consistentes, la caché convierte muchas solicitudes en respuestas de latencia de milisegundos con un costo de cómputo casi nulo.
• Elimina el movimiento de datos redundante. Sirve BI directamente desde el lakehouse a través de DirectQuery o conexiones en vivo, en lugar de usar extractos o importaciones.
• Monitorea con tablas del sistema. Se pueden usar tablas del sistema como system.billing.usage y system.query.history para rastrear el uso de BI por dashboard, usuario y almacén. Crea Vistas de Métricas y un Dashboard de IA/BI sobre tablas del sistema para obtener visibilidad de tu uso de BI.

Comienza

No necesitas implementar toda la pila a la vez. Empieza donde verás el mayor impacto:

1. Construye (o valida) tu esquema de estrella de capa Gold con tablas administradas, claves primarias/externas y clustering líquido
2. Habilita la Optimización Predictiva en tu catálogo para administrar automáticamente OPTIMIZE, VACUUM y la recolección de estadísticas
3. Define Vistas de Métricas para tus KPIs de negocio principales; empieza con SQL o la interfaz de usuario de UC Explorer
4. Habilita la materialización de Vistas de Métricas para tus métricas de mayor tráfico
5. Monitorea los resultados; apunta dashboards a Vistas de Métricas y rastrea el rendimiento de las consultas a través de tablas del sistema

Databricks proporciona optimizaciones en cada capa de la pila de servicio de BI. Las tablas administradas, el clustering líquido y la Optimización Predictiva minimizan los datos escaneados y el cómputo gastado. Las Vistas de Métricas centralizan tu lógica de negocio en una capa semántica gobernada que sirve dashboards, Genie y agentes de IA de manera consistente. La materialización ofrece un rendimiento de consulta sub-segundo sin pipelines de pre-agregación manuales. Juntas, estas capas se acumulan, reduciendo tanto la latencia de consulta como el costo total de propiedad.

Empieza definiendo tu primera Vista de Métricas sobre una tabla de capa Gold existente y habilitando la materialización. Consulta los recursos a continuación para empezar.

• Descripción general de Vistas de Métricas de Unity Catalog
• Presentación de Vistas de Métricas en IA/BI
• Consulta de Vistas de Métricas desde un Editor SQL
• Implementación de un Data Warehouse Dimensional en Databricks SQL

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