Snowflake DCM Projects¶

Termes clés¶

Ci-dessous figurent les termes clés que vous devez connaître lorsque vous travaillez avec DCM Projects.

Définitions déclaratives

Dans DCM Projects, vous définissez l’état souhaité de votre environnement Snowflake, par exemple les tables, schémas ou rôles qui doivent exister, indépendamment de l’état actuel des objets. Vous ne spécifiez pas chaque étape pour les créer ou les modifier. Vous décrivez ce que vous voulez, et Snowflake détermine comment y parvenir.

Plus précisément, DCM Projects tire parti des instructions DEFINE avec des fonctionnalités de modélisation. Les fichiers de projet sont ainsi réutilisables et personnalisables pour différents environnements. L’ordre et l’emplacement des instructions DEFINE au sein d’un projet n’affectent pas les résultats. Snowflake collecte et trie toutes les instructions avant d’appliquer les modifications, de sorte que vous n’avez pas besoin de gérer manuellement les séquences ou les dépendances.

Fichiers de projet DCM

Un DCM project est basé sur un ensemble de fichiers sources SQL et YAML, généralement gérés dans un dépôt Git ou dans votre espace de travail local. Vous définissez les objets Snowflake, leurs attributs, leurs relations et leurs contraintes pour un DCM project dans vos fichiers de définition de projet (fichiers SQL). Vous mettez à jour vos fichiers de projet dans un espace de travail de développement. Les modifications ne prennent effet dans Snowflake qu’après leur déploiement via un objet DCM project.

Objet de projet DCM

Un DCM project est un objet de niveau schéma dans Snowflake que vous utilisez pour déployer et gérer les objets définis dans les fichiers DCM project. Vous avez besoin d’un objet DCM project pour chaque environnement cible.

L’objet DCM project est utilisé pour exécuter les commandes DCM et stockent les artefacts immuables et les fichiers de définition de tous les déploiements exécutés.

Bien qu’un DCM project soit un objet de niveau schéma, vous pouvez l’utiliser pour créer et gérer des objets dans d’autres bases de données. Vous pouvez également exécuter un DCM project pour effectuer une série de modifications de votre flux de travail afin de pouvoir prévisualiser les modifications avant de les déployer.

Exigences¶

• Utilisez Snowsight, Snowflake CLI, SQL ou Cortex CLI pour gérer DCM Projects.

• Vous avez besoin d’une base de données et d’un schéma où vous pouvez créer vos objets DCM project.

• Stockez vos définitions DCM project localement ou dans l’espace de travail Snowflake.

• Utilisez Git pour la collaboration, la gestion des versions et la synchronisation des modifications.

• Si vous souhaitez exécuter des définitions locales à l’aide de Snowflake CLI, vous avez également besoin de privilèges pour créer une zone de préparation temporaire dans le schéma de votre objet DCM project cible.

Considérations et limites¶

• Taille du projet

  • Actuellement, DCM Projects prend en charge jusqu’à 1 000 fichiers sources et 10 000 définitions d’objets rendus ou autorisations.

    Au-delà de 1 000 fichiers ou de 10 000 définitions, vous pouvez subir une dégradation des performances et, dans certains cas, un échec de l’exécution.

    La consolidation des définitions en moins de fichiers montre généralement des temps d’exécution plus rapides pour les commandes PLAN et DEPLOY.

    Cette limite sera augmentée pendant la période de prévisualisation publique, à mesure que les performances et l’évolutivité continueront de s’améliorer.

• Ensemble des modifications

  Les deux commandes PLAN et DEPLOY listent les modifications DDL dans le fichier plan_result.json. L’ensemble des modifications répertorie les opérations effectuées ou planifiées (CREATE, ALTER, DROP) et les attributs individuels concernés, tels que le commentaire, la planification et le délai d’attente.

  Important

  Pendant la phase de prévisualisation de DCM Projects, il n’est pas garanti que l’ensemble des modifications capture chaque modification granulaire dans toutes les propriétés de chaque objet.

• Modélisation

  • Comme les fichiers de définition sont des modèles Jinja2, toutes les limitations relatives aux modèles Jinja2 s’appliquent.

  • Les variables de modélisation DCM ne sont pas destinées aux informations sensibles telles que les identifiants de connexion. Les définitions SQL rendues n’éditent pas les valeurs insérées par les variables d’environnement.

Cas d’utilisation clés pour DCM Projects¶

Cette section décrit les principaux cas d’utilisation de DCM Projects et comment ils aident à résoudre les défis que les entreprises du secteur des données rencontrent à grande échelle. Ces cas d’utilisation peuvent être répartis en deux catégories générales basées sur la responsabilité des équipes :

• Équipes de plateforme qui gèrent l’infrastructure et la gouvernance

• Équipes de fonctionnalités qui gèrent les produits de données et les pipelines individuels

DCM Projects pour la gestion de l’infrastructure¶

DCM Projects aide à résoudre les défis suivants que les équipes de plateforme rencontrent souvent :

Lorsque les équipes de plateforme souhaitent déployer et maintenir une infrastructure normalisée pour plusieurs unités commerciales, elles peuvent utiliser DCM Projects pour définir un ensemble d’objets standard dans le code comme fichiers SQL. Et avec Jinja, ce modèle peut être paramétré, par exemple, selon le nom de l’équipe, et déployé plusieurs fois.

Exemple : Créer un DCM project dédié pour chaque unité commerciale¶

Une approche consiste à créer un DCM project dédié pour chaque unité commerciale, tous les projets référençant les mêmes fichiers de définition paramétrés, comme le montre l’exemple definitions.sql suivant :

CopyExpand

DEFINE DATABASE {{team_name}}_DB;

DEFINE ROLE {{team_name}}_ADMIN;

DEFINE WAREHOUSE {{team_name}}_WH WITH
  warehouse_size = '{{wh_size}}'
  auto_suspend = 300;

GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;

GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;

GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;

Show lessSee more

Scroll to top

Exécutez le DCM project à l’aide de la commande suivante :

CopyExpand

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (team_name => 'Finance', wh_size => 'LARGE')
FROM
  ...

Show lessSee more

Scroll to top

Exemple : Créez un seul DCM project pour plusieurs unités commerciales¶

Dans cette approche, vous gérez l’infrastructure de plusieurs unités commerciales dans un seul DCM project en utilisant des boucles dans votre modèle Jinja, comme indiqué dans l’exemple definitions.sql suivant :

CopyExpand

{% for team_name in teams %}

  DEFINE DATABASE {{team_name}}_DB;
  DEFINE ROLE {{team_name}}_ADMIN;
  DEFINE WAREHOUSE {{team_name}}_WH
    WITH
      warehouse_size = '{{wh_size}}'
      auto_suspend = 300;

  GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;
  GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;

{% endfor %}

Show lessSee more

Scroll to top

Exécutez le DCM project à l’aide de la commande suivante :

CopyExpand

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (teams => ['Finance', 'HR', 'Engineering'], wh_size => 'MEDIUM')
FROM
  ...

Show lessSee more

Scroll to top

Cela permet aux équipes et aux administrateurs de plateforme d’apporter facilement des modifications telles que :

• Ajouter une nouvelle équipe à la liste pour déployer le modèle d’infrastructure existant pour cette équipe.

• Retirer une équipe de la liste pour supprimer l’infrastructure de cette équipe.

• Ajouter un nouveau rôle READ_ONLY pour toutes les équipes.

• Modifier des configurations spécifiques telles que des autorisations ou la taille de l’entrepôt dans toutes les équipes ou pour une équipe spécifique.

• Exécuter PLAN pour comparer l’état actuel aux normes attendues et le redéployer pour rétablir les normes.

DCM Projects pour les pipelines de données¶

DCM Projects aide à résoudre les défis suivants que les équipes de fonctionnalités rencontrent souvent :

Les unités commerciales qui souhaitent créer et gérer facilement leurs pipelines de données peuvent utiliser DCM Projects pour définir, tester, déployer et itérer sur leur logique métier.

Vous pouvez :

• Gérer les types d’objets Snowflake tels que les tables, les tables dynamiques, les vues, les entrepôts, les rôles, les autorisations, les fonctions de métrique des données et les attentes, le tout dans un seul projet.

• Tester et déployer des modifications incrémentielles dans les pipelines. Vous pouvez modifier les configurations, mettre en œuvre une logique de transformation et ajouter des colonnes et des vues.

• Prévisualiser les échantillons de données pour valider la logique de transformation avant de déployer les objets.

• Déployer la même définition de pipeline dans plusieurs environnements.

• Tester les attentes en matière de qualité des données dans les environnements de pré-prod avant de déployer les changements en production.

DCM Projects offre des fonctionnalités supplémentaires pour la création et la gestion de pipelines de données. Voir DCM Projects pour pipelines de données pour plus de détails.