Nov 17

A la découverte de Power BI

17/11/2020
Clélia Boursin-Bellot
6 Comments
Actualités, Big Data, Bonnes pratiques, Business Intelligence, Cloud, Tableaux de bord

Business Intelligence : Partez à la découverte de Power BI : une solution tout en un et un concurrent technologique et économique ! Par les consultants de la #SynalTeam.

|Business Intelligence : A la découverte de Power BI

Bienvenue dans une nouvelle série d’articles où l’on va présenter et évaluer une sélection d’outils BI comprenant : DataPrep, Analytics, dataviz, data storytelling, Machine Learning… Autant de sujets qui vous permettront de choisir au mieux votre solution BI !

Si vous avez loupé notre entrée en matière, nous vous conseillons d’aller y faire un tour juste ici :

Comment bien choisir son outil de BI ?

Chose promise chose due, faisons la découverte de quelques unes des solutions BI disponibles sur le marché :

– Tableau Software

-    Power BI

– Qlik Sense

– Knowage (ex Spago BI)

– Domo

– Looker

Aujourd’hui, nous allons parler de la suite Microsoft, solution tout en un et essor technologique, j’ai nommé Power BI.

| Introduction

Power BI est l’un des petits nouveaux de la suite Microsoft 365. Sorti en 2014, il avait pour but de compléter l’offre que proposait Excel en apportant une découverte visuelle plus performante et simplifiée des données.

Depuis, il a bien évolué et propose une plateforme complète comprenant la préparation et modélisation de données, l’exploration et la restitution visuelle, des analyses augmentées, un service de diffusion sur le cloud ou en local. Power BI propose un prix défiant toute concurrence.

Trois flux de données et deux interfaces

La conception des données commence avec Power BI Desktop (intégrant l’éditeur de requête, la vue Relations, Données et Rapports), installé en local, qui va pouvoir intégrer différentes sources de données (en local ou en cloud) et publier les jeux de données et rapports sur le cloud vers Power BI Service.

L’actualisation des données est possible, soit en local (avec Power BI Desktop), soit en cloud (avec Power BI Service).

La visualisation des données : les utilisateurs finaux peuvent visualiser les rapports et tableaux de bord sur différents supports (mobile, lien web…).

Source : BIWORKS – Architecture de Microsoft Power BI

Avant de commencer les travaux de conception, une prise en compte de l’architecture de Power BI est nécessaire. Celle-ci possède deux interfaces :

Celle de l’éditeur de requête qui permet d’importer et de formater les données, suivant le processus de l’ETL (Extract, Transform, Load) grâce à son langage M.
Celle de la vue des données après chargement dans le modèle, qui elle-même permet d’accéder à trois zones de travail ou vues :
- La vue Relation qui affiche toutes les tables, colonnes et relations du modèle.
- La vue Données qui permet d’examiner les données et d’ajouter des champs calculés complémentaires grâce au langage DAX.
- Une vue Rapports qui permet de créer un nombre important de pages de rapport avec des visualisations.

Ainsi, son éventail de fonctionnalités grandissantes et son modèle économique attaché à la suite 365, lui permettent de prendre une place significative sur le marché de la BI et d’en perturber plus d’un. Quant aux mises à jour, nous parlions de Tableau et de son rythme trimestriel ; et bien pour Power BI, le rythme actuel pour son service cloud est hebdomadaire.

De quoi ne pas être en reste sur la veille technologique, accrochez-vous !

| En résumé

Le prix de la licence Power BI combiné à son inclusion dans la suite Office 365, a longtemps été un argument accrocheur pour les entreprises en quête d’une nouvelle solution BI. Cependant, depuis quelques années, son déploiement technologique a pris le relais.

L’outil de développement a bien été pensé puisqu’il combine préparation, modélisation et visualisation des données dans une seule et unique interface. Cela permet de basculer facilement d’une fonctionnalité à une autre sans changer d’environnement de travail et donc faciliter son utilisation.

Les familiers de l’interface Microsoft ne sont pas dépaysés puisque l’outil reprend les codes de la suite.

Toutefois, Power BI propose une solution modulaire répartie en plusieurs briques applicatives, le prix d’utilisation est donc relatif à vos besoins. Nous constatons également un nombre conséquent de menus et modules de développement qui surcharge le visuel et donc, ne facilite pas l’exploration. Pour les adeptes du SQL, sachez que vous devriez également maîtriser le langage DAX.

En partant à la découverte de Power BI, voici nos remarques concernant l’offre :

| Grille de benchmarking

En effet, cette grille détaillée vous permet de visualiser rapidement les fonctionnalités proposées par les éditeurs à partir d’une liste de critères plus ou moins exhaustifs de ce qu’on attend d’un outil BI. Vous pourrez retrouver la grille complète des solutions dans l’article de clôture de ce benchmark.

Power BI

(Version 2.79.5768.1082)

Légende :

Télécharger le PDF

| Note de fin

Power BI propose une offre “Data Preparation » et “Data Visualisation” packagée en une seule solution. Elle se démarque donc d’une solution comme Tableau où cette dualité est distribuée en deux produits.

Power BI a plusieurs avantages :

Une approche basée sur le Cloud adaptée aux entreprises en quête d’une entrée en matière sur ce sujet à moindre coût.
Son rattachement à la suite Microsoft offre des licences à des conditions très attractives et font donc de lui un vrai concurrent technologique et économique.
Aucune installation de software (installation en local) n’est en général nécessaire. Sa facilité d’utilisation avec des mises à jour régulières et sans heurt (real time streaming) en font un atout majeur.

Ce qu’il faut savoir c’est que Power BI ne propose pas uniquement que du Cloud. Une version “On Premise”, Power BI Report Server est disponible pour les plus réticents au Cloud. Toutefois, cette version évolue moins vite et ne bénéficie pas de toutes les nouveautés de la version Cloud. Certains services proposés sur le Cloud tels que les analyses en streaming, les requêtes NLP ou encore le contenu prédéfini ne sont pas pris en charge par Power BI Report Server.

Power BI n’est pas un outil destiné aux petites entreprises si vous voulez pleinement tirer parti de ses fonctionnalités. Il est aujourd’hui passé d’outil prometteur à un leader du Magic Quadrant. Son intégration avec le Cloud et la compatibilité avec les principaux outils de datawarehouse font de lui une valeur sûre du marché actuel de la Business Intelligence.

Retrouvez-nous toutes les deux semaines pour une nouvelle analyse !

A propos de l'auteur: cboursin

Membre de la team Dataviz, Clélia s'intéresse particulièrement aux aspects géo/carto des analyses. Elle aime Tableau et le tricot.

Articles Suggérés

Dremio et les couches sémantiques avec dbt

Exemple d’utilisation de dbt core avec Dremio software #2

Introduction

dbt (data build tool) offre la possibilité de vous aider à organiser et mettre à jour de manière cohérente vos couches sémantiques de données dans Dremio tout en contrôlant la qualité des données grâce aux tests. De plus, dbt vous permet de passer d’un environnement de développement à un environnement de production très facilement.

Dans cet article nous allons illustrer la construction de couches sémantiques dans Dremio et montrer des exemples d’utilisation de certaines fonctionnalités qu’offre dbt : les tests, l’utilisation de code jinja et les macros.

Sommaire

Prérequis

Présentation de l’exercice

Construction des couches sémantiques dans Dremio

Arborescence et configuration

La couche bronze

La couche silver

La couche gold

Création dans Dremio

Exemple d’utilisation des tests, la qualité des données

Les tests singuliers

Les tests génériques

Exemple d’utilisation de code jinja et des macros

Du code jinja dans la définition d’un modèle

Du code jinja dans la définition d’un test

Utilisation d’une macro dans la définition d’un modèle

Conclusion

Prérequis

Dremio cloud ou Dremio Software (version 22.0 ou supérieures).

dbt-dremio installé (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.

Dans cet article nous travaillerons sur un environnement linux (ubuntu) avec Dremio software connecté à une base de données postgres (BDLearn) où le jeux de données est disponible ici.

Présentation de l’exercice

L’objectif de cet article est d’illustrer comment utiliser dbt pour construire des couches sémantiques de données dans Dremio. Nous le ferons avec l’exemple suivant.

Le jeu de données représente la location de dvd dans des magasins, il contient des informations sur les films, les magasins de location et les locations, ainsi que les clients et le personnel des magasins. Pour l’exercice nous nous concentrerons sur le prêt de film et nous allons construire nos couches de données afin de répondre aux questions suivantes (nous ne nous intéresserons pas aux clients, aux magasins ou aux personnels).

Quels sont les films les plus regardés ? Lesquels génèrent le plus de bénéfices et à quelle catégorie appartiennent-il ? Quels sont les films peu ou pas empruntés ?

Parmi les films les plus empruntés, quelle est la durée des films ? Est elle similaire ?

Combien de films il y a par catégorie ? Quel genre de film est le plus emprunté ? Quelle catégorie de film génère le plus de bénéfices ?

Combien est ce qu’il y a de langue de film dans l’inventaire ? Les films dans quelle langue sont les plus empruntés ?

Pour cela nous nous intéresserons aux tables suivantes de la base de données :

Construction des couches sémantiques dans Dremio

Lors de l’initialisation d’un projet dbt, nous avons l’arborescence du projet ci-contre (voir l’article précédent initialiser un projet).

Nous nous intéresserons dans la suite, uniquement au dossier models/, tests/, macros/, dbt_packages/ et au fichier dbt_project.yml du projet dbt.

Commençons l’exercice par créer l’arborescence et la configuration des modèles.

Arborescence et configuration

Construisons nos couches de données dans Dremio comme suit :

une 1ère couche (bronze) qui sera le reflet des tables de la base de données qui nous intéresse.

une 2ème couche (silver) où nous allons regrouper les tables selon leur catégorie. Nous aurons deux vues, l’une concernant les films et l’autre concernant leur emprunt.

une 3ème couche applicative (gold), où nous aurons une vue qui englobera toutes les informations permettant de répondre à nos questions pour l’analyse.

Sous le répertoire modèle nous allons créer une arborescence similaire à celle que l’on souhaite avoir dans Dremio pour faciliter l’écriture de la configuration et l’organisation du projet.

Et dans le fichier dbt_project.yml nous allons écrire la configuration de nos modèles. Tous nos modèles seront matérialisés en vue et seront créés dans le même space Dremio ‘dbt_learn’. De plus, dans le space ‘dbt_learn’ on va créer un répertoire par couche de données (bronze, silver et gold). Dans le répertoire bronze on placera tous les modèles du répertoire models/dbt_learn/0_bronze du projet, dans silver ceux du répertoire models/dbt_learn/1_silver et dans gold ceux du répertoire models/dbt_learn/2_gold.

Construisons maintenant les modèles couche par couche.

La couche bronze

Dans le répertoire 0_bronze/ ajoutons 7 modèles (fichiers .sql) et un fichier bronze_config.yml pour leur configuration et les tests (que l’on verra plus tard).

Définissons les modèles comme le reflet des tables du modèle de données présenté précédemment. Par exemple pour la table category on écrira la requête suivante :

Pour référencer les tables physiques dans Dremio on va utiliser le bloc de code source {{source()}} au lieu de référencer la table directement comme nous l’aurions fait dans Dremio. C’est une bonne pratique de l’utiliser car de cette façon, si un changement survient dans la base de données il n’y aura plus besoin de venir dans chaque modèle pour modifier la référence de la table, mais juste dans le fichier .yml où sa définition aura été notée. De plus, pour la documentation du projet ça permettra de connaître les sources qui ont permis de construire les modèles. Nous ne verrons pas la partie documentation que pourvoit dbt dans cet article mais dbt fournit un lineage qui est généré à partir de la définition de nos modèles grâce aux bloc {{source()}} et {{ref()}} (que nous verrons dans la partie suivante).

Sous le répertoire models/dbt_learn/ on va créer un fichier source.yml avec le contenu suivant :

Les références entre Dremio et dbt sont expliquées dans le schéma suivant :

Les modèles de la couche bronze sont maintenant prêts.

La couche silver

Au-dessus des modèles de la couche bronze nous allons construire deux modèles sous le répertoire /1_silver.

Pour lier ces modèles aux modèles le la couche bronze on va utiliser le bloc de code {{ref()}}. Définissons les modèles comme suit.

La couche gold

Enfin, au-dessus de la couche silver on va créer un modèle en vue de répondre à notre analyse. Ajoutons un fichier .sql sous le répertoire /2_gold.

Définissons le modèle comme suit.

Création dans Dremio

Actuellement, nous n’avons rien dans Dremio à part la connexion à la base de données.

Ajoutons nos couches sémantiques définies avec dbt dans Dremio en exécutant la commande suivante :

dbt run --select models/dbt_learn # tous les modèles present dans le répertoire models/dbt_learn ou dbt run --select +rented_film # le model rented_film et tous les modèles parents

Nos 10 vues ont bien été créées dans Dremio et le space ainsi que les répertoires se sont créés :

On observe dans les logs d’exécution que les modèles se construisent dans l’ordre des couches, c’est grâce aux références entre les modèles.

Les données sont maintenant prêtes à être exploitées pour l’analyse.

Exemple d’utilisation des tests, la qualité des données

dbt est très pratique pour exécuter un grand nombre de tests de qualité sur les données. Écrire des tests va permettre d’effectuer un contrôle sur les données manipulées, de s’assurer que les données sont conformes à ce qui est attendu (éviter les surprise après coût) et de vérifier la fraîcheur des données sources.

Il existe deux types de tests, les tests singuliers et les tests génériques. Les tests singuliers sont, comme son nom l’indique, des tests pour un modèle spécifique (ou groupe de modèles) que l’on écrit soit même. Et les tests génériques sont des tests réutilisables qui peuvent être appliqué à plusieurs modèles. Il y a des tests génériques intégrés (built-in ou pre-built generic tests), ce sont 4 tests prédéfinis que l’on peut utiliser directement sur un modèle, et les tests génériques personnalisés (custom generic tests) que l’on écrit soit même. Illustrons l’utilisation des tests avec nos modèles précédemment construits.

Les tests singuliers

Les tests personnalisés sont à définir dans le répertoire tests/, dans un fichier sql. Le test est conçu pour un modèle unique. La requête doit identifier les lignes où la condition n’est pas remplie.

En voici un exemple :

Dans l’exemple, on veut que la date à laquelle on empreinte le film (rental_date) soit antérieure à la date à laquelle on rend le film (return_date). La condition n’est donc pas remplie lorsque rental_date > return_date. La commande dbt test va permettre de lancer le test. Ici nous souhaitons uniquement lancer ce test, pour cela nous allons lancer la commande dbt test -s test_rental_check_date.

Le test est passé donc on a bien la date rental_date antérieur à la date return_date.

Les tests génériques

Les tests intégrés :

Il existe 4 tests génériques prédéfinie :

unique

not_null

relationship

accepted_values

Ces tests sont à définir dans un fichier .yml dans le répertoire models/. Implémentons ces 4 tests pour le modèle film dans le fichier bronze_config.yml. Vérifions que la colonne film_id ne contient pas de valeur nulle et contient des valeurs uniques. Que les valeurs de la colonne language_id sont bien présentes dans la colonne language_id du modèle language et qu’elles sont non nulles (notion de clé étrangère). Et enfin que les valeurs de la colonne rating soit l’une des valeurs suivantes : R, PG-13, NC-17, PG ou G.

Exécutons les tests du modèle film avec la commande suivante : dbt test -s film

Les tests personnalisés :

Ces tests, une fois définis, peuvent être réutilisés pour plusieurs modèles. Ils sont créés avec du code Jinja dans un bloc test et placés dans le répertoire /macros ou vous pouvez créer un répertoire generic sous le répertoire tests/ et les y placer.

Ajoutons le test not_empty_string à la colonne name du modèle category. Et exécutons les tests du modèle category avec la commande dbt test -s category.

Nous ne le verrons pas dans cet article mais dbt offre la possibilité d’utiliser des packages. Les packages permettent par exemple d’importer des tests déjà implémentés par d’autres dans votre projet et de les utiliser comme les tests génériques. Cela permet de ne pas réinventer la roue.

Exemple d’utilisation de code jinja et des macros

Nous ne verrons pas en détail dans cet article la syntaxe et tout ce qu’offre le code jinja et les macros dans un projet dbt, mais nous allons présenter quelques exemples d’utilisation.

Du code jinja dans la définition d’un modèle

Dans le jeux de données il y a la présence de 6 tables “payment” pour les 6 premiers mois de 2020. Imaginons que l’on souhaite avoir une vue regroupant l’ensemble de ces tables, il faudrait faire l’union de toutes ces tables. En utilisant du code jinja on a la possibilité de faire une itération sur le nom des tables. Voici un exemple :

Du code jinja dans la définition d’un test singulier

Écrivons un test qui permet que les tables dans la source contiennent au moins un certain nombre de ligne. Ce test peut être utile par exemple si on est dans un environnement de recette et que l’on souhaite vérifier que le jeu de données qu’on test est suffisant.

Le test nous dit que 2 tables n’ont pas un nombre de lignes suffisant. Et effectivement la table category et language ne respecte pas les conditions.

Utilisation d’une macro dans la définition d’un modèle

Imaginons que dans plusieurs modèles nous ayons besoin de faire l’agrégation COUNT et SUM sur une colonne, comme nous l’avons fait pour le modèle de la couche gold. Nous pourrions écrire une macro qui ferait ces opérations et l’utiliser après dans ces modèles.

Dans le dossier macros/ on va ajouter un fichier “aggregate_calculation.sql”. Et dans ce fichier on va ajouter le code suivant :

Dans un même fichier il est possible de définir plusieurs macros.

Maintenant dans notre modèle rented_film, faisons référence à la macro que nous venons d’ajouter :

Conclusion

Dans cet article nous avons vu un exemple de comment créer des couches sémantiques dans Dremio avec dbt. Nous avons également vu comment utiliser les tests pour contrôler la qualité des données utilisées et comment utiliser du code jinja ou des macro dans la définition de nos modèles.

Dans un prochain article on illustrera d’autres fonctionnalités qu’offre dbt.

Ressource pour aller plus loin :

1er article : Démarrer un projet dbt avec Dremio

Using dbt to Manage Your Dremio Semantic Layer

Semantic Layer CI/CD with Dremio and dbt

Cours dbt

Best practices

Jinja cheatsheet
Apache Airflow 3.0 arrive

Toutes les organisations exploitent un orchestrateur. Il est même étonnant d’observer que nombre de clients vont s’appuyer sur un orchestrateurs pour gérer l’ensemble des tâches à exécuter pour tous les systèmes et applications en lieu et place de celui associés à leurs solutions ETL.

De même, les organisations ont un besoin de modernisation, justement de leur orchestrateur, qui ne leur offre pas l’agilité et la flexibilité des nouvelles approches « as code ».

Il y un nombre très important de solutions d’orchestration, y compris en open source. Une solutions qui innove grandement en la matière : Kestra. De nombreuses solutions d’orchestration se compare à Apache Airflow en pointant ses défauts.

A la mi-avril 2025 la version 3.0 de ce projet va voir le jour. Elle apporte des améliorations significatives qui promettent de transformer l’expérience des utilisateurs et d’attirer de nouveaux adeptes.

Performance et architecture repensées

La nouvelle architecture client-serveur d’Airflow 3.0 offre une flexibilité et une scalabilité accrues. Cette refonte permet une exécution fluide sur différents environnements cloud et améliore considérablement les performances globales du système.

Le monitoring des DAGs a été optimisé, offrant une visibilité en temps réel sur l’état des workflows. Le découplage entre l’API et le frontend permet une meilleure réactivité de l’interface utilisateur et facilite les mises à jour indépendantes de ces composants.

La version 3 introduit le Edge Executor ! Il est ainsi possible d’avoir des déploiements très flexibles. L’exécution des tâches est réalisée au plus près des données.

Avec l’introduction des tâches différables, il est déjà possible d’exécuter des workflows asynchrones et de libérer le slot du worker Airflow. Certes, on peut utiliser l’opérateur SSH, mais Airflow ne prenait pas nativement en charge l’exécution de workers sur des machines distantes. Avec Airflow 3.0, tout cela change.

Les workers n’auront plus besoin d’être contenus dans le déploiement Airflow. Airflow fait référence aux workers externes sous le nom d’Edge executors. Cela signifie que plusieurs choses vont changer :

Les workers ne pourront plus accéder à la base de données Airflow. Par défaut, tous les services Airflow ont accès à la base de données Airflow car elle est responsable du suivi de l’état. En découplant les workers et la base de données Airflow, il devient possible d’exécuter des workers à distance. Ceci est principalement facilité par le nouveau Task SDK.

Les workers communiqueront via l’API REST d’Airflow. L’authentification des workers externes se fera par le biais de jetons JWT ou ID.

Les workers ne seront plus liés aux packages Airflow. Il n’y aura plus de dépendance aux packages installés dans l’image fournie avec le déploiement Airflow. Un package distinct sera disponible, beaucoup plus léger que l’image de base d’Airflow. Ce package fournira les outils nécessaires pour exécuter le worker externe.

Versionning des DAGs

Une fonctionnalité très attendue est le versionning natif des DAGs. Les utilisateurs peuvent désormais suivre l’historique des modifications de leurs workflows directement dans l’interface utilisateur. Cette fonction permet de visualiser les changements apportés aux DAGs au fil du temps et de revenir facilement à des versions antérieures si nécessaire.

Des Datasets aux Assets

Airflow 3.0 introduit le concept d’Assets, une évolution des Datasets. Cette approche offre une gestion plus fine des dépendances entre les tâches et les données.

from airflow.decorators import dag, task from airflow.datasets import Dataset input_dataset = Dataset("s3://bucket/input.csv") output_dataset = Dataset("s3://bucket/output.csv") @dag(schedule=[input_dataset]) def process_data(): @task(outlets=[output_dataset]) def transform(): # Logique de transformation return "Data processed" transform() dag = process_data()

De cette manière, la traçabilité entre jeu de données et traitements (tâche, DAG) est intrinsèque. Vous pourrez tout de suite identifier les jeux de données exploités par un DAG et tous les DAGs qui lisent ou écrivent tels ou tels jeux de données.

SDK multi-langages

Airflow 3.0 étend son support à plusieurs langages de programmation grâce à un nouveau SDK. Les langages de programmation supportés par le nouveau SDK : Python, Java (langages dérivé Scala…), Javascript, TypeScript, Go.

Par exemple, on peut maintenant écrire les DAG en Java.

import io.astronomer.airflow.sdk.DAG; import io.astronomer.airflow.sdk.annotations.DAGTask; import io.astronomer.airflow.sdk.annotations.Workflow; @Workflow( dagId = "java_example", schedule = "0 0 * * *", startDate = "2025-04-01" ) public class JavaExampleDAG extends DAG { @DAGTask public void helloWorld() { System.out.println("Hello from Java DAG!"); } }

Interface graphique modernisée

L’interface utilisateur d’Airflow 3.0 a été entièrement repensée avec React et FastAPI. Elle offre une expérience plus intuitive et réactive, avec des fonctionnalités telles que :

Un mode sombre

Une vue en grille et une vue graphique des DAGs redimensionnables

Une visualisation améliorée des dépendances entre les assets

Un accès rapide aux informations clés sur le déploiement Airflow et l’état des services.

Tester Apache Airflow 3 par vous même

L’article a surtout vocation à vous rappeler que la version 3 est bientôt là. Bien sûr toutes les fonctionnalités de cette verion 3 n’ont pas été exhaustivement listées. Et nous vous invitons à le découvrir par vous même. Cette suite de commandes devrait vous aider.

git clone https://github.com/apache/airflow.git cd airflow# Création et activation de l'environnement virtuel (recommandé) python3 -m venv .venv source .venv/bin/activate git checkout v3-0-stable pip install "pipx>=1.4.1" pipx ensurepath pipx install -e ./dev/breeze breeze start-airflow --backend postgres --load-example-dags --dev-mode --db-reset

Par la suite, ouvrez votre navigateur à la page suivante : http://127.0.0.1:28080.

La participation de tout un chacun est importante. Faites des retours à la communauté.

En attendant la mi-avril

Avec ces améliorations majeures, Apache Airflow 3.0 se positionne comme une solution d’orchestration de workflows encore plus puissant et accessible. Dans un contexte économique où la maîtrise du système d’information est cruciale, cette nouvelle version pourrait attirer de nombreux nouveaux utilisateurs en quête d’un outil flexible, performant et facile à utiliser pour gérer leurs pipelines de données et leurs processus métier. Les utilisateurs de Control-M seraient surpris de la facilité de migration vers Apache Airflow.

Toute l’équipe de Synaltic se tient disponible pour vous aider à découvrir et faire vos premiers pas avec Apache Airflow y compris avec cette nouvelle version.

A PROPOS DES FORMATIONS AIRFLOW
Formation Dbt à Vincennes les 18 et 19 mars 2025

Que vous soyez Data Analyst, Data Engineer, Data Scientist, Chef de projet ou Business Analyst, ne manquez pas l’occasion de rester à la pointe de l’innovation dans le domaine des données !

Formez-vous à Dbt en 2 jours !

18 et 19 Mars 2025

1.000€ par participant pour les 2 jours

S’INSCRIRE

Objectifs Pédagogiques de la Formation

À la fin de cette formation, vous serez en mesure de comprendre les concepts clés, les avantages et l’architecture de dbt en tant qu’outil de transformation et de modélisation des données. De plus vous pourrez mettre en place un projet utilisant dbt en partant de 0 et en appliquant les bonnes pratiques.

A propos de DBT

Data Build Tool (ou dbt) est un outil open source qui facilite la transformation de vos données au sein de votre Data Warehouse ou de votre Data Lakehouse comme Dremio, à travers le processus ELT (Extract Load Transform). L’outil utilise le langage sql pour la transformation des données avec la possibilité d’intégrer du code jinja dans les requêtes ou d’utiliser des macros pour par exemple réutiliser du code ou créer des fonctions. Vous pouvez utiliser git pour faciliter la collaboration et le versionning de votre projet dbt.

EN SAVOIR PLUS

_

6 Commentaires

A la découverte de Qlik Sense - Benchmark - Synaltic
09/12/2020 at 11:52 am · Répondre

[…] – Power BI […]
A la découverte de Knowage - Benchmark - Synaltic
14/12/2020 at 3:51 pm · Répondre

[…] Power BI […]
A la découverte de Looker - Benchmark BI - Synaltic
29/12/2020 at 10:00 am · Répondre

[…] – Power BI […]
A la découverte de Domo - Benchmark BI - Synaltic
07/01/2021 at 2:41 pm · Répondre

[…] – Power BI […]
Business Intelligence : la grille de benchmarking - Synaltic
25/01/2021 at 4:41 pm · Répondre

[…] Power BI […]
A la découverte de Tableau Software - Synaltic
16/02/2021 at 12:17 pm · Répondre

[…] – Power BI […]

A la découverte de Power BI