Projets dbt sur Snowflake¶

Flux de travail CI/CD pour les objets de projet dbt¶

Les objets de projet dbt prennent en charge les commandes CLI Snowflake que vous pouvez utiliser pour créer et gérer des projets dbt à partir de la ligne de commande. Cela est utile pour intégrer des projets dbt dans vos flux de travail d’ingénierie des données et pipelines CI/CD. Pour plus d’informations, voir Snowflake CLI, Intégration de CI/CD à Snowflake CLI, et Commandes snow dbt.

Gestion des versions pour les objets et fichiers de projet dbt¶

Snowflake conserve les versions des objets de projet dbt et des fichiers de projet correspondants. Vous pouvez utiliser cette gestion des versions pour suivre et gérer les modifications tout au long de votre cycle de vie du développement des données et du déploiement. Snowflake identifie les versions des objets de projet dbt dans la zone de préparation du projet dbt comme indiqué dans l’exemple suivant :

snow://dbt/my_db.my_schema.my_dbt_project_object/versions/version_id

version_id peut être l’un des identificateurs suivants :

• VERSION$<num> – spécifie un identificateur de version sous la forme VERSION$<num>, où <num> is a positive integer, for example, VERSION$1.

  Le numéro de version commence à 1 lorsque vous créez un objet de projet dbt et augmente de un à chaque nouvelle version de l’objet de projet dbt.

  Snowflake incrémente l’identificateur de version lorsque vous effectuez les tâches suivantes :

  • Redeploy dbt project à partir d’un espace de travail (exécute la commande ALTER).

  • Mettre à jour le projet en utilisant la commande ALTER DBT PROJECT.

  • Exécuter la commande CLI snow dbt deploy Snow sans l’option --force.

  Snowflake réinitialise l’identificateur de version sur 1 et suppriment tous les alias de version lorsque vous exécutez les commandes suivantes :

  • La commande CREATE DBT PROJECT dans SQL avec l’option OR REPLACE.

  • La commande snow dbt deploy avec l’option --force dans le Snowflake CLI.

• LAST – Indique la version la plus récente de l’objet du projet dbt.

• FIRST – Indique la version la plus ancienne de l’objet de projet dbt.

• version_name_alias – Indique un alias de nom de version personnalisée que vous avez créé pour une version spécifique de l’objet de projet dbt en utilisant la commande ALTER DBT PROJECT avec l’option ADD VERSION. Un alias de nom de version correspond toujours à un identificateur de version spécifique, tel que VERSION$3.

Les fichiers de projet stockés dans la zone de préparation de projet dbt sont organisés par version, chaque version ayant son propre sous-répertoire. Par exemple, un objet de projet dbt nommé my_dbt_project_object avec un identificateur de version de VERSION$3 et un fichier de projet dbt nommé dbt_project.yml peut être référencé comme indiqué dans l’exemple suivant :

snow://dbt/my_db.my_schema/my_dbt_project_object/versions/VERSION$3/dbt_project.yml

projets dbt¶

Les exigences, considérations et limitations suivantes s’appliquent aux configurations de projet dbt prises en charge par dbt Projects on Snowflake :

• Seuls les projets dbt Core sont pris en charge. Les projets dbt Cloud ne sont pas pris en charge. dbt Projects on Snowflake exécute la version 1.9.4 de dbt-core et la version 1.9.2 de dbt-snowflake. Lorsque vous migrez un projet dbt existant vers Snowflake, vos versions dbt n’ont pas besoin de s’aligner sur les versions de Snowflake.

• Chaque dossier de projet dbt dans votre espace de travail Snowflake doit contenir un fichier profiles.yml qui spécifie une cible warehouse, database, schema et role dans Snowflake pour le projet. Le type doit être défini sur snowflake. dbt nécessite un account et un user, mais ceux-ci peuvent être laissés avec une chaîne vide ou arbitraire, car le projet dbt s’exécute dans Snowflake sous le compte actuel et le contexte utilisateur.

• Un projet dbt dans un espace de travail ne peut pas avoir plus de 20 000 fichiers dans sa structure de dossiers. Cette limite inclut tous les fichiers dans le répertoire et les sous-répertoires du projet dbt, y compris les répertoires target/dbt_packages/logs, qui sont l’endroit où les fichiers journaux sont enregistrés lorsqu’un projet dbt est exécuté à partir de l’espace de travail.

Procédures stockées¶

Lorsque vous utilisez une procédure stockée pour appeler EXECUTE DBT PROJECT, utilisez une procédure stockée avec droits de l’appelant. Pour plus d’informations, voir CREATE PROCEDURE et Création d’une procédure stockée.

Espaces de travail pour dbt Projects on Snowflake¶

Les exigences, considérations et limites suivantes s’appliquent aux espaces de travail pour dbt Projects on Snowflake :

Dépendances dbt¶

Les exigences, considérations et limitations suivantes s’appliquent aux dépendances dbt pour les projets dbt dans dbt Projects on Snowflake :

• Vous devez exécuter la commande dbt deps à partir d’un espace de travail pour dbt Projects on Snowflake ou utiliser la commande snow dbt execute de Snowflake CLI pour construire et remplir le dossier dbt_packages du projet. Vous ne pouvez pas exécuter la commande deps en utilisant la commande EXECUTE DBT PROJECT SQL. Vous pouvez également exécuter deps sur votre projet dbt local avant de le déployer dans Snowflake en tant qu’objet de projet dbt.

• La spécification des paquets Git dans le fichier packages.yml n’est pas pris en charge.

• Une règle réseau et une intégration d’accès externe sont nécessaires pour permettre à Snowflake d’accéder aux référentiels des dépendances. Pour plus d’informations, voir Créer une intégration d’accès externe dans Snowflake pour les dépendances dbt. Pour plus d’informations sur les limitations de l’accès au réseau externe, voir Limitations de l’accès au réseau externe.

Télémétrie, journalisation et traçage¶

Les exigences, considérations et limitations suivantes s’appliquent à la télémétrie, à la journalisation et au traçage pour dbt sur Snowflake :

• Les espaces de travail pour dbt Projects on Snowflake ne diffusent pas stdout de manière dynamique, et stdout n’est visible qu’à l’issue de la commande.

• L’affichage des journaux et du traçage nécessite que vous définissiez le LOG_LEVEL et le TRACE_LEVEL sur l’objet du projet dbt. Pour plus d’informations, voir Contrôle d’accès pour les projets dbt sur Snowflake et Surveiller des projets dbt sur Snowflake.

• Par défaut, Snowflake collecte la télémétrie dans le tableau SNOWFLAKE.TELEMETRY.EVENTS par défaut. Si vous avez un tableau des événements personnalisé qui est défini comme tableau des événements pour votre compte, les données de télémétrie y sont collectées. Si vous utilisez un compte Enterprise Edition, vous pouvez créer un tableau des événements pour collecter des données de télémétrie et les associer à la base de données dans laquelle l’objet de projet dbt est déployé. Pour plus d’informations, voir Aperçu de la table d’événements.