Ce site stocke des cookies sur votre ordinateur. Nous les utilisons afin de personnaliser votre expérience de navigation ainsi que pour des analyses d'audience.
La fréquentation du salon Big Data Paris en septembre 2022 (12.000 participants en physique, 4.000 à distance) nous montre l’intérêt des organisations pour la mise en place de plateformes de données. Data Mesh faisait partie de toutes les conversations. Data Mesh est une approche organisationnelle dans le cadre de la gestion et la gouvernance des données permettant de simplifier la collaboration et le self-service. Nous avons sélectionnés 3 vidéos mettant en lumière l’intérêt de Dremio dans cette nouvelle approche.
BIC : du datawarehouse à la BI self-service : notre trajectoire vers la Data Mesh
Yassine TRAD est Lead Data Architecte depuis 2019 pour le groupe BIC. “Pour faire bref, on va parler ici de 26 millions de produits vendus chaque jour dans le monde. On imagine le volume de donnée et l’importance d’être à jour ! Comment consolider nos données et offrir aux utilisateurs la possibilité de bénéficier d’un haut niveau de reporting réactif sur le monde entier ? Comment combiner les données du référentiel aux données locales ?” L’architecture Data Mesh répond à ces problématiques ! Dans cette vidéo de 26 minutes, Yassine revient sur la transformation que BIC a du opérer et l’intérêt “Data Mesh ready” de Dremio.
source : https://vimeo.com/756298169
CIH BANK : comment une architecture Data Mesh facilite une organisation orientée data
Badr Lemkhenke est Chief Strategy, Customer & Data Officer pour CIH BANK depuis 2017. CIH BANK est la banque centrale du Maroc depuis 100 ans et ces besoins en analyse et reporting de données ne cessent de grandir. Outre les problématiques techniques, Badr revient, dans cette vidéo de 34 mn, sur les difficultés liées aux ressources humaines et la nécessité d’une bonne gouvernance. En conclusion (32:50) , Badr indique que “Dremio nous a permis d’économiser 2 ans dans notre maturité et notre progression Data”.
source : https://vimeo.com/756374164
MICHELIN : des data lakes à la Data Mesh
Joris NURIT, Head of data transformation et Karim HSINI, Architect Data et Analytics pour le groupe MICHELIN, nous raconte le chemin que l’on parcours pour faire en sorte de simplifier l’accès à la donnée au sein du groupe Il s’agit d’une véritable histoire de 24 mn : on y aborde les défis techniques ainsi que les différents rôles des acteurs de la donnée, et enfin l’importance de la gouvernance.
source: https://vimeo.com/755616475 Pour en savoir plus sur l’aventure MICHELIN: https://blogit.michelin.io/creating-and-defining-a-data-driven-culture/
Pour aller plus loin, organiser une démo de la solution DREMIO !
Indiquez-nous vos coordonnées professionnelles et nous vous contacterons rapidement.
Pour Dremio : vous pouvez utiliser Dremio cloud comme Dremio Software (version 22.0 ou supérieures). De plus, il faut disposer d’un utilisateur ayant les droits nécessaires pour effectuer des actions avec dbt (en fonction de ce que vous souhaitez réaliser avec dbt).
Pour dbt : assurez-vous que Python 3.8.x ou une version ultérieure est installée, ainsi que git.
Avoir une connaissance basique du langage sql (ainsi que les CTE).
Compétences basiques dans l’utilisation de la ligne de commande.
Dans la suite, VisualStudio code sera utilisé pour éditer les fichiers du projet. Vous pouvez utiliser un autre IDE ou l’éditeur de fichier de votre choix. Pour VisualStudio code plusieurs plugins existent que vous pouvez installer pour améliorer l’expérience utilisateur dans vos projet dbt comme dbt-power-user.
Dans cet article nous travaillerons sur un environnement linux (ubuntu) avec Dremio software monté avec docker et connecté à une base de données postgres (où le jeux de données est disponible ici).
Initialisation du projet
Installation
On va commencer par se créer un répertoire de travail “dbt_project” pour localiser nos projets dbt. Puis on va créer un environnement python virtuel et y installer dbt-dremio.
mkdir dbt_project/
cd dbt_project/
python3 -m venv dbt-env
Dans la commande “python3 -m venv dbt-env”, vous pouvez choisir un autre emplacement que dbt-env pour la création de l’environnement virtuel. Ici un répertoire dbt-env sera créé dans le répertoire dbt_project.
Ensuite nous allons activer l’environnement et installer dbt-dremio :
source dbt-env/bin/activate # active l'environnement pour Mac ou Linux
dbt-env\Scripts\activate # active l'environnement pour Windows
pip install dbt-dremio # (vous pouvez installer d’autre connecteur comme dbt-postgres …, lors de l’initialisation d’un projet il suffira de choisir quel type de projet vous souhaitez réaliser, ici Dremio)
dbt --version # pour vérifier l'installation
Attention : dans la suite, lorsque vous voudrez exécuter des commandes dbt, il faudra bien vérifier que l’environnement python est bien activé sinon les commandes ne fonctionneront pas. La présence de (dbt-env) indique que l’environnement est activé.
Création du projet
Maintenant que l’installation est terminée, il suffit de créer le projet avec la commande dbt init et de répondre aux questions avec vos informations de connexion.
Précisions concernant les informations à renseigner
Quelques précisions concernant l’object_storage_source, l’object_storage_path, le dremio_space et le dremio_space_folder :
object_storage_source : il faut ici définir l’espace par défaut dans lequel les tables seront créées. Il faut que ce soit un espace de stockage capable de stocker au format iceberg. Si rien n’est spécifié, les tables seront stockées dans la source $scratch.
object_storage_path : il faut ici définir le répertoire dans la source (object_storage_source) dans lequel on souhaite stocker les tables. Si rien n’est spécifié, les tables seront stockées à la racine de la source précisée précédemment. Si vous voulez préciser le chemin d’un sous répertoire il faut séparer les répertoire par un point. Par exemple : repertoire1.sous_repertoire1.sous_sous_repertoire2.
dremio_space : il faut ici définir l’espace par défaut dans lequel les vues seront créées. Il faut donner le nom du space. Si rien n’est spécifié, les vues seront stockées dans l’espace dremio personnel de l’utilisateur.
dremio_space_folder : il faut ici définir le répertoire dans le space dans lequel on souhaite enregistrer les vues. Si rien n’est spécifié, les tables seront stockées à la racine du space.
Le projet est maintenant initialisé. Lors de l’initialisation du projet un fichier profiles.yml est créé (s’il s’agit de votre 1er projet) ou modifié, dans un répertoire .dbt/, au sein de votre répertoire utilisateur (comme l’indique la dernière ligne de log de la commande dbt init). Ce fichier contient tous les profils de connexion des projets dbt. Vous pouvez y ajouter d’autres profils ainsi que d’autres environnements comme nous le verrons dans la suite de l’article.
Test de connexion et arborescence du projet
Pour vérifier la connexion avec Dremio on peut exécuter la commande dbt debug (attention, il faut se placer dans le répertoire du projet). Si une erreur survint, il faudra vérifier que les paramètres de connexion sont les bons dans le fichier profiles.yml.
Lors de l’initialisation du projet l’arborescence suivante est créée. Un exemple est donné définissant 2 modèles (fichiers .sql) ainsi qu’un fichier de configurations (fichier .yml) pour ces modèles, sous le répertoire models/example.
Nous nous intéresserons dans la suite, uniquement au répertoire models et au fichier dbt_project.yml du projet dbt.
Création d’une table ou d’une vue dans Dremio
Création de 2 modèles
Que l’on veuille créer une table ou une vue, il s’agit de construire un modèle dans dbt, un fichier .sql dans le répertoire models/ (ou .py mais les modèles écrit en python ne sont supporté que pour certains data warehouse) et de choisir ensuite comment on souhaite le matérialiser, en table ou en vue. Il existe d’autres types de matérialisation possible que l’on n’illustrera pas dans cet article (incremental, ephemeral, reflection, snapshot). Dans ce fichier sql il suffit d’écrire une requête sql comme vous le feriez dans Dremio en privilégiant leur écriture avec des CTE pour une meilleure visibilité. Et avant la requête dans un bloc config, il faudra choisir la matérialisation pour le modèle.
Créons notre première vue et notre première table dans Dremio. Sous le répertoire models, créons un répertoire bronze et ajoutons-y 2 fichiers .sql comme suit. Le nom des fichiers sql sera le nom de la table ou de la vue dans Dremio (il est possible de changer le nom en ajoutant un alias dans la configuration comme nous le verrons plus tard dans l’article).
Ajoutons les maintenant dans Dremio avec la commande suivante : dbt run.
La commande dbt run va exécuter tous les modèles du projet. Mais dans l’exemple ici nous voulons exécuter uniquement les deux modèles que nous venons d’écrire. Pour cela on va exécuter la commande suivante : dbt run --select customers inventory(ou dbt run --select models/bronze).
Dans Dremio, on a bien une vue dans le space dbt_learnpour le modèle customers (à la racine car nous n’avions pas précisé de répertoire lors de l’initialisation du projet).
La requête envoyée à Dremio pour le modèle customers
Et on a bien une table dans $scratch pour le modèle inventory.
La requête envoyée à Dremio pour le modèle inventory
La stratégie twin_strategy
On peut observer que le modèle inventory a aussi été matérialisé en vue bien qu’on ait choisi “table” comme matérialisation, c’est parce qu’il existe un comportement par défaut lors de la création d’une vue ou d’une table dans Dremio. Les tables dans Dremio peuvent être créées uniquement dans un “object storage” et les vues dans Dremio ne peuvent être créées que dans un “space”. En conséquence, l’adaptateur utilise une stratégie twin_strategy pour déterminer comment gérer la création d’une vue portant le même nom qu’une table existante et vice versa.
Lors de la création d’une table, une vue est aussi créée comme le reflet de la table (dans le space.répertoire configuré pour le modèle).
La requête envoyée à Dremio en plus de celle précédemment illustrée pour le modèle inventory
Lors de la création d’une vue, un drop table avec le nom de la vue est effectué (dans l’object_storage_source.object_storage_path spécifié dans la configuration du modèle)
La requête envoyée à Dremio en plus de celle précédemment illustrée pour le modèle customers
Pour contrôler ce comportement, si vous souhaitez que lorsqu’une table est créée, seul la table est créée et que lorsque la vue est créée il n’y a pas de suppression de table vous pouvez choisir la valeur allow pour la configuration twin_strategy. Voir la documentation pour les différentes stratégies.
La vue et la table ont été créées à l’endroit défini lors de l’initialisation du projet (dans le fichier profiles.yml) mais il est possible de configurer pour chaque modèle ou groupe de modèles là où on veut qu’elles se trouvent dans Dremio. Regardons de plus près les fichiers dbt_project.yml et profiles.yml.
Présentation des fichiers dbt_project.yml et profiles.yml
Le fichier profiles.yml
Dans le fichier profiles.yml, on trouve les différents profils créés lors de l’initialisation d’un projet dbt (les paramètres d’un profil peuvent varier d’un datawarehouse à un autre). Il contient les informations de connexion fournies lors de la commande dbt init. Le profil utilisé dans un projet dbt est spécifié dans le fichier dbt_project.yml. Dans un profil les informations de connexion sont par défaut spécifiées pour un environnement nommé dev(en bleu) et par défaut toutes les commandes s’exécuteront dans l’environnement spécifié dans target, ici dev (en vert).
Il est possible d’éditer le fichier pour rajouter d’autre environnement(en violet). Pour exécuter les requêtes dans un autre environnement il suffira d’ajouter --target nom_env dans la commande. Pour utiliser un autre profil(en jaune), il est possible de modifier le profil à utiliser dans le fichier dbt_project.yml ou de préciser le profil souhaité en ligne de commande avec --profile nom_profil.
Exemple de commande :
dbt run --target prod
dbt run --profile dbt_dremio_test2 --target dev
Le fichier dbt_project.yml
Le fichier dbt_project.yml sert à définir les configurations générales du projet. Par exemple :
le nom du projet (en bleu).
le profil de connexion à utiliser (en vert).
l’emplacement des différents répertoire du projet (en violet).
la configuration des modèles à un niveau macro (en jaune). Par défaut lorsqu’une table sera créée, elle sera stockée dans le dossier de l’espace de stockage spécifié lors de l’initialisation du projet (dans le fichier profiles.yml). De même, les vues seront enregistrées dans le dossier du space spécifié dans le fichiers profiles.yml. Mais il est possible de spécifier un autre emplacement pour la créations des tables ou des vues (tout comme on a choisi le type de matérialisation pour le modèle). Nous verrons cela dans la prochaine partie.
la configuration d’autres éléments présents dans les autres répertoires du projet, à l’image du répertoire models (qui ne seront pas vu ici).
Configuration des modèles
Il est possible de définir des configurations pour les modèles à 3 endroits différents :
dans le fichier dbt_project.yml
dans un fichier yml à créer dans le dossier models/ (à l’initialisation du projet le fichier schema.yml sous models/example, est donnée comme exemple)
dans la définition du modèle directement (dans le fichier .sql, comme nous l’avons fait précédemment pour le choix de la matérialisation)
Se référer à la documentation pour voir les différentes configurations possibles, on en illustrera quelques-unes ci-après.
Dans le fichier dbt_project.yml
Il suffit de remplir la section model à la fin du fichier yml. Dans l’exemple données au démarrage du projet, une configuration a été écrite pour que par défaut (s’il n’y a pas d’autre configuration qui viendrait écraser celle-ci) tous les modèles se trouvant dans le répertoire models/example soient matérialisés en vue. Par défaut, si aucune matérialisation n’est choisie, le modèle sera matérialisé en vue.
Il est possible de rajouter d’autres configurations. Par exemple de choisir l’emplacement dans Dremio où seront enregistrées les vues ou les tables (dans un autre emplacement que celui défini à l’initialisation du projet). Il faut utiliser les configurations suivantes :
object_storage_source: <nom de l’espace de stockage>
object_storage_path: <nom du répertoire dans l’espace de stockage>
databaseoudremio_space: <nom du space>
schemaoudremio_space_folder: <nom du répertoire dans le space>
Dans l’exemple ci-dessous, on définit que tous les modèles sous le répertoire models/bronze seront matérialisés en vue. De plus, les modèles matérialisés en vue seront enregistrés dans un répertoire bronze dans le space dbt_learn dans Dremio, et les modèles matérialisés en table seront stockés dans l’object storage $scratch, dans le répertoire test.
On peut aussi définir la stratégie allow de twin-strategy (dont on a parlé plus haut dans l’article) pour tous les modèles du projet en l’ajoutant juste après “models:”.
Si on ajoute la même configuration à un niveau inférieur, ça écrasera la configuration définie à un niveau supérieur (attention, cela dépend de la configuration, mais c’est vrai pour celles vues dans cet article, se référer à la documentation pour plus de détail). Par exemple, si on ajoute “twin_strategy: clone” sous example, tous les modèles suivront la stratégie allow sauf ceux sous le répertoire models/example.
Les + devant les configurations servent à distinguer une configuration d’un répertoire, ils servent à lever une ambiguïté qui pourrait exister si par exemple le nom d’une configuration est le même que celui d’un répertoire dans le répertoire models. Sa présence n’est pas obligatoire s’il n’y a pas d’ambiguïté.
Dans un fichier yml dans le dossier models
Dans le dossier model/ du projet, il faut créer un fichier yml dans lequel on définira une configuration spécifique pour chaque modèle (on peut créer plusieurs fichiers yml, par exemple un par sous répertoire ou pour un groupe de modèles). Ces configurations écraseront celles qui auraient pu être définies dans le fichier dbt_project.yml(attention, cela dépend de la configuration, mais c’est vrai pour celles vues dans cet article, se référer à la documentation pour plus de détail).
Dans ce fichier on peut documenter les modèles et définir des tests mais nous ne le verrons pas dans cet article (le fichier schema.yml en est un exemple). Tout comme dans le fichier dbt_project.yml, on peut ajouter les mêmes configurations (twin_strategy, materialized, dremio_space, …). On peut également ajouter un alias au modèle pour définir le nom qui sera enregistré dans Dremio à la place de celui du nom du fichier sql.
Par exemple, dans le dossier models/bronze on peut créer un fichier bronze_configuration.yml avec le contenue suivant :
Dans le fichier sql avant la requête il suffit d’ajouter un bloc config avec les configurations souhaitées pour le modèle (comme nous l’avons fait précédemment), séparées par une virgule : {{ config(config1=’valeur’, config2=’valeur’, …) }}
Ces configurations écraseront celles qui auraient pu être définies dans le fichier dbt_project.yml ou dans un autre fichier yml (attention, cela dépend de la configuration, mais c’est vrai pour celles vues dans cet article, se référer à la documentation pour plus de détail).
Exemple :
{{ config(materialized='table', twin_strategy='allow', dremio_space='test') }}
WITH CUSTOMER AS (
SELECT ...
)
SELECT ...
Pour changer la destination dans Dremio pour les vues, il n’y a pas besoin que le space ou que les sous dossiers soient créés au préalable, s’ils n’existent pas ils seront alors créés dans Dremio (sauf dans le cas de la stratégie clone, avec la configuration materialized=’table’, s’ils n’existent pas, après la création de la table, une erreur sera levé lors de la création de la vue). De même lors de la création d’une table les répertoires (object_storage_path) au sein de l’object_storage_source n’ont pas besoin d’exister, en revanche l’object_storage_source doit exister dans Dremio.
Exemple de la création d’une vue dans Dremio en changeant les configurations par défaut
Définissons dans le fichier dbt_project.yml les configurations suivantes pour les modèles sous le répertoire models/bronze :
Définissons un autre space pour la sauvegarde de la vue customers, en ajoutant le bloc config suivant dans le fichier customers.sql : {{ config(dremio_space='test') }}
Avec ces configurations on doit trouver dans Dremio une vue inventory dans dbt_learn.bronze et une vue customers dans test.bronze. De plus, on observera que les répertoire se créeront sans que nous ayons besoin de le faire manuellement ainsi que le space test.
Ajoutons un fichier de configuration bronze_config.yml sous le répertoire models/bronze comme suit, pour changer le nom de nos vue dans Dremio.
Lors de l’exécution on observe bien que le nom des vues est bien celui de l’alias défini dans le fichier de configuration. Et elles sont bien présentes dans Dremio (à noter que de nouvelles vues sont créées, les vues précédemment créées ne sont pas remplacées car elles ont un nom différent).
Conclusion
Dans cet article nous avons vu comment démarrer un projet dbt avec Dremio. Comment créer un modèle dans le but d’en faire une vue ou une table avec le choix de leur emplacement et différents moyens de les configurer. Nous avons également vu la fonction des fichiers dbt_project.yml et profiles.yml, et comment exécuter nos modèles d’un environnement à un autre.
Nous vous invitons maintenant à lire Dremio et les couches sémantiques avec dbt où on s’intéresse à d’autres fonctionnalités (la dépendance entre les modèles, les tests, les macros, …) et plus particulièrement à la construction de couches sémantiques dans Dremio.
Avec plus de 350 présentations, 250 exposants et 20 000 participants, Big Data & AI Paris offre une occasion unique de découvrir les dernières tendances du marché et de nouer des contacts avec tous les professionnels de la donnée en France.
