Présentation de la qualité automatique des données

Knowledge Catalog (anciennement Dataplex Universal Catalog) vous permet de définir et d'évaluer la qualité des données de vos tables BigQuery et Iceberg REST Catalog. Vous pouvez automatiser l'analyse des données, les valider par rapport à des règles définies et enregistrer des alertes si vos données ne répondent pas aux exigences de qualité. La qualité automatique des données vous permet de gérer les règles et les déploiements de qualité des données en tant que code, ce qui améliore l'intégrité des pipelines de production de données.

Pour analyser les données à la recherche d'anomalies, consultez Analyse de profilage des données Knowledge Catalog. L'analyse peut générer des règles de qualité des données. Vous pouvez également utiliser des règles de qualité intégrées ou créer des règles personnalisées.

Knowledge Catalog fournit des fonctionnalités de surveillance, de dépannage et d'alerte Cloud Logging intégrées à la qualité automatique des données.

Modèle conceptuel

Une analyse de la qualité des données applique des règles de qualité aux données d'une table pour générer des résultats.

Une analyse de la qualité des données est un type d'analyse des données Knowledge Catalog qui valide vos données par rapport à un ensemble de règles intégrées. Une analyse de données est un job Knowledge Catalog qui échantillonne les données de BigQuery et Cloud Storage (via des tables externes BigQuery), et infère différents types de métadonnées. Pour mesurer la qualité d'une table à l'aide de la qualité automatique des données, vous créez un objet DataScan de type data quality. L'analyse ne s'exécute que sur une seule table BigQuery. L'analyse utilise les ressources d'un projet locataire Google. Vous n'avez donc pas besoin de configurer votre propre infrastructure.

Pour créer et utiliser une analyse de la qualité des données, effectuez les opérations suivantes :

  1. Définir des règles de qualité des données
  2. Configurer l'exécution des règles
  3. Analyser les résultats de l'analyse de la qualité des données
  4. Configurer la surveillance et les alertes
  5. Résoudre les échecs liés à la qualité des données

Définition de la règle

Les règles de qualité des données associées à une analyse de la qualité des données définissent les attentes concernant les données. Vous pouvez créer des règles de qualité des données des différentes manières suivantes :

Règles intégrées

Knowledge Catalog est compatible avec les catégories de règles intégrées suivantes :

Au niveau des lignes

Pour les règles de catégorie au niveau des lignes, l'attente est appliquée à chaque ligne de données. Chaque ligne réussit ou échoue indépendamment face à la condition. Par exemple : column_A_value < 1.

Les vérifications au niveau des lignes vous obligent à spécifier un seuil de réussite. Lorsque le pourcentage de lignes respectant la règle est inférieur à la valeur seuil, la règle échoue.

Agrégat

Pour les règles d'agrégation, l'attente est appliquée à une seule valeur agrégée sur l'ensemble des données. Par exemple, Avg(someCol) >= 10. Pour réussir, la vérification doit renvoyer la valeur booléenne true. Les règles d'agrégation ne fournissent pas de nombre indépendant de réussites ou d'échecs pour chaque ligne.

Pour les deux catégories de règles, vous pouvez définir les paramètres suivants :

  • Colonne à laquelle s'applique la règle
  • Une dimension

Le tableau suivant liste les types de règles agrégées et au niveau des lignes compatibles :

Type de règle
(nom dans la console Google Cloud )		 Règle au niveau des lignes ou agrégée Description Types de colonnes acceptés Paramètres spécifiques aux règles
RangeExpectation
(Vérification de la plage)		 Au niveau des lignes Vérifiez si la valeur est comprise entre le minimum et le maximum. Toutes les colonnes de type numérique, date et code temporel. Obligatoire :
  • Pourcentage du seuil de réussite
  • Valeurs min ou max : spécifiez au moins une valeur.
Facultatif :
  • Activer strict min : si cette option est activée, la vérification de la règle utilise ">" au lieu de ">=".
  • Activer strict max : si cette option est activée, la vérification de la règle utilise "<" au lieu de "<=".
  • Activez ignore null : si cette option est activée, les valeurs nulles sont ignorées lors de la vérification des règles.
NonNullExpectation
(Contrôle des valeurs NULL)		 Au niveau des lignes Validez que les valeurs des colonnes ne sont pas NULL. Tous les types de colonnes acceptés. Obligatoire :
  • Pourcentage du seuil de réussite.
SetExpectation
(Définir la vérification)		 Au niveau des lignes Vérifier si les valeurs d'une colonne font partie d'un ensemble de valeurs spécifié. Tous les types de colonnes acceptés, sauf Record et Struct. Obligatoire :
  • Ensemble de valeurs de chaîne à vérifier.
  • Pourcentage du seuil de réussite.
Facultatif :
  • Activez ignore null : si cette option est activée, les valeurs nulles sont ignorées lors de la vérification des règles.
RegexExpectation
(Vérification des expressions régulières)		 Au niveau des lignes Vérifiez les valeurs par rapport à une expression régulière spécifiée. Chaîne Obligatoire :
  • Modèle d'expression régulière utilisé pour la vérification.
  • Pourcentage du seuil de réussite.
  • Remarque : La bibliothèque re2 permet d'utiliser des expressions régulières dans GoogleSQL. Consultez la documentation de cette bibliothèque pour en savoir plus sur la syntaxe d'expression régulière à utiliser.
Facultatif :
  • Activez ignore null : si cette option est activée, les valeurs nulles sont ignorées lors de la vérification des règles.
Uniqueness
(Vérification de l'originalité)		 Agrégat Vérifiez si toutes les valeurs d'une colonne sont uniques. Tous les types de colonnes acceptés, sauf Record et Struct. Obligatoire :
  • Colonne et dimension à partir des paramètres acceptés.
Facultatif :
  • Activez ignore null : si cette option est activée, les valeurs nulles sont ignorées lors de la vérification des règles.
StatisticRangeExpectation
(Vérification des statistiques)		 Agrégat Vérifie si la métrique donnée correspond à la plage attendue. Tous les types de colonnes numériques acceptés. Obligatoire :
  • Valeurs mean, min ou max : spécifiez au moins une valeur.
Facultatif :
  • Activer strict min : si cette option est activée, la vérification de la règle utilise ">" au lieu de ">=".
  • Activer strict max : si cette option est activée, la vérification de la règle utilise "<" au lieu de "<=".

Types de règles SQL personnalisées acceptés

Les règles SQL offrent la possibilité d'étendre la validation avec une logique personnalisée. Ces règles se présentent sous les types suivants.

Type de règle Règle au niveau des lignes ou agrégée Description Types de colonnes acceptés Paramètres spécifiques aux règles Exemple
Condition de ligne Au niveau des lignes Spécifiez une attente pour chaque ligne en définissant une expression SQL dans une clause WHERE. L'expression SQL doit renvoyer la valeur true (succès) ou false (échec) par ligne.

Knowledge Catalog calcule le pourcentage de lignes qui répondent à cette attente et compare cette valeur au pourcentage de seuil de réussite pour déterminer si la règle a réussi ou échoué.

L'expression peut inclure une référence à une autre table, par exemple pour créer des vérifications de l'intégrité référentielle.		 Toutes les colonnes Obligatoire :
  • Condition SQL à utiliser
  • Pourcentage du seuil de réussite
  • Dimension
Facultatif :
  • Colonne à laquelle associer cette règle.
 grossWeight <= netWeight
Condition de table
(expression SQL agrégée)		 Agrégat Ces règles sont exécutées une fois par table. Fournissez une expression SQL qui renvoie la valeur booléenne true (succès) ou false (échec).

L'expression SQL peut inclure une référence à un autre tableau à l'aide de sous-requêtes d'expression.		 Toutes les colonnes Obligatoire :
  • Condition SQL à utiliser
  • Dimension
Facultatif :
  • Colonne à laquelle associer cette règle
 Exemple d'agrégation simple :
avg(price) > 100
Utiliser une sous-requête d'expression pour comparer des valeurs dans une autre table :
(SELECT COUNT(*) FROM `example_project.example_dataset.different-table`) < COUNT(*)
Assertion SQL Agrégat Une règle d'assertion utilise une requête de qualité des données pour trouver les lignes qui ne respectent pas une ou plusieurs conditions spécifiées dans la requête. Fournissez une instruction SQL qui doit être évaluée afin de renvoyer les lignes correspondant à l'état non valide. Si la requête renvoie un résultat, la règle échoue.

Omettez le point-virgule de fin de l'instruction SQL. L'instruction SQL peut inclure une référence à une autre table à l'aide de sous-requêtes d'expression. 		Toutes les colonnes Obligatoire :
  • Instruction SQL pour vérifier l'état non valide
  • Dimension
Facultatif :
  • Colonne à laquelle associer cette règle.
 Exemple d'agrégation simple pour s'assurer que discount_pct n'est pas supérieur à 100 :
SELECT * FROM example_project.example_dataset.table WHERE discount_pct > 100

Utiliser une sous-requête d'expression pour comparer des valeurs dans une autre table :
SELECT * FROM `example_project.example_dataset.different-table` WHERE gross_weight > (SELECT avg(gross_weight) FROM `example_project.example_dataset.different-table`)

Pour obtenir des exemples de règles, consultez Exemples de règles de qualité automatique des données.

Pour connaître les fonctions SQL compatibles, consultez la documentation de référence sur GoogleSQL.

Réutiliser des règles de qualité des données

Vous pouvez réutiliser les règles de qualité des données Knowledge Catalog pour partager des définitions de règles métier complexes ou standardisées dans plusieurs règles de qualité des données à l'aide de modèles de règles. Par exemple, vous pouvez créer un modèle de règle pour la validation d'une adresse e-mail ou pour la validation d'une clé étrangère entre deux tables, puis réutiliser ces modèles dans vos analyses de données.

La réutilisabilité des règles offre les principales fonctionnalités suivantes :

  • Modèles de règles de qualité des données : créez des modèles de règles personnalisés pour stocker des définitions de règles métier complexes ou standardisées qui peuvent être partagées entre plusieurs règles de qualité des données. Créez une entrée data-quality-rule-template et ajoutez-y un aspect data-quality-rule-template pour définir la logique du modèle.
  • Règles de données en tant que métadonnées : déclarez les règles de qualité des données en tant qu'aspects dans Knowledge Catalog sur des entrées telles que les tables BigQuery ou les termes du glossaire d'entreprise. Utilisez le type d'aspect data-rules pour associer ces règles aux entrées.
  • Modèles de règles système : utilisez les modèles de règles système pour les règles courantes.

Pour en savoir plus, consultez Réutiliser des règles de qualité des données.

Dimensions

Les dimensions vous permettent d'agréger les résultats de plusieurs règles de qualité des données pour la surveillance et les alertes. Vous devez associer chaque règle de qualité des données à une dimension. Knowledge Catalog fournit les dimensions suivantes :

Actualisation
La fraîcheur indique la date de la dernière mise à jour des données. Ces informations peuvent vous aider à déterminer si les données sont suffisamment récentes pour être utiles.
Volume
Le volume indique si toutes les données attendues sont présentes.
Exhaustivité
L'exhaustivité évalue si les données contiennent toutes les informations requises pour leur objectif.
Validité
 La validité évalue si les données sont conformes aux normes intégrées en termes de format, de plages acceptables ou d'autres critères. Par exemple, si une date valide doit être au format YYYY/mm/dd, alors 08-12-2019 n'est pas une donnée valide. Autre exemple : si un prix soldé valide pour un article est compris entre 10 $ et 20 $, un prix soldé de 100 $ constitue une donnée non valide.
Cohérence
La cohérence fait référence à l'utilisation des mêmes valeurs pour les données dans plusieurs instances, telles que les tables et les colonnes. Par exemple, une incohérence des données se produit lorsque les revenus d'un produit diffèrent selon qu'ils sont lus dans une base de données de ventes ou dans une base de données d'utilisation.
Précision
 La justesse reflète l'exactitude des données. Notez que des données valides ne sont pas nécessairement exactes. Par exemple, la couleur de cheveux "brun" peut être une donnée valide, mais si une personne n'a pas les cheveux bruns, il s'agit d'une donnée inexacte.
Unicité
L'unicité mesure si les données sont distinctes et ne contiennent pas de doublons.

Saisie clavier dans les règles

Tous les paramètres de valeur sont transmis à l'API sous forme de chaînes. Knowledge Catalog exige que les entrées respectent le format spécifié pour BigQuery.

Les paramètres de type binaire peuvent être transmis sous forme de chaîne encodée en base64.

Type Formats compatibles Exemples
Binaire Valeur encodée en base64 YXBwbGU=
Code temporel AAAA-[M]M-[J]J[( |T)[H]H:[M]M:[S]S[.F]] [time_zone]
OU AAAA-[M]M-[J]J[( |T)[H]H:[M]M:[S]S[.F]][time_zone_offset]		 2014-09-27 12:30:00.45-08
Date AAAA-M[M]-J[J] 2014-09-27
Temps [H]H:[M]M:[S]S[.DDDDDD] 12:30:00.45
DateTime AAAA-[M]M-[J]J [[H]H:[M]M:[S]S[.DDDDDD]] 2014-09-27 12:30:00.45

Paramètre de référence des données

Lorsque vous créez une règle SQL personnalisée, vous pouvez faire référence à une table de source de données et à tous ses filtres de préconditions en utilisant le paramètre de référence de données ${data()} dans la règle, au lieu de mentionner explicitement la table source et ses filtres. Knowledge Catalog interprète le paramètre comme une référence à la table source et à ses filtres. Les filtres de préconditions incluent, par exemple, les filtres de lignes, les pourcentages d'échantillonnage et les filtres incrémentaux.

Par exemple, supposons que vous disposiez d'une table de source de données appelée my_project_id.dim_dataset.dim_currency. Vous souhaitez exécuter une analyse incrémentielle de la qualité des données qui n'analyse que les nouvelles données quotidiennes. Un filtre de ligne qui filtre les entrées d'aujourd'hui, transaction_timestamp >= current_date(), est appliqué à la table.

Voici à quoi ressemble une règle SQL personnalisée permettant de trouver les lignes avec discount_pct pour aujourd'hui :

discount_pct IN (SELECT discount_pct FROM my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date())

Si vous utilisez le paramètre de référence de données, vous pouvez simplifier la règle. Remplacez la mention de la table et de ses filtres de préconditions par le paramètre ${data()} :

discount_pct IN (SELECT discount_pct FROM ${data()})

Knowledge Catalog interprète le paramètre ${data()} comme une référence à la table de source de données avec les entrées du jour, my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date(). Dans cet exemple, le paramètre de référence de données ne fait référence qu'aux données incrémentielles.

Le paramètre ${data()} est sensible à la casse.

Lorsque vous utilisez un alias dans une sous-requête pour faire référence à des colonnes de la table source, utilisez le paramètre de référence des données pour faire référence à la table source ou omettez la référence à la table. Ne faites pas référence aux colonnes de la table source en utilisant une référence directe à la table dans la clause WHERE.

Recommandé :

  • Utilisez le paramètre de référence des données pour faire référence à la table source :

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = ${data()}.timestamp
)

  • Omettez la référence à la table :

    discount_pct IN (
SELECT discount_pct FROM
`another_project.another_dataset.another_table` AS temp-table
WHERE
temp-table.transaction_timestamp = timestamp

Non recommandé :

  • N'utilisez pas de référence directe à une table pour faire référence aux colonnes de la table source :

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = `my_project_id.dim_dataset.dim_currency`.timestamp
)

Utilisation valide de différentes tables :

  • Vous pouvez utiliser une référence directe à une table lorsque vous comparez des colonnes provenant d'une autre table :

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = `another_project.another_dataset.another_table`.timestamp
)

Déboguer les requêtes

Lorsque vous créez une règle, vous pouvez éventuellement inclure une requête de débogage à exécuter en même temps que la règle. Une requête de débogage est une instruction SQL qui renvoie jusqu'à 10 valeurs scalaires. Ces valeurs peuvent aider à diagnostiquer la cause de l'échec de la règle. Vous ne pouvez ajouter qu'une seule requête de débogage par règle, et elle ne doit pas dépasser 1 024 caractères.

Prenons l'exemple de la règle d'assertion SQL suivante sur la table example_project.example_dataset.table, qui vérifie si le revenu moyen par article dépasse 100 :

SELECT
  *
FROM
  `example_project.example_dataset.table`
WHERE
  SUM(revenue) / COUNT(DISTINCT item_id) > 100

Si la règle précédente échoue, vous pouvez consulter des métriques telles que le revenu total, le nombre d'articles distincts et le revenu moyen par article pour vous aider à diagnostiquer le problème. La requête de débogage suivante renvoie ces métriques :

SELECT
  SUM(revenue),
  COUNT(DISTINCT item_id),
  SUM(revenue) / COUNT(DISTINCT item_id)
FROM `example_project.example_dataset.table`

Exécution des règles

Vous pouvez planifier l'exécution des analyses de la qualité des données à un intervalle spécifique ou exécuter une analyse à la demande.

Identité d'exécution

Par défaut, Knowledge Catalog utilise un agent de service centralisé (service-PROJECT_NUMBER@gcp-sa-dataplex.) pour exécuter des analyses de la qualité des données.

Vous pouvez remplacer cette identité d'exécution par défaut en spécifiant un compte de service personnalisé ou en utilisant vos propres identifiants utilisateur final (EUC). Cela présente plusieurs avantages :

  • Principe du moindre privilège : n'accordez à un compte de service dédié que les autorisations IAM exactes requises pour des tâches spécifiques de qualité des données, ce qui minimise l'accès surprovisionné.
  • Contrôle des accès ultraprécis : définissez des autorisations pour des ressources spécifiques, ce qui permet l'intégration aux règles d'accès au niveau des lignes et des colonnes dans BigQuery.
  • Auditabilité améliorée : attribuez des comptes de service personnalisés ou des identifiants utilisateur à des analyses spécifiques. Le suivi et la journalisation des activités sont ainsi beaucoup plus clairs dans les journaux d'audit.
  • Unification de la facturation : lorsque vous utilisez une identité d'exécution personnalisée, les frais de traitement et de stockage sont centralisés directement sous BigQuery (en contournant les SKU Knowledge Catalog Premium). Cela vous permet de profiter des remises BigQuery pour les entreprises et des engagements d'emplacements.

Pour savoir comment configurer une identité d'exécution personnalisée, consultez Configurer l'identité d'exécution.

Exigences de mise en réseau

Pour exécuter une analyse, vous devez activer l'accès privé à Google sur le sous-réseau VPC que vous utilisez pour l'analyse. Si vous ne spécifiez pas de sous-réseau, assurez-vous que l'accès privé à Google est activé sur votre sous-réseau par défaut.

Lorsque vous exécutez une analyse de la qualité des données, Knowledge Catalog crée un job. Si un job est mal configuré ou s'exécute plus longtemps que prévu, vous pouvez l'annuler.

Lorsque vous spécifiez une analyse de la qualité des données, vous pouvez définir le champ d'application d'un job sur l'une des valeurs suivantes :

Table complète
Chaque job valide l'intégralité de la table.
Incrémentielle
 Chaque job valide les données incrémentielles. Pour déterminer les incréments, fournissez une colonne Date ou Timestamp dans le tableau pouvant servir de repère. Il s'agit généralement de la colonne par rapport à laquelle la table est partitionnée.

Filtrer les données

Vous pouvez filtrer les données à analyser pour la qualité des données à l'aide d'un filtre de ligne. Créer un filtre de ligne vous permet de vous concentrer sur les données d'une période ou d'un segment spécifiques, comme une région donnée. L'utilisation de filtres peut réduire la durée d'exécution et les coûts. Par exemple, vous pouvez filtrer les données dont le code temporel est antérieur à une certaine date.

Exemples de données

Vous pouvez spécifier un pourcentage d'enregistrements de vos données à échantillonner pour exécuter une analyse de la qualité des données. La création d'analyses de la qualité des données sur un échantillon de données plus petit peut réduire la durée d'exécution et le coût par rapport à l'interrogation de l'ensemble de données.

Règles de filtrage

Lorsque vous exécutez une analyse de la qualité des données, vous pouvez utiliser la syntaxe de filtre AIP-160 pour exécuter de manière sélective des règles spécifiques. Knowledge Catalog filtre les métadonnées des règles définies dans l'analyse ou des règles associées à l'entrée de catalogue via l'aspect data-rules.

Syntaxe de filtre

La syntaxe du filtre suit les consignes AIP-160. Vous pouvez utiliser les opérateurs AIP-160 standards (tels que =, !=, >, <, =~) et combiner plusieurs conditions à l'aide de AND ou OR.

Lorsque vous utilisez une chaîne de filtre AIP-160, procédez comme suit :

  • Dans la console Google Cloud  : saisissez le filtre directement en utilisant la syntaxe AIP-160, par exemple name = "critical_check".
  • Dans un appel d'API : la chaîne de filtre est souvent une valeur dans un autre littéral de chaîne JSON. Pour cela, vous devez échapper les guillemets doubles dans la chaîne AIP-160. Exemple :"filter": "name = \"critical_check\""

Champs acceptant le filtrage

Vous pouvez filtrer la plupart des champs disponibles dans la définition de la règle :

  • name : nom à afficher de la règle.
  • dimension : dimension de la qualité des données (par exemple, VALIDITY).
  • column : nom de la colonne à laquelle s'applique la règle.
  • threshold : seuil de réussite de la règle.
  • ignore_null : valeur booléenne. Lorsque true, les lignes NULL sont considérées comme réussies.
  • attributes : paires clé-valeur personnalisées attribuées à la règle.

Les exemples suivants illustrent des modèles de filtres courants. Les valeurs numériques et booléennes ne sont pas mises entre guillemets.

Filtrer par nom

  • Correspondance exacte : name = "critical_check"
  • Correspondance avec un modèle : name =~ "temp_.*"

Filtrer par dimension

  • Correspond à une dimension spécifique : dimension = "COMPLETENESS"
  • Faire correspondre plusieurs dimensions : dimension = "VALIDITY" OR dimension = "ACCURACY"

Filtrer par colonne et seuil

  • Correspond à une colonne spécifique : column = "user_id"
  • Atteindre un seuil : threshold > 0.95
  • Faire correspondre une plage : threshold >= 0.8 AND threshold < 0.9

Filtrer par ignore_null

  • Valeur booléenne de correspondance : ignore_null = true

Filtrer par attributs personnalisés

  • Vérifiez la présence de la clé : attributes:environment
  • Clé et valeur correspondantes : attributes.environment = "prod"
  • Correspond à l'expression régulière : attributes.tag =~ "prio-.*"
  • Combinaisons de correspondance : attributes.environment = "prod" AND attributes.criticality = "high"

Résultats de l'analyse de la qualité des données

Les résultats de vos analyses de la qualité des données sont disponibles dans Knowledge Catalog et BigQuery. Vous pouvez également examiner et analyser les résultats de l'analyse à l'aide des méthodes suivantes :

  • Exporter les résultats vers BigQuery

    Vous pouvez exporter les résultats de l'analyse vers une table BigQuery pour une analyse plus approfondie. Pour personnaliser les rapports, vous pouvez connecter les données de la table BigQuery à un tableau de bord Looker. Vous pouvez créer un rapport agrégé en utilisant la même table de résultats pour plusieurs analyses.

  • Publier les résultats en tant que métadonnées Knowledge Catalog

    Vous pouvez publier les résultats de l'analyse de la qualité des données en tant que métadonnées Knowledge Catalog. Les derniers résultats sont enregistrés dans l'entrée Knowledge Catalog qui représente la table source, sous le type d'aspect système data-quality-scorecard. Vous pouvez consulter les résultats sur les pages BigQuery et Knowledge Catalog de la table source dans la console Google Cloud , dans l'onglet Qualité des données. Vous pouvez également récupérer les résultats à l'aide de l'API.

    Pour en savoir plus sur les métadonnées Knowledge Catalog, consultez À propos de la gestion des métadonnées dans Knowledge Catalog.

  • Examiner les scores de qualité des données

    Chaque résultat d'analyse fournit des scores de qualité des données qui indiquent le pourcentage de règles respectées. Les scores sont indiqués au niveau global du job, au niveau de la colonne (si la règle est évaluée par rapport à une colonne) et au niveau de la dimension. Utilisez les scores de qualité des données pour normaliser la qualité des données dans les tables ou les colonnes, suivre les tendances et identifier les données qui ne répondent pas aux exigences de qualité.

Pour en savoir plus, consultez Afficher les résultats de l'analyse de la qualité des données.

Surveillance et alertes

Vous pouvez surveiller les analyses de la qualité des données et recevoir des alertes à leur sujet à l'aide des méthodes suivantes :

  • Définir des alertes dans Cloud Logging

    Vous pouvez surveiller les jobs de qualité des données à l'aide des journaux data_scan et data_quality_scan_rule_result dans l'explorateur de journaux.

    Pour chaque job de qualité des données, le journal data_scan avec le champ data_scan_type défini sur DATA_QUALITY contient les informations suivantes :

    • Source de données utilisée pour l'analyse des données.
    • Détails de l'exécution du job, tels que l'heure de création, l'heure de début, l'heure de fin et l'état du job.
    • Résultat du job d'évaluation de la qualité des données : réussite ou échec.
    • Indique si la dimension est conforme ou non.

    Chaque job réussi contient un journal data_quality_scan_rule_result avec les informations détaillées suivantes sur chaque règle de ce job :

    • Informations de configuration, telles que le nom, le type et le type d'évaluation de la règle, ainsi que la dimension.
    • Informations sur les résultats, telles que la réussite ou l'échec, le nombre total de lignes, le nombre de lignes réussies, le nombre de lignes nulles et le nombre de lignes évaluées.

    Les informations contenues dans les journaux sont disponibles via l'API et la consoleGoogle Cloud . Vous pouvez utiliser ces informations pour configurer des alertes. Pour en savoir plus, consultez Définir des alertes dans Logging.

  • Envoyer des rapports de notifications par e-mail

    Vous pouvez envoyer des rapports de notification par e-mail pour informer les utilisateurs de l'état et des résultats d'un job de qualité des données. Les rapports de notification sont disponibles pour les scénarios suivants :

    • Le niveau de qualité des données est inférieur à un niveau cible spécifié.
    • Le job a échoué.
    • Le job est terminé.

    Vous configurez les rapports de notification lorsque vous créez une analyse de la qualité des données.

  • Surveiller les coûts de calcul des DCU dans Cloud Billing

    Le calcul sans serveur de l'analyse de la qualité des données n'émet pas de métriques de séries temporelles vers Cloud Monitoring. Pour suivre et attribuer les coûts des DCU de qualité des données par projet, ID d'analyse ou table, interrogez l'exportation Cloud Billing dans BigQuery à l'aide des libellés système goog-dataplex-datascan-*. Pour en savoir plus, consultez Surveiller et attribuer les coûts DCU Dataplex avec l'exportation Cloud Billing.

Résoudre les échecs liés à la qualité des données

Lorsqu'une règle ne s'exécute pas, Knowledge Catalog fournit une requête permettant d'obtenir les enregistrements ayant échoué. Exécutez cette requête pour afficher les enregistrements qui ne correspondaient pas à votre règle. Pour en savoir plus, consultez Résoudre un échec de qualité des données.

Limites

  • Les recommandations de règles ne sont pas disponibles dans gcloud CLI.
  • Le choix des dimensions est limité à l'une des sept dimensions prédéfinies.
  • Le nombre de règles par analyse de la qualité des données est limité à 1 000.
  • Les scores de qualité des données signalés au niveau des colonnes ne sont acceptés que dans l'API.
  • Vous ne pouvez exécuter des règles de qualité des données que sur les tables BigQuery, Iceberg REST Catalog, SAP Business Data Cloud Delta Lake et Apache Hive.

Tarifs

Étapes suivantes