Entendiendo la Capacidad de Fabric: Unidades de Capacidad (CU) y Rendimiento

En el modelo tradicional de datos, gestionábamos silos. Teníamos un servidor para SQL Server, un clúster para Spark y una capacidad Premium para Power BI. Cada uno con su propia factura, sus propios límites de hardware y, lo más ineficiente, sus propios recursos ociosos. Microsoft Fabric rompe esta estructura mediante el concepto de Capacidad de Fabric, un fondo común de recursos donde la potencia de cálculo se abstrae en una métrica única: las Unidades de Capacidad (CU).

Como consultor, uno de los errores más comunes que veo en empresas de retail y sector público es tratar a Fabric como si fuera simplemente un ‘Power BI Premium con esteroides’. No lo es. Si no entiendes cómo se consumen las CUs entre los diferentes motores (Warehouse, Lakehouse, Notebooks, KQL), acabarás pagando por una SKU superior a la que necesitas o, peor aún, sufriendo caídas de rendimiento constantes por un estrangulamiento (throttling) mal gestionado. En este artículo vamos a desglosar qué son realmente estas unidades y cómo afectan al día a día de un proyecto de datos real.

La clave de Microsoft Fabric: La convergencia analítica SaaS y el fin de la integración manual es precisamente esta unificación. Ya no compramos máquinas virtuales ni núcleos aislados; compramos una reserva de potencia que se reparte dinámicamente según la demanda de cada carga de trabajo.

¿Qué son exactamente las Unidades de Capacidad (CU)?

Las Capacity Units (CU) son la unidad de medida que cuantifica la potencia de procesamiento disponible para tu capacidad de Fabric. A diferencia de un vCore tradicional, que representa una unidad física de CPU, la CU es una medida de rendimiento normalizado. Esto permite a Microsoft actualizar el hardware subyacente en sus centros de datos sin que tú tengas que reconfigurar tus procesos; tu capacidad de 64 CUs seguirá entregando la misma potencia relativa independientemente de la generación del servidor.

El concepto fundamental aquí es el fondo común de recursos. Cuando ejecutas una consulta T-SQL en un Warehouse o un proceso de limpieza de datos en un Notebook de Spark, ambos restan potencia del mismo cubo de CUs. Esto es especialmente crítico en escenarios de industria, donde los procesos de ingesta nocturna (muy pesados en Spark) pueden chocar con los informes de disponibilidad matutinos si no se planifican correctamente.

La diferencia entre Capacidad Reservada y Consumo en Tiempo Real

Es vital distinguir entre la capacidad contratada (la SKU que pagas) y el consumo instantáneo. Fabric permite algo llamado bursting (picos de capacidad). Si tienes una capacidad F2 (2 CUs), puedes realizar una tarea que requiera 10 CUs de forma momentánea. Fabric ‘te presta’ esa potencia y luego la compensa a lo largo del tiempo. Aquí es donde entra en juego la herramienta de monitorización, como explicamos en Fabric Capacity Metrics: Dominando el consumo de CUs y evitando el estrangulamiento.

Jerarquía de SKUs y equivalencias

Para un consultor, elegir la SKU correcta es la primera decisión crítica. En proyectos de tamaño medio, solemos empezar con SKUs bajas para desarrollo (F2 o F4) y escalamos a producción según los resultados de las pruebas de carga. Es importante recordar que las SKUs de Fabric (F-SKUs) son las sucesoras naturales de las SKUs de Power BI Premium (P-SKUs), pero con mayor flexibilidad.

Un punto de decisión clave: si necesitas que usuarios sin licencia de Power BI Pro puedan consumir informes, debes saltar a una F64 o superior. Por debajo de ese nivel, cada usuario que visualice un informe necesitará su propia licencia Pro o Premium Per User (PPU), lo cual suele ser un trade-off económico importante en sectores como el público con miles de empleados.

Suavizado (Smoothing) y Throttling: El corazón del rendimiento

Esta es la parte donde la mayoría de los arquitectos de datos se confunden. Fabric no corta tu consulta en el momento en que superas tu límite de CUs. En su lugar, utiliza un algoritmo de suavizado (smoothing). El sistema promedia el consumo de las tareas pesadas durante un periodo de tiempo (normalmente 24 horas para tareas en segundo plano como el refresco de modelos o ETLs, y unos minutos para tareas interactivas como visualización de informes).

Si tu consumo promedio excede la capacidad contratada, entras en estado de throttling (estrangulamiento). Esto se manifiesta de tres formas:

1. Rechazo de trabajos interactivos: Tus informes de Power BI dejan de cargar o dan error.
2. Retraso de trabajos en segundo plano: Tus refrescos de datos se ponen en cola y tardan mucho más.
3. Degradación total: El workspace se vuelve inmanejable hasta que el promedio de consumo baja.

En mi experiencia en el sector retail, durante el Black Friday, es común ver picos de consumo masivos. Si no has analizado tus consultas costosas en Fabric: del pico de capacidad al código SQL exacto, el suavizado no te salvará de que los directivos vean pantallas en blanco justo cuando más necesitan los datos.

Medición del consumo por carga de trabajo

Como mencioné, el problema no suele ser el modelo de datos en sí (un buen esquema en estrella es sagrado), sino cómo interactuamos con él. En un Warehouse, una consulta mal optimizada con múltiples JOIN sobre tablas de hechos sin filtrar puede devorar CUs en segundos. Veamos cómo se ve esto desde la perspectiva de la monitorización técnica.

-- Ejemplo de consulta que podría disparar el consumo de CUs
-- Si no tenemos índices o si la tabla no está bien particionada en el Delta Lake
SELECT 
 c.Categoria,
 SUM(v.Importe) AS TotalVentas,
 COUNT(DISTINCT v.ClienteID) AS ClientesUnicos
FROM Ventas v
JOIN Producto p ON v.ProductoID = p.ProductoID
JOIN Calendario c ON v.FechaID = c.FechaID
WHERE c.Anio = 2023
GROUP BY c.Categoria
HAVING SUM(v.Importe) > 10000;

En Fabric, esta consulta no solo consume tiempo de CPU, consume CUs. Si esta tabla Ventas tiene 500 millones de filas y no estás aprovechando el V-Order o el particionamiento adecuado en tu Lakehouse vs Data Warehouse en Microsoft Fabric, el motor de SQL tendrá que trabajar el triple para escanear los archivos Parquet en OneLake.

Por otro lado, en ingeniería de datos, un Notebook de Spark mal configurado puede ser igual de peligroso. Un error clásico es asignar demasiados ejecutores para una tarea pequeña, reservando CUs que no se están utilizando realmente pero que ‘bloquean’ la capacidad para otros procesos.

# Configuración de sesión Spark que consume CUs de forma agresiva
from pyspark.sql import SparkSession

spark = SparkSession.builder \
 .appName("ProcesamientoVentasRetail") \
 .config("spark.executor.memory", "8g") \
 .config("spark.dynamicAllocation.enabled", "true") \
 .config("spark.dynamicAllocation.maxExecutors", "20") # Ojo: esto reserva mucha capacidad
 .getOrCreate()

# Proceso de limpieza en capa Silver
df_ventas = spark.read.format("delta").load("Files/Bronze/Ventas")
df_limpio = df_ventas.dropDuplicates(["TransaccionID"]).filter("Importe > 0")
df_limpio.write.format("delta").mode("overwrite").save("Tables/Silver_Ventas")

Errores frecuentes en la gestión de capacidad

• No usar el auto-pausado: En SKUs F contratadas a través de Azure (Pay-as-you-go), dejar la capacidad encendida 24/7 cuando solo se usa 10 horas al día es tirar el dinero.
• Ignorar el efecto acumulativo: Pensar que porque una consulta SQL es rápida no importa. 1000 consultas rápidas mal optimizadas pueden sumar más CUs que un proceso ETL pesado.
• Confundir almacenamiento con cómputo: OneLake cobra por GB almacenado, mientras que la Capacidad de Fabric cobra por CU (cómputo). Son facturas distintas.
• Falta de gobernanza en Workspaces: Asignar demasiados Workspaces a una capacidad pequeña provoca que el suavizado de unos ‘ahogue’ a los otros.

Conclusión y Checklist de Optimización

La Capacidad de Fabric es el motor que mueve toda tu infraestructura de datos moderna. Su flexibilidad es su mayor virtud, pero también su mayor riesgo si se gestiona sin métricas claras. Antes de escalar a una SKU superior, asegúrate de que el problema no sea una ineficiencia en tus procesos.

Como consultor, mi recomendación siempre es: mide antes de pagar. Utiliza la App de Capacity Metrics para identificar qué motor (Power BI, SQL, Spark) es el que está consumiendo más recursos y optimiza el código en ese punto específico.

«En Microsoft Fabric, el rendimiento no es un problema de hardware, es un problema de gestión de inventario de CUs.»

Checklist para el Administrador de Capacidad:

1. Verificar si el suavizado (smoothing) está moviendo el consumo de tareas pesadas a horas de baja actividad.
2. Revisar que no haya estrangulamiento (throttling) en horas críticas de negocio (09:00 – 11:00 AM).
3. Asegurarse de que las tareas de mantenimiento como VACUUM y OPTIMIZE se ejecutan en ventanas de bajo consumo.
4. Validar que los desarrolladores de Spark están usando tamaños de nodo adecuados para sus Notebooks.
5. Confirmar que la SKU elegida cubre las necesidades de licenciamiento de los usuarios finales (F64 para usuarios free).

Preguntas frecuentes

¿Puedo pausar mi capacidad de Fabric para ahorrar costes?

Sí, las SKUs F compradas a través de Azure permiten pausarse y reanudarse. Ten en cuenta que mientras esté pausada, los elementos del Workspace (informes, warehouses) no estarán accesibles, aunque los datos sigan seguros en OneLake.

¿Qué ocurre si consumo más CUs de las que tengo contratadas en un pico?

Gracias al bursting y al suavizado, Fabric procesará la tarea. Sin embargo, ‘deberás’ esas CUs al sistema, y si el exceso es constante, el sistema empezará a retrasar tus procesos futuros hasta compensar la deuda.

¿Las CUs de Power BI Premium son iguales a las de Fabric?

Conceptualmente sí, pero Fabric ofrece una granularidad mucho mayor. Mientras que Premium se centraba en el motor de Analysis Services, Fabric reparte esas mismas CUs entre SQL, Spark, Data Factory y Real-Time Analytics.

¿Cómo sé si necesito subir de una F2 a una F4?

Debes monitorizar el porcentaje de ‘Overages’ en la Capacity Metrics App. Si ves que tu capacidad está constantemente por encima del 100% de utilización suavizada, es el momento técnico de escalar para evitar latencias.