Fabric Capacity Metrics: Dominando el consumo de CUs y evitando el estrangulamiento
En el antiguo modelo de Power BI Premium por capacidad (P-SKUs), la gestión de recursos era relativamente predecible. Teníamos núcleos virtuales dedicados y sabíamos que, si los saturábamos, el rendimiento caía. Con la llegada de Microsoft Fabric: La convergencia analítica SaaS y el fin de la integración manual, las reglas del juego han cambiado radicalmente. Ahora trabajamos con Capacidades (F-SKUs) y Unidades de Capacidad (CUs), un concepto de cómputo elástico que permite que una operación consuma más recursos de los asignados teóricamente mediante un sistema de suavizado o smoothing.
Como consultores, ya no basta con que un informe sea visualmente atractivo o que el DAX sea correcto. Si una sola consulta en el Lakehouse o un proceso de staging mal diseñado consume el presupuesto de CUs de toda la empresa, el resto de usuarios sufrirá las consecuencias. La herramienta fundamental para evitar este escenario es la Fabric Capacity Metrics App. En este artículo vamos a desglosar cómo auditar esta aplicación para encontrar no solo qué consume más, sino por qué lo hace y cómo solucionarlo antes de que Microsoft aplique el temido estrangulamiento o throttling.
Antes de entrar en detalle, es vital entender que el objetivo de la monitorización no es solo reducir costes. Es garantizar la estabilidad del servicio. En sectores como el retail o la industria, donde los cierres de mes exigen una disponibilidad total de los datos, un pico inesperado de consumo en una capacidad F2 o F4 puede bloquear el acceso a los informes de ventas justo cuando más se necesitan. En el blog ya hemos tratado la Estimación de costes en Fabric: Pago por uso vs Capacidades reservadas, pero hoy nos centraremos en la parte operativa: qué está pasando exactamente dentro de vuestro motor de cómputo.
Conceptos clave: Smoothing, Carryover y Throttling
Microsoft Fabric introduce una abstracción de recursos que puede ser confusa al principio. A diferencia de una base de datos SQL tradicional donde el consumo es instantáneo, en Fabric las operaciones se dividen en dos categorías principales:
- Operaciones Interactivas: Consultas DAX desde informes, exploraciones en el Lakehouse o ejecución de celdas en Notebooks. Se promedian en intervalos de 5 a 10 minutos.
- Operaciones de Segundo Plano (Background): Refrescos de modelos semánticos, ejecución de Pipelines o Dataflows. Se promedian en ventanas de 24 horas.
El Smoothing es la capacidad de la plataforma para distribuir un pico masivo de consumo a lo largo del tiempo. Si un proceso consume 100 CUs en 1 minuto, Fabric no te cobrará 100 CUs en ese minuto, sino que repartirá ese esfuerzo. El problema surge con el Carryover: si vuestro consumo promedio acumulado supera el 100% de la capacidad contratada, Fabric empieza a «deber» cómputo al sistema. Cuando esa deuda es excesiva, se activa el Throttling, que puede ralentizar vuestras consultas o, en el peor de los casos, rechazarlas por completo.
Identificación de artefactos con alto consumo
Una vez instalada la app desde la AppSource y configurada con el ID de vuestra capacidad, la primera parada obligatoria es la pestaña de Compute. Aquí no buscamos promedios, buscamos culpables. La aplicación permite filtrar por Workspace, por tipo de ítem y por operación específica.
Análisis del gráfico de Timepoint
En la parte superior de la aplicación encontraréis un gráfico de líneas que muestra el consumo de CUs frente al límite de la capacidad. Lo que debéis buscar son las líneas que superan el 100%. Al hacer clic en un punto específico (un timepoint), la tabla inferior se actualiza para mostrar exactamente qué ocurrió en ese intervalo de 30 segundos.
Para un análisis profundo, seguid estos pasos:
- Identificad el pico de consumo en el gráfico principal.
- Seleccionad el punto exacto para cargar el detalle.
- En la tabla inferior, cambiad a la vista de «Background Operations».
- Ordenad por la columna «CU (s)» de mayor a menor.
Es común encontrar que un solo refresco de un modelo semántico antiguo, con un Plegado de consultas en Power Query deficiente, está absorbiendo el 40% de la capacidad diaria de una F8. Este es el momento de decidir si el problema es el volumen de datos o una ineficiencia técnica.
Comparativa de tipos de consumo
Es fundamental diferenciar entre el coste de almacenamiento (OneLake) y el de cómputo. La tabla siguiente resume cómo impactan las diferentes tareas en vuestra cuota de CUs:
| Tipo de Operación | Categoría | Ventana de Suavizado | Impacto en el Usuario |
|---|---|---|---|
| Consulta DAX (Informe) | Interactiva | 10 Minutos | Alta latencia si hay estrangulamiento. |
| Refresco de Power BI | Background | 24 Horas | Fallo del refresco o retraso acumulado. |
| Notebook (Spark) | Background | 24 Horas | Consumo masivo de CUs en procesos ETL. |
| SQL Endpoint Query | Interactiva | 10 Minutos | Bloqueo de consultas ad-hoc. |
Como se observa, las operaciones de fondo son más «peligrosas» a largo plazo porque su consumo se arrastra durante todo el día. Si lanzáis 10 procesos pesados a las 8 de la mañana, podríais estar pagando ese exceso de cómputo hasta las 8 de la mañana del día siguiente.
Diagnóstico de estrangulamiento (Throttling)
El estrangulamiento no ocurre de forma binaria. Microsoft Fabric aplica tres niveles de penalización cuando se abusa de la capacidad:
- Interactive Delay: Las consultas DAX tardan un poco más en responder. Es el primer aviso.
- Interactive Rejection: El sistema rechaza nuevas consultas. El usuario ve un error en su informe de Power BI.
- Background Rejection: Se cancelan los refrescos programados y procesos ETL.
Para diagnosticar esto en la aplicación, debéis dirigiros a la pestaña de Throttling. Si veis barras rojas en el gráfico de «Utilization by Throttling Type», tenéis un problema estructural. No es un pico puntual, es que vuestra capacidad es demasiado pequeña para el volumen de trabajo o vuestros procesos son extremadamente ineficientes.
Un error clásico que he visto en proyectos de retail es programar todos los refrescos de inventario a la misma hora. Esto genera un pico de Background operations que agota el buffer de suavizado y provoca que, cuando los directivos entran a ver las ventas a primera hora, sus consultas interactivas sean rechazadas. Para entender mejor cómo leer estos patrones, recomiendo revisar Fabric Capacity Metrics: Cómo leer los gráficos para encontrar al culpable.
Optimización proactiva: El enfoque del consultor
Si la App de métricas indica que un proceso de Power Query está consumiendo demasiadas CUs, el primer paso no es aumentar la SKU de Fabric. Eso es tirar dinero. El primer paso es auditar el código. Muchas veces, un paso de Table.Distinct() sobre una tabla de 50 millones de filas sin plegado de consulta es el responsable.
Aquí tenéis un ejemplo de cómo monitorizar el rendimiento de una consulta SQL en el Warehouse de Fabric para ver cuánto tiempo de CPU está realmente consumiendo, lo que ayuda a correlacionar con los datos de la App de Métricas:
-- Consultar las ejecuciones más costosas en el Warehouse
SELECT TOP 10
query_hash,
COUNT(*) as NumeroEjecuciones,
AVG(total_elapsed_time_ms) as PromedioMilisegundos,
MAX(max_dop) as GradoParalelismo
FROM sys.dm_pbi_log_entries -- Vista orientada a telemetría de Fabric
WHERE operation_type = 'QueryExecution'
GROUP BY query_hash
ORDER BY AVG(total_elapsed_time_ms) DESC;
En el lado de DAX, si detectáis que un informe específico está penalizando la capacidad, usad el Performance Analyzer de Power BI Desktop y copiad la consulta al DAX Studio para analizar los Server Timings. Si el Formula Engine (FE) está trabajando demasiado, probablemente tengáis una medida con iteradores complejos (SUMX, FILTER) que podría optimizarse.
/* Ejemplo de medida ineficiente que dispara el consumo de CUs */
ImporteVentasSemanales =
VAR FechaActual = MAX('Calendario'[Fecha])
RETURN
SUMX(
FILTER(
ALL('Ventas'),
'Ventas'[Fecha] > FechaActual - 7 && 'Ventas'[Fecha] <= FechaActual
),
'Ventas'[Unidades] * 'Ventas'[PrecioUnitario]
)
/* Alternativa optimizada para reducir el esfuerzo del motor de cómputo */
ImporteVentasSemanales_Opt =
CALCULATE(
[Importe Total],
DATESINPERIOD('Calendario'[Fecha], MAX('Calendario'[Fecha]), -7, DAY)
)
La segunda versión utiliza funciones de inteligencia de tiempo nativas que el motor de VertiPaq puede resolver de forma mucho más eficiente, consumiendo menos CUs en cada interacción del usuario.
Errores frecuentes en la gestión de capacidades
- Ignorar el almacenamiento: Aunque la App se centra en cómputo, el almacenamiento en OneLake también tiene un coste. Revisad la pestaña de Storage para evitar sustos en la factura mensual.
- No usar alertas: Fabric permite configurar alertas de Azure Monitor basadas en el consumo de la capacidad. No esperéis a abrir la App de métricas para saber que estáis al 95%.
- Subestimar el impacto de los Notebooks: Un Notebook de Spark mal configurado (con demasiados ejecutores o instancias muy grandes) puede consumir vuestra cuota diaria de CUs en minutos.
- Confundir tiempo de ejecución con consumo de CU: Una consulta puede tardar mucho porque está bloqueada, pero no consumir CUs. La App distingue entre duración y esfuerzo de cómputo.
Para aquellos que están trabajando en escenarios avanzados, recordad que la calidad de los datos influye directamente en el coste. Un modelo bien gobernado consume menos. Podéis profundizar en esto en Gobierno de datos para IA generativa en Microsoft Fabric: Calidad y Trazabilidad.
Checklist de revisión semanal de capacidad
- [ ] Revisar el gráfico de Utilization frente al límite de la capacidad en la App oficial.
- [ ] Identificar los 3 artefactos (Reports, Notebooks o Dataflows) que más CUs han consumido en los últimos 7 días.
- [ ] Comprobar si ha habido eventos de Throttling (especialmente Rejecting) en horas críticas.
- [ ] Validar que no hay procesos de «Background» que se solapen innecesariamente.
- [ ] Comparar el consumo actual con la estimación presupuestaria inicial.
Preguntas frecuentes
¿Por qué la App muestra datos con retraso?
La telemetría de Fabric no es en tiempo real. Los datos suelen tener un retraso de entre 15 y 30 minutos debido al proceso de agregación de métricas que realiza el motor de Microsoft. Para monitorizaciones críticas, se recomienda usar Azure Monitor de forma complementaria.
¿Qué pasa si mi capacidad llega al 100% de forma constante?
Si el consumo es sostenido y no puntual, entraréis en un estado de deuda técnica de cómputo permanente. En este caso, el suavizado ya no os protegerá y debéis escalar la SKU (por ejemplo, de F4 a F8) o reducir drásticamente la carga de trabajo optimizando procesos.
¿Las operaciones de Copilot consumen CUs de mi capacidad?
Sí, el uso de capacidades de IA generativa dentro de Fabric consume CUs. Es fundamental monitorizar estos ítems por separado en la App para entender si el uso de IA está desplazando recursos necesarios para el reporting estándar.
¿Puedo ver qué usuario concreto ha disparado un pico de consumo?
Sí, en el detalle del timepoint, la aplicación desglosa las operaciones y, en muchos casos, identifica el usuario o la identidad de servicio que ha lanzado la consulta o el proceso que ha provocado el gasto.
