Suivi de la qualité des données avec Databricks : Le guide 2026

Si vous avez déjà vu un pipeline Delta se terminer proprement alors qu'un tableau de bord en aval affichait encore des chiffres obsolètes, vous savez déjà que le problème n'est pas de savoir si une exécution a eu lieu. Le problème est de savoir si les données étaient sûres à utiliser lors de leur arrivée. Dans les configurations de data quality monitoring Databricks, cet écart apparaît rapidement dans les environnements réglementés, où un travail terminé peut encore contenir des charges incomplètes, des validations différées ou des modifications de schéma silencieuses que personne ne remarque avant qu'un utilisateur métier ne s'en plaigne.

La surveillance native de Databricks offre aux équipes un véritable point de départ, notamment parce qu'elle enregistre les métriques de profil historiques telles que count, num_nulls, avg, min/max, stddev et 1,000 quantiles pour chaque colonne profilée, et compare une table actuelle à une référence ou à des fenêtres successives pour détecter les dérives. Elle s'étend également aux tables d'inférence avec des métriques de ML telles que accuracy_score, log_loss, mean_squared_error, mean_absolute_percentage_error et r2_score. C'est utile, mais ce n'est encore qu'une couche de la pile, pas la pile elle-même, car la détection sans attribution de propriété, routage et barrières de validation des versions n'empêche pas les mauvaises données d'entrer en production. Databricks data quality monitoring documentation

Table des matières

• Quand la surveillance native de Databricks ne suffit plus

  • La fraîcheur et l'exhaustivité sont nécessaires, mais pas suffisantes

  • Ce que le reste de la pile doit ajouter

• Architecture pour une pile de surveillance multicouche

  • Où s'intègrent les modules

• Activation du Unity Catalog Data Quality Monitoring

  • Ce que signifient les états natifs

  • Une séquence de déploiement minimale

• Superposer la validation des enregistrements et la détection d'anomalies

  • Ajouter d'abord des règles déterministes

  • Ajouter l'apprentissage de base pour les colonnes métier

• Combler l'écart de propriété et de lignage

  • Ce que la surveillance native laisse encore en suspens

  • Un flux d'enrichissement pratique

• Alertes, tableaux de bord et barrières CI/CD

  • Acheminer les alertes par propriétaire, et pas seulement par gravité

  • Bloquer les promotions avant qu'elles n'atteignent la production

• Un plan de déploiement sur 90 jours et une liste de contrôle de dépannage

  • Correctifs rapides pour les problèmes les plus fréquents

Quand la surveillance native de Databricks ne suffit plus

Les équipes des secteurs réglementés se heurtent généralement aux limites de la surveillance native après avoir frôlé un incident ou lors d'une revue post-incident. Le scénario est classique. Un moniteur au niveau du schéma est activé, la tâche du tableau de bord se termine comme prévu, et la table semble s'exécuter correctement à première vue. Puis, quelqu'un s'aperçoit que la dernière table Silver pointe toujours vers la version source de la veille, ou qu'un chargement partiel est passé parce que le pipeline a uniquement vérifié l'arrivée des données, et non leur exhaustivité ou leur fiabilité.

La fraîcheur et l'exhaustivité sont nécessaires, mais pas suffisantes

La surveillance intégrée de Databricks se concentre sur la fraîcheur et l'exhaustivité, ce qui constitue une excellente première étape car ces signaux permettent de détecter rapidement les modes de défaillance évidents. Le service apprend les schémas historiques et saisonniers, puis signale les changements inattendus à l'aide de résultats statistiques explicites plutôt que par une inspection manuelle. Il peut également marquer une table comme obsolète lorsque la validation suivante arrive plus tard que prévu par le calendrier d'apprentissage, ou incomplète lorsque le nombre de lignes des dernières 24 heures tombe en dessous de la limite inférieure attendue par le modèle. Ce comportement est logique d'un point de vue opérationnel, mais il laisse un fossé important entre « quelque chose semble anormal » et « cette règle métier spécifique a échoué ».

Le problème pratique est qu'une option d'activation de schéma peut créer une fausse confiance. Une table peut être techniquement présente tout en étant incorrecte pour les rapports, les fonctionnalités de ML ou les extractions réglementaires. Si le pipeline vérifie uniquement l'arrivée et le volume, il manquera une non-correspondance de clé étrangère, une contrainte de nullité rompue ou une valeur structurellement valide mais sémantiquement incorrecte. Les équipes qui ont besoin d'auditabilité doivent superposer des vérifications au niveau des enregistrements, un routage prenant en compte les propriétaires et des preuves qui vont au-delà du simple scan de schéma.

Règle pratique : si un moniteur peut vous dire que des données ont été déplacées, mais pas si ce sont les bons enregistrements qui l'ont été, il signale des symptômes sans garantir la confiance.

Ce que le reste de la pile doit ajouter

Le reste de la conception comble quatre lacunes. Premièrement, la validation au niveau de l'enregistrement permet de saisir les règles métier déterministes. Deuxièmement, les références de ponctualité séparent un retard prévu d'une livraison manquée. Troisièmement, les alertes basées sur le lignage empêchent la mauvaise équipe d'être sollicitée. Quatrièmement, les barrières CI/CD bloquent les mauvaises modifications avant qu'elles n'atteignent les tables de production.

C'est la différence entre un moniteur qui signale des symptômes et une pile d'Observability qui soutient la confiance en production. Dans un déploiement Databricks réel, le point de départ est une approche multicouche construite autour de Unity Catalog, des attentes du pipeline et d'analyses en base de données, plutôt qu'une simple option d'activation dans l'interface utilisateur. Pour un exemple pratique de la façon dont les équipes intègrent ces couches dans un modèle opérationnel unique, consultez le Databricks observability implementation pattern.

Architecture pour une pile de surveillance multicouche

Une configuration de data quality monitoring Databricks en production fonctionne de manière optimale sous forme de pile multicouche. Delta Lake Storage conserve la source de vérité. Unity Catalog assure la governance et la gestion des métadonnées. Delta Live Tables est l'endroit où s'exécutent les contrôles déclaratifs. Le plan d'Observability lit les tables système et les sorties de métriques, tout en conservant les données de production à l'intérieur de l'environnement.

Un mode de défaillance courant consiste à traiter chaque signal comme le même type de problème. Une table en retard, un chargement partiel, une règle métier échouée et un changement de schéma ne nécessitent pas la même réponse, ils ne devraient donc pas partager le même chemin d'alerte. La surveillance native de Databricks est particulièrement performante pour la santé globale de la plateforme, car elle analyse les tables critiques d'un schéma, apprend les modèles historiques et stocke les résultats au sein de l'environnement client. La documentation d'Azure Databricks de Microsoft décrit également les résultats de la surveillance comme une table système avec une conservation gratuite indéfinie, ce qui la rend adaptée aux examens historiques et aux travaux d'audit sur l'ensemble du compte. Azure Databricks system tables for data quality monitoring

La séparation doit rester claire. La surveillance de la plateforme indique si la table est arrivée à temps et avec un volume suffisant pour être digne de confiance. Les attentes du pipeline indiquent si un enregistrement a enfreint une règle. La détection des anomalies indique si une colonne métier s'est écartée de sa référence apprise. Cette répartition permet de maintenir les flux d'astreinte gérables, car chaque incident n'est pas réduit à une défaillance générique.

Où s'intègrent les modules

La carte des modules de digna s'aligne sur cette conception. Data Anomalies couvre l'apprentissage des références et la détection continue des anomalies. Timeliness couvre les fenêtres d'arrivée prévues et les chargements retardés. Data Validation applique les règles au niveau de l'enregistrement. Schema Tracker surveille les dérives structurelles. Cette répartition correspond à l'architecture car le plan d'Observability peut consommer ces signaux sans déplacer de lignes hors du warehouse ou du lake.

Gardez le calcul proche des données. Dans les environnements réglementés, ce n'est pas seulement un choix de performance, c'est la limite qui maintient les enregistrements de production au sein de l'environnement du client.

La valeur du diagramme est opérationnelle, non visuelle. Il montre le flux de contrôle qui fonctionne en production. Le pipeline émet des signaux, le plan d'Observability les évalue et la couche d'alerte décide de ce qui doit être acheminé, supprimé ou remonté. Ce modèle s'adapte à mesure que l'infrastructure grandit, car il évite de centraliser chaque décision dans un moniteur monolithique unique.

Activation du Unity Catalog Data Quality Monitoring

Databricks permet la surveillance au niveau du schéma, plutôt que d'écrire manuellement un contrôle pour chaque table. L'action opérationnelle est simple. Activez le moniteur dans Unity Catalog, laissez s'exécuter la première tâche planifiée, puis inspectez les tables système et les vues de qualité qui en résultent. La cadence par défaut est horaire, et Databricks indique que le test rétrospectif historique intégré peut simuler le moniteur comme s'il avait été activé deux semaines plus tôt, ce qui est un moyen utile d'initialiser une référence avant de faire confiance aux signaux en temps réel. Unity Catalog data quality monitoring rollout details

Ce que signifient les états natifs

Ce modèle d'état est pratique car il fournit aux équipes opérationnelles des éléments concrets sans les obliger à définir des seuils à partir de zéro. La documentation d'Azure Databricks de Microsoft indique que la tâche en arrière-plan surveille la fraîcheur et l'exhaustivité, utilise l'analyse intelligente pour décider quand effectuer un scan, et consigne les problèmes de qualité dans une table qui peut être consultée dans Catalog Explorer ou Governance Hub. Azure Databricks monitoring workflow

Une séquence de déploiement minimale

Commencez par quelques tables Bronze qui alimentent des processus critiques en aval. Activez le moniteur de schéma, laissez la première mise à jour établir une référence, puis inspectez l'historique avant de connecter les alertes. Si vous activez trop de schémas dès le premier jour, chaque faux positif se transformera en réunion de gouvernance.

Un simple contrôle SQL suffit souvent pour commencer :

SELECT schema_name, table_name, monitor_state, last_updated
FROM system.data_quality_monitoring
WHERE monitor_state IN ('stale', 'incomplete');

SELECT schema_name, table_name, monitor_state, last_updated
FROM system.data_quality_monitoring
WHERE monitor_state IN ('stale', 'incomplete');

SELECT schema_name, table_name, monitor_state, last_updated
FROM system.data_quality_monitoring
WHERE monitor_state IN ('stale', 'incomplete');

Cette requête n'est pas destinée à remplacer l'interface utilisateur. Elle vise à donner aux équipes de plateforme un moyen rapide d'inspecter les schémas surveillés et de décider où appliquer la prochaine phase d'optimisation. Une fois la référence stable, la sortie du moniteur devient un simple signal dans la boucle d'incident globale, et non l'intégralité du plan de réponse.

Superposer la validation des enregistrements et la détection d'anomalies

Une table peut arriver à temps, passer un contrôle de schéma, et tout de même perturber l'activité de l'entreprise. Un fichier de réclamation peut se charger correctement, tandis qu'un montant de remboursement devient négatif, qu'un code région obligatoire est manquant, ou qu'un dossier de santé passe à travers avec un identifiant invalide. Les contrôles natifs de fraîcheur et d'exhaustivité détectent le modèle d'arrivée, pas la règle importante pour la finance, la santé ou les opérations. C'est pourquoi la couche suivante est constituée par les attentes de Delta Live Tables, qui maintiennent les contrôles déterministes explicites et versionnés avec le pipeline.

Ajouter d'abord des règles déterministes

Utilisez les attentes DLT pour les conditions qui ne devraient jamais dépendre d'un comportement appris. Les contrôles de valeurs nulles, de plages de valeurs et d'intégrité référentielle sont d'excellents points de départ, car ils échouent rapidement et vous donnent une raison claire d'arrêter ou de mettre en quarantaine les mauvais enregistrements.

CONSTRAINT valid_customer_id EXPECT (customer_id IS NOT NULL),
CONSTRAINT valid_amount EXPECT (amount >= 0),
CONSTRAINT valid_region EXPECT (region IN ('NA', 'EMEA', 'APAC'))

CONSTRAINT valid_customer_id EXPECT (customer_id IS NOT NULL),
CONSTRAINT valid_amount EXPECT (amount >= 0),
CONSTRAINT valid_region EXPECT (region IN ('NA', 'EMEA', 'APAC'))

CONSTRAINT valid_customer_id EXPECT (customer_id IS NOT NULL),
CONSTRAINT valid_amount EXPECT (amount >= 0),
CONSTRAINT valid_region EXPECT (region IN ('NA', 'EMEA', 'APAC'))

Les vérifications multi-tables doivent également être positionnées au plus près des données. Placez la logique dans une jointure au sein du pipeline ou écrivez le résultat dans une table de validation en aval, puis laissez le pipeline décider si un enregistrement est valide. Cela maintient la règle dans le même chemin d'exécution que les données et évite d'envoyer des lignes vers un outil distinct simplement pour répondre à une question binaire.

Ajouter l'apprentissage de base pour les colonnes métier

Une fois les règles déterministes en place, utilisez la détection d'anomalies pour les colonnes dont la forme évolue au fil du temps. Les volumes, les moyennes, les distributions et la saisonnalité sont souvent plus utiles qu'un seuil fixe, en particulier pour les métriques opérationnelles qui dérivent avec les cycles d'activité. La couche de profilage de Databricks stocke des métriques historiques telles que count, num_nulls, avg, min/max, stddev et 1,000 quantiles, ce qui vous donne une série chronologique pour analyser le comportement plutôt qu'un instantané ponctuel. Elle prend également en charge la comparaison par rapport à une référence ou à des fenêtres successives, afin que le plan d'Observability puisse surveiller les dérives sans transférer les données de production hors de l'environnement. Databricks profiling and drift metrics

Un modèle pratique consiste à calculer une référence glissante en base de données et à écrire le score dans une table Delta :

from pyspark.sql import functions as F

baseline = (
    spark.table("gold.orders")
    .groupBy("order_date")
    .agg(F.avg("order_amount").alias("avg_order_amount"))
)

baseline.write.mode("overwrite").saveAsTable("obs.order_amount_baseline")

from pyspark.sql import functions as F

baseline = (
    spark.table("gold.orders")
    .groupBy("order_date")
    .agg(F.avg("order_amount").alias("avg_order_amount"))
)

baseline.write.mode("overwrite").saveAsTable("obs.order_amount_baseline")

from pyspark.sql import functions as F

baseline = (
    spark.table("gold.orders")
    .groupBy("order_date")
    .agg(F.avg("order_amount").alias("avg_order_amount"))
)

baseline.write.mode("overwrite").saveAsTable("obs.order_amount_baseline")

Cette table peut alimenter votre couche d'alerte, un tableau de bord ou un moteur de règles distinct. Si vous souhaitez un flux de travail dédié aux anomalies, digna's anomaly detection approach suit le même modèle, d'abord la référence, ensuite l'alerte, le calcul restant en base de données.

Le contrôle le plus robuste est celui qui ne quitte jamais le warehouse. Dans les charges de travail réglementées, cela compte tout autant que le signal lui-même.

La séparation est pratique. Les attentes DLT imposent ce que vous savez déjà devoir être vrai. Les références capturent ce qui change au fil du temps. Utilisées ensemble, elles couvrent les cas que la surveillance au niveau du schéma ne sait pas évaluer.

Combler l'écart de propriété et de lignage

La détection est généralement la partie la plus simple. Le routage est plus difficile. Un moniteur peut indiquer qu'une table est obsolète ou incomplète, mais il ne vous dit toujours pas qui en est propriétaire, quel flux en amont l'a altérée, ou si l'impact atteint un tableau de bord des revenus, un rapport clinique ou un extrait réglementaire. La surveillance des tables système de Databricks expose les champs d'impact en aval, y compris une échelle de gravité de 0 à 4 (où 4 = très élevé), ainsi que des exemples de champs comme num_downstream_tables = 5 et num_queries_on_affected_tables = 120 au cours des 30 derniers jours. Cela est important car cela vous donne une vision concrète de l'impact, et pas seulement un statut d'échec.

Ce que la surveillance native laisse encore en suspens

Les pièces manquantes sont la gouvernance, la propriété (ownership) et l'actionnabilité. Les équipes ont toujours besoin de niveaux de criticité, de balises de propriété, de tri de lignage et de règles de barrière de version. La documentation d'Azure Databricks de Microsoft est explicite sur le fait que le service natif est centré sur la détection d'anomalies au niveau du schéma pour la fraîcheur et l'exhaustivité, d'autres contrôles étant décrits comme devant être intégrés plus tard, c'est pourquoi la plupart des entreprises superposent encore un plan d'Observability externe. Azure Databricks monitoring scope

Un modèle pratique consiste à enrichir la sortie de la table système avec les métadonnées d'Unity Catalog. Si une table Bronze échoue, l'alerte doit être acheminée vers le propriétaire de la table Bronze, et non vers le consommateur de la table Silver. Si une table Gold régresse, la notification doit être envoyée au propriétaire de la couche de service et inclure les champs d'impact en aval afin que l'équipe d'astreinte puisse évaluer l'urgence avant de remonter le problème. Cela permet de maintenir le moniteur natif dans son rôle et de donner au chemin de réponse suffisamment de contexte pour agir.

Un flux d'enrichissement pratique

1. Extraire les problèmes du moniteur de la table système.

2. Les associer aux balises Unity Catalog pour le propriétaire, la criticité et le domaine.

3. Fusionner les métadonnées de lignage pour identifier les consommateurs en aval.

4. Acheminer les alertes par gravité et importance métier.

Cette jointure transforme un événement de surveillance brut en un enregistrement opérationnel. Elle facilite également les examens d'audit car l'événement apporte du contexte, et pas seulement un état.

Un modèle courant dans les environnements de la finance et du secteur public consiste à traiter le moniteur comme le détecteur et la couche d'alerte comme le moteur de politiques. Cette limite permet de préserver l'utilité de la fonctionnalité native sans prétendre qu'elle peut résoudre seule la responsabilité des données. Cette même séparation laisse également de la place pour les références de ponctualité, la validation en base de données et les barrières CI/CD lorsque la surveillance au niveau du schéma s'avère insuffisante.

Alertes, tableaux de bord et barrières CI/CD

Une fois les métriques générées, l'erreur suivante consiste à les déverser dans un tableau de bord unique et à appeler cela de l'Observability. Cela masque plus de choses que cela n'en révèle. Une vue de la santé de la plateforme doit afficher l'état de l'analyse, l'état du moniteur et la santé de la tâche. Une vue de la santé de l'entreprise doit afficher la fraîcheur, l'exhaustivité et la dérive par rapport aux données utilisées par les consommateurs. Ce sont des publics différents, et ils ont besoin d'alertes différentes.

Acheminer les alertes par propriétaire, et pas seulement par gravité

La logique de routage doit être assez simple pour être expliquée lors d'un audit. D'abord le niveau de criticité, ensuite la balise de propriété, puis le contexte de lignage. Si le problème survient dans Gold et que l'impact en aval est élevé, remontez-le immédiatement. S'il s'agit d'un flux Bronze en amont sans consommateur actif, acheminez-le vers l'équipe propriétaire et évitez de déclencher une alerte sonore à moins que le retard ne persiste.

C'est également là qu'une plateforme comme digna dashboards for data quality s'intègre naturellement. L'intérêt ne réside pas dans l'interface elle-même. Il réside dans la séparation entre les métriques de la plateforme et les métriques métier, car c'est ce qui évite aux opérateurs de traquer le bruit du pipeline lorsque le problème réel est une règle métier rompue.

Bloquer les promotions avant qu'elles n'atteignent la production

La surveillance doit faire partie du pipeline de livraison, et non pas seulement du flux de travail de gestion des incidents. Si une modification de schéma, un échec de validation ou une nouvelle attente rompt un contrôle, la promotion doit être bloquée avant que la modification ne soit appliquée aux tables de production. Les Databricks Asset Bundles peuvent intégrer ce contrôle aux côtés de la définition de la tâche, ce qui est exactement ce que souhaitent les équipes de gouvernance car la preuve est versionnée avec le déploiement.

resources:
  jobs:
    dq_job:
      name: dq_validation
      tasks:
        - task_key: validate
          sql_task:
            query: SELECT 1

resources:
  jobs:
    dq_job:
      name: dq_validation
      tasks:
        - task_key: validate
          sql_task:
            query: SELECT 1

resources:
  jobs:
    dq_job:
      name: dq_validation
      tasks:
        - task_key: validate
          sql_task:
            query: SELECT 1

Cet exemple est volontairement minimal. Dans un déploiement réel, la tâche de validation devrait interroger la table Delta surveillée ou la vue de validation et faire échouer le bundle lorsqu'une règle est enfreinte. L'objectif est d'intégrer la qualité dans l'artefact déployable, plutôt que de l'associer à un tableau de bord après coup que quelqu'un doit penser à vérifier.

Le monitoring-as-code est essentiel dans les environnements réglementés car chaque modification nécessite un contrôle traçable. Si la règle vit dans le pipeline, la piste d'audit y figure également.

Un plan de déploiement sur 90 jours et une liste de contrôle de dépannage

Le moyen le plus rapide de rendre cela opérationnel est de procéder par phases. Les jours 1 à 30 sont consacrés à l'activation de la surveillance Unity Catalog sur un petit ensemble de tables Bronze et à l'ajustement des références. Les jours 31 à 60 sont consacrés à l'ajout de la validation des enregistrements et des contrôles de ponctualité sur les tables Silver. Les jours 61 à 90 servent à intégrer les alertes dans la CI/CD, à associer des niveaux de criticité et à acheminer les incidents vers les propriétaires.

Correctifs rapides pour les problèmes les plus fréquents

• Écarts d'historique (backfill). Exécutez à nouveau le moniteur une fois le chargement historique terminé, puis traitez la première fenêtre propre comme la nouvelle référence.

• Fausses alertes de fraîcheur après une évolution de schéma. Vérifiez si la planification apprise correspond toujours au nouveau rythme de validation, puis réinitialisez la référence du moniteur.

• Gravités bloquées à 0. Confirmez que les métadonnées d'impact en aval et le lignage sont renseignés, car l'absence de zone d'impact signifie qu'aucune gravité significative ne peut être établie.

• Tables de lignage n'affichant aucun élément en aval. Vérifiez le lignage d'Unity Catalog et l'enregistrement des tables avant de vous fier au graphique.

• Alertes envoyées à la mauvaise équipe. Révisez les balises de propriété et les étiquettes de criticité, puis effectuez le routage à partir de l'enregistrement d'alerte enrichi plutôt qu'à partir de la sortie brute du moniteur.

La leçon opérationnelle est simple. La surveillance native de Databricks est efficace pour détecter la santé des tables, mais la confiance en production découle de la manière dont vous superposez la gouvernance, la validation et le routage autour d'elle. Si vous construisez cette pile actuellement, digna peut s'associer à Databricks en tant que couche d'Observability en base de données pour les anomalies, la ponctualité, la validation et les dérives de schéma. Visitez digna pour voir comment elle s'intègre dans un modèle opérationnel Databricks réglementé et comparez-la à votre configuration de surveillance actuelle.