Pruebas de rendimiento en Fabric Warehouse: metodología y métricas reales

En proyectos de Business Intelligence con Microsoft Fabric, el rendimiento ya no se mide únicamente en segundos de reloj. La arquitectura SaaS de Fabric introduce una variable crítica: las Capacity Units (CU). Optimizar un proceso en el Warehouse no solo busca que el usuario reciba sus datos antes, sino garantizar que no agotamos los recursos de la capacidad, evitando el estrangulamiento (throttling) de otros procesos del área de trabajo.

Muchos equipos cometen el error de extrapolar metodologías de SQL Server local o Azure SQL a Fabric. Sin embargo, en un entorno donde el almacenamiento está desacoplado (OneLake) y el cómputo es elástico pero compartido, las pruebas de rendimiento deben ser más rigurosas y repetibles. No basta con ejecutar una consulta y mirar el cronómetro; hay que entender qué ocurre en la capa de control y cómo el motor distribuye la carga sobre los archivos Parquet.

Este artículo detalla la metodología que aplico en consultoría para validar cambios en la arquitectura de datos, comparar versiones de procesos ETL y asegurar que el modelo en estrella responda con eficiencia. Antes de tocar una sola línea de código, debemos establecer una línea base y entender qué métricas realmente dictan el éxito de nuestra implementación.

El cambio de paradigma: De segundos a Capacity Units

En el modelo tradicional de SQL Server, el coste era fijo (licencia o instancia) y el rendimiento dependía de la CPU y la RAM. En Microsoft Fabric, el rendimiento es una moneda de cambio. Cada consulta consume CU, y estas se suavizan (smoothing) a lo largo del tiempo. Si lanzamos una prueba de carga masiva sin control, podemos penalizar el rendimiento del tenant durante las próximas 24 horas.

Al diseñar pruebas en el Warehouse, el primer paso es aislar la capacidad. Si realizas pruebas mientras otros usuarios están consumiendo informes de Power BI o ejecutando Notebooks, tus resultados estarán contaminados. La metodología correcta exige un entorno de pruebas con una capacidad dedicada o, en su defecto, realizar las mediciones en horarios de nula actividad, monitorizando siempre la aplicación Microsoft Fabric Capacity Metrics.

Es fundamental recordar que el Warehouse de Fabric utiliza un motor basado en Polaris, que optimiza las consultas sobre archivos Parquet con V-Order. Esto significa que el rendimiento no solo depende del código SQL, sino de cómo se han escrito los datos en OneLake. Si venimos de un entorno donde el plegado de consultas en Power Query era nuestra mayor preocupación, aquí el foco se desplaza hacia la eficiencia de la computación distribuida.

Metodología de pruebas repetibles

Para que una prueba de rendimiento sea válida, debe ser reproducible. En mi experiencia, el mayor error es probar con volúmenes de datos insuficientes. El motor de Fabric brilla con millones de filas; probar con 10.000 registros no nos dirá nada sobre cómo escalará la solución en producción.

1. Definición del escenario: Identifica las 5 consultas más críticas (las más frecuentes o las que mueven más volumen).
2. Preparación del set de datos: Utiliza tablas con un volumen real. Si estás en retail, usa una tabla de Ventas que refleje al menos dos años de histórico.
3. Limpieza de caché: Aunque Fabric gestiona la caché de forma automática, para pruebas de rendimiento puro debemos considerar tanto el estado «frío» (cold cache) como el «caliente» (warm cache). La primera ejecución tras un periodo de inactividad siempre será más lenta por la lectura desde OneLake.
4. Ejecuciones múltiples: Ejecuta cada prueba al menos 5 veces y descarta el valor más alto y el más bajo. Calcula la media de los 3 restantes.

Durante estas pruebas, es vital observar el plan de ejecución. Al igual que al leer planes de ejecución en SQL Server, en Fabric buscamos operadores que indiquen movimientos de datos costosos (Data Movement Service) entre nodos, lo cual suele ser el principal cuello de botella en sistemas distribuidos.

Métricas críticas y DMVs en Fabric Warehouse

Para medir el rendimiento de forma técnica, no podemos confiar solo en el reloj de la interfaz web. Debemos recurrir a las Vistas de Gestión Dinámica (DMVs) que expone el punto de conexión SQL del Warehouse. La vista sys.dm_exec_requests y sus variantes en el contexto de Synapse/Fabric nos permiten ver qué está ocurriendo en tiempo real.

El siguiente script permite capturar información sobre las consultas en ejecución, su duración y el identificador de sesión, algo básico para trazar el impacto de cada proceso:

-- Monitorización de consultas activas en Fabric Warehouse
SELECT 
 r.session_id,
 r.start_time,
 r.total_elapsed_time / 1000 AS Duracion_Segundos,
 r.status,
 r.command,
 s.login_name,
 SUBSTRING(st.text, (r.statement_start_offset/2) + 1, 
 ((CASE r.statement_end_offset 
 WHEN -1 THEN DATALENGTH(st.text) 
 ELSE r.statement_end_offset END 
 - r.statement_start_offset)/2) + 1) AS Query_Text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
WHERE s.is_user_process = 1
AND r.session_id <> @@SPID;

Además del tiempo de ejecución, debemos fijarnos en el suavizado de capacidad. Fabric permite exceder el límite de CU de forma puntual, pero nos «cobrará» ese exceso en los periodos siguientes. Si una prueba consume el 200% de la capacidad asignada, veremos una degradación en el rendimiento de las tareas interactivas posteriores. Esto es especialmente crítico si estamos implementando modelos en producción con ventanas de carga muy ajustadas.

Comparativa técnica: SQL tradicional vs. Fabric Warehouse

Es vital entender las diferencias operativas para no aplicar técnicas de optimización contraproducentes. Por ejemplo, en Fabric no existen los índices tradicionales (clustered/non-clustered) tal como los conocemos en SQL Server. La optimización pasa por el particionamiento y la ordenación de los datos en el almacenamiento.

Esta tabla subraya por qué las pruebas de rendimiento deben enfocarse en el volumen de datos procesados por segundo y no solo en la complejidad del código. Una consulta con muchos JOINs sobre tablas mal particionadas en OneLake obligará al motor a realizar un «shuffle» de datos entre nodos de cómputo, disparando el consumo de CU.

Generación de datos y pruebas de estrés

Para medir el límite de nuestra arquitectura, recomiendo generar datos sintéticos que mantengan la cardinalidad de los datos reales. Si trabajamos en un modelo en estrella, la tabla de hechos (Fact) debe ser el centro de nuestras pruebas de estrés. Podemos usar un bucle simple para multiplicar nuestras filas de Ventas y observar en qué punto la latencia deja de ser lineal.

-- Ejemplo de duplicación controlada para pruebas de carga
-- Inserta datos de la tabla real en una tabla de staging de gran volumen
INSERT INTO dbo.Ventas_Performance_Test
SELECT 
 NEWID() as ID_Transaccion, -- Generamos nuevo ID para evitar duplicados de clave si aplica
 Producto_Key, 
 Cliente_Key, 
 Fecha_Key, 
 Unidades, 
 Importe * 1.05 -- Variamos ligeramente los datos
FROM dbo.Ventas_Real
WHERE Fecha_Key >= 20230101;

Un aspecto que suelo encontrar en consultoría es que el rendimiento se degrada no por el Warehouse, sino por una mala configuración de la capa semántica. Si usamos DirectQuery, debemos ser extremadamente cautelosos. Como se explica en la guía sobre patrones DAX que destruyen el rendimiento en DirectQuery, cada interacción visual genera una consulta SQL al Warehouse. Multiplicar 20 visuales por 50 usuarios concurrentes puede colapsar cualquier capacidad si no hemos optimizado la base.

Checklist para tus pruebas de rendimiento en Fabric

• Aislamiento: ¿Estás ejecutando la prueba en una capacidad sin interferencia de otros procesos?
• V-Order: ¿Has verificado que las tablas de destino tienen el V-Order habilitado para optimizar la lectura desde OneLake?
• Métricas de CU: ¿Has consultado la App de métricas para ver el impacto real en la capacidad (Interactive vs. Background)?
• Planes de ejecución: ¿Has identificado operadores de movimiento de datos (Broadcast, Shuffle) que se puedan evitar con un mejor diseño de tablas?
• Concurrencia: ¿Has probado el comportamiento con múltiples consultas simultáneas o solo de forma secuencial?

En conclusión, las pruebas de rendimiento en Fabric Warehouse requieren un cambio de mentalidad. El objetivo no es solo que la consulta sea rápida, sino que sea eficiente en el uso de recursos compartidos. Una metodología basada en datos, DMVs y un profundo conocimiento de la arquitectura distribuida es lo único que garantiza que tu solución de BI sea escalable y sostenible a largo plazo.

Preguntas frecuentes

¿Por qué mis pruebas de rendimiento varían entre ejecuciones?

Principalmente por la caché y la gestión compartida de recursos. La primera ejecución lee de OneLake (fría), mientras que las siguientes pueden usar la caché de datos en el nodo de cómputo. Además, si otros procesos en la misma capacidad están activos, el programador de tareas de Fabric puede asignar menos recursos a tu consulta de forma dinámica.

¿Es mejor usar Warehouse o Lakehouse para el rendimiento de las consultas?

Depende del perfil de carga. El Warehouse ofrece un motor SQL completo con optimizaciones automáticas y es ideal para analistas SQL. El Lakehouse, vía SQL Analytics Endpoint, es excelente para consultas rápidas sobre datos procesados por Spark. Para transformaciones complejas y grandes volúmenes con ACID, el Warehouse suele ser más robusto en la gestión de recursos SQL.

¿Cómo puedo saber si mi consulta está provocando Throttling?

Debes monitorizar la columna status en sys.dm_exec_requests y cruzar los datos con la Fabric Capacity Metrics App. Si ves que el «Burn Rate» de tu capacidad está al 100% y tus consultas pasan a estado suspendido o tardan mucho más de lo habitual, es probable que la capacidad esté limitando tu ejecución por exceso de consumo previo.