Cambios en Fabric

Cambios en Fabric Data Warehouse

LinkedIn
Facebook
Twitter
WhatsApp

El cambio en la medición de Fabric Data Warehouse: qué cambia, a quién afecta y cómo mitigarlo

Desde agosto de 2026, Microsoft mide el consumo de Warehouse por tiempo de cómputo asignado y no por CPU de cada consulta. Esto es lo que conviene saber.

Fabric 1

Qué ha cambiado

Microsoft ha modificado cómo contabiliza el consumo de capacidad (CU) de Fabric Data Warehouse y del SQL analytics endpoint de los Lakehouse. El cambio se despliega desde agosto de 2026.

Hasta ahora, el consumo estaba ligado al tiempo de CPU que gastaba cada consulta. Con el nuevo modelo, lo que cuenta es cuánto cómputo asigna Fabric y durante cuánto tiempo. Según la documentación oficial, esto se articula así:

  • Unidad de medida: el vNode (nodo virtual), un bloque de 4 vCores que Fabric asigna y libera automáticamente según la demanda.
  • Fórmula conceptual: consumo = vNodes activos × tiempo activo.
  • Ventana base de un minuto: el cómputo se asigna con una ventana mínima de un minuto, después de ese minuto el consumo se mide por segundo.
  • Tarifa: según Fabric operations, un core de Data Warehouse equivale a 0,538 CU, es decir, unos 2,15 CU por vNode mientras está activo.
  • Alcance: afecta a la medición de Warehouse y del SQL endpoint, no a los SKU ni a la capacidad contratada. Incluye las consultas de usuario, las generadas por el sistema y las consultas a vistas de catálogo y DMVs.

Según el aviso que Microsoft envió a los clientes, el modelo anterior aplicaba 2 CU por vCore y el nuevo mínimo de un minuto se aplica por workspace. Esos dos detalles proceden del aviso y no de la documentación pública, así que conviene contrastarlos con el email recibido.

Por qué puede aumentar el consumo

Que la tarifa por vCore sea más baja no garantiza un menor consumo. La tarifa se aplica al tiempo de cómputo asignado, no al trabajo realmente realizado.

  • Las cargas densas pueden salir ganando. ETL, transformaciones programadas o refrescos que mantienen los vNodes ocupados aprovechan bien el tiempo asignado.
  • Las cargas dispersas pueden encarecerse. Consultas cortas y frecuentes, sondas de monitorización o procesos automáticos mantienen vNodes asignados durante mucho más tiempo del que trabajan.

 

Un ejemplo ilustrativo, que popularizaron los análisis de la comunidad: diez workspaces ejecutan cada uno una consulta de 20 segundos. Cada workspace paga su minuto mínimo, unos 129 CU-segundos por workspace, es decir, unos 1.290 en total. Si esas diez consultas coincidieran en un solo workspace dentro del mismo minuto, el coste sería de unos 129. Es una simplificación, pero muestra por qué la organización de los workspaces pasa a ser un factor de coste.

Fabric 2
Fabric 3

Posible impacto

El efecto depende del patrón de carga de cada entorno, pero puede ser considerable:

  • Aumento del consumo de CU en capacidades con mucha actividad dispersa.
  • Menos margen disponible. Las operaciones de Warehouse son background y se suavizan en 24 horas, pero si el consumo medio se acerca o supera el 100 % de la capacidad, ya no hay espacio para absorber picos.
  • Throttling y degradación del rendimiento, que se nota en informes, refrescos y cargas que comparten capacidad con Warehouse.
  • Más presión sobre el presupuesto, si la única salida es ampliar el SKU.

Estrategias de mitigación

  1. Medir antes de actuar. Combinar la app Capacity Metrics (cuánto y cuándo se consume) con Query Insights (qué consultas y qué usuarios estaban activos). Conviene desglosar el consumo por tipo de item y por workspace, antes y después del cambio, para saber cuánto del aumento se debe a Warehouse.
  2. Revisar procesos automáticos y sondas. Eliminar o espaciar consultas periódicas, monitorización y refrescos innecesarios.
  3. Agrupar cargas y consultas. Concentrar en el tiempo las ejecuciones programadas, para que compartan la ventana de un minuto en lugar de dispersarse.
  4. Valorar la consolidación de workspaces. Menos workspaces con actividad de Warehouse implica menos mínimos de un minuto independientes. Hay que ponderarlo frente a las necesidades de permisos y aislamiento.
  5. Ajustar la capacidad. Redistribuir cargas hacia capacidades con margen o, si es necesario, ampliar el SKU.
  6. Acudir a Microsoft si el impacto es material. Fabric operations indica que, si un cambio de tarifas aumenta de forma material los CU necesarios para una carga, los clientes pueden recurrir a las opciones de cancelación de su método de pago. Abrir un caso de soporte también ayuda a validar el alcance.

Conclusión

Este cambio no altera los SKU de Fabric, pero sí modifica la relación entre cómo se usa Warehouse y cuánta capacidad consume. Antes de tomar decisiones, lo más útil es entender el propio patrón de carga: cuántos workspaces tienen actividad, con qué frecuencia y cuánto tiempo mantienen el cómputo asignado.

Fuentes: documentación de Microsoft Learn (Warehouse consumption and utilization, Fabric operations, Fabric throttling), aviso de Microsoft a clientes y análisis de la comunidad (Data Mozart, DEV Community).

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Business Data Master Logo

No te pierdas el

WEBINAR
Gratuito

Explicaremos en detalle los contenidos y objetivos del Business Data Master

29/11/2021

18:30 (GTM+1)

Online

BUSINESS DATA MASTER

* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.

Best Data Solutions - Logo
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando utilizas nuestra web para personalizar el idioma o ayudar a nuestro equipo a comprender qué secciones de la web son más visitadas.