Tech Talk: L'ETL dans le cloud est-il possible sans codage ? (Partie 2)

Tech Talk: L'ETL dans le cloud est-il possible sans codage ? (Partie 2)

Illustration de la configuration d'un projet de flux ETL pour un client de l'industrie hôtelière.

Illustration de la configuration d'un projet de flux ETL pour un client de l'industrie hôtelière.

Illustration de la configuration d'un projet de flux ETL pour un client de l'industrie hôtelière.

Dans cet article, suivant la Partie 1, je souhaite illustrer la mise en place d'un projet de flux ETL pour un client du secteur de l'hôtellerie. Le client souhaitant utiliser Power BI comme outil de front-end, nous avons proposé Microsoft comme le bon fournisseur pour la migration vers le cloud. Azure Portal est l'interface utilisateur cloud la plus conviviale avec une documentation complète, ce qui en fait une bonne option pour les débutants. Le seul inconvénient est qu'Azure est légèrement plus cher par rapport aux concurrents.

Il n'y avait qu'une seule source de données pour cette preuve de concept, ici mise en évidence en violet :

Architecture des données existantes

Extraction (ETL)

La première étape de l'ETL est l'Extraction. Notre tâche était d'obtenir près de 30 tables de la base de données MySQL. Nous avons utilisé Azure Data Factory (ADF) pour cela. En effet, c'est l'une des rares activités où le codage est inutile. La seule partie délicate est qu'un réseau privé héberge la base de données MySQL. Cela signifie que vous devez configurer votre ADF sur une VM appartenant à ce réseau. Le processus d'installation du runtime d'intégration auto-hébergé n'est pas le plus simple. N'oubliez pas non plus de fournir à cette VM un environnement d'exécution Java pour pouvoir extraire les tables en fichiers parquet. C'est un format efficace qui contient des métadonnées. Snappy est le mode de compression par défaut, et nous le recommandons fortement.

ADF a la hiérarchie suivante : Data Factory > Pipelines > Activités. Une fois que vous avez lié votre ADF à toutes les ressources nécessaires (dans notre cas : base de données MySQL, stockage Azure Data et Databricks), vous pouvez commencer à extraire des données avec les 'activités de copie' ainsi nommées. ADF propose deux options : des modèles d'ingestion et des pipelines créés par l'utilisateur.

Dans le premier cas, vous pouvez analyser votre source de données et choisir les tables qui vous intéressent. Vous pouvez copier des tables entières dans le récepteur de votre choix.

Dans le second cas, vous devez créer une activité de copie distincte par table de base de données. Oui, c'est fastidieux, mais vous pouvez y joindre une requête SQL. Cela peut vous faire économiser beaucoup d'espace de stockage si vous souhaitez supprimer des colonnes obsolètes ou filtrer certaines lignes (par exemple, en fonction de la date). De plus, vous voudrez peut-être vérifier si vous avez bien extrait les colonnes de type datetime. Sinon, vous devrez effectuer un casting de type.

Transformation (ETL)

La deuxième étape de l'ETL est la Transformation. Nous avons effectué cela en utilisant deux clusters Spark (un pour le développement et un pour les traitements batch) gérés par l'environnement Databricks. Les notebooks de Databricks sont un moyen pratique d'écrire votre code en Python (ce dialecte s'appelle Pyspark) ou de déboguer et de surveiller les emplois particuliers au sein du cluster en Scala.

Chargement (ETL)

La troisième et dernière étape est le Chargement. La tâche consistait à insérer plusieurs tables de dimensions et de faits stockées en parquet dans l'entrepôt de données, qui est une base de données Azure SQL. Étonnamment, ADF s'est avéré assez limité ici. Vous ne pouvez pas charger plusieurs fichiers parquet automatiquement. De plus, nous ne pouvons pas définir d'options de chargement importantes telles que la troncature/la suppression/le remplacement de tables. Cela nous a amenés à placer les scripts de chargement avec un pilote JDBC dans Databricks en utilisant le code suivant :

df_name.write \    

.format("jdbc") \    

.option("url", "jdbc:postgresql:dbserver") \    

.option("dbtable", "schema.tablename") \    

.option("user", "username") \    

.option("password", "password") \  

.save()

Il existe de nombreuses options avec cette méthode. Elles sont décrites ici : JDBC vers d'autres bases de données - Documentation Spark 3.2.1 (apache.org)

A suivre

Restez à l'écoute pour la Partie 3, où je décrirai une autre histoire cloud utilisant AWS pour aider le client à établir ses flux ETL et ses entrepôts de données.

Dans cet article, suivant la Partie 1, je souhaite illustrer la mise en place d'un projet de flux ETL pour un client du secteur de l'hôtellerie. Le client souhaitant utiliser Power BI comme outil de front-end, nous avons proposé Microsoft comme le bon fournisseur pour la migration vers le cloud. Azure Portal est l'interface utilisateur cloud la plus conviviale avec une documentation complète, ce qui en fait une bonne option pour les débutants. Le seul inconvénient est qu'Azure est légèrement plus cher par rapport aux concurrents.

Il n'y avait qu'une seule source de données pour cette preuve de concept, ici mise en évidence en violet :

Architecture des données existantes

Extraction (ETL)

La première étape de l'ETL est l'Extraction. Notre tâche était d'obtenir près de 30 tables de la base de données MySQL. Nous avons utilisé Azure Data Factory (ADF) pour cela. En effet, c'est l'une des rares activités où le codage est inutile. La seule partie délicate est qu'un réseau privé héberge la base de données MySQL. Cela signifie que vous devez configurer votre ADF sur une VM appartenant à ce réseau. Le processus d'installation du runtime d'intégration auto-hébergé n'est pas le plus simple. N'oubliez pas non plus de fournir à cette VM un environnement d'exécution Java pour pouvoir extraire les tables en fichiers parquet. C'est un format efficace qui contient des métadonnées. Snappy est le mode de compression par défaut, et nous le recommandons fortement.

ADF a la hiérarchie suivante : Data Factory > Pipelines > Activités. Une fois que vous avez lié votre ADF à toutes les ressources nécessaires (dans notre cas : base de données MySQL, stockage Azure Data et Databricks), vous pouvez commencer à extraire des données avec les 'activités de copie' ainsi nommées. ADF propose deux options : des modèles d'ingestion et des pipelines créés par l'utilisateur.

Dans le premier cas, vous pouvez analyser votre source de données et choisir les tables qui vous intéressent. Vous pouvez copier des tables entières dans le récepteur de votre choix.

Dans le second cas, vous devez créer une activité de copie distincte par table de base de données. Oui, c'est fastidieux, mais vous pouvez y joindre une requête SQL. Cela peut vous faire économiser beaucoup d'espace de stockage si vous souhaitez supprimer des colonnes obsolètes ou filtrer certaines lignes (par exemple, en fonction de la date). De plus, vous voudrez peut-être vérifier si vous avez bien extrait les colonnes de type datetime. Sinon, vous devrez effectuer un casting de type.

Transformation (ETL)

La deuxième étape de l'ETL est la Transformation. Nous avons effectué cela en utilisant deux clusters Spark (un pour le développement et un pour les traitements batch) gérés par l'environnement Databricks. Les notebooks de Databricks sont un moyen pratique d'écrire votre code en Python (ce dialecte s'appelle Pyspark) ou de déboguer et de surveiller les emplois particuliers au sein du cluster en Scala.

Chargement (ETL)

La troisième et dernière étape est le Chargement. La tâche consistait à insérer plusieurs tables de dimensions et de faits stockées en parquet dans l'entrepôt de données, qui est une base de données Azure SQL. Étonnamment, ADF s'est avéré assez limité ici. Vous ne pouvez pas charger plusieurs fichiers parquet automatiquement. De plus, nous ne pouvons pas définir d'options de chargement importantes telles que la troncature/la suppression/le remplacement de tables. Cela nous a amenés à placer les scripts de chargement avec un pilote JDBC dans Databricks en utilisant le code suivant :

df_name.write \    

.format("jdbc") \    

.option("url", "jdbc:postgresql:dbserver") \    

.option("dbtable", "schema.tablename") \    

.option("user", "username") \    

.option("password", "password") \  

.save()

Il existe de nombreuses options avec cette méthode. Elles sont décrites ici : JDBC vers d'autres bases de données - Documentation Spark 3.2.1 (apache.org)

A suivre

Restez à l'écoute pour la Partie 3, où je décrirai une autre histoire cloud utilisant AWS pour aider le client à établir ses flux ETL et ses entrepôts de données.

Dans cet article, suivant la Partie 1, je souhaite illustrer la mise en place d'un projet de flux ETL pour un client du secteur de l'hôtellerie. Le client souhaitant utiliser Power BI comme outil de front-end, nous avons proposé Microsoft comme le bon fournisseur pour la migration vers le cloud. Azure Portal est l'interface utilisateur cloud la plus conviviale avec une documentation complète, ce qui en fait une bonne option pour les débutants. Le seul inconvénient est qu'Azure est légèrement plus cher par rapport aux concurrents.

Il n'y avait qu'une seule source de données pour cette preuve de concept, ici mise en évidence en violet :

Architecture des données existantes

Extraction (ETL)

La première étape de l'ETL est l'Extraction. Notre tâche était d'obtenir près de 30 tables de la base de données MySQL. Nous avons utilisé Azure Data Factory (ADF) pour cela. En effet, c'est l'une des rares activités où le codage est inutile. La seule partie délicate est qu'un réseau privé héberge la base de données MySQL. Cela signifie que vous devez configurer votre ADF sur une VM appartenant à ce réseau. Le processus d'installation du runtime d'intégration auto-hébergé n'est pas le plus simple. N'oubliez pas non plus de fournir à cette VM un environnement d'exécution Java pour pouvoir extraire les tables en fichiers parquet. C'est un format efficace qui contient des métadonnées. Snappy est le mode de compression par défaut, et nous le recommandons fortement.

ADF a la hiérarchie suivante : Data Factory > Pipelines > Activités. Une fois que vous avez lié votre ADF à toutes les ressources nécessaires (dans notre cas : base de données MySQL, stockage Azure Data et Databricks), vous pouvez commencer à extraire des données avec les 'activités de copie' ainsi nommées. ADF propose deux options : des modèles d'ingestion et des pipelines créés par l'utilisateur.

Dans le premier cas, vous pouvez analyser votre source de données et choisir les tables qui vous intéressent. Vous pouvez copier des tables entières dans le récepteur de votre choix.

Dans le second cas, vous devez créer une activité de copie distincte par table de base de données. Oui, c'est fastidieux, mais vous pouvez y joindre une requête SQL. Cela peut vous faire économiser beaucoup d'espace de stockage si vous souhaitez supprimer des colonnes obsolètes ou filtrer certaines lignes (par exemple, en fonction de la date). De plus, vous voudrez peut-être vérifier si vous avez bien extrait les colonnes de type datetime. Sinon, vous devrez effectuer un casting de type.

Transformation (ETL)

La deuxième étape de l'ETL est la Transformation. Nous avons effectué cela en utilisant deux clusters Spark (un pour le développement et un pour les traitements batch) gérés par l'environnement Databricks. Les notebooks de Databricks sont un moyen pratique d'écrire votre code en Python (ce dialecte s'appelle Pyspark) ou de déboguer et de surveiller les emplois particuliers au sein du cluster en Scala.

Chargement (ETL)

La troisième et dernière étape est le Chargement. La tâche consistait à insérer plusieurs tables de dimensions et de faits stockées en parquet dans l'entrepôt de données, qui est une base de données Azure SQL. Étonnamment, ADF s'est avéré assez limité ici. Vous ne pouvez pas charger plusieurs fichiers parquet automatiquement. De plus, nous ne pouvons pas définir d'options de chargement importantes telles que la troncature/la suppression/le remplacement de tables. Cela nous a amenés à placer les scripts de chargement avec un pilote JDBC dans Databricks en utilisant le code suivant :

df_name.write \    

.format("jdbc") \    

.option("url", "jdbc:postgresql:dbserver") \    

.option("dbtable", "schema.tablename") \    

.option("user", "username") \    

.option("password", "password") \  

.save()

Il existe de nombreuses options avec cette méthode. Elles sont décrites ici : JDBC vers d'autres bases de données - Documentation Spark 3.2.1 (apache.org)

A suivre

Restez à l'écoute pour la Partie 3, où je décrirai une autre histoire cloud utilisant AWS pour aider le client à établir ses flux ETL et ses entrepôts de données.

Prêt à atteindre vos objectifs avec les données ?

Si vous souhaitez atteindre vos objectifs grâce à une utilisation plus intelligente des données et de l'IA, vous êtes au bon endroit.

Prêt à atteindre vos objectifs avec les données ?

Si vous souhaitez atteindre vos objectifs grâce à une utilisation plus intelligente des données et de l'IA, vous êtes au bon endroit.

Prêt à atteindre vos objectifs avec les données ?

Si vous souhaitez atteindre vos objectifs grâce à une utilisation plus intelligente des données et de l'IA, vous êtes au bon endroit.

Prêt à atteindre vos objectifs avec les données ?

Si vous souhaitez atteindre vos objectifs grâce à une utilisation plus intelligente des données et de l'IA, vous êtes au bon endroit.

© 2025 Agilytic

© 2025 Agilytic

© 2025 Agilytic