Limites, exigences et considérations pour dbt Projects on Snowflake

Avant d’utiliser dbt Projects on Snowflake, examinez les exigences, les considérations et les limites :

Limites, exigences et considérations pour les configurations de projet dbt

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

  • Only dbt Core projects are supported. dbt Cloud projects aren’t supported. When you migrate an existing dbt Core project to Snowflake, it must be compatible with supported dbt Core versions.

  • 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.

  • Les variables d’environnement (par exemple, {{ env_var ('MY_ENV_VAR') }}) ne sont pas prises en charge lors de l’exécution d’un objet de projet dbt. Comme alternative, vous pouvez utiliser des variables de projet (par exemple, --vars). Pour plus d’informations, voir Variables de projet.

  • Serverless tasks can’t be used to execute dbt project objects. When you create a task that executes the EXECUTE DBT PROJECT command, you must specify a user-managed warehouse.

  • L’exécution de plusieurs commandes EXECUTE DBT PROJECT simultanément sur le même objet de projet dbt n’est pas prise en charge, même en cas d’utilisation de sélecteurs de modèles (par exemple, EXECUTE DBT PROJECT foo ARGS='--select model1' et EXECUTE DBT PROJECT foo ARGS='--select model2'). Cela pourrait entraîner des messages d’erreur interne inattendus. Exécutez une seule commande EXECUTE DBT PROJECT sur un objet de projet dbt donné à la fois. Si vous devez exécuter plusieurs commandes en parallèle, créez des objets de projet dbt distincts pour chaque commande simultanée.

    L’utilisation d’une configuration de threading dans dbt (par exemple,:code:threads: 8) est prise en charge et encouragée. La limitation de la simultanéité s’applique uniquement à l’exécution de plusieurs appels EXECUTE DBT PROJECT en même temps sur le même objet de projet dbt.

Limites, exigences et considérations pour les 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.

Limitations, exigences et considérations pour la télémétrie, la journalisation et le 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 Moniteur dbt Projects on 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.

Limites du DAG de l’historique des requêtes

Le DAG de l’historique des requêtes requiert les deux artefacts manifest.json et run_results.json pour rendre la visualisation. Si l’exécution d’un objet de projet dbt échoue avant que run_results.json ne soit généré, l’onglet DAG dans Query Details affiche « Aucune donnée disponible » à la place.

Les causes communes d’exécutions qui échouent rapidement et qui empêchent run_results.json d’être généré incluent :

  • Privilèges insuffisants pour exécuter l’objet de projet dbt.

  • Configuration du projet non valide (par exemple, un fichier dbt_project.yml manquant ou malformé).

  • Dépendances manquantes qui n’ont pas été installées avec dbt deps.

To resolve this, check the dbt Output section in the Query Details tab for error messages, fix the underlying issue, redeploy the dbt project object, and re-execute it. For more information about monitoring dbt project object executions, see Affichage du DAG de l’historique des requêtes.