Cómo validar datos en Microsoft Fabric

Guía práctica para validar la calidad de datos en Microsoft Fabric — Warehouse y el SQL analytics endpoint del Lakehouse, el T-SQL para escribir las seis comprobaciones esenciales, la trampa de la sincronización de metadatos y cómo ejecutarlo todo como un contrato de datos versionado.

2026-08-30 · 9 min read

Para validar datos en Microsoft Fabric, conéctate al Warehouse o al SQL analytics endpoint del Lakehouse mediante el protocolo T-SQL estándar, expresa cada expectativa como una consulta de agregación que devuelva un recuento de violaciones y ejecuta el lote después de cada pipeline. Las seis comprobaciones que importan son las mismas en todas partes —nulos, claves duplicadas, valores no permitidos, números fuera de rango, cadenas mal formadas, filas obsoletas—, pero Fabric añade dos modos de fallo que las comprobaciones tienen que tener en cuenta: los metadatos del endpoint SQL pueden ir por detrás de lo que OneLake contiene en realidad, y la superficie de T-SQL es deliberadamente más estrecha que la de SQL Server.

A qué te estás conectando en realidad

Fabric expone tres cosas que hablan SQL, y las diferencias importan para la validación:

Warehouse: T-SQL de lectura y escritura sobre tablas Delta en OneLake. DML completo.
SQL analytics endpoint del Lakehouse: una vista T-SQL de solo lectura sobre las tablas Delta del Lakehouse, mantenida sincronizada de forma automática.
Bases de datos replicadas (mirrored): fuentes replicadas, expuestas a través del mismo endpoint de solo lectura.

Las tres hablan el protocolo TDS, así que cualquier cliente de SQL Server se conecta a ellas. Las tres son de solo lectura o casi solo lectura desde el punto de vista de una herramienta de validación, que es exactamente lo que quieres. Catalyst trata Fabric como un tipo de conexión propio en lugar de reutilizar el de SQL Server, porque el modelo de autenticación y los límites del dialecto son distintos. Si partes de cero, la guía completa para validar datos cubre lo que es igual en todos los motores; esta guía cubre lo que Fabric hace de otra manera.

La trampa de la sincronización de metadatos

Esto es lo específico de Fabric que hay que entender. Cuando un job de Spark o un pipeline escribe una tabla Delta en un Lakehouse, el SQL analytics endpoint descubre el cambio de forma asíncrona. Durante una ventana breve, el endpoint puede informar del estado anterior de la tabla: recuentos de filas antiguos y, de vez en cuando, una tabla que todavía no existe.

La consecuencia para la validación: una comprobación que salta inmediatamente al terminar un notebook puede leer metadatos previos a la escritura e informar de un falso aprobado, que es peor que un falso fallo. Dos mitigaciones:

Dispara la validación desde la actividad de finalización del pipeline con un pequeño retardo, en lugar de desde el propio notebook.
Incluye una regla de frescura a nivel de fila junto a cualquier regla basada en metadatos, de modo que un endpoint desactualizado se manifieste como un fallo de actualidad y no como silencio.

Las seis comprobaciones que necesita toda tabla

El T-SQL de Fabric tiene los mismos límites fundamentales que el de SQL Server —ningún operador de expresiones regulares, TOP n en lugar de LIMIT n, entrecomillado con corchetes— más algunos propios: nada de MERGE en el endpoint de lectura y un conjunto de funciones integradas más estrecho que el de una instancia completa de SQL Server.

1. Completitud — nulos en columnas obligatorias

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [order_id] IS NULL;

COUNT_BIG en lugar de COUNT: los warehouses de Fabric albergan tablas de hechos que superan con comodidad el límite de 2.100 millones de filas del tipo int.

2. Unicidad — claves de negocio duplicadas

SELECT COUNT_BIG(*) AS violations
FROM (
    SELECT [order_id]
    FROM [dbo].[orders]
    WHERE [order_id] IS NOT NULL
    GROUP BY [order_id]
    HAVING COUNT(*) > 1
) AS dupes;

Fabric Warehouse soporta las restricciones PRIMARY KEY y UNIQUE solo como metadatos NOT ENFORCED para el optimizador. No rechazan duplicados. Si un pipeline vuelve a ejecutar una partición, los duplicados aterrizan, la restricción sigue afirmando unicidad y el optimizador puede incluso producir resultados erróneos por fiarse de ella. Aquí validar la unicidad de forma explícita no es redundancia: es la única aplicación que existe.

3. Conformidad — valores fuera de un conjunto permitido

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [status] IS NOT NULL
  AND [status] NOT IN ('pending', 'paid', 'shipped', 'refunded');

Mantén la protección frente a nulos: NULL NOT IN (...) es UNKNOWN y la fila desaparece del recuento.

4. Exactitud — números fuera de un rango plausible

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [total_amount] IS NOT NULL
  AND ([total_amount] < 0 OR [total_amount] > 100000);

Delta almacena los decimales con fidelidad, así que usa decimal para el dinero en vez de float. Ojo con la deriva de esquema del lado de Spark: un notebook que un día escribe una columna como double y al siguiente como decimal cambiará el tipo de la columna en el endpoint SQL, y una comprobación de rango que antes comparaba limpiamente empieza a comparar con error de redondeo.

5. Conformidad — identificadores mal formados

No hay expresiones regulares. Igual que en SQL Server, los patrones anclados de forma fija se traducen a LIKE con clases de caracteres:

-- ^ORD-[0-9]{6}$  becomes:
SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [reference] IS NOT NULL
  AND [reference] NOT LIKE 'ORD-[0-9][0-9][0-9][0-9][0-9][0-9]';

Nada que implique alternancia, grupos opcionales o repetición no acotada se puede expresar. Catalyst traduce una regla regex a LIKE cuando el patrón lo permite e informa de un error explícito de dialecto no soportado cuando no, de modo que la comprobación aflora como error en lugar de pasar en silencio. Para patrones genuinamente complejos, haz la validación en el notebook de Spark que escribe la tabla, donde tienes un motor de expresiones regulares de verdad, y conserva una regla LIKE o validValues más gruesa en la capa SQL como red de seguridad.

6. Oportunidad — frescura

SELECT COUNT_BIG(*) AS violations
FROM [dbo].[orders]
WHERE [created_at] < DATEADD(HOUR, -24, SYSUTCDATETIME());

SYSUTCDATETIME() en lugar de GETDATE(), para que la comprobación no derive con la región de la capacidad ni con el horario de verano.

Acceso y autenticación

Fabric autentica mediante Microsoft Entra ID y no con inicios de sesión de SQL. Para un validador automatizado, usa un service principal:

Registra una aplicación en Entra ID y crea un secreto de cliente.
Añade el service principal al workspace de Fabric con el rol Viewer: suficiente para leer del endpoint SQL, insuficiente para cambiar nada.
Concede SELECT sobre los esquemas concretos si quieres un alcance más estrecho que la lectura de todo el workspace.
Asegúrate de que está habilitada la configuración de inquilino que permite a los service principals usar las API de Fabric: viene desactivada por defecto en muchos inquilinos y es la causa habitual de un fallo de inicio de sesión por lo demás inexplicable.

Catalyst guarda el secreto de cliente cifrado y se conecta en modo solo lectura; del espacio de trabajo solo salen metadatos y resultados de comprobaciones.

También merece la pena pensar en la capacidad. Las consultas de validación consumen Capacity Units del mismo bolsón que todo lo demás en el workspace. Una suite grande de escaneos de tablas completas ejecutándose cada quince minutos sobre una capacidad F2 estrangulará tus informes. Acota las comprobaciones a una partición siempre que puedas y escalona las programaciones.

De SQL ad hoc a un contrato de datos

Declarar las expectativas las hace revisables y portables entre las tres superficies de Fabric. Catalyst usa el Open Data Contract Standard:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: fabric-platform
schema:
  - name: orders
    physicalName: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        required: true
        primaryKey: true
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
          - rule: duplicateCount
            dimension: uniqueness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: total_amount
        logicalType: number
        physicalType: decimal(12,2)
        quality:
          - rule: between
            dimension: accuracy
            severity: error
            mustBe: "[0, 100000]"
      - name: reference
        logicalType: string
        quality:
          - rule: regex
            dimension: conformity
            severity: warning
            mustBe: "'^ORD-[0-9]{6}#39;"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"
    quality:
      - rule: rowCount
        dimension: consistency
        severity: error
        mustBe: "> 0"

La regla rowCount a nivel de tabla se gana su sitio especialmente en Fabric: un resultado vacío tras la ejecución de un pipeline es el síntoma clásico de una escritura Delta que aterrizó en la ruta equivocada, y es la comprobación que más probablemente salte cuando el endpoint SQL y OneLake discrepan.

Catalyst importa las columnas desde INFORMATION_SCHEMA.COLUMNS, compila cada regla al T-SQL correcto para Fabric y registra pass, warn o fail por comprobación. El YAML va y vuelve por el constructor visual, así que el contrato que está en tu repositorio es el que se ejecuta.

Trampas de Fabric que conviene conocer

Trampa	Qué ocurre	Qué hacer
Retraso de metadatos del endpoint	La comprobación lee el estado previo a la escritura: falso aprobado	Dispara desde el pipeline y añade frescura a nivel de fila
Claves `NOT ENFORCED`	Los duplicados aterrizan pese a la clave primaria	Añade siempre una regla `duplicateCount`
Sin expresiones regulares en T-SQL	Las reglas de patrón no se pueden expresar	Traduce a `LIKE` o valida en Spark
Deriva de esquema en Spark	El tipo de la columna cambia entre ejecuciones	Fija los tipos en el contrato; alerta sobre la deriva
Service principal bloqueado	El inicio de sesión falla sin error útil	Habilita la configuración de inquilino para las API de Fabric
Estrangulamiento de capacidad	Los informes se ralentizan cuando se ejecutan las comprobaciones	Acota a particiones y escalona las programaciones
`GETDATE()`	Hora local de la capacidad	Usa `SYSUTCDATETIME()`

Programación y alertas

Engancha la validación al final del pipeline de Data Factory que produce la tabla, con un pequeño margen para que el endpoint SQL se ponga al día. Alerta sobre la transición hacia el fallo y no sobre el estado continuado, y reserva la severidad error para las reglas que de verdad deberían detener una actualización de Power BI aguas abajo: un modelo semántico reconstruido sobre una carga fallida es la forma en que los datos malos llegan al dashboard de un directivo.

Preguntas frecuentes

¿Puedo usar herramientas de SQL Server para validar datos de Microsoft Fabric?

En su mayor parte, sí. El Warehouse y el SQL analytics endpoint de Fabric hablan el protocolo TDS, así que los clientes y drivers de SQL Server se conectan. Las diferencias son la autenticación (Entra ID en lugar de inicios de sesión de SQL), una superficie de T-SQL más estrecha en el endpoint de solo lectura y las restricciones no aplicadas. Las reglas escritas para SQL Server se portan por lo general sin cambios.

¿Por qué aparecen duplicados si mi tabla de Fabric tiene clave primaria?

Porque las restricciones de Fabric se declaran NOT ENFORCED: informan al optimizador de consultas, pero no rechazan filas. Un pipeline que se vuelve a ejecutar escribirá claves duplicadas sin inmutarse. Valida la unicidad de forma explícita con una regla duplicateCount; es la única aplicación presente.

¿Cómo ejecuto una comprobación con expresiones regulares en Fabric?

En la capa SQL no puedes: T-SQL no tiene operador de expresiones regulares. Los patrones anclados de longitud fija pueden reescribirse como LIKE con clases del estilo [0-9]. Para cualquier cosa más compleja, haz la validación de patrón en el notebook de Spark que escribe la tabla y conserva una regla LIKE o validValues más gruesa en el endpoint SQL como red de seguridad.

¿Qué permisos necesita un service principal de validación?

El rol Viewer del workspace suele bastar para leer del SQL analytics endpoint, además de la configuración de inquilino que permite a los service principals usar las API de Fabric. Concede SELECT sobre esquemas concretos si quieres un alcance más ajustado. No hace falta permiso de escritura: cada comprobación es un SELECT de agregación.

¿La validación consume capacidad de Fabric?

Sí. Las consultas se ejecutan contra las Capacity Units de tu capacidad, en el mismo bolsón que los pipelines y las actualizaciones de Power BI. Mantén las comprobaciones acotadas a columnas y a particiones siempre que puedas, y escalona las programaciones para que un barrido de validación no choque con la actualización de los informes de la mañana.