Introducción
Elegir correctamente la capacidad de Microsoft Fabric es una de las primeras —y más importantes— decisiones que tendrás que tomar al diseñar tu arquitectura de datos.
Si vienes de otras plataformas o fabricantes, seguramente estés acostumbrado a un modelo pay-as-you-go, donde pagas exactamente por lo que consumes en cada momento.
En Fabric, el enfoque es distinto. En lugar de pagar por cada ejecución o recurso individual, reservas una capacidad mensual, que actúa como un pool virtual de recursos de cómputo del que todos tus workloads van consumiendo.
¿Qué es realmente una Fabric Capacity?
Fabric ofrece distintos tamaños de capacidad: F2, F4, F8, F16, F32, F64, etc.
Cada uno representa una cantidad determinada de Capacity Units (CUs). Las CUs son la medida de cómputo consumido por segundo.
No hablan de máquinas, CPUs o nodos concretos, sino de capacidad abstracta compartida entre todos los workloads.
Y aquí viene uno de los puntos clave: esta capacidad no es rígida, puede escalar dinámicamente.
Bursting & Smoothing: el corazón del modelo de Fabric
Fabric introduce un mecanismo fundamental que hay que entender bien: Bursting & Smoothing.
En términos simples:
- Provisionas una capacidad base (por ejemplo, F8 = 8 CUs)
- Tus workloads pueden consumir muy por encima de esa capacidad de forma temporal
- El sistema redistribuye ese consumo en el tiempo, permitiéndote “devolver” la capacidad prestada más adelante
Este modelo es lo que permite combinar flexibilidad, rendimiento y control de costes… siempre que se diseñe bien. A partir de este mecanismo surgen tres aspectos críticos que hay que entender bien.
Aspecto crítico nº1: Burst Multipliers
El primer factor importante es el multiplicador de burst, que depende del SKU que tengas contratado.
- Capacidades pequeñas (por ejemplo, F2)
Pueden llegar a multiplicar hasta x32 su capacidad provisionada.
En la práctica, un F2 puede alcanzar picos equivalentes a una F64 durante la ejecución de un workload. - Capacidades grandes (por ejemplo, F64)
También pueden hacer burst, pero con un multiplicador menor, típicamente hasta x12.
Esto rompe un mito habitual: una capacidad pequeña no implica necesariamente bajo rendimiento, siempre que el uso sea controlado y puntual.
Aspecto crítico nº2: Smoothing Windows (periodos de repago)
Obviamente, ese burst no es gratis. Toda la capacidad “prestada” debe devolverse, y aquí entra en juego el concepto de smoothing.
Fabric aplica distintos periodos de repago según el tipo de workload:
Trabajos largos o en segundo plano
- El consumo extra se suaviza a lo largo de las siguientes 24 horas
- Ideal para pipelines batch, cargas nocturnas o procesos programados
Workloads interactivos
- El repago se hace en ventanas mucho más cortas
- Pensado para consultas, notebooks exploratorios o acciones de usuario
Ejemplo práctico con una F2
Supongamos que trabajas con una capacidad F2:
- Job corto (10 segundos)
Puedes consumir hasta el equivalente a una F64 (32x burst)
El sistema descuenta ese consumo en los minutos siguientes - Job largo (1–2 horas)
Puedes ejecutar hasta 12x la capacidad base
El “exceso” se reparte y se paga durante las siguientes 24 horas
Un caso muy habitual: un pipeline maestro diario, ejecutándose a las 2:00 AM durante 1 hora. Este patrón encaja perfectamente con el modelo de bursting + smoothing si está bien dimensionado.
Aspecto crítico nº3: Throttling (limitaciones)
Aquí es donde muchos entornos empiezan a tener problemas. Si excedes los límites de forma constante, Fabric actuará:
- Primero, aplicando throttling (ralentizando tus jobs)
- Si el patrón continúa, rechazando ejecuciones
Esto no es un error de la plataforma, sino una señal clara de que:
- la capacidad está mal dimensionada
- o los workloads no están bien diseñados
FinOps, arquitectura y decisiones técnicas
Por eso, en Fabric, FinOps y arquitectura van de la mano. Las decisiones técnicas tienen impacto directo en el consumo:
- Usar Notebooks vs Dataflows Gen2
- Cómo diseñas y gestionas tus Spark Pools
- Cuántos procesos paralelos lanzas
- En qué momentos del día ejecutas cargas pesadas
Para todo esto, Fabric Capacity Metrics App es una herramienta clave:
- Visualiza consumo real
- Identifica picos, deudas de capacidad y throttling
- Ayuda a tomar decisiones basadas en datos, no en suposiciones
Conclusión
Entender cómo funciona realmente la capacidad en Microsoft Fabric no es un detalle técnico menor: es la base para construir una plataforma de datos resiliente, escalable y sostenible en costes.
Las elecciones que hagas al principio sí importan.
