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

TL;DR

ResumenPuntos clave

Cuando una carga supera tu capacidad, Fabric no te dice “no”: te presta recursos para que el trabajo termine rápido (bursting), te cobra ese exceso en cuotas repartidas en el tiempo (smoothing) y solo te frena (throttling) cuando la deuda acumulada supera tu presupuesto futuro. 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 ejecutar puntualmente consultas “de 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.
• La ventana es móvil (las últimas 24 h), no 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.

Operaciones background e interactivas

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
• Todo lo relativo a OneLake (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 hay dos operaciones que me sorprendieron se clasificaran como brackground, ya que se comportan más como operaciones interactivas, estas son:

• 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.”

Como puedes ver estas operaciones se clasifican como background para poder manejar mejor los picos a través del suavizado del consumo de estas actividades.

Conceptos claves

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 como 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 es flexible, ya que el bursting permite que los dos se ejecuten al mismo tiempo, aunque juntos superen el límite del SKU, y el smoothing se encarga después de la factura, repartiendo el consumo excedente en cuotas sobre los timepoints futuros.

Veamos ahora como funciona esto en detalle.

Bursting

Bursting es el mecanismo por el que Fabric te da más recursos de los que tu SKU otorga, para que tus trabajos terminen más rápido, incluso si eso implica superar temporalmente tu límite de capacidad.

La definición más clara la dio el propio equipo de producto: “bursting es solo una forma elegante de decir que usamos toda la CPU que podamos para completar el trabajo lo antes posible; después, los CU consumidos se suavizan”.

Factores de Bursting

El bursting se activa de forma automática, como comportamiento por defecto del motor porlo que no tienes que solicitarlo ni activarlo, y sus factores depende del 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 ejecute puntualmente consultas “de 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×
F4096	4.096	1× – 6×
F8192	8.192	1× – 3×

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, esta falla arrojando el error: This query was rejected due to current capacity constraints.En ese caso te conviene optimizar la consulta primero, o subir de SKU temporalmente si no alcanza.

• 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
F4096	8.192	24.576	3×	4.096
F8192	16.384	49.152	3×	8.192
Trial	128	128	sin burst	no disponible
FTL4	8	16	2×	16

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 de Fabric que permite repartir el consumo excedente en pequeñas cuotas sobre los timepoints futuros en lugar de descontar el consumo de una operación de golpe en el momento en que ocurre. 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 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, es decir, si un solo trabajo interactivo puede llegar a consumir más del 50% de un timepoint, Fabric alarga su ventana para reducir el impacto.

El siguiente gráfico muestra un ejemplo de como se suavizaría una operación brackground vs una interativa. 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 como se reparte ese consumo en la ventana de suavizado correspondiente.

Del lado izquierdo puedes ver como ese consumo en una operación background se reparte en 24 horas, por lo que la barra celeste queda mas 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 corta y alta, cercana al 100% acecando 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 procesao 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 son 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 sea probablemente usuarios quejándose de que “sus reportes cargan muy lento o no abren”.

Ejemplo de throotling

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 thottling estas son las opciones uqe puede smanejar:

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, y además la pausa corta los trabajos background que estuvieran corriendo — si un dataflow llevaba dos horas y le faltaban diez minutos, ese trabajo se pierde con su consumo ya hecho. Por lo que si tiene trabajos 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 colpase.
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 sobre todo este mecanismo, “throttling” puede verse como algo negativo pero conviene leerlo como lo que es un sistema de protección donde tus límites de endeudamiento se acotan, así evitas acumular semanas de deuda, las restricciones te frenan mucho antes.

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.