Présentation

Les monitors Data Observability utilisent la détection d’anomalies qui apprend de la saisonnalité, des tendances et des retours des utilisateurs pour détecter les données retardées, les chargements incomplets et les changements de valeur inattendus avant qu’ils n’affectent les dashboards en aval, les applications d’IA ou les décisions commerciales. Combinés à une traçabilité complète des données et du code, ces monitors aident les équipes à détecter les problèmes tôt, à évaluer l’impact en aval et à les acheminer vers le bon responsable.

Les monitors Data Observability prennent en charge les types de métriques suivants :

Types de métriques au niveau du tableau :

Types de métriques au niveau des colonnes :

Datadog collecte des métriques telles que le nombre de lignes et la pertinence à partir des métadonnées du système d’entrepôt (par exemple, INFORMATION_SCHEMA) lorsqu’elles sont disponibles. Cela évite d’exécuter une requête sur votre entrepôt et réduit les coûts de calcul. Tous les entrepôts n’exposent pas les métadonnées système. Pour les métriques qui ne peuvent pas être collectées à partir des métadonnées système, le monitor exécute une requête directement sur votre entrepôt pour calculer la valeur.

Les monitors Data Observability nécessitent que le Quality Monitoring soit configuré avec au moins un entrepôt de données pris en charge (par exemple, Snowflake, Databricks ou BigQuery).

Data Observability propose quatre types de monitors, sélectionnés lors de la première étape du flux de création de monitor :

Sauf indication contraire, les sections ci-dessous décrivent le type de monitor de qualité des données.

Création de monitor

Pour créer un monitor Data Observability dans Datadog, accédez à Data Observability > Monitors > New Monitor ou Monitors > New Monitor > Data Observability. Pour afficher tous les monitors Data Observability existants, consultez la page des monitors Data Observability.

Choisir les données à surveiller

Tout d’abord, sélectionnez si vous souhaitez surveiller le niveau Table ou Column :

Ensuite, utilisez l’onglet Edit pour rechercher des tableaux, des vues ou des colonnes en saisissant des filtres key:value dans le champ de recherche.

Filtrer par nom ou emplacement :

Filtrer par tag :

Filtrez sur n’importe quel tag appliqué à vos ressources de données en utilisant la clé de tag comme clé de filtre. Par exemple, si vos ressources sont marquées avec owner, platform ou environment, effectuez une recherche directement sur ces tags :

Les filtres de tags prennent en charge les mêmes * caractères génériques et citations que les filtres de nom, par exemple owner:data-* ou platform:"Snowflake Prod".

Filtrer par attribut calculé :

En plus de vos propres tags, Datadog calcule des attributs pour vos ressources de données sur lesquels vous pouvez appliquer des filtres. L’attribut calculé disponible est :

lineage_score est réparti dans les niveaux discrets énumérés ci-dessus plutôt que de prendre une valeur continue ; filtrez donc sur l’une de ces valeurs exactes. Faites correspondre un seul niveau, ou combinez des niveaux avec OR. Par exemple, lineage_score:1.00 renvoie vos actifs les plus dépendants, et lineage_score:(0.90 OR 1.00) renvoie les deux niveaux supérieurs.

Combinez l’un de ces filtres avec AND ou OR, utilisez des parenthèses pour regrouper les conditions, et ajoutez le préfixe - pour exclure.

Exemples :

Filtrer par relation de lignage :

Pour limiter votre sélection aux actifs connectés à un autre actif dans votre graphe de lignage, cliquez sur Add Relation Filter. Choisissez Upstream of ou Downstream of, puis sélectionnez un actif spécifique ou utilisez les mêmes filtres key:value pour faire correspondre un ensemble d’actifs. Par exemple, surveillez chaque tableau situé en amont d’un dashboard critique, ou chaque colonne située en aval d’un tableau source spécifique.

Filtrer par relation hiérarchique :

Pour limiter votre sélection aux actifs qui sont parents ou enfants d’un autre actif dans votre graphe de lignage, cliquez sur Add Relation Filter. Choisissez Parent of ou Child of, puis sélectionnez un actif spécifique ou utilisez les mêmes filtres key:value pour faire correspondre un ensemble d’actifs. Par exemple, surveillez chaque tableau qui possède une colonne revenue, ou chaque tableau situé dans un schéma critique.

Un seul monitor peut suivre jusqu’à 5 000 tableaux, vues ou colonnes. Cette limite ne peut pas être augmentée. Si votre requête en correspond davantage, répartissez-les sur plusieurs monitors.

Sélectionnez votre type de métrique

Choisissez un type de métrique en fonction du signal de qualité des données que vous souhaitez suivre. Chaque monitor suit un type de métrique.

Le type de métrique Freshness détecte quand les données n’ont pas été mises à jour dans une fenêtre temporelle attendue. Utilisez-le pour détecter des données obsolètes avant qu’elles n’affectent les rapports ou les modèles en aval.

La - pertinence de tableau suit le temps écoulé depuis la dernière mise à jour du tableau. La pertinence de tableau n’est pas disponible pour les vues ou pour les entrepôts de données qui ne fournissent pas d’horodatages mis à jour pour les tableaux dans les métadonnées système. Utilisez plutôt la pertinence au niveau de la colonne. La - pertinence de colonne suit la date la plus récente observée dans une colonne de type date/heure.

Le type de métrique Row Count suit les changements du nombre de lignes dans vos tableaux. Utilisez-le pour détecter des baisses ou des pics inattendus dans les données qui pourraient indiquer des échecs de pipeline ou des problèmes en amont.

Les types de métrique Column suivent des métriques au niveau de la colonne pour détecter une dérive des données ou une dégradation de la qualité. Faites votre choix parmi les éléments suivants :

Métrique	Description
Uniqueness	Le pourcentage de valeurs dans une colonne qui sont uniques.
Nullness	Le pourcentage de valeurs nulles dans une colonne.
Cardinality	Le nombre de valeurs distinctes dans une colonne.
Percent Zero	Le pourcentage de valeurs égales à zéro dans une colonne.
Percent Negative	Le pourcentage de valeurs négatives dans une colonne.
Min	Le minimum de toutes les valeurs dans une colonne.
Max	Le maximum de toutes les valeurs dans une colonne.
Mean	La moyenne de toutes les valeurs dans une colonne.
Standard Deviation	La mesure de la variation au sein des valeurs dans une colonne.
Sum	La somme de toutes les valeurs dans une colonne.

Certaines métriques de colonne ne sont disponibles que pour des types de colonne spécifiques. Les métriques numériques (Pourcentage de zéro, Pourcentage de négatif, Min, Max, Moyenne, Écart-type, Somme) nécessitent des colonnes numériques.

Le type de métrique Custom SQL suit une valeur de métrique personnalisée renvoyée par une requête SQL que vous définissez. Utilisez-le lorsque les types de métriques intégrés ne couvrent pas votre cas d’utilisation, comme la surveillance de règles de qualité de données spécifiques à l’entreprise.

1. Sélectionnez un type de modèle qui décrit la valeur renvoyée par votre requête :
   • Default : La requête renvoie une valeur scalaire. Utilisez ceci dans la plupart des cas.
   • Freshness : La requête renvoie la différence (en secondes) entre l’heure actuelle et la dernière fois qu’un événement s’est produit.
   • Percentage : La requête renvoie une valeur en pourcentage comprise entre 0 et 100.
2. Écrivez une requête SQL qui renvoie une valeur unique avec alias dd_value, par exemple : SELECT COUNT(*) as dd_value FROM ANALYTICS_DB.PROD.ORDERS WHERE STATUS = 'FAILED'
3. Cliquez sur Validate pour vérifier la syntaxe de votre requête.

Si votre requête SQL comporte une clause GROUP BY, regroupez les colonnes regroupées sous forme de liste séparée par des virgules dans le champ Group by (par exemple, column_a, column_b). Chaque groupe est évalué indépendamment.

Remarque : Chaque monitor SQL personnalisé compte comme un tableau surveillé individuel à des fins de facturation.

Configurer le monitor

Méthode de détection

Sélectionnez une méthode de détection :

• Anomalies : Alertez lorsque la métrique s’écarte d’un modèle attendu. Aucune valeur seuil n’est requise. Le modèle d’anomalie nécessite 3 à 7 jours pour s’entraîner (incluant un week-end), selon la fréquence de mise à jour des données sous-jacentes. Pendant la période d’entraînement, le monitor ne déclenche pas d’alertes et est affiché en bleu. Une fois l’entraînement terminé, le monitor est affiché en vert lorsqu’il est dans un état normal et en rouge lorsqu’il est dans un état singulier.
• Thresholds : alerte lorsque la métrique dépasse une valeur prédéfinie. Définissez l’opérateur de comparaison (above, above or equal to, below, below or equal to, equal to ou not equal to) et définissez un seuil Critical (requis) et éventuellement un seuil Warning. Pour plus de détails, consultez Configure Monitors.

Clause WHERE

Ajoutez une clause WHERE pour filtrer les données évaluées par le monitor. Ceci est utile pour surveiller des segments de données spécifiques ou uniquement des enregistrements récents. Exemple :

• created_at >= DATEADD(day, -7, CURRENT_TIMESTAMP()) — surveillez uniquement les lignes de la semaine passée.
• region = 'US' — surveillez uniquement les données d’une région spécifique.

Grouper par

Vous pouvez ajouter une clause Group by pour diviser un seul monitor en plusieurs groupes, chacun étant évalué indépendamment. Par exemple, le regroupement d’un monitor de nombre de lignes par une colonne REGION produit une alerte distincte pour chaque zone géographique.

La limite par défaut est de 500 groupes par monitor. Pour augmenter cette limite, contactez le support.

Configuration du modèle

Pour les monitors utilisant la méthode de détection Anomalies, développez Model configuration pour affiner le comportement du modèle :

Dans le menu déroulant If data is missing to evaluate, sélectionnez ce que le monitor signale lorsqu’aucune donnée n’est disponible pour une évaluation.

Planning du monitor

Définissez la fréquence à laquelle le monitor évalue vos données :

• Scheduled : Le monitor s’exécute selon une cadence fixe. Sous Run this monitor, sélectionnez Hourly, Every 3 hours, Every 6 hours, Every 12 hours, Daily ou Custom schedule.
• Manual (Aperçu) : Le monitor s’exécute uniquement lorsqu’il est déclenché par programmation. Déclenchez ces monitors à l’aide de l’API Data Observability selon un planning afin d’accumuler suffisamment de données historiques pour que la modélisation soit utile. L’interface utilisateur ne prend pas en charge les métriques par défaut telles que le nombre de lignes et la pertinence ; ce workflow s’applique donc aux métriques personnalisées ou au niveau des colonnes.

Pour définir votre propre cadence, sélectionnez Custom schedule et fournissez une expression cron. Un planning personnalisé peut s’exécuter toutes les 15 minutes. Preview times répertorie les prochaines exécutions dans votre fuseau horaire local, afin que vous puissiez confirmer l’expression avant de l’enregistrer.

Définir les conditions d’alerte

Choisissez un type d’agrégation :

• Simple Alert : Envoyez une notification unique lorsqu’un tableau ou une colonne surveillé(e) remplit la condition.
• Multi Alert : Envoyez une notification pour chaque groupe remplissant la condition. Personnalisez les dimensions de regroupement (par exemple, table, schema, database) pour contrôler la granularité des alertes. Par exemple, le regroupement par schema n’envoie qu’une seule alerte par schéma, regroupant tous les tableaux concernés pour réduire le bruit.

Exemple de notification

{{#is_alert}}
Data quality issue detected on {{database.name}}.{{schema.name}}.{{table.name}}:
current value {{value}} has breached the threshold of {{threshold}}.
{{/is_alert}}

{{#is_recovery}}
Data quality issue on {{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Current value {{value}} is within the threshold of {{threshold}}.
{{/is_recovery}}

{{#is_alert}}
Anomaly detected on {{database.name}}.{{schema.name}}.{{table.name}}:
observed value {{observed}} is outside the expected range of {{lower_bound}} to {{upper_bound}}
(predicted: {{predicted}}).
{{/is_alert}}

{{#is_recovery}}
{{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Observed value {{observed}} is within the expected range.
{{/is_recovery}}

monitors de la source à la cible

Un monitor de la source à la cible compare la même métrique sur deux actifs de données et envoie une alerte lorsque les deux valeurs divergent. D’autres monitors Data Observability suivent si un seul actif est récent ou complet. Un monitor de la source à la cible suit si la copie arrivée à destination correspond à ce qui a quitté la source.

Lorsqu’un pipeline déplace des données entre des systèmes, les échecs partiels ressemblent rarement à des échecs. Si 100 000 lignes quittent un tableau source et que 99 850 lignes arrivent à destination, un monitor de nombre de lignes sur la destination seule voit une valeur plausible. La comparaison des deux actifs met en évidence l’écart.

Utilisez un monitor de la source à la cible pour :

• Valider la réplication de Postgres vers Databricks.
• Réconciliez deux bases de données au sein du même compte Snowflake, par exemple une base de données de qualité par rapport à la production.
• Vérifiez une migration de Redshift vers BigQuery avant le basculement, en exécutant les deux systèmes côte à côte et en confirmant qu’ils correspondent.
• Confirmez qu’une transformation ne supprime pas de lignes entre son entrée et sa sortie.

Les monitors « source vers cible » sont disponibles dans toutes les régions, à l’exception de GovCloud.

Créer un monitor de la source à la cible

1. Accédez à Monitors > New Monitor et sélectionnez Source to Target.
2. Sous Choose source, sélectionnez l’entrepôt qui contient les données sources, puis sélectionnez les données à comparer.
3. Sous Choose target, faites de même pour la destination. La source et la cible peuvent se trouver dans des entrepôts de données différents ou dans le même.
4. Sous Select your metric type, choisissez la métrique à comparer. Les monitors « source vers cible » prennent en charge les mêmes types de métriques que les autres monitors Data Observability, notamment le nombre de lignes, la pertinence, la nullité, l’unicité, la cardinalité et Custom SQL.
5. Définissez Format pour contrôler la manière dont la comparaison est exprimée :
   • Difference : la valeur cible moins la valeur source. Une valeur négative signifie que la cible a moins que la source.
   • % Difference : la même différence en pourcentage de la valeur source.
6. Configurez la méthode de détection, le planning et les notifications comme décrit dans Configurer le monitor.

Le panneau Preview Monitor Evaluation affiche la source et la cible identifiées, ainsi qu’un aperçu de la métrique sélectionnée.

L’actif surveillé est la cible, le monitor apparaît donc sur la page d’état de la cible.

Comparer une métrique personnalisée

Lorsque le type de métrique est Custom SQL, fournissez une requête pour la source et une requête pour la cible. Une clause WHERE n’est pas acceptée pour ce type de métrique. Incluez tout filtrage dans chaque requête.

Évaluation

La différence entre la source et la cible est enregistrée en tant que métrique distincte ; un monitor source vers cible est donc évalué par les mêmes méthodes de détection que tout autre Data Observability monitor, y compris la détection d’anomalies. Les deux côtés sont mesurés selon un planning synchronisé, de sorte que les deux valeurs sont capturées en même temps plutôt que de suivre la cadence de collecte par défaut de chaque entrepôt.

Monitors de changement de schéma

Un monitor de changement de schéma vous alerte lorsque la structure de vos données change, plutôt que lorsque leur contenu change. Utilisez-le pour détecter un changement en amont avant qu’il n’interrompe un pipeline ou un dashboard en aval, par exemple lorsqu’une colonne est supprimée, renommée ou convertie vers un type de données différent.

Les monitors de changement de schéma détectent quatre types de changements dans les bases de données, les schémas, les tableaux et les colonnes :

Les changements de schéma sont détectés pour Snowflake, BigQuery, Databricks et Redshift.

Créer un monitor de changement de schéma

1. Accédez à Monitors > New Monitor > Schema Change.
2. Sous Choose data to monitor, sélectionnez l’entrepôt à surveiller.
3. Configurez les notifications comme décrit dans Configurer le monitor.

Un monitor de changement de schéma ne prend pas de type de métrique ni de méthode de détection car il alerte sur un changement structurel plutôt que sur une valeur mesurée dépassant une limite.

Parcourir les changements de schéma détectés

Pour voir les changements que Datadog a détectés sans créer de monitor, allez dans Data Observability > Schema Changes. Filtrez par plateforme, compte, base de données, schéma ou type de changement, et développez une entrée pour voir les colonnes affectées et leurs types de données.

Les changements sont détectés lorsque Datadog collecte ensuite les métadonnées de schéma depuis votre entrepôt et compare la structure actuelle avec celle précédemment collectée.

Exemples de monitors

Annoter les limites

Pour les monitors utilisant la méthode de détection Anomalie, vous pouvez annoter des plages de limites pour fournir des commentaires et améliorer le modèle au fil du temps. Contrairement aux métriques d’infrastructure, les métriques de qualité des données sont souvent spécifiques à l’entreprise ; utilisez donc des annotations pour apprendre au modèle quel comportement est normal pour vos données.

Sur la page d’état d’un monitor, cliquez sur Annotate Bounds, sélectionnez une plage temporelle sur le graphique et choisissez l’une des annotations suivantes :

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Vue d'ensemble de Data ObservabilityDOCUMENTATION Quality MonitoringDOCUMENTATION Configurer les notifications de vos monitorsDOCUMENTATION Planifier un downtime pour désactiver un monitorDOCUMENTATION Consulter le statut de votre monitorDOCUMENTATION