Dominando el monitoreo en Microsoft Fabric Data Warehouse

Introducción

El monitoreo de un Data Warehouse en Microsoft Fabric no consiste únicamente en saber si una consulta ha fallado. En un entorno analítico real, necesitas responder preguntas como:

¿Qué consultas están consumiendo más tiempo?
¿Qué usuarios o procesos generan más actividad?
¿Hay consultas recurrentes que conviene optimizar?
¿La capacidad de Fabric está mostrando señales de saturación?
¿Los tiempos de carga y transformación siguen siendo aceptables?

Microsoft Fabric Data Warehouse ofrece varias superficies de observabilidad que conviene entender de forma conjunta: vistas de actividad, vistas de sistema para análisis histórico, DMVs compatibles y métricas de capacidad. No todas resuelven el mismo problema, y esa distinción es clave para diseñar una estrategia de monitoreo útil.

Nota: Este artículo se centra en Microsoft Fabric Data Warehouse. Algunas recomendaciones pueden aplicar también al SQL analytics endpoint de un Lakehouse, pero las capacidades concretas deben validarse en cada tipo de elemento.

Qué significa monitorear un Data Warehouse en Fabric

En Fabric, el monitoreo de un Data Warehouse suele cubrir cuatro dimensiones principales:

Actividad operativa: saber qué consultas se están ejecutando, cuáles han finalizado y cuáles han fallado.
Rendimiento de consultas: identificar consultas lentas, frecuentes o candidatas a optimización.
Consumo de capacidad: entender el impacto de las cargas de trabajo sobre la capacidad de Fabric.
Confiabilidad de procesos: revisar cargas, transformaciones y operaciones recurrentes para detectar desviaciones.

Es importante no mezclar conceptos. Fabric Data Warehouse no debe tratarse como si fuera una instancia tradicional de SQL Server administrada por el cliente. La plataforma abstrae buena parte de la infraestructura, por lo que el foco del monitoreo se desplaza hacia la actividad SQL, el comportamiento de las consultas y el consumo de capacidad.

Superficies de monitoreo disponibles

1. Vista de actividad de consultas del Warehouse

Una de las formas más directas de revisar lo que ocurre en un Warehouse es utilizar las capacidades de actividad de consultas disponibles desde la experiencia de Fabric.

Esta vista resulta útil para tareas operativas como:

Revisar consultas en ejecución.
Consultar el estado de consultas recientes.
Identificar consultas con errores.
Analizar duraciones elevadas.
Ver qué actividad está asociada a usuarios o procesos concretos, según la información disponible en el entorno.

Es una herramienta especialmente útil durante investigación de incidencias: por ejemplo, cuando un usuario reporta lentitud o cuando una carga programada tarda más de lo habitual.

2. Query Insights

Query Insights permite analizar el comportamiento histórico de las consultas en Fabric Data Warehouse mediante vistas de sistema. Es una de las capacidades más relevantes para pasar de un monitoreo reactivo a un análisis más sistemático.

Entre los casos de uso más habituales están:

Encontrar consultas de larga duración.
Detectar consultas ejecutadas con mucha frecuencia.
Revisar historial de solicitudes SQL.
Analizar patrones de rendimiento a lo largo del tiempo.
Priorizar qué consultas optimizar primero.

Antes de crear consultas de análisis complejas, es recomendable inspeccionar las vistas y columnas disponibles en el entorno:

SELECT
    TABLE_SCHEMA,
    TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'queryinsights'
ORDER BY TABLE_NAME;

Para revisar la estructura de una vista concreta:

SELECT
    COLUMN_NAME,
    DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'queryinsights'
  AND TABLE_NAME = 'exec_requests_history'
ORDER BY ORDINAL_POSITION;

A partir de ahí, se pueden explorar las vistas de Query Insights:

SELECT TOP (100)
    *
FROM queryinsights.exec_requests_history;

También puedes revisar las consultas de mayor duración si la vista está disponible en tu entorno:

SELECT TOP (50)
    *
FROM queryinsights.long_running_queries;

Y analizar consultas frecuentes:

SELECT TOP (50)
    *
FROM queryinsights.frequently_run_queries;

Recomendación: evita construir automatizaciones críticas basadas en nombres de columnas no verificados. Primero inspecciona el esquema disponible en tu tenant y después ajusta las consultas de monitoreo.

3. DMVs para actividad en curso

Fabric Data Warehouse expone determinadas vistas dinámicas de administración compatibles con T-SQL. Estas vistas ayudan a revisar actividad actual, sesiones y solicitudes.

Por ejemplo, para inspeccionar solicitudes activas:

SELECT TOP (50)
    *
FROM sys.dm_exec_requests;

Para revisar sesiones:

SELECT TOP (50)
    *
FROM sys.dm_exec_sessions;

Si necesitas relacionar sesiones y solicitudes, puedes partir de una consulta como esta y adaptarla a las columnas disponibles:

SELECT TOP (50)
    r.session_id,
    r.status,
    r.command,
    r.start_time,
    r.total_elapsed_time,
    s.login_name,
    s.host_name
FROM sys.dm_exec_requests AS r
LEFT JOIN sys.dm_exec_sessions AS s
    ON r.session_id = s.session_id
ORDER BY r.total_elapsed_time DESC;

Estas consultas son útiles para diagnóstico inmediato. Para análisis histórico, Query Insights suele ser más adecuado.

4. Métricas de capacidad de Fabric

El rendimiento percibido de un Warehouse no depende solo de una consulta individual. También influye el estado de la capacidad de Fabric donde se ejecuta la carga.

Para administradores de plataforma, la aplicación de métricas de capacidad de Microsoft Fabric es una pieza importante porque permite analizar aspectos como:

Uso de capacidad.
Tendencias de consumo.
Operaciones interactivas y en segundo plano.
Posibles señales de saturación o throttling.
Distribución del consumo entre cargas de trabajo.

Este nivel de monitoreo es especialmente relevante cuando varios equipos comparten la misma capacidad o cuando conviven cargas de Power BI, Data Engineering, Data Factory y Data Warehouse.

Ejemplo práctico: investigar consultas lentas

Supongamos que varios usuarios indican que un informe basado en el Warehouse tarda más de lo habitual. Un enfoque razonable sería combinar revisión operativa e histórica.

Paso 1: comprobar actividad actual

Primero revisa si hay consultas activas que estén tardando demasiado:

SELECT TOP (50)
    *
FROM sys.dm_exec_requests
ORDER BY total_elapsed_time DESC;

Si el problema está ocurriendo en ese momento, esta consulta puede ayudarte a detectar actividad anómala o solicitudes de larga duración.

Paso 2: revisar histórico de solicitudes

Después, consulta el historial disponible mediante Query Insights:

SELECT TOP (100)
    *
FROM queryinsights.exec_requests_history;

A partir de las columnas disponibles en tu entorno, puedes filtrar por ventana temporal, estado, usuario, duración o texto de consulta si la vista expone esa información.

Paso 3: identificar consultas candidatas a optimización

Consulta las vistas agregadas para priorizar:

SELECT TOP (50)
    *
FROM queryinsights.long_running_queries;

SELECT TOP (50)
    *
FROM queryinsights.frequently_run_queries;

Una consulta que tarda mucho y se ejecuta pocas veces puede tener una prioridad distinta a una consulta moderadamente lenta que se ejecuta cientos de veces al día.

Paso 4: revisar el diseño y el patrón de acceso

Una vez identificadas las consultas problemáticas, revisa aspectos como:

Predicados y filtros aplicados.
Joins innecesarios o excesivamente amplios.
Consultas que leen muchas más columnas de las necesarias.
Transformaciones repetidas que podrían materializarse previamente.
Modelado de tablas y granularidad de datos.
Uso de objetos intermedios para simplificar consultas complejas.

En Fabric Data Warehouse, como en cualquier plataforma analítica, la optimización no consiste solo en “hacer más rápida una consulta”, sino en reducir trabajo innecesario y alinear el diseño del modelo con los patrones reales de consumo.

Monitoreo de cargas y procesos recurrentes

Además de las consultas interactivas, muchos Warehouses reciben datos mediante procesos programados: pipelines, notebooks, Dataflows Gen2 u otros mecanismos de ingesta y transformación.

Para estos escenarios conviene revisar:

Duración de cargas.
Frecuencia de fallos.
Volumen cargado.
Cambios bruscos en tiempos de ejecución.
Dependencias entre procesos.
Horarios de mayor concurrencia.

El monitoreo del Warehouse debe coordinarse con el monitoreo de los procesos que lo alimentan. Si una tabla llega tarde, incompleta o con un volumen inesperado, el problema puede aparecer en el Warehouse aunque su origen esté en una etapa previa del flujo de datos.

Calidad de datos: necesaria, pero no sustituye al monitoreo

La calidad de datos no debe confundirse con monitoreo de infraestructura o rendimiento. Fabric Data Warehouse puede ayudarte a observar actividad y rendimiento, pero la validación funcional de los datos requiere controles adicionales.

Algunos controles recomendables son:

Recuentos de filas por lote.
Validación de claves y duplicados.
Comprobaciones de nulos en columnas críticas.
Comparación de totales contra sistemas origen.
Reglas de negocio sobre rangos, estados o fechas.
Tablas de auditoría para cargas y transformaciones.

Por ejemplo, puedes mantener una tabla de auditoría de cargas:

CREATE TABLE dbo.LoadAudit
(
    LoadId VARCHAR(100) NOT NULL,
    ProcessName VARCHAR(200) NOT NULL,
    StartTime DATETIME2(6) NOT NULL,
    EndTime DATETIME2(6) NULL,
    Status VARCHAR(50) NOT NULL,
    RowsInserted BIGINT NULL,
    RowsUpdated BIGINT NULL,
    ErrorMessage VARCHAR(4000) NULL
);

Y consultar procesos fallidos o incompletos:

SELECT TOP (100)
    *
FROM dbo.LoadAudit
WHERE Status <> 'Succeeded'
ORDER BY StartTime DESC;

Este tipo de auditoría complementa la observabilidad técnica y ayuda a responder una pregunta distinta: no solo si el sistema ejecutó una operación, sino si el resultado fue correcto desde el punto de vista del negocio.

Buenas prácticas para monitorear Fabric Data Warehouse

1. Separa monitoreo operativo y análisis histórico

Usa la actividad de consultas y las DMVs para diagnóstico inmediato. Usa Query Insights para análisis de tendencias, priorización de optimizaciones y revisión periódica.

2. Define umbrales realistas

No todas las consultas deben durar lo mismo. Una consulta exploratoria compleja puede tardar más que una consulta usada por un informe ejecutivo. Define umbrales por tipo de carga:

Consultas interactivas.
Informes recurrentes.
Procesos de carga.
Transformaciones pesadas.
Consultas ad hoc de análisis.

3. Revisa la capacidad, no solo el Warehouse

Si varios equipos comparten capacidad, una degradación de rendimiento puede estar relacionada con otras cargas de trabajo. Incluye las métricas de capacidad en el diagnóstico.

4. Prioriza por impacto

No optimices únicamente la consulta más lenta. Prioriza combinando:

Duración.
Frecuencia.
Usuarios afectados.
Importancia del proceso.
Ventana horaria.
Consumo relativo de capacidad.

5. Mantén consultas de diagnóstico versionadas

Conviene disponer de un pequeño conjunto de consultas T-SQL revisadas y versionadas para diagnóstico. Por ejemplo:

Actividad actual.
Consultas históricas de larga duración.
Consultas frecuentes.
Sesiones activas.
Auditoría de cargas.
Procesos fallidos.

Esto reduce el tiempo de respuesta durante incidencias y evita improvisar consultas bajo presión.

6. Documenta patrones normales

El monitoreo solo es útil si puedes distinguir lo normal de lo anómalo. Documenta valores de referencia:

Duración habitual de cargas.
Horarios de mayor actividad.
Consultas críticas.
Procesos que no deben solaparse.
Volúmenes esperados por día o por lote.

Errores comunes que conviene evitar

Asumir que existe una única consola de monitoreo para todo

Fabric proporciona distintas experiencias y vistas según el tipo de información que necesitas. No conviene reducirlo todo a una única pantalla.

Confundir métricas de capacidad con métricas de consulta

Las métricas de capacidad ayudan a entender el consumo global. Query Insights y las vistas de actividad ayudan a entender el comportamiento de consultas concretas. Ambas perspectivas son complementarias.

Automatizar sobre columnas no validadas

Antes de construir informes o alertas basadas en vistas de sistema, valida las columnas disponibles en tu entorno. Las consultas de diagnóstico deben ser explícitas y mantenibles.

Ignorar procesos de ingesta

Una parte importante de los problemas percibidos en un Warehouse se origina antes de que el dato llegue a las tablas finales. Monitorea también pipelines, transformaciones y controles de calidad.

Conclusión

Monitorear Microsoft Fabric Data Warehouse requiere combinar varias capas: actividad de consultas, Query Insights, DMVs, métricas de capacidad y controles propios de calidad y auditoría. Ninguna de estas piezas por sí sola ofrece una visión completa.

Una estrategia sólida debería permitirte:

Detectar consultas lentas o fallidas.
Analizar tendencias históricas.
Priorizar optimizaciones por impacto.
Entender la presión sobre la capacidad.
Validar que los procesos de carga producen datos correctos.

El objetivo no es acumular dashboards, sino reducir el tiempo de diagnóstico y mejorar la confiabilidad de la plataforma analítica. En entornos Fabric con varios equipos y cargas de trabajo compartidas, esta disciplina marca la diferencia entre reaccionar ante incidencias y operar el Data Warehouse con control.