Estrategias para escalar Microsoft Fabric: capacidad, datos y usuarios

Muchos proyectos de Microsoft Fabric comienzan con una capacidad mínima (F2 o F4) bajo la premisa de que el pago por uso y la elasticidad resolverán cualquier problema de rendimiento en el futuro. Sin embargo, la realidad de la consultoría nos enseña que el escalado lineal de costes no siempre soluciona un diseño ineficiente. Escalar una plataforma Fabric implica entender cómo el sistema gestiona las unidades de capacidad (CU) y cuándo el crecimiento de los datos o de la concurrencia de usuarios exige un cambio de enfoque arquitectónico.

El error más común es tratar a Fabric como un servidor tradicional donde si falta memoria, se añade más. En Fabric, el concepto de smoothing (suavizado) y throttling (estrangulamiento) cambia las reglas del juego. Si tus procesos de ETL consumen más CUs de las disponibles, Fabric permite que ‘tomes prestada’ capacidad del futuro, pero ese préstamo se paga con latencia en las consultas de los usuarios finales. En este artículo detallamos cómo identificar que tu plataforma ha llegado al límite y qué pasos dar para escalar con criterio técnico.

Señales críticas que obligan a un rediseño

Antes de aumentar el SKU y pagar más a final de mes, hay que identificar si el problema es de volumen o de eficiencia. En sectores como el retail o la industria, donde los volúmenes de la tabla de Ventas o LecturasSensores pueden crecer de forma exponencial, las señales de agotamiento suelen aparecer en tres frentes: la latencia de refresco, la respuesta de las consultas DAX y el rechazo de operaciones en el Lakehouse.

Una señal inequívoca de que necesitas rediseñar es el Carry Forward persistente en la aplicación Microsoft Fabric Capacity Metrics. Si ves que el consumo acumulado de tus procesos de madrugada está afectando al rendimiento de los informes a las 9:00 AM, el suavizado ya no es suficiente. No estás ante un pico puntual, sino ante un déficit estructural de capacidad. Otro indicador es la degradación del rendimiento en el SQL Endpoint del Lakehouse al realizar cruces complejos; a menudo esto se debe a una falta de mantenimiento de metadatos o a un particionamiento inexistente.

Es fundamental aplicar pruebas de rendimiento en Fabric Warehouse para distinguir entre un problema de motor de computación y un problema de modelado de datos. Si un modelo en estrella bien definido (Hechos y Dimensiones) empieza a fallar, el problema es de capacidad. Si el problema es una tabla plana de 200 columnas, el problema es el arquitecto.

Gestión de la capacidad: el impacto del Smoothing

Microsoft Fabric promedia el consumo de las operaciones interactivas (como un clic en un informe de Power BI) en 5 minutos, mientras que las operaciones en segundo plano (como un Notebook de Spark o un Data Pipeline) se promedian en 24 horas. Este mecanismo de smoothing es una bendición para el presupuesto, pero una trampa para los que no monitorizan.

Cuando el consumo promediado supera el 100% de la capacidad contratada, entra en juego el throttling. Primero, Fabric retrasa las operaciones (latencia), y si el exceso continúa, empieza a rechazar nuevas tareas. Para escalar correctamente, debes analizar la relación entre tus procesos de carga y las horas de mayor concurrencia de usuarios.

Si tus cargas de Ventas_Historico consumen el 80% de tu capacidad diaria, apenas dejas margen para que los usuarios finales exploren los datos. En estos casos, antes de escalar el SKU, conviene optimizar el código. Por ejemplo, en procesos Spark, el uso de V-Order puede reducir drásticamente el tiempo de lectura posterior.

# Ejemplo de optimización en Notebook de Fabric aplicando V-Order
# Esto reduce el consumo de CUs en lecturas posteriores

df_ventas = spark.read.table("Lakehouse.Ventas_Raw")

# Aplicamos transformaciones necesarias
df_ventas_limpio = df_ventas.filter("Importe > 0")

# Escritura optimizada con V-Order activado por defecto en Fabric
df_ventas_limpio.write.mode("overwrite").format("delta").saveAsTable("Ventas_Gold")

# Forzamos la compactación y optimización de archivos Delta
spark.sql("OPTIMIZE Ventas_Gold")

Estrategias de particionamiento y mantenimiento

El crecimiento de datos no se gestiona solo con más potencia, sino con mejor organización. En tablas de gran volumen como Fact_Transacciones, el particionamiento es obligatorio para evitar escaneos completos del OneLake. Sin embargo, un exceso de particiones (over-partitioning) puede ser tan perjudicial como no tener ninguna, debido al problema de los «archivos pequeños» (small files).

En Fabric, el motor de SQL y Power BI se benefician enormemente de la estructura de archivos Parquet. Si no gestionas la fragmentación, el motor desperdiciará CUs abriendo y cerrando miles de archivos de pocos kilobytes. Es vital entender la fragmentación en Microsoft Fabric Warehouse para mantener el rendimiento sin subir de SKU. Una tabla bien compactada consume menos recursos de red y CPU al ser consultada.

El dilema del motor: Lakehouse vs. Warehouse para escalar

Una decisión arquitectónica clave para escalar es elegir el motor adecuado. Aunque ambos almacenan datos en OneLake en formato Delta Parquet, su comportamiento bajo carga es distinto. El Warehouse ofrece una experiencia SQL completa con transacciones ACID multi-tabla y es excelente para perfiles que dominan T-SQL. Sin embargo, para cargas masivas de datos no estructurados o transformaciones complejas de ingeniería, el motor de Spark en el Lakehouse suele escalar mejor de forma horizontal.

He observado en proyectos de sector público con millones de registros que intentar hacer transformaciones pesadas mediante INSERT INTO ... SELECT en el Warehouse puede consumir rápidamente la cuota de CUs interactivas. En cambio, delegar esa lógica a un Notebook de Spark permite aprovechar el suavizado de 24 horas, liberando la capacidad para las consultas de los informes de Power BI durante el día. Es un trade-off de diseño: SQL para simplicidad y gobierno, Spark para potencia y eficiencia en costes de carga.

Además, para mantener la frescura de datos en Microsoft Fabric, es preferible usar arquitecturas de metadatos que solo procesen los cambios (CDC) en lugar de recargas completas. Esto es especialmente crítico cuando pasamos de miles a millones de filas diarias.

Errores frecuentes en el escalado de Fabric

• Ignorar la aplicación de métricas: No instalar la «Fabric Capacity Metrics App» y basarse solo en la percepción de los usuarios.
• No usar Direct Lake: Seguir usando el modo Import para tablas de cientos de millones de filas, saturando la memoria de la capacidad.
• Despreciar el mantenimiento Delta: Olvidar ejecutar VACUUM y OPTIMIZE, lo que lleva a un crecimiento desmesurado del almacenamiento y lentitud en lectura.
• Lógica compleja en Power Query: Mantener transformaciones pesadas en Power Query (Dataflows Gen2) que podrían hacerse de forma más eficiente en SQL o Spark.
• No configurar alertas: No establecer alertas de consumo que avisen cuando se alcanza el 80% de la capacidad de forma sostenida.

-- Consulta para identificar el tamaño y la salud de las tablas en el Warehouse
-- Ayuda a decidir qué tablas necesitan particionamiento o limpieza

SELECT 
 s.name AS Esquema,
 t.name AS Tabla,
 p.rows AS NumeroFilas,
 SUM(a.total_pages) * 8 / 1024 AS TamañoMB
FROM 
 sys.tables t
JOIN 
 sys.schemas s ON t.schema_id = s.schema_id
JOIN 
 sys.partitions p ON t.object_id = p.object_id
JOIN 
 sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY 
 s.name, t.name, p.rows
ORDER BY 
 TamañoMB DESC;

Conclusión: Cuándo saltar al siguiente SKU

Escalar no es una derrota del diseño, es una consecuencia del éxito del dato en la organización. Debes considerar subir de SKU (de F4 a F8, por ejemplo) cuando, tras optimizar el particionamiento, aplicar V-Order y distribuir las cargas de trabajo, el gráfico de Utilización muestra que el 100% de la capacidad está comprometida durante más de 4 horas consecutivas. Si el sistema empieza a rechazar conexiones interactivas de Power BI, el impacto de negocio supera el coste del escalado.

Recuerda que Fabric es una plataforma en evolución. Estar al tanto de la evolución de OneLake y sus nuevas capacidades de almacenamiento distribuido te permitirá anticipar cambios que hoy requieren intervención manual pero que mañana estarán automatizados por el propio motor.

Preguntas frecuentes

¿Qué sucede si consumo más CUs de las que tengo contratadas?

Fabric aplica un sistema de suavizado (smoothing). Si el exceso es breve, se compensa con periodos de baja actividad. Si el exceso es persistente, entrarás en estado de estrangulamiento (throttling), lo que ralentizará o bloqueará las consultas y procesos hasta que la capacidad se recupere.

¿Es mejor escalar verticalmente (más SKU) o repartir la carga?

Siempre intenta primero repartir la carga. Mueve las transformaciones pesadas a horas valle para aprovechar el suavizado de 24 horas de los procesos de fondo. Si aun así la experiencia del usuario en los informes es lenta, escala el SKU verticalmente.

¿Influye el número de usuarios en el consumo de capacidad?

Sí, cada consulta generada por un visual de Power BI consume CUs interactivas. A mayor número de usuarios concurrentes y mayor complejidad de las medidas DAX, más rápido se agotará la capacidad asignada al área de trabajo.

Checklist de escalabilidad en Fabric

• Monitorización activa: ¿Tienes instalada y revisas semanalmente la App de métricas de capacidad?
• Optimización Delta: ¿Has programado procesos de OPTIMIZE y VACUUM en tus tablas Gold?
• Estrategia de carga: ¿Tus Data Pipelines más pesados se ejecutan fuera del horario comercial?
• Modo de almacenamiento: ¿Estás evaluando Direct Lake para las tablas que superan los límites razonables de Import?
• Gobierno de Workspace: ¿Has separado las capacidades de desarrollo y producción para evitar que una carga de prueba tumbe el sistema real?