Optimizar y monitorear tu capacidad de Microsoft Fabric (Parte 4)

En resumen

Antes de aumentar el SKU conviene revisar si la capacidad usa bien los recursos que ya paga. Los SKU de Fabric duplican en cada salto, así que escalar suele dejar capacidad ociosa: si la F4 no alcanza, el siguiente paso es una F8 que quizá uses al 60%. Microsoft plantea tres estrategias —optimizar, escalar verticalmente o distribuir la carga— y la única recomendación explícita es optimizar primero, con la evidencia de la Capacity Metrics App.

• Optimizar antes que escalar: el orden entre escalar y distribuir depende del caso; optimizar primero, no.
• Las ventanas de throttling son tres: interactive delay a 10 minutos, interactive rejection a 60 y background rejection a 24 horas.
• Superar el 100% en Utilization no es throttling: eso se comprueba en Throttling y System events, no en el gráfico de utilización.
• Compute guarda 14 días de detalle y Storage 30; los datos de uso aparecen con 10-15 minutos de retraso.
• Una operación fallida también consume CU: los procesos que fallan y se relanzan en bucle son una fuga sostenida de capacidad.

Si llegaste hasta aquí, ya conoces cómo funciona una capacidad de Fabric, cómo se distribuye su consumo mediante bursting y smoothing y cómo se traduce ese consumo en costo.

En esta parte llevaremos esos conceptos a la práctica. Veremos cómo identificar qué operaciones están consumiendo más recursos, cómo optimizar cada workload y cómo decidir, con evidencia, si realmente necesitas aumentar la capacidad o distribuir las cargas de otra manera.

Siempre antes de aumentar el SKU, revisa si la capacidad utiliza los recursos eficientemente, identifica los elementos y operaciones que generan más carga y corrige lo que pueda optimizarse. La Microsoft Fabric Capacity Metrics App será la herramienta central para hacerlo.

El problema de los saltos entre SKU

Como has podido ver hasta ahora, los SKU de Fabric aumentan duplicando la cantidad de CU disponibles: F2, F4, F8, F16, F32, F64 y así sucesivamente. Esto significa que no existen tamaños intermedios entre un SKU y el siguiente.

Si una F4 resulta insuficiente, el siguiente tamaño disponible es una F8, que duplica su capacidad de cómputo. Sin embargo, tu carga podría necesitar solamente una parte de ese incremento. Por ejemplo, podría superar lo que soporta una F4, pero utilizar únicamente el 60 % de una F8.

Cuando la carga queda entre dos SKU, escalar al siguiente tamaño puede dejar una parte de la capacidad disponible sin utilizar, por lo que antes de escalar, conviene determinar si el exceso se debe a un crecimiento real de la demanda o a algunas operaciones ineficientes.

Estrategias ante la saturación de capacidad

Optimizar, escalar verticalmente o distribuir la carga

Cuando una capacidad presenta una utilización elevada, throttling o rechazos, Microsoft plantea tres estrategias principales:

1. Optimizar: revisar el diseño de los elementos y las operaciones para utilizar la menor cantidad posible de recursos de cómputo.
2. Escalar verticalmente (scale up): aumentar temporal o permanentemente el SKU para disponer de más CU. Las capacidades F pueden redimensionarse, pausarse y reanudarse desde Azure.
3. Escalar horizontalmente (scale out): distribuir la carga trasladando workspaces o soluciones a otra capacidad. Esta alternativa permite separar cargas con diferentes niveles de prioridad, administración, configuración o requisitos de servicio.

Estas estrategias no constituyen una secuencia rígida en la que siempre debas escalar verticalmente antes de distribuir la carga. La recomendación que sí es explícita es optimizar primero. Después, la decisión entre aumentar el SKU o utilizar varias capacidades debe basarse en los patrones de consumo, la criticidad de las soluciones, los requisitos de aislamiento y el costo.

Microsoft también ofrece mecanismos complementarios, como las notificaciones de capacidad, los límites específicos de cada workload, el autoscale y surge protection. Estos controles ayudan a reducir el riesgo, pero no sustituyen la optimización ni un dimensionamiento adecuado.

Aislar el problema del vecino ruidoso

Cuando varios equipos comparten una capacidad, una carga intensiva de un workspace puede consumir recursos compartidos y afectar al resto de las soluciones. Microsoft denomina a este escenario el problema del noisy neighbor o vecino ruidoso.

Cuando tenemos este escenario lo recomendable es distribuir los workspaces entre capacidades diferentes. Así puedes separar soluciones críticas, desarrollo y autoservicio, además de aplicar administradores y configuraciones distintas. También puedes establecer límites específicos, como memoria por consulta, query timeout, cantidad de filas devueltas y configuraciones de Spark.

Separar el procesamiento de Power BI de la capacidad Fabric

Las operaciones interactivas de Fabric se suavizan durante un periodo de entre 5 y 64 minutos, mientras que las operaciones clasificadas como background se distribuyen durante 24 horas. Por eso, en capacidades pequeñas puede ser conveniente separar el procesamiento interactivo de Power BI de los workloads de ingeniería:

• La transformación y el almacenamiento —dataflows, pipelines, notebooks, warehouse, lakehouse— dejarlos dentro de la capacidad Fabric.
• Publicar los modelos semánticos (modo import) y los informes en workspaces Pro o PPU. Así su consumo interactivo no impacta tus CU, y el modelo puede leer perfectamente los datos de tu warehouse o lakehouse de Fabric.

Esta separación traslada fuera de la capacidad F las consultas DAX y el procesamiento del modelo Import. Sin embargo, no elimina completamente el consumo sobre Fabric, ya que durante el refresh las consultas que leen el Warehouse o Lakehouse siguen utilizando la capacidad que aloja el origen. Y con DirectQuery, cada interacción del informe puede volver a consultar Fabric y consumir CU.

Microsoft contempla oficialmente el traslado de workspaces de Power BI a capacidad compartida como una alternativa de scale out, siempre que los consumidores dispongan de las licencias necesarias.

Otros aspectos a tener en cuenta para que la estrategia funcione adecuadamente:

1. Mueve el modelo semántico, no solo el informe. El consumo interactivo (consultas DAX, interacción con los reportes) se procesa donde está alojado el modelo. Mover solo un informe conectado al mismo modelo de Fabric no traslada ese consumo.
2. PPU no provisiona capacidad Fabric. PPU ofrece características y límites Premium, pero se sigue necesitando la capacidad F para ejecutar los workloads de Fabric.
3. Esta estrategia no admite Direct Lake. Los modelos Direct Lake deben permanecer en una capacidad Fabric. La elección depende de los requisitos:
   • Import en Pro puede ser adecuado para modelos moderados, latencia controlada, con alta concurrencia de usuarios y presupuesto reducido.
   • PPU, cuando se necesitan características Premium por usuario.
   • Direct Lake, cuando se necesita consumir grandes tablas Delta desde OneLake con baja latencia manteniendo disponible la capacidad Fabric.

Optimización por workload

Cada motor de Fabric tiene estrategias de optimización diferentes.

Data Warehouse

• Escribe T-SQL eficiente: limita columnas, cálculos, agregaciones y operaciones innecesarias.
• Usa los tipos de datos más pequeños posibles. Reducir un VARCHAR(500) a VARCHAR(25), o un DECIMAL(32,8) a DECIMAL(10,2), puede reducir significativamente los recursos asignados a una consulta.
• Usa un esquema en estrella para leer menos filas y minimizar joins innecesarios.
• Mantén las estadísticas al día. Se crean solas en runtime, pero después de cargas grandes conviene actualizarlas manualmente (considera FULLSCAN en vez del muestreo automático).
• Combina Capacity Metrics y Query Insights. queryinsights.exec_requests_history conserva 30 días de consultas completadas y expone, entre otros campos, el texto, distributed_statement_id, CPU asignada y tiempos de inicio y fin. El Fabric Toolbox incluye consultas útiles para las vistas de diagnóstico.

Spark (Data Engineering y Data Science)

• Detén las sesiones Spark cuando ya no se utilicen. Una sesión activa puede seguir acumulando CU aunque no esté ejecutando nada, y el timeout por defecto es de 20 minutos, el cual puede ajustarse.

  

• Comparte sesiones con High Concurrency. Cuando varios notebooks del mismo usuario emplean el mismo Lakehouse y configuración, pueden compartir una aplicación Spark en lugar de iniciar una sesión para cada uno. Esto reduce los tiempos de arranque y aprovecha mejor el cómputo, especialmente en desarrollo y pipelines paralelos.

  

• Dimensiona los recursos Spark según la carga real. En el detalle de la aplicación, la pestaña Resources muestra casi en tiempo real los núcleos Running, Idled, Allocated y Maximum instances. Compara especialmente los núcleos asignados con los realmente utilizados:

  • Una diferencia sostenida indica recursos ociosos y justifica revisar el tamaño del pool, el autoscale y la asignación dinámica de ejecutores.
  • Si la ejecución alcanza repetidamente el máximo, puede existir falta de paralelismo disponible.

  

• Ajusta la configuración de los pools al nivel de concurrencia requerido. Fabric admite ejecuciones paralelas y job-level bursting. Este último permite que un trabajo use temporalmente recursos de burst cuando están disponibles, pero un solo trabajo puede consumirlos si el pool lo permite, así que ajusta el tamaño y el máximo de nodos para equilibrar la duración de cada trabajo con la concurrencia del resto.

• Entiende la cola de Spark. Los notebooks disparados desde pipelines o el programador y los Spark Job Definitions elegibles entran en una cola FIFO cuando se alcanza el límite de cómputo. Los notebooks interactivos y los enviados mediante la API pública no se encolan. Las entradas expiran a las 24 horas y, si la capacidad ya está en throttling, los trabajos nuevos se rechazan.
• Optimiza el código Spark:
  • Procesa solo lo necesario: filtra los datos cuanto antes y conserva únicamente las columnas que vas a utilizar. Así Spark mueve y procesa menos información.
  • Distribuye bien el trabajo: si unas tareas tardan mucho más que otras, los datos podrían estar repartidos de forma desigual. Usa repartition para equilibrarlos y coalesce cuando solo necesites reducir la cantidad de particiones.
• Mantén eficientes las tablas Delta:
  • Evita demasiados archivos pequeños: activa Auto Compaction cuando realizas muchas escrituras pequeñas. Si esos archivos ya se acumularon, utiliza OPTIMIZE para unirlos en archivos más grandes y eficientes.
  • Usa V-Order cuando predominan las lecturas: puede acelerar las consultas y mejorar la compresión, aunque las escrituras podrían tardar un poco más.
  • Limpia archivos obsoletos con cuidado: VACUUM elimina archivos que la tabla Delta ya no referencia. Conserva normalmente una retención mínima de siete días para no afectar el historial ni a lectores o escritores concurrentes.

Data Factory (dataflows y pipelines)

• Mantén el query folding siempre que sea posible. De esta forma, las transformaciones se delegan al sistema de origen, lo que reduce tanto el volumen de datos transferidos como el procesamiento dentro de Fabric. Cuando una operación interrumpe el plegado, Power Query debe procesar en su propio motor los datos que no hayan podido filtrarse o transformarse en el origen, lo que puede aumentar significativamente la duración y el consumo de CU.

• Usa Fast Copy para mover grandes volúmenes de datos. Fast Copy es una función de Dataflow Gen2 que utiliza la infraestructura de alto rendimiento de Copy Activity para acelerar la ingesta desde conectores compatibles, sin necesidad de agregar una actividad Copy independiente al pipeline.

  

• Desactiva el staging cuando no aporte beneficios. En transformaciones simples o consultas que se pliegan completamente al origen, el staging puede introducir escrituras, lecturas, almacenamiento temporal y consumo de capacidad innecesarios. Resérvalo para transformaciones complejas o no plegables, especialmente cuando permita dividir el procesamiento en etapas y hacer que las consultas posteriores vuelvan a plegarse mediante el cómputo del Lakehouse o Warehouse de staging.
• Evita merges, sorts y transformaciones costosas que no sean necesarias. Cuando sea posible, filtra los registros lo antes posible, conserva únicamente las columnas requeridas y evita pasos intermedios que no aporten valor al resultado final.
• Alinea la frecuencia de actualización con la disponibilidad de los datos. Si el sistema de origen se actualiza una vez cada 24 horas, ejecutar el proceso cada hora no aporta ningún valor y aumenta innecesariamente el consumo de recursos.
• Usa actualización incremental en tablas grandes. Procesa únicamente los periodos nuevos o modificados para reducir duración y consumo. Siempre que sea posible, procura que los filtros incrementales se plieguen al origen y verifica que el destino, el conector y la columna de fecha sean compatibles con esta modalidad.

Power BI

El modelo semántico

• Diseña el modelo siguiendo un esquema en estrella. Separa claramente las tablas de hechos y dimensiones, utiliza relaciones de uno a varios y procura que los filtros se propaguen desde las dimensiones hacia las tablas de hechos. Este diseño simplifica el modelo, evita ambigüedades y suele ofrecer un mejor rendimiento.
• Evita las relaciones many-to-many. En la mayoría de los casos, es preferible crear dimensiones conformadas o una tabla puente con valores únicos y establecer relaciones de uno a varios. Las relaciones de varios a varios son válidas en determinados escenarios, pero deben utilizarse de manera consciente.
• Evita las relaciones bidireccionales. Estas relaciones permiten que los filtros se propaguen en ambos sentidos, pero requieren más procesamiento, pueden crear rutas de filtrado ambiguas y dificultan la comprensión del modelo. Utilízalas únicamente cuando exista una necesidad funcional clara.

Los informes

• Cuida la calidad del código de tus medidas DAX. Ten especial cuidado con las funciones iterativas como SUMX, COUNTX y AVERAGEX, ya que pueden resultar muy costosas cuando recorren tablas grandes, evalúan expresiones complejas por cada fila o provocan transiciones de contexto innecesarias. Para profundizar en este tema puedes consultar mi artículo sobre optimización de medidas DAX.
• Limita la cantidad de visuales por página. Cada visual que se carga o se actualiza suele enviar una consulta independiente al modelo. Por tanto, una página con 20 visuales normalmente genera más carga inicial que una con 10. Dividir el contenido entre varias páginas, utilizar drillthrough, marcadores o páginas de detalle para reducir la carga inicial y mejorar la experiencia.
• Controla la cardinalidad de los visuales. Las tablas, matrices y gráficos con demasiadas filas, categorías, series o medidas tardan más en consultar y representar los resultados. Aplica filtros, Top N o niveles de agregación adecuados y muestra únicamente el detalle necesario para responder a la pregunta de negocio.
• Limita la cantidad de slicers. Un segmentador también es un visual y puede ejecutar consultas, además de provocar la actualización de otros visuales cuando cambia una selección. Evita segmentadores redundantes, campos con millones de valores únicos y cadenas de segmentadores que se filtren entre sí sin aportar una mejora clara a la experiencia.
• Desactiva las interacciones que no sean necesarias. Power BI crea interacciones entre los visuales de una página. Cada selección puede actualizar varios visuales y desencadenar nuevas consultas. Revisa estas interacciones y conserva únicamente aquellas que tengan una función analítica concreta.
• Utiliza Performance Analyzer. Esta herramienta permite identificar cuánto tarda cada visual, cuánto tiempo corresponde a la consulta DAX y cuánto al procesamiento o representación del visual. Úsala para localizar los elementos más costosos antes de optimizar el informe.

Encontrarás más recomendaciones en mi artículo sobre buenas prácticas de visualización de datos.

Gestiona la concurrencia de acuerdo con el tamaño de la capacidad. Cuando muchos usuarios consultan simultáneamente un mismo modelo semántico, la capacidad puede experimentar aumentos de latencia, sobrecarga y throttling. En modelos con alta concurrencia, considera habilitar query scale-out, que permite que Power BI cree réplicas de solo lectura y distribuya entre ellas las consultas de informes y paneles, mientras reserva la réplica principal para operaciones de escritura y actualización.

Esto puede mejorar el rendimiento y la disponibilidad durante los refrescos, pero no aumenta ni reduce el cómputo total disponible; únicamente permite aprovechar y distribuir mejor los recursos del SKU. Por tanto, no sustituye la optimización de medidas, modelos y reportes ni la necesidad de ampliar la capacidad cuando el consumo supera de forma sostenida los recursos disponibles.

Hábitos operativos

• Coordina las cargas en el tiempo cuando exista contención. El smoothing reduce los picos contables, pero no elimina los límites de concurrencia, memoria ni los recursos físicos necesarios para ejecutar trabajos simultáneos. Cambiar el horario no reduce por sí mismo las CU totales consumidas.
• Evita ciclos innecesarios de pausa y reanudación. Al pausar, Fabric liquida en ese momento el consumo suavizado pendiente y los excedentes. Si utilizas una reserva, la pausa tampoco recupera automáticamente el costo de las unidades reservadas no utilizadas.
• Valida antes de producción. Prueba modelos, consultas y pipelines con volúmenes representativos y revisa su consumo antes de promoverlos.
• Educa a los usuarios y aplica gobierno. Una sola consulta ineficiente puede afectar a todos los elementos de una capacidad compartida.
• Mide antes de decidir. Optimiza con evidencia de Capacity Metrics y de la telemetría específica de cada workload.

Monitoreo con Microsoft Fabric Capacity Metrics App

Una capacidad debe monitorearse con frecuencia. Si está infrautilizada, podría encontrarse sobredimensionada y generar costos innecesarios. Si está saturada, puede requerir optimización, redistribución de cargas o escalado.

La revisión debe realizarse periódicamente y también ante alertas, cambios de carga o degradaciones del servicio.

La herramienta central para esta tarea es Microsoft Fabric Capacity Metrics. Para instalarla, busca Microsoft Fabric Capacity Metrics en Aplicaciones > Obtener aplicaciones. La persona que realiza la instalación debe ser administradora de la capacidad.

Cómo interpretar la aplicación

Paso 1: Empieza por Health para establecer prioridades

La página Health permite comparar las capacidades que administras e identificar cuáles presentan mayor utilización, riesgo de throttling o rechazo de operaciones.

Alterna entre estas vistas:

• Last one hour: para investigar incidentes recientes y obtener una visión cercana al tiempo real.
• Last 24 hours: para analizar el contexto general y detectar patrones más amplios.

Paso 2: Analiza el % de utilización

Para comenzar abre la página Compute y selecciona la capacidad que deseas investigar. Esta página conserva hasta 14 días de información y permite filtrar por fecha, workspace, tipo de elemento y operación.

En la misma verás 3 secciones:

1. Multi metric ribbon chart: ofrece el contexto temporal y permite comparar CU, duración, cantidad de operaciones y usuarios. Al seleccionar una columna se filtran los demás elementos de la página.
2. Panel principal: permite alternar entre diferentes vistas —Utilization, Throttling, Overages y System events—, cada una de las cuales responde a diferentes preguntas.
3. Matriz de detalle: muestra el consumo desglosado por elemento y operación.

El gráfico de Utilization muestra las operaciones background e interactivas, donde:

• Las columnas azules corresponden a operaciones background.
• Las columnas rojas corresponden a operaciones interactivas.
• Los colores adicionales pueden representar operaciones no facturables, como algunas funciones en preview; úsalas para anticipar cuánto crecerá tu consumo cuando estas pasen a ser facturables.

Una parte del área correspondiente a las operaciones background puede representar consumo pasado que continúa distribuyéndose en puntos temporales posteriores mediante smoothing. Por lo tanto, no todo lo representado en un momento determinado corresponde necesariamente a trabajo que continúa ejecutándose en ese instante.

Paso 3: Analiza el riesgo de throttling

Para evaluar el riesgo de throttling, utiliza los gráficos de Throttling y contrasta sus resultados con la tabla System events.

La carga de una capacidad tiene dos dimensiones:

1. El porcentaje consumido en cada timepoint.
2. La cantidad de capacidad futura que ya se encuentra comprometida.

El gráfico Utilization representa principalmente la primera dimensión. El throttling, en cambio, depende del consumo suavizado y de la capacidad futura comprometida.

Por esta razón, pueden existir picos superiores al 100 % sin que se produzcan restricciones inmediatas: es el mecanismo de bursting en funcionamiento. El riesgo debe evaluarse en los gráficos de Throttling, que reflejan el avance hacia los distintos niveles de restricción.

Dentro de esta vista puedes alternar entre:

• Interactive delay: se evalúa sobre una ventana de 10 minutos.
• Interactive rejection: se evalúa sobre una ventana de 60 minutos.
• Background rejection: se evalúa sobre una ventana de 24 horas.

Paso 4: Identifica las operaciones más costosas

Selecciona un timepoint y utiliza el botón Explore para acceder al detalle.

Ordena por consumo: utiliza Total CU(s) para localizar las operaciones más costosas y Timepoint CU(s) para conocer la contribución de cada operación al momento seleccionado.

Agrega columnas de diagnóstico, cuando estén disponibles:

• Operation ID
• Timepoint CU(s)
• Smoothing start
• Smoothing end
• Estado
• Usuario

Las columnas Smoothing start y Smoothing end permiten identificar el intervalo durante el cual se distribuye el consumo de una operación.

Paso 5: Interpreta la deuda pendiente

La vista Overages permite analizar qué sucede cuando el consumo suavizado supera las CU disponibles en uno o varios timepoints.

Fabric calcula el overage después de aplicar smoothing. Un pico por encima del 100 % no produce throttling de manera inmediata: la capacidad dispone de una protección que le permite consumir hasta 10 minutos de capacidad futura. Cuando el consumo comprometido supera esa ventana, el excedente pasa a registrarse como carryforward.

El carryforward se traslada a los timepoints posteriores. Cuando alguno de esos puntos no utiliza todas sus CU disponibles, la capacidad libre se emplea para reducir la deuda acumulada. A esta reducción se la denomina burndown.

En el gráfico Overage (Carryforward):

• Add % representa el carryforward agregado durante el timepoint.
• Burndown % representa la parte de la deuda que se redujo utilizando capacidad disponible.
• Cumulative % representa el saldo acumulado de carryforward.

Selecciona un punto del gráfico y utiliza Explore para acceder al detalle. Allí podrás identificar qué elementos y operaciones agregaron consumo y cuáles coincidieron con periodos de burndown.

El indicador Minutes to burndown estima cuánto tardaría la capacidad en eliminar la deuda pendiente si no se ejecutaran nuevas operaciones. Es una proyección, no un tiempo garantizado: cualquier consumo nuevo puede prolongar la recuperación.

Si el carryforward se mantiene elevado de forma frecuente, investiga las operaciones responsables y considera optimizarlas, redistribuir las cargas o aumentar temporal o permanentemente el SKU. Pausar y reanudar una capacidad F elimina el consumo futuro acumulado, pero genera un evento de facturación y puede dejar el contenido temporalmente inaccesible.

Configura alertas de capacidad

Configura las alertas por correo electrónico desde la administración de la capacidad. Como punto de partida, puedes establecer una alerta al 75 % para reaccionar con margen y otra al 100 % para señalar una situación crítica.

Incluye destinatarios adicionales a los administradores de la capacidad, de modo que la alerta pueda ser atendida aunque estos no se encuentren disponibles. Ajusta los umbrales según el patrón de consumo, la criticidad y el margen operativo de cada entorno.

Limitaciones y siguiente nivel de detalle

• Compute conserva una ventana de 14 días, mientras que Storage muestra 30 días.
• La exportación puede aplicar muestreo.
• La app no muestra todas las restricciones específicas de cada elemento, como todos los límites de memoria de modelos semánticos.
• Cuando la capacidad no cambia de estado durante el periodo, puede no aparecer en System events.
• Los umbrales mostrados en Throttling no reflejan los umbrales personalizados de surge protection; consúltalos en el portal de administración.
• El modelo semántico interno de la app solo está soportado para los informes incluidos. Microsoft no admite consultarlo, reutilizarlo o modificarlo directamente.

Monitoreo por capas

Un diagnóstico eficaz funciona en tres niveles:

1. Capacity Metrics para identificar la capacidad, el workspace, el elemento y la operación costosa.
2. Telemetría específica del motor: utiliza Query Insights, Monitoring Hub o Workspace Monitoring para encontrar la consulta, actividad o trabajo responsable.
3. Una nueva medición después del cambio para comprobar que la optimización redujo consumo sin degradar el servicio.

Conclusión

Una gestión eficaz combina monitoreo periódico, alertas, optimización de cargas y un dimensionamiento acorde con el comportamiento real del entorno. Cuando estos elementos se aplican en conjunto, Capacity Metrics deja de ser solamente un panel de observación y se convierte en una herramienta para tomar decisiones operativas y financieras fundamentadas.

Recursos

• Evaluate and optimize your Fabric capacity (la guía oficial de Microsoft sobre el tema)
• Capacity Metrics App
• Query Insights en Data Warehouse
• Facturación de Spark en Fabric
• Fabric Toolbox
• Best Practice Analyzer (Tabular Editor)

Preguntas frecuentes

¿Conviene subir el SKU cuando la capacidad se satura?

No como primera medida. Los SKU de Fabric duplican en cada salto, así que pasar de F4 a F8 puede dejar buena parte de la capacidad pagada sin usar. Microsoft recomienda optimizar primero y recién después decidir entre escalar verticalmente o repartir las cargas en varias capacidades.

¿Superar el 100% de utilización significa que hay throttling?

No. El gráfico de Utilization muestra el consumo frente a la potencia base, y los picos por encima del 100% pueden ser bursting funcionando con normalidad. El throttling se comprueba en las vistas de Throttling y en la tabla System events.

¿Qué son el carryforward y el burndown en Fabric?

El carryforward es el consumo ya realizado que la capacidad todavía debe absorber cuando el excedente supera los 10 minutos de capacidad futura que puede adelantar. El burndown es el proceso por el cual los timepoints con CU libres van pagando esa deuda acumulada.

¿Cuánta historia guarda la Capacity Metrics App?

La página Compute conserva 14 días de detalle y la página Storage muestra 30 días. Además, los datos de uso suelen aparecer con 10 a 15 minutos de retraso, así que no sirve para observación en tiempo real; para eso están los eventos de capacidad y Real-Time Hub.

¿Una operación que falla consume CU igual?

Sí. Las ejecuciones fallidas también consumen capacidad y contribuyen a la sobrecarga. Los procesos que fallan y se relanzan automáticamente en bucle son una de las fugas de capacidad más frecuentes y menos visibles.

¿Sirve mover los modelos de Power BI a workspaces Pro para ahorrar CU?

Puede servir en capacidades pequeñas, porque el consumo interactivo se procesa donde vive el modelo semántico. Hay que mover el modelo y no solo el informe, tener en cuenta que PPU no provisiona capacidad Fabric y saber que la estrategia no es compatible con Direct Lake.