Comment valider les données dans Microsoft Fabric

Un guide pratique de la validation de la qualité des données dans Microsoft Fabric — Warehouse et point de terminaison analytique SQL du Lakehouse, le T-SQL des six contrôles essentiels, le piège de la synchronisation des métadonnées, et comment exécuter le tout sous forme de contrat de données versionné.

2026-08-30 · 10 min read

Pour valider les données dans Microsoft Fabric, connectez-vous au Warehouse ou au point de terminaison analytique SQL du Lakehouse via le protocole T-SQL standard, exprimez chaque attente sous forme de requête d'agrégation renvoyant un nombre de violations, et exécutez le lot après chaque pipeline. Les six contrôles qui comptent sont les mêmes partout — valeurs nulles, clés en double, valeurs non autorisées, nombres hors plage, chaînes malformées, lignes périmées —, mais Fabric ajoute deux modes de défaillance dont les contrôles doivent tenir compte : les métadonnées du point de terminaison SQL peuvent être en retard sur ce que OneLake contient réellement, et la surface T-SQL est délibérément plus étroite que celle de SQL Server.

À quoi vous vous connectez réellement

Fabric expose trois objets qui parlent SQL, et les différences comptent pour la validation :

• Warehouse — T-SQL en lecture/écriture sur des tables Delta dans OneLake. DML complet.
• Point de terminaison analytique SQL du Lakehouse — une vue T-SQL en lecture seule sur les tables Delta du Lakehouse, tenue à jour automatiquement.
• Bases de données mises en miroir — des sources répliquées, exposées par le même point de terminaison en lecture seule.

Les trois parlent le protocole TDS : n'importe quel client SQL Server s'y connecte. Les trois sont en lecture seule, ou majoritairement en lecture, du point de vue d'un outil de validation, ce qui est exactement ce que l'on veut. Catalyst traite Fabric comme un type de connexion à part entière plutôt que de réutiliser celui de SQL Server, parce que le modèle d'authentification et les limites du dialecte diffèrent. Si vous partez de zéro, le guide complet de la validation des données couvre ce qui est identique sur tous les moteurs ; ce guide-ci couvre ce que Fabric fait différemment.

Le piège de la synchronisation des métadonnées

C'est le point propre à Fabric qu'il faut comprendre. Lorsqu'un job Spark ou un pipeline écrit une table Delta dans un Lakehouse, le point de terminaison analytique SQL découvre le changement de façon asynchrone. Pendant une courte fenêtre, il peut rapporter l'état précédent de la table — d'anciens nombres de lignes, et parfois une table qui n'existe pas encore.

Conséquence pour la validation : un contrôle qui se déclenche immédiatement à la fin d'un notebook peut lire les métadonnées d'avant l'écriture et signaler un faux succès, ce qui est pire qu'un faux échec. Deux parades :

1. Déclencher la validation depuis l'activité de fin du pipeline, avec un court délai, plutôt que depuis le notebook lui-même.
2. Ajouter une règle de fraîcheur au niveau des lignes à côté de toute règle fondée sur les métadonnées, pour qu'un point de terminaison en retard se manifeste par un échec d'actualité plutôt que par du silence.

Les six contrôles dont toute table a besoin

Le T-SQL de Fabric a les mêmes limites fondamentales que celui de SQL Server — pas d'opérateur d'expression régulière, TOP n au lieu de LIMIT n, citation par crochets —, plus quelques-unes qui lui sont propres : pas de MERGE sur le point de terminaison en lecture, et un jeu de fonctions intégrées plus restreint que celui d'une instance SQL Server complète.

1. Complétude — valeurs nulles dans les colonnes obligatoires

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

COUNT_BIG plutôt que COUNT : les entrepôts Fabric hébergent sans difficulté des tables de faits qui dépassent la limite de 2,1 milliards de lignes de l'int.

2. Unicité — clés métier en double

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 ne prend en charge les contraintes PRIMARY KEY et UNIQUE que sous forme de métadonnées NOT ENFORCED destinées à l'optimiseur. Elles ne rejettent pas les doublons. Si un pipeline rejoue une partition, les doublons atterrissent, la contrainte continue d'affirmer l'unicité, et l'optimiseur peut même produire des résultats faux en lui faisant confiance. Ici, valider l'unicité explicitement n'est pas une redondance — c'est la seule contrainte qui existe réellement.

3. Conformité — valeurs hors de l'ensemble autorisé

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

Gardez la protection contre les valeurs nulles : NULL NOT IN (...) vaut UNKNOWN et la ligne disparaît du compte.

4. Exactitude — nombres hors d'une plage plausible

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

Delta stocke les décimaux fidèlement : utilisez donc decimal pour les montants plutôt que float. Surveillez la dérive de schéma côté Spark : un notebook qui écrit une colonne en double un jour et en decimal le lendemain changera le type de la colonne au niveau du point de terminaison SQL, et un contrôle de plage qui comparait proprement se met à comparer avec une erreur d'arrondi.

5. Conformité — identifiants malformés

Il n'y a pas d'expressions régulières. Comme sur SQL Server, les motifs ancrés de forme fixe se traduisent en LIKE avec des classes de caractères :

-- ^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]';

Tout ce qui fait intervenir une alternative, un groupe facultatif ou une répétition non bornée est inexprimable. Catalyst traduit une règle regex en LIKE lorsque le motif le permet et signale une erreur explicite de dialecte non pris en charge dans le cas contraire — le contrôle remonte donc comme une erreur plutôt que de passer en silence. Pour les motifs réellement complexes, faites la validation dans le notebook Spark qui écrit la table, où vous disposez d'un vrai moteur d'expressions régulières, et conservez une règle LIKE ou validValues plus grossière au niveau SQL comme filet de sécurité.

6. Ponctualité — fraîcheur

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

SYSUTCDATETIME() plutôt que GETDATE(), pour que le contrôle ne dérive ni avec la région de la capacité ni avec l'heure d'été.

Accès et authentification

Fabric s'authentifie via Microsoft Entra ID plutôt que par des connexions SQL. Pour un validateur automatisé, utilisez un principal de service :

1. Enregistrez une application dans Entra ID et créez un secret client.
2. Ajoutez le principal de service à l'espace de travail Fabric avec le rôle Viewer — suffisant pour lire depuis le point de terminaison SQL, insuffisant pour modifier quoi que ce soit.
3. Accordez SELECT sur des schémas précis si vous voulez un périmètre plus étroit qu'une lecture sur tout l'espace de travail.
4. Assurez-vous que le paramètre de locataire autorisant les principaux de service à utiliser les API Fabric est activé — il est désactivé par défaut dans beaucoup de locataires, et c'est la cause habituelle d'un échec de connexion autrement inexplicable.

Catalyst stocke le secret client chiffré et se connecte en lecture seule ; seuls des métadonnées et des résultats de contrôles quittent l'espace de travail.

La capacité mérite également réflexion. Les requêtes de validation consomment des Capacity Units du même pool que tout le reste de l'espace de travail. Une grosse suite de parcours complets de tables exécutée toutes les quinze minutes sur une capacité F2 va brider vos rapports. Limitez les contrôles à une partition quand c'est possible, et échelonnez les planifications.

Du SQL ponctuel au contrat de données

Déclarer les attentes les rend relisibles et portables sur les trois surfaces Fabric. Catalyst utilise l'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 règle rowCount au niveau de la table gagne particulièrement sa place dans Fabric : un résultat vide après l'exécution d'un pipeline est le symptôme classique d'une écriture Delta atterrie au mauvais endroit, et c'est le contrôle le plus susceptible de se déclencher quand le point de terminaison SQL et OneLake divergent.

Catalyst importe les colonnes depuis INFORMATION_SCHEMA.COLUMNS, compile chaque règle en T-SQL conforme à Fabric, et enregistre pass, warn ou fail pour chaque contrôle. Le YAML fait l'aller-retour avec le constructeur visuel, si bien que le contrat présent dans votre dépôt est celui qui s'exécute.

Pièges Fabric à connaître

Planification et alertes

Rattachez la validation à la fin du pipeline Data Factory qui produit la table, avec une courte marge pour laisser le point de terminaison SQL se mettre à jour. Alertez sur le passage en échec plutôt que sur l'état persistant, et réservez la gravité error aux règles qui doivent réellement arrêter une actualisation Power BI en aval — un modèle sémantique reconstruit au-dessus d'un chargement défaillant est la façon dont des données fausses arrivent jusqu'à un tableau de bord de direction.

Questions fréquentes

Puis-je utiliser des outils SQL Server pour valider des données Microsoft Fabric ?

En grande partie. Le Warehouse et le point de terminaison analytique SQL de Fabric parlent le protocole TDS : les clients et pilotes SQL Server s'y connectent. Les différences portent sur l'authentification (Entra ID plutôt que des connexions SQL), sur une surface T-SQL plus étroite sur le point de terminaison en lecture seule, et sur des contraintes non appliquées. Les règles écrites pour SQL Server se portent généralement sans modification.

Pourquoi des doublons apparaissent-ils alors que ma table Fabric a une clé primaire ?

Parce que les contraintes Fabric sont déclarées NOT ENFORCED — elles renseignent l'optimiseur de requêtes mais ne rejettent aucune ligne. Un pipeline rejoué écrira volontiers des clés en double. Validez l'unicité explicitement avec une règle duplicateCount ; c'est la seule contrainte présente.

Comment exécuter un contrôle par expression régulière dans Fabric ?

C'est impossible au niveau SQL — T-SQL n'a pas d'opérateur d'expression régulière. Les motifs ancrés de longueur fixe peuvent être réécrits en LIKE avec des classes de type [0-9]. Pour tout ce qui est plus complexe, faites la validation de motif dans le notebook Spark qui écrit la table, et gardez une règle LIKE ou validValues plus grossière au point de terminaison SQL comme filet de sécurité.

De quelles permissions un principal de service de validation a-t-il besoin ?

Le rôle Viewer sur l'espace de travail suffit normalement pour lire depuis le point de terminaison analytique SQL, en plus du paramètre de locataire autorisant les principaux de service à utiliser les API Fabric. Accordez SELECT sur des schémas précis si vous voulez un périmètre plus serré. Aucune permission d'écriture n'est requise — chaque contrôle est un SELECT d'agrégation.

La validation consomme-t-elle de la capacité Fabric ?

Oui. Les requêtes s'exécutent sur les Capacity Units de votre capacité, dans le même pool que les pipelines et les actualisations Power BI. Gardez les contrôles limités à une colonne et à une partition quand c'est possible, et échelonnez les planifications pour qu'un balayage de validation n'entre pas en collision avec l'actualisation des rapports du matin.