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.
Open Data Lakehouse, Simplifier, Gérer, Maîtriser ses données, un article rédigé par Charly Clairmont Directeur Général chez Synaltic.
Open Data Lakehouse, Simplifier, Gérer, Maîtriser ses données
Que fait-on de son infrastructure informatique ? Elle est responsable de la gestion des postes de travail et de la collaboration, de la gestion des applications opérationnelles et de l’amélioration du flux des données. Cependant, elle gère surtout les données au sens très large
Vous êtes-vous déjà posé la question de savoir quel est aujourd’hui le cœur de votre système d’information ? En effet, est-ce l’infrastructure réseau ? Car sans elle, il n’y aurait pas de connexion entre tous vos utilisateurs. Ou peut-être est-ce votre ERP, tel que SAP ou Oracle Business ? D’ailleurs, peut-être que votre CRM joue un rôle central dans cette équation ? Et, en tant que logisticien, est-ce votre Warehouse Management System ?
La question n’est pas si simple ! Avez-vous mis en place PRA, PRI, PSSI ?
Toutes ses questions ne sont pas anodines. Ici, je voudrais vous inviter à regarder le système d’information sous un autre angle. Celui des données.
Entrée en matière
L’informatique décisionnelle, que l’on nomme aujourd’hui « Analytics » ou même « Data », devient peu à peu un centre ou un multi-centre vers où la donnée est acheminée. De plus, elle retrouve un souffle pour repartir dans le système. Certains ont nommé ce système de données du data warehouse vers le système opérationnel « Reverse ETL« . Il est important de noter ici qu’il n’a pas été question encore de Master Data Management ou de référentiel. Cependant, il convient de se demander s’il y a une grande différence entre la « Dimension Client » dans le data warehouse et la table de données maître Client du MDM. D’un côté, on est sur une organisation dite en « étoile » ou « satellite« . De l’autre côté, on est sur une 3ème forme normale « classique » qui permet de retenir toutes les clés étrangères des différents logiciels métiers qui alimentent le MDM et qui les réalimentent en retour. Pause ! Est-ce que ça ne vous rappelle pas quelque chose ? N’avons-nous pas déjà vu cela plus haut ? Certains ont appelé cela… Reverse ETL, n’est-ce pas ?
Faisons à nouveau un petit flash back. Depuis, Hadoop a introduit le data lake. Pour sûr, Hadoop apportait un faible coût du stockage, la capacité à y exécuter tout type de traitements. Plus tard, on a compris qu’il fallait détacher stockage et calcul pour une plus grande flexibilité. Il s’agissait surtout de faciliter la mise en œuvre de traitements très divers et très hétérogènes avec les mêmes données ! Ici, c’est exactement cette flexibilité-là que les promoteurs du Cloud Data Warehouse viennent offrir.
Reprenons maintenant notre fil ! La question peut alors prendre une autre forme. Existe-t-il un système avec les fonctionnalités et la simplicité du Data Warehouse et la flexibilité du Data Lake ?
Nous sommes précisément là où je voulais vous amener. Le Data Lakehouse ! Il va un peu plus loin 🙂
Définition
C’est une architecture de gestion des données. Le Data Lakehouse combine la flexibilité, la rentabilité et l’échelle de Data Lake avec la gestion des données et les transactions ACID de Data Warehouse grâce à des formats de table Data Lake (Delta Lake, Apache Iceberg et Apache Hudi) qui facilite autant les traitements de Business Intelligence (BI), de Machine Learning (ML) ou même accueillir les données des processus tant en batch qu’en continu, et ce, sur toutes les données.
Le concept initial a été créé par Databricks dans le document CIDR en 2021.
À data lakehouse, nous préférons. Open Data Lakehouse. Ici, c’est pour bien renforcer l’idée d’un format standardisé que “tout le monde” ou “presque” sait lire. Je veux dire que les données enregistrées dans ce format seront durablement lisibles aussi bien par la solution que vous mettez en place qu’une autre dont le déploiement s’articulera dans 5 ans.
Cette définition est un point de départ à la découverte de l’Open Data Lakehouse.
Après le Data Warehouse, le cloud Data warehouse, le Data Lake, l’Open Data Lakehouse.
Pourquoi le Data Lakehouse ?
Rendre la donnée accessible
Si les lacs de données ont facilité la consolidation des données, ni leur architecture ni les traitements ont été si simples à mettre en œuvre. Cependant, cette complexité a freiné l’adoption jusqu’aux utilisateurs. Le Data Warehouse, quant à lui, facilite cet accès, mais il ne sait pas accueillir toutes les données ! En revanche, avec le data lakehouse, l’utilisateur peut accéder à toutes les données, et ce, en utilisant SQL, le langage d’interrogation des données que beaucoup maîtrisent, y compris vos outils analytiques actuels.
Grâce à une telle accessibilité, on peut viser la responsabilisation des utilisateurs et leur autonomisation. De plus, cette approche permet d’envisager une organisation des données conforme à ce que propose le Data Mesh.
Simplifier l’architecture, réduire les coûts
Le stockage objet est la clé de cette réduction de coûts. En outre, grâce à l’amélioration continue des performances des moteurs de data lakehouse, il est désormais possible d’employer de moins en moins de ressources pour une même quantité de données. De plus, l’architecture est fluide et compréhensible : un moteur sait ingérer et stocker les données vers le stockage d’objets dans un format de données tabulaire. En conséquence, il peut interroger ses données depuis le lac à destination des outils variés.
Augmenter la durabilité des données
Étant donné le caractère des tableaux de formats et leur ouverture, il est assez simple de passer d’un fournisseur à l’autre avec ses mêmes données sans qu’elles subissent une quelconque transformation. De plus, il faut également considérer l’appui de pareils standards afin d’accéder durablement aux données au fil des années. Par ailleurs, les fichiers aux formats CSV et JSON sont bien parce qu’ils restent lisibles. Cependant, ils ne se composent pas toujours de schémas et ne sont pas fortement typés.
Gouvernance des données et observabilité
Dans la mesure où toute la donnée est gérée depuis le lac, d’ailleurs, le moteur du lakehouse sécurise la donnée jusqu’à l’utilisateur. De plus, jusqu’à la donnée elle-même, ce processus garantit une protection complète. Dans la mesure où tous les traitements sont tracés, les organisations peuvent finement structurer, organiser, suivre l’usage des données.
Faciliter le partage de données, et son réemploi
A la fois les formats Table ouverts, à la fois le Data Catalog de tous les jeux de données (Table, Vues) contenu dans le Data Lakehouse participent à la fois à un partages des données en internes au sein des organisations, mais aussi vers l’externe avec soin particulier pour s’assurer que toutes les règles de sécurité (PSSI) ont bien été prises en compte.
Aujourd’hui, le mot Big Data est quasi « désuet ». En effet, on parle désormais de données. De plus, le data lakehouse s’adresse à toutes les organisations. Néanmoins, il est tout de même évident qu’il faudra aussi choisir la bonne solution par rapport à ses besoins. Par conséquent, les data lakehouses éviteront bien des processus ETL. En effet, Fort de toutes les métadonnées, de simples scripts SQL (ici comprenez que des processus ELT) sont mis en œuvre, ce qui est souvent plus accessible au départ pour les organisations.
Par où puis-je commencer ?
Comme toute technologie est nouvelle dans une organisation, il convient de l’apprivoiser. Cela peut être rapide. Cela peut être d’autant plus rapide que vous avez déjà une certaine culture de la donnée (intégration de données, business intelligence, reporting opérationnel… Data Steward, Data Facilitateur).
A Synaltic, nous vous proposons d’aborder ce type de projet via des ateliers de découverte, des mises en situation (preuve technologique) avec vos propres données. Convaincu par l’approche, sa simplicité, sa sécurité, nous vous accompagnons dans la mise en place de la plateforme, son alimentation et la structuration des données.
Vous souhaitez découvrir Dremio ?
Nous pouvons nous déplacer dans vos locaux Parisien ou organiser une session à distance via Google Meet ou Zoom. Comptez une heure de présentation pour faire un tour complet des fonctionnalités.
Après un court passage par une startup dans les années 2000, Charly fonde Altic qui est ensuite devenue Synaltic. Passionné par l'urbanisation des systèmes d’information, l'innovation, la donnée, il a toujours défendu le logiciel libre et l'open source.
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.
