"Vous ne savez rien": peut-on repartir des bases?

Pour l'instant, nous n'avons pas connecté le Store à la base de données. Pour connecter le Store et commencer à matérialiser nos vues et nos tables, nous devons dire à dbt où trouver les identifiants et les informations de connexion. Pour cela, nous créons un fichier profiles.yml.

C'est quoi, un fichier profiles.yml?

Le fichier de profile dbt est nécessaire parce que dbt doit savoir où vos données sont stockées, comment s'y connecter et quels paramètres utiliser. Avec un fichier de configuration centralisé, vous pouvez gérer ces paramètres au même endroit et passer d'un environnement à l'autre, par exemple développement et production, sans modifier vos modèles dbt.

Voici les principaux éléments que l'on retrouve dans un fichier de profile dbt:

1. Détails de connexion à la base de données: type de base de données, par exemple BigQuery, Snowflake, Redshift ou SQL Server, hôte, nom de base, schéma et paramètres d'authentification.
2. Profiles: vous pouvez définir plusieurs profiles dans le fichier, ce qui permet de basculer facilement entre différents environnements ou entrepôts de données.

En résumé, le fichier de profile dbt est essentiel pour configurer et connecter dbt à votre entrepôt de données, et pour fluidifier le processus de transformation.

Ce fichier n'est pas situé dans le projet lui-même, car il contient des identifiants que nous ne voulons pas exposer dans Git. Il se trouve généralement dans le dossier ~/.dbt.

Comment dbt sait-il quel profile utiliser?

Lorsque vous exécutez des commandes dbt dans un projet donné, dbt détermine quel profile utiliser à partir de la configuration définie dans profiles.yml. Ce fichier se trouve généralement dans ~/.dbt/.

Voici comment dbt sait quel profile utiliser pour un projet précis:

1. Profile par défaut:
   • Si votre fichier profiles.yml contient un seul profile, dbt l'utilise par défaut. C'est le cas lorsque vous n'avez qu'un seul environnement ou qu'une seule connexion à un entrepôt de données.
2. Configuration du projet:
   • Dans le fichier dbt_project.yml de votre projet dbt, vous pouvez préciser le profile à utiliser avec la clé profile. Si cette clé n'est pas définie, dbt utilise le profile par défaut du fichier profiles.yml.

Exemple de dbt_project.yml:

name: my_project
version: 1.0

profile: my_custom_profile

Dans cet exemple, dbt utilise le profile nommé my_custom_profile pour le projet my_project.

En fournissant l'information de profile dans dbt_project.yml, vous indiquez à dbt quel profile utiliser pour un projet donné.

Quelle est la différence entre un profile et une target?

Dans le contexte de dbt, un profile et une target ont des rôles différents:

1. Profile:
   • Un profile dbt est une configuration nommée dans profiles.yml qui contient les informations de connexion à votre entrepôt de données.
   • Il inclut le type de base de données, par exemple BigQuery, Snowflake ou Redshift, l'hôte, le nom de la base, le schéma et les paramètres d'authentification.
   • Vous pouvez définir plusieurs profiles dans profiles.yml afin de configurer des connexions pour différents environnements, par exemple développement et production.
   • Les profiles servent principalement à préciser comment dbt se connecte à un entrepôt de données.
   • Le Dashboards Store devrait utiliser un seul profile.
2. Target:
   • Une target dbt est un environnement ou un déploiement précis de votre projet dbt.
   • Les targets configurent l'exécution des commandes dbt dans un contexte donné, comme le développement ou la production.
   • Les targets sont souvent indiquées avec l'option --target, ce qui permet de changer facilement d'environnement.
   • Les targets peuvent référencer des profiles précis dans profiles.yml, afin d'utiliser différentes connexions d'entrepôt selon l'environnement.
   • En résumé, un profile est la configuration générale permettant de connecter dbt à un entrepôt de données et il est défini dans profiles.yml. Une target est une configuration spécifique pour exécuter dbt dans un contexte ou un environnement particulier. Les targets vous aident à gérer et à changer d'environnement de déploiement pour votre projet dbt.

D'accord. Il me faut un profile. Peux-tu m'aider à démarrer?

Lors de l'initialisation de cssXX.dashboards_store, quelques informations vous ont été demandées:

• Quelle est l'adresse IP de votre base de données?
• Quel est le port de votre base de données?

Ces informations ont servi à générer un exemple de profiles.yml, disponible dans cssXX.dashboards_store/profiles-sample.yml.

Vous devez maintenant compléter et déplacer profiles-sample.yml:

1. Ajoutez le mot de passe de l'utilisateur de base de données: modifiez profiles-sample.yml et remplacez password: dontLookAtMeImSecret par le vrai mot de passe.
2. Déplacez profiles-sample.yml vers ~/.dbt/profiles.yml:

mv profiles-sample.yml ~/.dbt/profiles.yml

Pourquoi ai-je trois targets dans profiles.yml?

Développement

Vous pouvez voir une target comme un environment. Les targets permettent à dbt de gérer vos différents environnements. La target par défaut de profiles.yml est dev. Elle est configurée pour utiliser votre nom comme schéma et c'est la target que vous utiliserez principalement pour développer vos modèles. Comme elle utilise votre nom comme schéma de base, les tables matérialisées et les modifications de code que vous faites n'altèrent pas les matérialisations des autres personnes sur le même projet. Avec les targets, plusieurs personnes peuvent travailler sur le même projet et la même base de données sans se marcher sur les pieds.

Staging et production

Le fichier profiles.yml contient deux autres targets:

1. staging: cette target sert à tester votre code avant de le déployer en production. Elle est configurée pour utiliser le schéma dbo dans la base store_dev. Vous pouvez utiliser le schéma de staging pour exécuter votre code de nuit et le prévisualiser avant de l'exécuter contre la base de production.
2. prod: cette target sert à déployer votre code en production. Elle est configurée pour utiliser le schéma dbo dans la base store. Vous ne devriez pas l'utiliser explicitement à moins de savoir exactement ce que vous faites.

Idéalement, vos dashboards Power BI non publiés devraient être connectés à l'environnement staging, et vos dashboards Power BI publiés devraient être connectés à l'environnement prod. Vous pouvez ainsi tester les modifications aux dashboards et aux scripts sans affecter vos utilisateurs finaux.