Conceptos clave: Bursting, smoothing y throttling (Parte 2)

En resumen

Cuando una carga supera tu capacidad, Fabric te presta recursos temporalmente para que el trabajo termine más rápido (bursting), luego distribuye el consumo generado en cuotas repartidas en el tiempo (smoothing) y cuando la deuda acumulada supera tu presupuesto futuro, Fabric te frena para proteger la capacidad y evitar el throttling. Entender las tres reglas es lo que te deja dimensionar el SKU para tu consumo promedio, no para tus picos.

• Bursting: Fabric te deja superar tu SKU para terminar rápido: una F2 puede alcanzar puntualmente una escala de cómputo comparable con la línea base de una F64.
• Smoothing: el exceso se paga en cuotas. Background a 24 horas; interactivas a 5–64 minutos.
• Throttling: el freno, por etapas. Primero se retrasan y rechazan las operaciones interactivas (fallan los informes); el background es lo último.
• Fabric evalúa cuánto consumo suavizado está comprometido en los próximos 10 minutos, 60 minutos y 24 horas; el cálculo no se reinicia con el día calendario.

En la Parte 1 vimos que una capacidad de Fabric funciona como un presupuesto de capacidad que se consume segundo a segundo, y que cada operación representa un gasto contra ese presupuesto.

En esta parte veremos qué sucede cuando una carga de trabajo exige más capacidad de la que has contratado. Para entender este comportamiento, primero es necesario conocer tres mecanismos fundamentales con los que Fabric administra el consumo de recursos: bursting, smoothing y throttling. Estos conceptos explican cómo la plataforma permite absorber picos de demanda, distribuir el consumo en el tiempo y, cuando es necesario, limitar la ejecución de nuevas operaciones para proteger la capacidad.

¿Cómo clasifica Fabric las operaciones?

Comencemos entendiendo la forma en que Fabric clasifica las operaciones, porque esa clasificación determina cómo se contabiliza su consumo. Toda operación en Fabric pertenece a uno de dos tipos:

Operaciones interactivas: solicitudes bajo demanda y operaciones que pueden desencadenarse por interacciones del usuario, donde el tiempo de respuesta forma parte de la experiencia. Son difíciles de controlar y, cuando llegan muchas a la vez (por ejemplo, muchos usuarios abriendo un mismo informe al mismo tiempo), pueden saturar la capacidad rápidamente. Las principales:

• Las consultas de los informes de Power BI contra el modelo semántico. Esta es la principal.
• Consultas DAX externas (SSMS, aplicaciones propias), XMLA read, web modeling
• Las consultas en SQL Database in Fabric
• GraphQL y User Data Functions
• El renderizado de informes paginados en el servicio y los visuales de R/Python
• Las únicas excepciones interactivas del Warehouse: las operaciones de modelado (crear una medida, visualizar resultados) y la creación o actualización de modelos semánticos e informes

Operaciones background: operaciones de mayor duración cuyo resultado no se necesita de inmediato, así que lo importante es que se ejecuten correctamente, estas operaciones pueden dispararse de forma manual, programada o vía API. Aquí entra la gran mayoría de las operaciones de Fabric:

• Las ejecuciones y actualizaciones de Dataflows Gen2
• El movimiento de datos y las actividades de los pipelines
• Los notebooks, incluso cuando los ejecutas manualmente desde la interfaz
• Las definiciones de trabajo Spark
• Las operaciones de cómputo de OneLake registradas por Fabric, incluidas las lecturas y escrituras.
• La ingesta por eventstream
• El uptime del Eventhouse, que es como se factura el motor KQL (por tiempo activo, no por consulta)
• Los refresh de modelos semánticos, en todas sus variantes: programados, manuales, por REST API o por XMLA

Adicionalmente, se incluyen las siguientes operaciones que, aunque desde la perspectiva del usuario parecen interactivas, Microsoft Fabric las clasifica como operaciones de background, para que así puedan beneficiarse del mecanismo de suavizado (smoothing), lo que permite administrar de forma más eficiente los picos de consumo de capacidad:

• Las consultas T-SQL en el Warehouse y en el SQL endpoint del Lakehouse. La documentación de Data Warehouse confirma que casi todo Warehouse es background, incluidas las DMVs: “la mayoría de las operaciones de la categoría Warehouse se reportan como background para aprovechar el suavizado de la actividad de 24 horas y permitir los patrones de uso más flexibles”.
• Las operaciones y consultas de Copilot. La documentación de consumo de Copilot indica: “las operaciones de Copilot en Fabric se clasifican como trabajos background, lo que permite que Fabric controle un mayor volumen de Copilot solicitudes durante las horas pico.”

¿Por qué el consumo de Fabric funciona como una compra a cuotas?

Antes de entrar en detalle con los conceptos técnicos, quédate con esta analogía: El consumo en Fabric funciona como una compra a cuotas. Cuando un trabajo necesita más capacidad de la que pagaste, Fabric te la presta para que termine rápido, y luego te la va cobrando en pagos pequeños repartidos en el tiempo. Cada pieza de esa imagen tiene su equivalente técnico en Fabric:

• El préstamo que te deja gastar hoy más de lo que tu presupuesto da, es el bursting.
• Las cuotas con las que devuelves lo gastado son el smoothing. Y como en cualquier financiera, el plazo depende del tipo de compra, en este caso, las operaciones background se pagan a 24 horas y las interactivas a minutos.
• Y throttling vendría a ser el freno, cuando las cuotas comprometidas superan tus ingresos futuros, el banco corta la tarjeta, por etapas.

Con eso en mente observa en el siguiente gráfico la comparativa de cómo se maneja este proceso en una plataforma tradicional vs Fabric:

Como puedes ver, en una plataforma tradicional el cómputo tiene un límite rígido, por lo que cuando dos trabajos que llegan a ese límite necesitan ejecutarse a la vez solo hay dos salidas: o uno espera (o directamente falla) hasta que el otro termine, o corren juntos repartiéndose los recursos y ambos se vuelven lentos.

En Fabric ese techo puede ser temporalmente flexible. En los workloads que admiten bursting, las operaciones pueden utilizar más recursos que la línea base del SKU, siempre dentro de sus guardrails. Después, smoothing distribuye el consumo registrado entre timepoints futuros.

Veamos ahora cómo funciona esto en detalle.

Bursting

El bursting permite que una operación utilice temporalmente más recursos que los proporcionados como base por el SKU.

Su objetivo es evitar que todos los trabajos queden limitados permanentemente a la capacidad base. Cuando el workload lo admite, Fabric puede asignar recursos adicionales para que la operación termine más rápido.

El bursting:

• No modifica el SKU contratado.
• No proporciona recursos ilimitados.
• Está sujeto a límites específicos de cada workload.
• Genera consumo que posteriormente se contabiliza mediante smoothing.

Factores de Bursting

El bursting está integrado en los workloads que lo admiten. Su funcionamiento y sus límites dependen de cada workload:

• Warehouse y SQL endpoint. Maneja los siguientes factores de bursting donde se puede observar que mientras más pequeño es el SKU, mayor es el multiplicador, lo que permite que una F2 por ejemplo alcance puntualmente una escala de cómputo comparable con la línea base de una F64:

Comparativa: SKU, CU base, Factor de burst

SKU	CU base	Factor de burst
F2	2	1× – 32×
F4	4	1× – 16×
F8	8	1× – 12×
F16	16	1× – 12×
F32	32	1× – 12×
F64	64	1× – 12×
F128	128	1× – 12×
F256	256	1× – 12×
F512	512	1× – 12×
F1024	1.024	1× – 12×
F2048	2.048	1× – 12×

Esto no convierte una F2 en una F64: la F2 continúa teniendo únicamente 2 CU por segundo para sostener el consumo a lo largo del tiempo.

Por lo tanto el bursting tiene un tope, si se ejecuta una consulta que necesita más recursos de los que el factor de burst de tu SKU permite, la operación falla con un error de restricción de capacidad. En ese caso te conviene optimizar la consulta primero, o subir de SKU temporalmente.

• Spark: Mide el burst en Spark VCores (1 CU = 2 Spark VCores). La tabla oficial incluye además el límite de cola, es decir, cuántos trabajos background pueden quedar encolados esperando cores:

Comparativa: SKU, Spark VCores base, Máximo con burst, Factor, Límite de cola

SKU	Spark VCores base	Máximo con burst	Factor	Límite de cola
F2	4	20	5×	4
F4	8	24	3×	4
F8	16	48	3×	8
F16	32	96	3×	16
F32	64	192	3×	32
F64	128	384	3×	64
F128	256	768	3×	128
F256	512	1.536	3×	256
F512	1.024	3.072	3×	512
F1024	2.048	6.144	3×	1.024
F2048	4.096	12.288	3×	2.048

Así que por ejemplo una F64 trae 128 Spark VCores de base y con burst llega a 384, que pueden repartirse entre varios trabajos concurrentes o consumirse en un solo trabajo grande, siempre que el pool esté configurado con esos cores.

Para el resto de workloads la documentación no publica los factores de bursting.

Smoothing

El smoothing, o suavizado, es el mecanismo contable mediante el cual Fabric distribuye las CU consumidas por una operación entre timepoints futuros, en lugar de aplicar todo el consumo a un único instante. Es por lo tanto, la contabilidad que hace posible el bursting, es decir, dejarte ejecutar ahora un trabajo que excede tu SKU precisamente porque sabe que te lo irá cobrando poquito a poco después.

Hay un detalle importante, el smoothing no cambia el rendimiento de tus trabajos, estos corren igual de rápido, lo que se reparte es la contabilidad del consumo, lo que te permite dimensionar tu SKU para tu consumo promedio en lugar de para tus picos, siendo una de las grandes ventajas económicas de este modelo.

Ventanas de suavizado

Recuerda que el consumo se contabiliza en bloques de 30 segundos llamados timepoints, y que un día tiene 2.880, bien, la ventana en la que se reparte el consumo depende del tipo de operación:

• Las operaciones background se suavizan a lo largo de 24 horas.
• Las operaciones interactivas se suavizan entre 5 y 64 minutos. Esta ventana es adaptativa en base a cuánto CU consuma la operación, a mayor consumo, la ventana será más larga para así reducir su impacto en cada timepoint.

El siguiente gráfico muestra un ejemplo de cómo se suavizaría una operación background vs una interactiva. La barra roja es el trabajo mientras se ejecuta, la cual gracias al bursting puede superar por mucho el 100% de la capacidad durante un momento. La barra celeste es cómo se reparte ese consumo en la ventana de suavizado correspondiente.

Representación conceptual; las barras no están dibujadas a escala.

Del lado izquierdo puedes ver cómo ese consumo en una operación background se reparte en 24 horas, por lo que la barra celeste queda más aplanada y lejos del 100%. Pero en cambio ese mismo consumo en una operación interactiva se cobraría en pocos minutos, por lo que la barra queda más corta y alta y, dependiendo del consumo, puede acercarse o superar ampliamente el 100%, acercando la capacidad al throttling.

Esta diferencia de ventanas es la que explica la razón de que las operaciones interactivas saturen una capacidad mucho más rápido que las operaciones background.

El background es fácil de medir y planificar (un ETL en producción consume casi lo mismo cada día), mientras que el margen de incertidumbre casi siempre viene del lado interactivo, porque depende de cuántos usuarios entren en simultáneo y de lo que hagan. Por eso cobra tanta importancia trabajar con informes y modelos semánticos optimizados, varios usuarios ejecutando una DAX no optimizada pueden llegar a saturar la capacidad en muy pocos minutos.

Ejemplo de Bursting y Smoothing

Supongamos que tienes una F2, como vimos en el artículo anterior eso equivale a:

Comparativa: Periodo, Capacidad de una F2

Periodo	Capacidad de una F2
1 segundo	2 CU
1 timepoint (30 s)	60 CU
1 hora	7.200 CU
1 día (24 h)	172.800 CU

El día 10 a las 9:00 lanzas un refresh de un dataflow que consume 43.200 CU y, gracias al bursting, termina en una hora.

Fabric no descuenta los 43.200 CU de golpe. Dado que es una operación background, reparte ese consumo entre los 2.880 timepoints de las siguientes 24 horas:

43.200 CU ÷ 2.880 timepoints = 15 CU por timepoint

Así que desde las 10:00 del día 10 hasta las 10:00 del día 11, cada timepoint de tu capacidad carga con esos 15 CU. Como cada timepoint tiene 60 CU, ese refresh ocupa el 25% de tu capacidad durante un día entero, aunque el trabajo terminó hace horas.

Ahora hagamos el mismo ejercicio para el mismo consumo de 43.200 CU pero para una operación interactiva, en ese caso la ventana máxima interactiva es de 64 minutos, es decir 128 timepoints:

43.200 CU ÷ 128 timepoints = 337,5 CU por timepoint

Pero tu F2 solo tiene 60 CU por timepoint, así que las cuotas serían más de 5 veces tu capacidad lo que se traduce en deuda instantánea y throttling casi seguro.

Así que como has podido ver hasta ahora, el costo de un trabajo no termina cuando el trabajo termina, y el tipo de operación define cómo impacta ese consumo.

Throttling

Llegamos a lo que quieres evitar. Si a pesar del smoothing acumulas tanta deuda de cómputo que agotas tu presupuesto futuro, Fabric empieza a frenar los procesos que puedes ejecutar.

Con el paso del día, a nuestras consultas y al batch se les van sumando más trabajos suavizados, que comienzan a apilarse:

Cuando la pila supera el límite, la capacidad no se declara en sobrecarga en ese instante: recorta el exceso y lo reubica en los timepoints futuros que tengan espacio libre.

De esa mecánica sale el vocabulario que vas a ver en la Capacity Metrics App (y que usamos en el ejemplo que viene):

• Overage: el consumo que excede tu SKU en un timepoint, calculado después del smoothing. En el gráfico, todo lo que asoma por encima de la línea de 60 CU.
• Carryforward: ese exceso arrastrado hacia los timepoints futuros: el área rayada del gráfico. Es, literalmente, tu deuda de cómputo.
• Burndown: el proceso por el cual los timepoints con capacidad libre van pagando esa deuda.

Etapas del proceso de throttling

Este proceso de throttling es gradual, avanza por etapas según cuánta capacidad futura llevas comprometida:

Comparativa: Consumo futuro ya comprometido, Política, Qué pasa

Consumo futuro ya comprometido	Política	Qué pasa
Hasta 10 minutos	Overage protection	Nada. Tienes 10 minutos de capacidad futura de colchón para picos
Entre 10 y 60 minutos	Interactive Delay	Las operaciones interactivas nuevas esperan 20 segundos al enviarse
Entre 60 minutos y 24 horas	Interactive Rejection	Las interactivas se rechazan: los informes fallan. El background sigue corriendo
Más de 24 horas	Background Rejection	Todo se rechaza: refrescos, notebooks, pipelines, consultas. Todo

Así que el throttling avanza por etapas según cuánta capacidad futura llevas comprometida, siendo las operaciones background las últimas en verse afectadas:

Fíjate que los usuarios de negocio serán los primeros en sufrir los efectos del throttling, tus informes empiezan a fallar horas antes de que tu ETL esté en riesgo, así que si el equipo de datos no monitorea, el primer síntoma de un problema de capacidad será probablemente usuarios quejándose de que “sus reportes cargan muy lento o no abren”.

Ejemplo de throttling

El escenario: Trabajas en una capacidad F2: 60 CU por timepoint de 30 segundos, 172.800 CU al día.

Usamos el mismo refresh de la sección anterior: cuesta 43.200 CU en total, y el smoothing lo convierte en una cuota de 15 CU por timepoint (el 25% de tus 60) durante las siguientes 24 horas.

Dado que las operaciones background se suavizan en cuotas repartidas en 24 horas, tu límite “sin deuda” es el presupuesto del día completo, es decir 172.800 CU en una F2.

Y no importa cómo lo repartas: 4 refreshes de 43.200 CU, 40 dataflows de 4.320 CU o un solo mega-proceso de 172.800 CU. Mientras la suma de lo que ejecutas en cualquier ventana de 24 horas no supere esa cifra, las cuotas nunca desbordan los 60 CU del timepoint y no se acumula deuda.

Así que con 4 refresh de 15 CU c/u las cuotas se apilan hasta 60 de 60. Estás justo al 100%, Sin deuda y sin throttling.

Ahora veamos lo que ocurre si se suma un refresh adicional:

Con 5 refresh: a cada timepoint le llegan 75 CU, pero solo puede pagar 60. Hagamos la cuenta en dos tramos:

1. La deuda solo se amortiza (burndown) con capacidad ociosa, así que durante las primeras 24 horas no hay ni un timepoint libre, ya que todos están ocupados pagando cuotas.

2. A partir de las 10:00 del día siguiente las cuotas se terminan y ahí es cuando la capacidad queda ociosa, dejando 7.200 CU libres por hora, por lo que pagar esos 43.200 CU de deuda le va a tomar 6 horas más, por lo tanto, se necesitaron 30 horas para pagar la deuda que generó ese quinto refresh.

Así es como una capacidad llega al throttling “sin estar haciendo nada”, ya que la deuda de trabajos que terminaron hace horas llenó el presupuesto futuro.

Recomendaciones para manejar el throttling

Si ya tu capacidad está en throttling estas son las opciones que puedes manejar:

1. Esperar. A medida que van quedando timepoints libres, la deuda se va pagando, sin que tengas que tocar nada.

2. Subir el SKU temporalmente. Más capacidad ociosa por timepoint significa burndown más rápido, por ejemplo, si duplicas el SKU, la espera se reduce a la mitad. Y cuando la deuda esté pagada, bajas de nuevo.

3. Pausar y reanudar la capacidad. Al pausar, todo el uso suavizado pendiente se suma y se cobra en un solo cargo; al reanudar, la capacidad arranca limpia y acepta trabajo inmediatamente.

   Dos cosas a tener en cuenta: estás adelantando el pago de toda la deuda pendiente en un solo cargo, y la documentación advierte que pausar puede dejar el contenido de Fabric no disponible, por lo que recomienda asegurarse de que la capacidad no esté en uso antes de hacerlo. Si tienes trabajos largos en curso, casi siempre te conviene más subir el SKU que pausar.

4. Capacity overage billing. Una opción relativamente nueva: puedes habilitar que los excedentes se facturen a 3 veces la tarifa normal en vez de sufrir throttling. Esto puede resultar caro, pero te permite evitar que tu capacidad colapse.

5. Prevenir. Existe la surge protection, una salvaguarda configurable que limita cuánto cómputo pueden acumular los trabajos background. La surge protection te deja adelantar ese freno al punto que tú elijas, con dos números:

   • Un umbral de rechazo: cuando el consumo background comprometido de las próximas 24 horas alcanza ese porcentaje (digamos, el 70%), la capacidad deja de aceptar trabajos background nuevos.
   • Un umbral de recuperación: cuando el consumo baja de ese otro porcentaje (digamos, el 50%), vuelve a aceptarlos. La separación entre ambos evita que el freno se active y desactive a cada rato.

Una última reflexión: aunque el throttling puede percibirse como algo negativo, en realidad funciona como un mecanismo de protección. Fabric limita cuánto consumo futuro puedes comprometer y aplica restricciones antes de que la sobrecarga siga creciendo. De este modo, evita que la capacidad acumule un exceso difícil de absorber y que su impacto en la capacidad se prolongue durante varios días.

Así que si tu capacidad está en throttling con frecuencia, el mensaje que te está dando es que tu capacidad está mal dimensionada o que hay artefactos por optimizar. Veremos esto más en detalle en la parte 4 de esta serie.

Ya conoces la mecánica del modelo; en la Parte 3 — ¿Cuánto cuesta Microsoft Fabric? seguimos con la otra cara: precios, pay-as-you-go vs reserva y el licenciamiento por usuario.