Référence DQDL (Data Quality Definition Language)

Le langage DQDL (Data Quality Definition Language) est spécifique au domaine que vous utilisez pour définir les règles relatives à AWS Glue Data Quality.

Ce guide présente les concepts clés de DQDL pour vous aider à vous familiariser avec ce langage. Il fournit également une référence pour les types de règles DQDL, avec syntaxe et exemples. Avant d’utiliser ce guide, nous vous recommandons de vous familiariser avec AWS Glue Data Quality. Pour plus d’informations, consultez Qualité des données de AWS Glue.

Syntaxe DQDL

Un document DQDL est sensible à la casse et contient un jeu de règles, qui regroupe les règles individuelles de qualité des données. Pour construire un jeu de règles, vous devez créer une liste nommée Rules (en majuscules), délimitée par une paire de crochets. La liste doit contenir une ou plusieurs règles DQDL séparées par des virgules, comme dans l’exemple suivant.

Rules = [
   IsComplete "order-id",
   IsUnique "order-id"
]

Structure des règles

La structure d’une règle DQDL dépend du type de la règle. Toutefois, les règles DQDL respectent généralement le format suivant.

<RuleType> <Parameter> <Parameter> <Expression>

RuleType est le nom sensible à la casse du type de règle que vous souhaitez configurer. Par exemple, IsComplete, IsUnique ou CustomSql. Les paramètres varient en fonction du type de règle. Pour obtenir une référence complète des types de règles DQDL et de leurs paramètres, consultez Référence du type de règle DQDL.

Règles composites

Le même opérateur peut être utilisé pour connecter plusieurs règles. La combinaison de règles suivante est donc autorisée.

(Mean "Star_Rating" > 3) and (Mean "Order_Total" > 500) and (IsComplete "Order_Id")

Vous pouvez combiner les opérateurs logiques en une seule expression. Par exemple :

(Mean "Star_Rating" > 3) and ((Mean "Order_Total" > 500) or (IsComplete "Order_Id"))

Vous pouvez également créer des règles imbriquées plus complexes.

(RowCount > 0) or ((IsComplete "colA") and (IsUnique "colA"))

Fonctionnement des règles composites

Par défaut, les règles composites sont évaluées en tant que règles individuelles pour l’ensemble du jeu de données ou de la table, puis les résultats sont combinés. En d’autres termes, elles évaluent d’abord l’ensemble de la colonne, puis appliquent l’opérateur. Ce comportement par défaut est expliqué ci-dessous à l’aide d’un exemple :

# Dataset

+------+------+
|myCol1|myCol2|
+------+------+
|     2|     1|
|     0|     3|
+------+------+

# Overall outcome

+----------------------------------------------------------+-------+
|Rule                                                      |Outcome|
+----------------------------------------------------------+-------+
|(ColumnValues "myCol1" > 1) OR (ColumnValues "myCol2" > 2)|Failed |
+----------------------------------------------------------+-------+
      

Dans l’exemple ci-dessus, AWS Glue Data Quality évalue d’abord (ColumnValues "myCol1" > 1), ce qui entraînera un échec. Ensuite, il évaluera (ColumnValues "myCol2" > 2) ce qui entraînera également un échec. La combinaison des deux résultats sera considérée comme un ÉCHEC.

Toutefois, si vous préférez un comportement de type SQL, dans lequel vous devez évaluer la ligne entière, vous devez définir explicitement le paramètre ruleEvaluation.scope comme indiqué dans additionalOptions, dans l’extrait de code ci-dessous.

object GlueApp {
  val datasource = glueContext.getCatalogSource(
    database="<db>",
    tableName="<table>",
    transformationContext="datasource"
  ).getDynamicFrame()

  val ruleset = """
    Rules = [
        (ColumnValues "age" >= 26) OR (ColumnLength "name" >= 4)        
    ]
  """

  val dq_results = EvaluateDataQuality.processRows(
    frame=datasource,
    ruleset=ruleset,
    additionalOptions=JsonOptions("""
        {
          "compositeRuleEvaluation.method":"ROW"
        }
      """
    )
  )
}     
      

Dans le Catalogue de donnés AWS Glue, vous pouvez facilement configurer cette option dans l’interface utilisateur, comme indiqué ci-dessous.

Une fois définies, les règles composites se comporteront comme une règle unique évaluant la ligne entière. L’exemple suivant illustre ce comportement.

# Row Level outcome

+------+------+------------------------------------------------------------+---------------------------+
|myCol1|myCol2|DataQualityRulesPass                                        |DataQualityEvaluationResult|
+------+------+------------------------------------------------------------+---------------------------+
|2     |1     |[(ColumnValues "myCol1" > 1) OR (ColumnValues "myCol2" > 2)]|Passed                     |
|0     |3     |[(ColumnValues "myCol1" > 1) OR (ColumnValues "myCol2" > 2)]|Passed                     |
+------+------+------------------------------------------------------------+---------------------------+     
      

Certaines règles ne peuvent pas être prises en charge dans cette fonctionnalité, car leur résultat global repose sur des seuils ou des ratios. Elles sont répertoriées ci-dessous.

Règles basées sur des ratios :

Règles dépendantes de seuils :

Lorsque les règles suivantes sont incluses dans un seuil, elles ne sont pas prises en charge. Cependant, les règles qui n’impliquent pas with threshold restent prises en charge.

Expressions

Si un type de règle ne produit pas de réponse booléenne, vous devez fournir une expression en tant que paramètre afin de créer une réponse booléenne. Par exemple, la règle suivante vérifie la moyenne de toutes les valeurs d’une colonne par rapport à une expression afin de renvoyer un résultat vrai ou faux.

Mean "colA" between 80 and 100

Certains types de règles tels que IsUnique et IsComplete renvoient déjà une réponse booléenne.

Le tableau suivant répertorie les expressions pouvant être utilisées dans les règles DQDL.

Completeness "colA" = "1.0",
ColumnValues "colA" = "2022-06-30"

ColumnValues "colA" != "a",
ColumnValues "colA" != "2022-06-30"

ColumnValues "colA" > 10

ColumnValues "colA" < 1000,
ColumnValues "colA" < "2022-06-30"

ColumnValues "colA" >= 10

ColumnValues "colA" <= 1000

Mean "colA" between 8 and 100,
ColumnValues "colA" between "2022-05-31" and "2022-06-30"

ColumnValues "colA" not between "2022-05-31" and "2022-06-30"

ColumnValues "colA" in [ 1, 2, 3 ],
ColumnValues "colA" in [ "a", "b", "c" ]

ColumnValues "colA" not in [ 1, 2, 3 ],
ColumnValues "colA" not in [ "a", "b", "c" ]

ColumnValues "colA" matches "[a-zA-Z]*"

ColumnValues "colA" not matches "[a-zA-Z]*"

ColumnValues "load_date" > (now() - 3 days)

ColumnValues "colA" in ["A", "B"] with threshold > 0.8,
ColumnValues "colA" matches "[a-zA-Z]*" with threshold between 0.2 and 0.9
ColumnDataType "colA" = "Timestamp" with threshold > 0.9

Mots-clés pour NULL, EMPTY et WHITESPACES_ONLY

Si vous souhaitez vérifier si une colonne de chaîne contient une valeur nulle, vide ou une chaîne contenant uniquement des espaces blancs, vous pouvez utiliser les mots clés suivants :

Pour une expression numérique ou basée sur une date, si vous souhaitez vérifier si une colonne contient une valeur nulle, vous pouvez utiliser les mots clés suivants.

Filtrage avec la clause Where

Vous pouvez filtrer vos données lorsque vous créez des règles. Cela s’avère utile lorsque vous souhaitez appliquer des règles conditionnelles.

<DQDL Rule> where "<valid SparkSQL where clause> "

Le filtre doit être spécifié avec le mot clé where, suivi d’une instruction SparkSQL valide placée entre guillemets ("").

Si vous souhaitez ajouter la clause Where à une règle avec un seuil, elle doit être spécifiée avant la condition de seuil.

<DQDL Rule> where "valid SparkSQL statement>" with threshold <threshold condition>
        

Avec cette syntaxe, vous pouvez écrire des règles comme les suivantes.

Completeness "colA" > 0.5 where "colB = 10"
ColumnValues "colB" in ["A", "B"] where "colC is not null" with threshold > 0.9
ColumnLength "colC" > 10 where "colD != Concat(colE, colF)"

Nous allons vérifier que l’instruction SparkSQL fournie est valide. Si elle n’est pas valide, l’évaluation des règles échouera et nous lancerons un IllegalArgumentException au format suivant :

Rule <DQDL Rule> where "<invalid SparkSQL>" has provided an invalid where clause :
<SparkSQL Error>

Comportement de la clause Where lorsque l’identification des enregistrements d’erreur au niveau des lignes est activée

Avec la Qualité des données d’AWS Glue, vous pouvez identifier les enregistrements spécifiques qui ont échoué. Lorsque vous appliquez une clause Where à des règles qui prennent en charge les résultats au niveau des lignes, nous étiquetons les lignes filtrées par la clause Where en tant que Passed.

Si vous préférez étiqueter séparément les lignes filtrées en tant que SKIPPED, vous pouvez définir les paramètres additionalOptions suivants pour la tâche ETL.

object GlueApp {
  val datasource = glueContext.getCatalogSource(
    database="<db>",
    tableName="<table>",
    transformationContext="datasource"
  ).getDynamicFrame()

  val ruleset = """
    Rules = [
       IsComplete "att2" where "att1 = 'a'"        
    ]
  """

  val dq_results = EvaluateDataQuality.processRows(
    frame=datasource,
    ruleset=ruleset,
    additionalOptions=JsonOptions("""
        {
          "rowLevelConfiguration.filteredRowLabel":"SKIPPED"
        }
      """
    )
  )
}

À titre d’exemple, reportez-vous à la règle et à la trame de données suivantes :

IsComplete att2 where "att1 = 'a'"

Règles dynamiques

Vous pouvez désormais créer des règles dynamiques pour comparer les métriques actuelles produites par vos règles avec leurs valeurs historiques. Ces comparaisons historiques sont rendues possibles en utilisant l’opérateur last() dans les expressions. Par exemple, la règle RowCount > last() fonctionne lorsque le nombre de lignes de l’exécution en cours est supérieur au nombre de lignes précédent le plus récent pour le même jeu de données. last() prend un argument de nombre naturel facultatif décrivant le nombre de métriques précédentes à prendre en compte ; last(k) où k >= 1 renvoyera aux dernières métriques k.

Pour former des expressions valides, utilisez last(k), où k > 1 nécessite une fonction d’agrégation pour réduire plusieurs résultats historiques en un seul nombre. Par exemple, RowCount > avg(last(5)) vérifiera si le nombre de lignes du jeu de données actuel est strictement supérieur à la moyenne des cinq dernières lignes du même jeu de données. RowCount > last(5) générera une erreur, car le nombre de lignes du jeu de données actuel ne peut pas être comparé de manière significative à une liste.

Fonctions d’agrégation prises en charge :

Exemples d’expressions

ColumnCorrelation

DistinctValuesCount

La plupart des types de règles comportant des conditions ou des seuils numériques prennent en charge les règles dynamiques. Consultez le tableau fourni, Analyseurs et règles pour vérifier si les règles dynamiques sont disponibles pour le type de règle que vous utilisez.

Exclure les statistiques des règles dynamiques

Vous devrez parfois exclure les statistiques de données de vos calculs de règles dynamiques. Supposons que vous ayez effectué un chargement de données historiques et que vous ne vouliez pas que cela ait un impact sur vos moyennes. Pour ce faire, ouvrez la tâche dans AWS Glue ETL et choisissez l’onglet Qualité des données, puis sélectionnez Statistiques et sélectionnez les statistiques que vous souhaitez exclure. Vous pourrez voir un graphique de tendance ainsi qu’un tableau de statistiques. Sélectionnez les valeurs que vous souhaitez exclure, puis choisissez Exclure les statistiques. Les statistiques exclues ne seront désormais pas incluses dans les calculs de règles dynamiques.

Analyseurs

Les règles DQDL utilisent des fonctions appelées analyseurs pour rassembler des informations sur vos données. Ces informations sont utilisées par l’expression booléenne d’une règle afin de décider si cette dernière doit être considérée comme réussie ou échouée. Par exemple, la règle RowCount RowCount > 5 utilisera un analyseur de nombre de lignes pour découvrir le nombre de lignes de votre jeu de données et comparer ce nombre à l’expression > 5 pour vérifier s’il existe plus de cinq lignes dans le jeu de données actuel.

Il est parfois préférable, plutôt que de créer des règles, de créer des analyseurs et de les configurer pour qu’ils génèrent des statistiques utiles à la détection d’anomalies. Dans de tels cas, vous pouvez créer des analyseurs. Les analyseurs se distinguent des règles de la manière suivante.

Les analyseurs peuvent exister indépendamment sans règles, vous offrant ainsi la possibilité de les configurer rapidement et de créer progressivement des règles de qualité des données.

Certains types de règles peuvent être saisis dans le bloc Analyzers de votre jeu de règles afin d’exécuter les règles nécessaires aux analyseurs et rassembler des informations sans avoir à valider une quelconque condition. Certains analyseurs ne sont pas associés à des règles et ne peuvent être saisis que dans le bloc Analyzers. Le tableau ci-dessous précise pour chaque élément s’il est pris en charge en tant que règle ou en tant qu’analyseur autonome, avec des informations supplémentaires pour chaque type de règle.

Exemple de jeu de règles avec analyseur

Le jeu de règles suivant utilise :

Les résultats des métriques de l’analyseur peuvent être consultés dans l’onglet Qualité des données de votre exécution de tâche.

Rules = [
   RowCount > avg(last(3))
]
Analyzers = [
   DistinctValuesCount "Name",
   ColumnLength "Name"
]     
        

La Qualité des données d’AWS Glue prend en charge les analyseurs suivants.

Commentaires

Vous pouvez utiliser le caractère « # » pour ajouter un commentaire à votre document DQDL. Tout ce qui se trouve après le caractère « # » et jusqu’à la fin de la ligne est ignoré par DQDL.

Rules = [
    # More items should generally mean a higher price, so correlation should be positive
    ColumnCorrelation "price" "num_items" > 0
]