Cómo un modelo semántico sobreutilizado casi colapsó nuestra capacidad de BI... y lo que aprendimos. The Monday Morning Spike El lunes por la mañana Spike Más de 300 tiendas en los Estados Unidos se preparaban para la semana que viene, imprimiendo sus informes diarios de ventas y inventario de Power BI. Volviendo a la sede, el día comenzó como cualquier otro - silencio de monitores, primeras gomas de café, carpeta de entrada llena. El primer mensaje llegó después de eso. “Hey, my report’s not loading - can you please check, I need it for a meeting?” Unos minutos más tarde, otro. “Hey, PowerBI is slow - can you please bump up the capacity ?” Y luego tres más. La ventana de Teams mostró un formato de cola de ayuda que se hizo visible en diez minutos. He accedido a la para encontrar un problema menor que esperaba ver. El rango completo del gráfico mostró valores rojos. Fabric capacity Utilization had spiked to 350 %, and I was completely taken aback. Los dashboards se habían vuelto insensibles, mientras que los informes paginados tardaron demasiado en cargarse y la plataforma de BI que soportaba a 300 tiendas experimentó problemas críticos de rendimiento. The day had just started, and we were already in firefighting mode. Tracing the Problem El primer paso fue abrir el Los gráficos de utilización mostraron el mayor uso porque una unidad de computación de espacio de trabajo de repente alcanzó su capacidad máxima. Fabric Capacity Metrics dashboard Buscando profundidad, encontramos one dataset consuming over 10× more compute than every other model combined. que nos permitió generar varios informes de página y periódicos que presentaban toda la información detallada sobre el rendimiento de la categoría de la tienda. Construido por nosotros, que es el Centro de Excelencia de BI para informes empresariales. Sin embargo, debido a que nuestra organización sigue un modelo de análisis de auto-servicio, cualquiera puede construir y compartir informes utilizando este conjunto de datos. This was a critical dataset 20 million-row semantic model The operations followed their typical pattern until that specific week. So what changed? Comenzamos a rastrear los registros de actividad junto con las ventanas de tiempo y las conexiones de informe.El sistema reveló un patrón que mostró que 300 usuarios distintos accedieron al mismo modelo a través de informes de página de la tienda alrededor de la misma ventana de tiempo. Para confirmar, hemos deshabilitado esos informes por un solo día. El sistema ha operado at its peak capacity since the beginning of its operation. We had our culprit. The Discovery: XMLA Read Operations El descubrimiento: las operaciones de lectura de XMLA Cuando examinamos la vista de operaciones detalladas, una métrica dominó: XMLA Read Operations. That was puzzling. The native Power BI feature Paginated Reports operated as external connections. 
 
 
 La propia documentación de Microsoft da la respuesta: El punto final XMLA permite las operaciones de lectura y escritura en los conjuntos de datos Power BI Premium, lo que permite a las herramientas y APIs externas ejecutar consultas y controlar modelos de datos. Microsoft’s own documentation gives the answer: El punto final XMLA permite las operaciones de lectura y escritura en los conjuntos de datos Power BI Premium, lo que permite a las herramientas y APIs externas ejecutar consultas y controlar modelos de datos. El punto final XMLA permite a los informes paginados acceder a los modelos semánticos de la misma manera que El motor del conjunto de datos recibe la ejecución de lotes DAX directa de todas las operaciones de renderización y exportación de páginas. Excel, DAX Studio or any external system 
 
 
 Como señala SQLBI: Los informes paginados generan alta concurrencia de consultas porque cada página renderizada ejecuta su propio lote de consultas de DAX. As SQLBI notes: Los informes paginados generan alta concurrencia de consultas porque cada página renderizada ejecuta su propio lote de consultas de DAX. Todos los informes de impresión de los usuarios de la tienda estaban creando varias sesiones de XMLA, cada una de las cuales era una lectura pesada y completa. El Se ha convertido en un sistema de computación distribuida. standard Monday printing operation Evaluating the Fixes Evaluar los fijos Descubrimos la causa raíz antes de comenzar a probar diferentes soluciones hasta que descubrimos el método eficaz. 
 
 
 
 
 
 
 
 
 
 
 Option 
 Description 
 Outcome 
 
 
 
 
 Keep Live to BigQuery 
 Maintain DirectQuery to BigQuery to avoid imported semantic model. 
 ❌ Too costly; XMLA reads still consume Fabric compute. 
 
 
 
 
 Fabric-Ingested Tables 
 Ingest data into Fabric and use a DirectQuery in the semantic model. 
 ⚠️ Minor improvement but XMLA concurrency remained. 
 
 
 
 
 SQL Endpoint with OLE DB 
 Connect paginated reports directly to SQL endpoint. 
 ⚠️ Technically possible but complex; lost relationships and added IT overhead. 
 
 
 
 
 Lean Semantic Model (Chosen) 
 Create a simplified model with only necessary granularity and metrics. 
 ✅ Massive reduction in compute usage and stable performance. Mantén vivo a BigQuery Mantenga DirectQuery en BigQuery para evitar el modelo semántico importado. Demasiado caro; los lectores de XMLA todavía consumen la computación de Fabric. Tablas fabricadas Ingrese datos en Fabric y use un DirectQuery en el modelo semántico. ⚠️ Mejora menor, pero la competencia de XMLA permaneció. SQL Endpoint con OLE DB Conectar los informes paginados directamente a SQL Endpoint. Técnicamente posible pero complejo; relaciones perdidas y sobrecarga de TI añadida. Modelo Semántico Lean (Elegido) Crear un modelo simplificado con sólo la granularidad y las métricas necesarias. ✅ Reducción masiva en el uso de computación y rendimiento estable. The Fix That Worked La corrección que funcionó El equipo desarrolló un modelo semántico específico para los informes paginados que incluían only required granularity and metrics. Cuando lo desplegamos, el lunes siguiente contó la historia. Peak utilization fell from 350 % to under 80% El sistema produjo informes paginados que funcionaron sin problemas cuando más de 100 usuarios accedieron al sistema. Interactive dashboards remained fast and stable. El panel de herramientas de métricas de Fabric mostró que el cálculo had been declining at a steady rate. El modelo más delgado logró el control a través de su estructura de diseño simple. Why XMLA Read Operations Matter Por qué las operaciones de lectura de XMLA son importantes El incidente reveló que los informes paginados dependen de un mecanismo de caché diferente que los informes interactivos, y XMLA lee el bypass completamente para consultar directamente el motor del conjunto de datos. Cualquier herramienta que utilice XMLA para conectarse a Excel, los informes paginados o los scripts personalizados utilizará unidades de cálculo interactivas (CU) de capacidad para cada consulta. 
 
 
 Como señala la investigación TDWI: La razón principal de los picos de capacidad proviene de los patrones de diseño que no consideran la ejecución simultánea de consultas en lugar de centrarse en el volumen de datos. As TDWI research notes: La razón principal de los picos de capacidad proviene de los patrones de diseño que no consideran la ejecución simultánea de consultas en lugar de centrarse en el volumen de datos. El sistema procesó múltiples solicitudes simultáneamente que resultaron en ningún cambio en nuestro volumen de datos. Para los equipos de BI de la empresa, esto significa que la planificación del rendimiento se refiere tanto al comportamiento de uso como al tamaño del modelo. Para evitar problemas similares: 
 
 
 
 Cargas de trabajo de segmentos: El sistema requiere dos modelos distintos para funcionar para las funciones interactivas y las operaciones paginadas. Monitor de operaciones de XMLA: Fabric le permite identificar problemas de rendimiento cuando aparecen por primera vez a través de sus métricas de nivel de operación. Alinear la escalación de la capacidad: el sistema necesita ejecutar la sincronización de SKU entre la inferior y la superior durante sus períodos de operación pesados designados. What We Learned Lo que aprendimos El rendimiento de los informes paginados se deteriora cuando el sistema opera en condiciones de carga de trabajo pesada. Dashboards aren’t the main compute consumers. XMLA opera todas las sesiones a través de un único nivel de acceso.El proceso de análisis para un analista y 300 tiendas sigue la misma ruta computacional. 
 
 
 
 
 
 
 Simplificación supera la complejidad: Un modelo lean produce resultados superiores a los complejos. La visibilidad evita las crisis: la aplicación Fabric Metrics proporcionó vistas con capacidades de diagnóstico precisas en lugar de obligarles a basar sus decisiones en supuestos inciertos. La gobernanza equivale al rendimiento: la organización necesita crear directrices específicas que especifiquen cuándo los miembros del equipo pueden acceder a modelos compartidos. El auto-servicio requiere supervisión: los equipos ganan poder significativo a través de la autonomía de la creación de informes, pero necesitan sistemas de seguimiento para rastrear sus actividades y reglas de propiedad definidas. La caché no es universal: el comportamiento de caché de los informes interactivos es diferente de los informes paginados, por lo que las organizaciones deben comprender sus mecanismos de manejo de consultas para evitar picos de computación inesperados. La prevención es más barata que la recuperación: cada nueva implementación de conjuntos de datos ahora incluye la segmentación de la carga de trabajo y el monitoreo de XMLA como características estándar. La imagen más grande El problema de fiabilidad afectó a varios modelos porque necesitaba el correcto funcionamiento de los sistemas de diseño arquitectónico y de gobernanza. Las operaciones de Retail BI dependen de un patrón rítmico porque necesita datos en tiempo real para tomar decisiones sobre precios, personalización, cumplimiento y operaciones de ventas. 
 
 
 Como dice el MIT Sloan Management Review: Los líderes de análisis superan a los demás no produciendo más informes, sino gobernando cómo se consumen los datos. As MIT Sloan Management Review writes: Los líderes de análisis superan a los demás no produciendo más informes, sino gobernando cómo se consumen los datos. Nuestros sistemas fueron rediseñados para manejar la carga y la propiedad, lo que nos permitió pasar de la lucha contra incendios de emergencia a la gobernanza programada. porque requiere un apoyo confiable en la toma de decisiones. The main focus of BI goes beyond fast data delivery El pensamiento cerrado La lección de ese lunes se convirtió en una verdad permanente que aprendimos. La causa real de los fallos de la capacidad del sistema proviene de las elecciones de diseño que se hicieron sin un conocimiento adecuado de las operaciones del sistema. Dashboards visualize data. Paginated reports distribute it. But BI engineers govern how it all holds together. El pico de computación recibió una solución, pero nuestro equipo encontró el vínculo crítico entre Fabric, XMLA y los sistemas de gobernanza que apoyan la estabilidad de la analítica empresarial. Next time, when 300 stores print again, we’ll be ready. Sobre el autor Rupesh Ghosh trabaja como Ingeniero de Inteligencia de Negocios en Total Wine & More mientras persigue su Doctorado Ejecutivo en Negocios en la Universidad de Cumberlands. Sus intereses de investigación incluyen gobernanza de datos, inteligencia de decisión, gestión de proyectos y análisis de BI rentable.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Este audio es producido en el idioma original de la historia!

Cuando 300 tiendas se imprimen a la vez: Debugging un pico de computación del 350% en Power BI Fabric

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps