Fichiers et modèles DCM Projects¶

Mappage entre les définitions de projet et les objets de projet¶

Les fichiers de définition DCM Projects ne sont pas strictement liés à un objet DCM project spécifique. Vous pouvez utiliser le même ensemble de définitions pour effectuer un déploiement sur plusieurs projets, soit sur différents comptes Snowflake, soit en référençant différents profils de configuration. Par exemple, les mêmes fichiers de définition sur une branche du référentiel peuvent être déployés à la fois sur les comptes DEV et PROD comme indiqué dans la figure suivante.

De même, vous pouvez exécuter un objet DCM Projects en référençant des fichiers de définition provenant de différents chemins. Par exemple, votre automatisation CI/CD peut déployer des définitions à partir de votre branche principale et vous pouvez exécuter manuellement un PLAN à partir de vos fichiers de définitions locaux vers le même projet pour vérifier comment vos définitions diffèrent du dernier déploiement. Vous pouvez également utiliser cette approche pour les déploiements manuels ad hoc à partir d’autres branches ou de chemins locaux.

Macros¶

Les fichiers macro sont nécessaires. Les fichiers SQL situés dans le dossier et ses sous-dossiers macros. Ils ne peuvent contenir que des macros.

Un exemple de structure de répertoire d’un DCM project avec des fichiers macro est :

My_dcm_project
 |_ manifest.yml
 |_ sources
    |_ definitions
       |_ my_definitions.sql
    |_ macros
       |_ my_global_macros.sql

Comme les fonctions dans les langages de programmation classiques, les macros permettent d’organiser les parties de code souvent utilisées en fonctions réutilisables, évitant ainsi les répétitions et suivant le principe DRY (Ne vous répétez pas). Les macros dans DCM Projects fonctionnent de la même manière que les `macros Jinja2<https://jinja.palletsprojects.com/en/stable/templates/#macros>`_ avec les exceptions suivantes :

• Emplacement dédié aux fichiers de macro dans le dossier macros.

• Les macros définies dans les fichiers de macros sont automatiquement visibles dans les autres fichiers sources. La balise Jinja `import<https://jinja.palletsprojects.com/en/stable/templates/#import>`_ n’est pas autorisée.

• La définition en double d’une macro portant le même nom est détectée et rejetée.

Commentaires de modèle¶

Dans les commandes SQL, vous pouvez ajouter -- avant votre code pour commenter la ligne. Jinja traite toujours les variables au sein du code SQL, mais laisse les commentaires SQL.

Par exemple, le code Jinja suivant :

-- hello {{ project_owner_role }}

Se présente comme :

-- hello DCM_DEVELOPER

Les commandes commentées ne s’exécutent pas en SQL. Vous pouvez utiliser les commentaires des modèles pour déboguer les modèles Jinja sans affecter votre code SQL.

Pour ignorer le code Jinja pendant le rendu, ajoutez # à l’intérieur des crochets d’ouverture et de fermeture, comme indiqué dans l’exemple suivant :

{# This Jinja comment will not appear in the rendered output. #}

Configurations¶

Lorsque vous utilisez des modèles dans vos définitions d’objets, vous disposez des options suivantes :

• Attribuer des valeurs aux variables lors de l’exécution.

• Définir différents profils de configuration sous templating: configurations: dans le manifest.yml. Chaque cible peut référencer une configuration via templating_config. Voir Configurations de la modélisation du projet pour plus de détails.

  Si des profils de configuration sont définis et qu’une cible fait référence à l’un d’eux via templating_config, la configuration est automatiquement appliquée lors de l’utilisation de cette cible. Pour des exemples, voir Planifier un DCM project.

  Le cas d’utilisation principal des profils de configuration dans DCM Projects consiste à cibler différents environnements. Les profils de configuration vous permettent d’effectuer les opérations suivantes :

  • Déployer le même code dans plusieurs environnements.

  • Tester le code de production dans un environnement de non production à une échelle réduite.

  • Conserver plusieurs environnements isolés sur le même compte.

  Toutes les configurations de modélisation ne doivent pas être référencées par un profil cible. Vous pouvez conserver les configurations inutilisées afin de passer d’une configuration de modèle à une autre pour votre cible.

• Définissez les valeurs par défaut partagées sous templating: defaults: pour éviter de répéter des variables communes entre les configurations. Voir Configurations de la modélisation du projet pour plus de détails.

• Écrasez des variables spécifiques avec des valeurs uniques au moment de l’exécution en utilisant l’indicateur --variable dansCLI.

Les variables sont résolues avec une hiérarchie à trois niveaux : valeurs par défaut globales < variables de configuration < variables d’exécution du runtime.

Dictionnaires¶

La modélisation DCM Projects prend en charge les dictionnaires sous forme de valeurs variables, ce qui permet une configuration structurée pour des déploiements complexes à plusieurs locataires ou à plusieurs ressources.

En regroupant les détails de configuration associés dans des dictionnaires, vous obtenez :

• Contrôle granulaire : Appliquez des paramètres spécifiques, tels que la taille des entrepôts, les politiques de conservation et les autorisations, aux ressources individuelles sans écrire une logique unique pour chaque variation.

• Bases de code plus claires : Remplacez les scripts répétitifs codés en dur par des boucles dynamiques qui s’adaptent en fonction de la configuration.

• Évolutivité : Intégrez de nouvelles équipes ou ressources en ajoutant des entrées à votre configuration, plutôt qu’en refactorisant les pipelines de déploiement.

templating:
  defaults:
    user: "GITHUB_ACTIONS_SERVICE_USER"
    wh_size: "X-SMALL"
  configurations:
    PROD:
      env_suffix: ""
      project_owner_role: "DCM_PROD_DEPLOYER"
      teams:
        - name: "Marketing"
          wh_size: "MEDIUM"
          data_retention_days: 14
          needs_sandbox_schema: true
        - name: "Finance"
          wh_size: "X-LARGE"
          data_retention_days: 90
          needs_sandbox_schema: false
        - name: "HR"
          data_retention_days: 30
          needs_sandbox_schema: false

-- loop through team dictionaries
{% for team in teams %}
    {% set team_name = team.name | upper %}

    -- inject dictionary values directly into object properties
    define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}
        comment = 'using JINJA dictionary values'
        data_retention_time_in_days = {{ team.data_retention_days }};

    -- pass the name to your macro
    {{ create_team_roles(team_name) }}

    define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.PRODUCTS(
        ITEM_NAME varchar,
        ITEM_ID varchar,
        ITEM_CATEGORY array
    )
    data_metric_schedule = 'TRIGGER_ON_CHANGES';

    {% if team_name == 'HR' %}
        define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.EMPLOYEES(
            NAME varchar,
            ID int
        )
        comment = 'This table is only created in HR';
    {% endif %}

    -- use dictionary booleans to deploy optional infrastructure
    {% if team.needs_sandbox_schema | default(false) %}
        define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}_SANDBOX
            comment = 'Sandbox schema defined via dictionary flag'
            data_retention_time_in_days = 1;
    {% endif %}

{% endfor %}