DCM Projects pour pipelines de données¶

Les DCM Projects offrent une expérience de développeur à cycle de vie complet qui comprend des capacités adaptées à la gestion des pipelines de données.

Les commandes spécifiques aux pipelines ne s’appliquent pas à tous les types d’objets. Elles étendent les commandes principales pour les cas d’utilisation suivants du pipeline :

La commande REFRESH pour les tables dynamiques géré par un DCM project.
Commande TEST pour les attentes en matière de qualité des données attachés à des objets gérés.
Commande PREVIEW pour vérifier l’exemple de sortie d’une table dynamique, d’une vue ou d’une table avant le déploiement.

La commande REFRESH pour les tables dynamiques¶

Après avoir déployé une modification de la définition du pipeline, vous pouvez actualiser les tables dynamiques à l’intérieur du projet de pipeline avant de tester les attentes en matière de qualité des données, de sorte que toute nouvelle logique de transformation soit appliquée de bout en bout.

Vous pouvez actualiser toutes les tables dynamiques gérées par le|dcm-object| et leurs tables dynamiques requises en amont avec une seule commande. Cette commande s’applique uniquement aux tables dynamiques qui sont déployées et gérées par le projet référencé, indépendamment des fichiers de définition. Les autres types d’objets, tels que les tâches, ne sont pas affectés.

Voir Commande TEST pour les attentes en matière de qualité des données pour des exemples d’utilisation qui combinent REFRESH et TEST.

La commande s’exécute jusqu’à ce que toutes les actualisations des tables dynamiques soient terminées et renvoie un résumé des modifications de lignes ou des erreurs pour chaque table dynamique.

Pour exécuter la commande REFRESH :

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_STG
  REFRESH ALL;

snow dcm refresh --target STAGE --save-output

La sortie JSON contient les résultats de l’opération d’actualisation de la table dynamique au format suivant :


Propriété	Description
`dts_refresh_result`	Contient les résultats de l’opération d’actualisation de la table dynamique.
`refreshed_tables[]`	Un tableau d’entrées, une pour chaque table dynamique actualisée.
`table_name`	Nom complet de la table dynamique qui a été actualisée.
`statistics`	Actualiser les statistiques de la table.
`inserted_rows`	Nombre de lignes insérées lors de l’actualisation.
`deleted_rows`	Nombre de lignes supprimées lors de l’actualisation.
`data_timestamp`	Horodatage ISO 8601 représentant le niveau d’actualisation ponctuel des données après l’actualisation.

Un exemple de sortie JSON pour l’actualisation d’une table dynamique :

{
  "dts_refresh_result": {
    "refreshed_tables": [
      {
        "table_name": "db.schema.my_dynamic_table",
        "statistics": {
          "inserted_rows": 150,
          "deleted_rows": 30
        },
        "data_timestamp": "2026-03-16T12:00:00.000Z"
      }
    ]
  }
}

Commande TEST pour les attentes en matière de qualité des données¶

Vous pouvez définir des attentes en matière de qualité des données sous forme de contrôles de qualité à toutes les étapes de la transformation de vos données :

Attachez les attentes aux données brutes de vos tables de destination de la couche Azure pour vous assurer que votre entrée brute répond aux attentes et ne provoque pas d’erreurs lors de la transformation.
Attachez des attentes en tant que contrôles de qualité à votre couche argent pour faciliter le débogage des problèmes de données grâce à différents points de contrôle à différents stades de transformation.
Attachez les attentes à votre couche or pour garantir la qualité de la sortie de votre produit de données.
Attachez les attentes des consommateurs en aval de votre produit de données à votre couche or afin de pouvoir valider ces attentes avant de déployer les changements importants.

Voir Fonction de métrique des données pour savoir comment joindre des attentes dans les projets DCM.

Vous pouvez tester toutes les attentes en matière de qualité des données attachées aux tables, tables dynamiques ou vues qui sont gérées par les DCM project avec une seule commande.

Les fonctions de métrique des données qui sont jointes sans attentes ne sont pas vérifiées.

Vous pouvez utiliser les commandes CLI pour configurer des tests automatisés dans le cadre de votre workflow CI/CD. Par exemple, si vous disposez de données de type production sur unQA, test ou environnement de mise en zone de préparation, vous pouvez suivre les étapes suivantes :

PLAN par rapport à QA pour vérifier les modifications attendues de la définition du projet.
DEPLOY et QA.
REFRESH ALL les tables dynamiques sur QA pour mettre à jour les données en fonction d’une nouvelle logique de transformation et de définitions mises à jour, afin que les attentes ne soient pas testées par rapport à des données obsolètes.
TEST ALL les attentes en matière de qualité des données attachées aux objets de table sur l’environnement QA pour vérifier que la logique nouvellement déployée fonctionne comme prévu et n’a pas d’effets secondaires négatifs sur la forme attendue de votre sortie de données.
Si toutes les attentes sont satisfaites sur l’environnement QA, continuez avec PLAN etDEPLOY vers votre environnement de production.

Pour exécuter la commande TEST :

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_STG
  TEST ALL;

snow dcm test --target STAGE --save-output

La sortie TEST contient l’état global et les attentes avec leurs valeurs au format suivant :

Important

Au cours de la phase de prévisualisation, le format de sortie exact peut changer.

{
  "status": <status>,
  "expectations": [
    {
      "table_name": <table_name>,
      "metric_database": <metric_database>,
      "metric_schema": <metric_schema>,
      "metric_name": <metric_name>,
      "expectation_name": <expectation_name>,
      "expectation_expression": <expectation_expression>,
      "value": <value>,
      "expectation_violated": <expectation_violated>,
      "column_names": <column_names>
    }
  ]
}


Propriété	Description
`status`	Résultat global de l’exécution du test. Valeurs possibles :`SUCCESSFUL` (toutes les attentes sont satisfaites),``FAILED`` (une ou plusieurs attentes ne sont pas respectées).
`expectations[]`	Tableau de résultats des attentes, un pour chaque attente en matière de qualité des données évaluée.
`table_name`	Nom complet de la table ou de la vue sur laquelle l’attente a été évaluée.
`metric_database`	Base de données contenant la fonction de métrique des données.
`metric_schema`	Schéma contenant la fonction de métrique des données.
`metric_name`	Nom de la fonction de métrique des données (par exemple, `NULL_COUNT`, `MIN`, `UNIQUE_COUNT`).
`expectation_name`	Nom de l’attente tel que défini dans le projet.
`expectation_expression`	Expression booléenne par rapport à laquelle la valeur de la métrique est évaluée (par exemple, `value = 0`,``value >= 0``).
`value`	Résultat de l’évaluation de la fonction de métrique des données. Présente uniquement lorsque `expectation_violated` est``false``.
`expectation_violated`	Si l’attente a été respectée ou non. `true` si la valeur de la métrique ne satisfait pas l’expression d’attente ; `false` dans le cas contraire.
`column_names`	Tableau de noms de colonnes sur lesquels la fonction de métrique des données a été évaluée.

Un exemple de sortie JSON pour un test de qualité des données :

{
  "status": "FAILED",
  "expectations": [
    {
      "table_name": "db.schema.my_table",
      "metric_database": "SNOWFLAKE",
      "metric_schema": "CORE",
      "metric_name": "NULL_COUNT",
      "expectation_name": "no_nulls_in_id",
      "expectation_expression": "value = 0",
      "value": 0,
      "expectation_violated": false,
      "column_names": ["ID"]
    },
    {
      "table_name": "db.schema.my_table",
      "metric_database": "SNOWFLAKE",
      "metric_schema": "CORE",
      "metric_name": "UNIQUE_COUNT",
      "expectation_name": "unique_id_check",
      "expectation_expression": "value >= 100",
      "value": null,
      "expectation_violated": true,
      "column_names": ["ID"]
    }
  ]
}

Commande PREVIEW¶

Lorsque vous écrivez ou modifiez l’instruction SELECT d’une table dynamique ou d’une vue, un exemple de sortie permet de valider la forme des données. Pour les graphiques de traçage complexes avec plusieurs étapes de transformation, vous pouvez vérifier la sortie d’une vue en aval ou d’une table dynamique lorsque vous apportez des modifications en amont.

Pour valider que la transformation dans votre code aboutit à la sortie de données attendue avant le déploiement, exécutez la commande PREVIEW.

La commande PREVIEW exécute PLAN pour compiler les définitions actuelles, indépendamment de tout état déployé, puis renvoie un échantillon de données pour une table dynamique, une vue ou une table régulière spécifiée.

Gardez les exigences et les considérations suivantes à l’esprit :

La commande PREVIEW doit toujours faire référence à un nom complet d’un objet de table, sans variables Jinja.
Pour voir des données d’exemple dans la sortie, vous devez vous assurer que les données sont déjà disponibles dans les tables sources.
PREVIEW interroge toutes les instructions SELECT des tables dynamiques et de vues référencées, mais il n’exécute pas de tâches ni d’instructions CREATETABLEASSELECT.

Pour exécuter la commande PREVIEW :

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  PREVIEW
    DCM_PROJECT_DEV.SERVE.V_DASHBOARD_KPI_SUMMARY
  USING CONFIGURATION DEV
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/DCM_Project_Quickstart_1'
  LIMIT 100;

snow dcm preview --object DCM_PROJECT_DEV.SERVE.V_DASHBOARD_KPI_SUMMARY --limit 100