L’environnement de la Data n’a cessé d’évoluer ces dernières années, l’importance de traiter efficacement de grands volumes de données à des fins analytiques ou prédictives ne fait que grandir. Pour répondre à cette problématique, différentes approches ont vu le jour, que ce soit le pour l’architecture avec des Datawarehouses, Data Lakes, Lakehouses ou encore l’hébergement avec l’arrivée de multiples cloud providers. Cependant, même s’ils existent depuis une vingtaine d’années, les Datawarehouses cloud modernes continuent de gagner des parts de marché, menés par Snowflake, Amazon Redshift, Google Cloud BigQuery ou encore Azure Synapse Analytics de Microsoft. 

Dans cet article nous allons nous pencher sur comment il est possible de mettre en place toute une architecture Datawarehouse dans une environnement AWS en s’appuyant à la fois sur les différents services Amazon (Redshift, Redshift Spectrum, AWS Glue Data Catalog et Amazon S3, etc…) ainsi que sur dbt (Data Build Tool), un outil de transformation de données développé par dbt Labs.

Commençons par une présentation rapide des services que nous allons utiliser.

Services AWS

Amazon S3

Amazon S3, ou Amazon Simple Storage Service, est un service de stockage d’objets dans le cloud qui fait partie des très anciens services d’AWS et qui est utilisé par des millions de clients dans le monde.

Il n’est donc plus à présenter, rappelons simplement que les caractéristiques qui ont fait son succès sont sa scalabilité infini permettant de stocker un très gros volume de données, sa disponibilité cible de 99,999999999 %, la réplication automatique et synchronisée des données dans une région AWS, la sécurité qui passe notamment par le cryptage des données, des politiques d’accès granulaires, et une intégration avec AWS Identity and Access Management (IAM).

Notre use case

Dans le cas qui nous intéresse ici, Amazon S3 est utilisé pour stocker nos données sources qui sont déposées dans un bucket sous forme de fichiers de type Apache parquet. Selon le schéma des données, ces fichiers sont répartis dans des “répertoires” (ou plutôt des préfixes) différents au sein du bucket.

AWS Glue

AWS Glue est un service Amazon d’extraction, de transformation et de chargement de données (ETL). Il gère l’infrastructure et nous permet donc de nous concentrer sur les opérations sur les données plutôt que sur la gestion des ressources.

Ce service permet de plus l’utilisation d’un grand nombre de fonctionnalités. Parmi elles le catalogage des données : il centralise les métadonnées, répertorie et organise les sources de données, les schémas, les transformations, etc…. Étant donné qu’il prend en charge une variété de sources de données, notamment Amazon S3 ou Amazon Redshift, le catalogage se fait très aisément pour ces sources, d’autant plus que AWS Glue s’intègre parfaitement avec les services Amazon comme S3 et Redshift mais aussi Athena ou encore Redshift Spectrum.

Notre use case

Vous l’aurez sans doute compris, ce qui va principalement nous intéresser est le catalogage de données stockées dans Amazon S3 que permet AWS Glue. Par l’intermédiaire de crawlers capables de parcourir nos buckets S3, il est possible d’obtenir le schéma de nos données sources depuis les fichiers parquet. Nous créons pour cela une base de données directement dans AWS Glue qui liste alors ces schémas sous forme de tables externes. 

Amazon Redshift Spectrum

Amazon Redshift Spectrum permet d’interroger les données stockées dans des fichiers directement sur Amazon S3, sans avoir à les charger dans Redshift. Cela permet de traiter de grandes quantités de données sans pour autant utiliser une grande capacité de stockage. Les données présentes sur Amazon S3 peuvent directement être interrogées par des requêtes SQL sans provisionner ni gérer d’infrastructures de calcul. Cela réduit la complexité et les coûts liés aux clusters Redshift. Plus précisément, les données stockées dans Amazon S3 sous forme de fichiers sont découvertes et cataloguées par AWS Glue Data Catalog par l’intermédiaire de crawlers. Ces derniers permettent l’accès aux fichiers dans Redshift Spectrum. Ce service est compatible avec un grand nombre de formats standards tels que parquet, ORC, JSON, Avro, CSV ou autres. Vous pouvez alors interroger les données directement à partir des tables externes définies dans le AWS Glue Data Catalog.

Amazon Redshift

Amazon Redshift est un service AWS de base de données de type Datawarehouse hautement extensible, il est possible de facilement augmenter ou diminuer la taille d’un cluster Redshift selon vos besoins en stockage ou en puissance de calcul.

Tout comme pour les services listés précédemment, Redshift s’intègre simplement avec Amazon S3 (au travers de Redshift Spectrum), AWS Glue et bien d’autres. Le service s’utilise comme toute autre base de données et permet l’écriture et l’exécution de vos requêtes analytiques. Il apporte aussi une couche de sécurité en vous permettant le chiffrement des données en transit et au repos, les contrôles d’accès granulaires, la gestion des clés de chiffrement, etc…

Pour mettre en place une architecture Datawarehouse complète dans AWS, de nombreux services  comme par exemple AWS IAM pour la gestion de la sécurité et des rôles des utilisateurs, Amazon CloudWatch pour la gestion des logs ou Amazon CloudFormation pour le déploiement des configurations de ces services.

dbt

dbt est un outil open source développé par dbt Labs qui permet d’exécuter des transformations de données SQL de tout type directement dans leur entrepôt de données : dbt est basé sur les processus ELT (Extract, Load, Transform). Toutefois, n’importe quel workbench SQL est capable de cela. Ce qui fait la spécificité de dbt est qu’il s’agit d’un outil de collaboration permettant le partage et la réutilisation des transformations de données. Les utilisateurs peuvent publier leurs transformations sur des référentiels git et les partager avec toute l’équipe, ce qui favorise la réutilisation du code et la cohérence des transformations.

dbt fournit de plus des fonctionnalités comme la planification des exécutions, la gestion des dépendances entre les requêtes et le monitoring des workflows. Il permet en somme aux utilisateurs de créer des pipelines de transformation pouvant être répliqués et orchestrés.

A cela s’ajoutent d’autres fonctionnalités comme la mise en place de tests de qualité des données permettant aux utilisateurs de valider leurs transformations. Vous pouvez aussi très simplement générer automatiquement une documentation détaillée de votre modèle de données, y compris les tables, les colonnes, les transformations et les dépendances. Vous pouvez trouver plus de détails au sujet de ces test sur notre article de blog : Mon meilleur ami c’est dbt test.

dbt est donc un outil complet de transformation de données s’intégrant facilement aux Datawarehouses cloud modernes tels que Amazon Redshift. Il vous est possible de l’héberger au sein de votre environnement avec la solution dbt-core, bibliothèque open source ou de profiter de la plateforme dbt cloud. La première solution est celle qui sera présentée par la suite.

Les principaux outils que nous allons utilisés sont enfin présentés, il ne nous reste plus qu’à vous décrire comment ils peuvent être intégrés afin de mettre en place votre architecture Datawarehouse dans AWS. 

Création d’un Datawarehouse AWS x dbt

Prérequis

Les prérequis pour la mise à place de cette architecture comprennent les éléments suivants :

  • Un bucket Amazon S3 pour stocker les données brutes ;
  • Un cluster Amazon Redshift provisionné ou Amazon Redshift Serverless ;
  • Un rôle IAM AWS par service avec des autorisations pour Amazon Redshift, Amazon S3 et AWS Glue ;
  • dbt-core installé sur votre machine ou un autre serveur (une instance Amazon EC2 par exemple);
  • Le connecteur dbt pour Amazon Redshift installé localement ;
  • Un IDE capable d’interpréter du code SQL. Ici nous utiliserons Microsoft Visual Studio Code (VS Code) avec les extensions dbt Power User installées

Organisation des sources de données avec Amazon S3

Les sources de données sont ici des fichiers au format parquet déposés dans un bucket S3. En prévision de la création d’un Data Catalog, les fichiers possédant le même schéma, sont regroupés dans un même “répertoire”. Plus précisément, la notion de répertoire n’est qu’un moyen pour l’utilisateur d’organiser ses fichiers mais n’existe pas dans S3. Il s’agit plus exactement d’un préfixe aux noms de fichier et d’un délimiteur, le plus souvent “/”.

Dans le cas où les fichiers ne sont pas organisés de cette manière au moment de leur dépôt sur le bucket S3, AWS Glue peut être utilisé afin de créer des jobs ETL permettant de réorganiser les fichiers source. Ces jobs peuvent être développés avec divers frameworks et ne nécessitent pas de provisionner les ressources pour leur exécution, AWS Glue le fait pour pour nous. Cependant les ressources mises à dispositions peuvent être configurées dans un souci d’optimisation et de gestion des coûts.

Une fois les fichiers sources en place, les buckets S3 peuvent êtres organisés de la façon suivante :

Figure 1 : Bucket S3 demo-dwh-source contenant les fichiers de données sources

Création d’une base de données avec AWS Glue Data Catalog

Une autre fonctionnalité d’AWS Glue est la mise en place de crawler capables de parcourir une partie ou l’intégralité d’un bucket S3, selon l’application de filtres sur les noms de fichiers, donc les préfixes mentionnés plus haut.

Une fois un crawler exécuté, il met à disposition les métadonnées de nos fichiers sources au sein d’une base de données du Data Catalog AWS Glue sous la forme de tables externes. Ces tables sont définies par les schémas, types de données, clés de partition, chemins d’accès aux fichiers sources, etc… L’exécution de ces crawlers peut être orchestrée directement à partir d’AWS Glue afin de rafraîchir ces métadonnées.

Figure 2 : Liste des tables externes du Data Catalog AWS Glue après exécution du crawler
Figure 3 : Métadonnées de la table externe client mises à disposition par le crawler

Création d’un cluster de bases de données dans Amazon Redshift

La mise en place d’une base de données aves Amazon Redshift commence par la création d’un cluster. Lors de cette création vous devez spécifier les détails de configuration pour votre cluster Redshift, y compris la taille du cluster, le type d’instance, le nombre de nœuds, la classe d’instance, etc… Ce paramétrage n’est néanmoins pas définitif et, selon vos besoins de performance et de stockage, il vous sera possible d’ajuster cette configuration sans pour autant créer un nouveau cluster et donc conserver vos bases de de données.

Figure 4 : Ecran de création d’un cluster Amazon Redshift

Il vous faudra de plus configurer la sécurité (groupes de sécurité contrôlant les connexions au cluster, sous-réseaux VPC autorisés à accéder au cluster, les clés de chiffrement pour les données, etc…). Vous devrez aussi prendre en compte les options de maintenance, les autorisations ainsi que les différents paramètres tels que la performance, la compression ou le chargement de données.

Une fois toutes les configurations terminées, vous pouvez valider les paramètres du cluster et lancer le processus de création. AWS Redshift commencera alors à provisionner les ressources nécessaires et à déployer le cluster. Une fois le cluster créé, vous pouvez surveiller ses performances, gérer les sauvegardes, les mises à jour logicielles et tout autre élément paramétrable.

Il est important de noter que la création d’un cluster Redshift peut prendre un certain temps en fonction de la taille et de la complexité du cluster, ainsi que des options de configuration spécifiées.

Une fois votre cluster Redshift créé, connectez-vous à celui-ci à l’aide de votre l’outil de votre choix (SQL Workbench/J, pgAdmin ou autre) ou directement par la console AWS grâce à l’Editeur de requête. Une fois connecté à votre cluster, vous pouvez exécuter des requêtes SQL pour créer une base de données. Notons cependant que seuls les utilisateurs disposant des autorisations nécessaires peuvent créer une base de données dans Amazon Redshift.

Accès aux données sources grâce Amazon Redshift Spectrum

La première étape dans l’accessibilité de nos données sources est de s’assurer que les rôles IAM associés à notre cluster Redshift ont les autorisations appropriées pour accéder au catalogue de données Glue. Vous devrez donc ajouter des autorisations pour les différentes actions de la façon suivante :

"Statement": [
{
"Action": [
"glue:GetDatabase",
"glue:GetPartition",
"glue:GetTables",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:GetDatabases",
"glue:GetTable",
"glue:CreateTable"
],
"Effect": "Allow",
"Resource": [
"arn:aws:glue:eu-west-***:table/***/*",
"arn:aws:glue:eu-west-***:database/***",
"arn:aws:glue:eu-west-***:table/***/*",
"arn:aws:glue:eu-west-***:database/***",
"arn:aws:glue:eu-west-***:catalog"
]
}
]

Avec l’accès configuré, vous pouvez maintenant exécuter des requêtes SQL sur votre cluster Redshift pour accéder aux métadonnées de la base de données Glue et aux tables qu’elle contient. Le plus simple pour cela est de créer un schéma au sein de Redshift qui sera directement relié à la base du Data Catalog AWS Glue.

Construction d’un Datawarehouse dans Amazon Redshift avec dbt

Créer une nouvelle base de données

Créez une nouvelle base de données Redshift à utiliser pour la démonstration, ici nommée demo. Les requêtes listées ici peuvent être exécutées depuis un workbench SQL permettant une connexion à Amazon Redshift ou directement via la console AWS grâce à l’onglet Query editor v2.

Figure 5 : Editeur SQL Query editor v2 accessible depuis la console AWS

Créer des schémas de base de données

Au sein de la nouvelle base de données Redshift demo, créez le schéma externe (demo_external dans notre cas) associé au catalogue de données AWS Glue externe correspondant, demo-db, en utilisant la commande SQL Redshift CREATE EXTERNAL SCHEMA. Assurez-vous de mettre à jour la commande pour refléter l’ARN de votre rôle IAM. Ensuite, créez les schémas qui contiendront nos modèles dbt, demo_staging par exemple. Enfin, par mesure de sécurité, supprimez le schéma public par défaut. Vous devriez voir apparaître un nouveau catalogue de données.

CREATE EXTERNAL SCHEMA demo_external FROM DATA CATALOG DATABASE demo-db IAM_ROLE default;

Créer un utilisateur et un groupe de base de données dbt

Afin de suivre les best practices en matière de sécurité, créez un utilisateur de base de données dbt et un groupe dbt distincts. Ensuite, appliquez les autorisations pour permettre à groupe dbt d’accéder à la nouvelle base de données et aux schémas. Enfin, changez les propriétaires des deux schémas pour l’utilisateur dbt (ici usr_demo_dbt).

Initialiser et configurer dbt pour Redshift

Il ne reste plus qu’à mettre en place le projet dbt qui permettra l’alimentation et la construction du Datawarehouse dans Amazon Redshift. Dans le cas présenté ici nous utiliserons dbt-core et non le produit cloud. Ce dernier repose cependant sur la même structure. Il vous faudra donc organiser votre code selon les répertoires suivant :

models

Ce dossier contient tous les fichiers SQL qui définissent les modèles de données. Chaque fichier SQL représente un modèle unique, tel qu’une table, une vue ou une requête SQL. Ces modèles sont la principale composante du projet dbt, où vous développerez la logique de transformation des données.

macros

ll rassemble des fichiers SQL qui définissent des macros dbt réutilisables. Les macros sont des fragments de code SQL qui peuvent être appelés à partir d’autres modèles ou analyses pour encapsuler une logique de traitement de données, il s’agit donc de fonctions réutilisables au sein de votre code SQL. Les requêtes définis précédemment peuvent par exemple être exécutées par ces fonctions. Une macro peut être appelée au sein d’un modèle dbt ou par la commande dbt run-operation ma_macro.

analyses

Il regroupe des fichiers SQL qui définissent des analyses ou des requêtes analytiques à exécuter sur les données. Les analyses peuvent être utilisées pour explorer les données, identifier des tendances, calculer des métriques, etc…

dbt_project.yml

Il s’agit du fichier de configuration principal du projet dbt. Il contient des informations sur le projet, telles que son nom, son ID, ses dépendances, ses paramètres de connexion à la base de données (ici nous utilisons le profile défini dans le fichier ~/.dbt/profiles.yml), etc…

name: 'demo_dwh'
version: '1.0.0'
config-version: 2

profile: 'demo_redshift'

model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
macro-paths: ["macros"]

target-path: "target"
clean-targets:
- "target"
- "dbt_packages"

models:
demo_dwh:
staging:
+schema: demo_staging
+materialized: table
intermediate:
+schema: demo_intermediate
+materialized: table
marts:
+schema: demo_marts
+materialized: table

Autres fichiers et dossiers

En fonction des besoins spécifiques du projet, vous pouvez également trouver d’autres fichiers ou dossiers dans la structure du projet dbt, tels que des fichiers de seeds, des fichiers de configuration supplémentaires, des tests, etc…

Figure 6 : Organisation d’un projet dbt ouvert ici avec Visual Studio Code

La structure du projet dbt suit le guide des best practices de dbt Labs. Les modèles de données dans le répertoire models sont notamment organisés dans les sous-répertoires de staging, intermediate et marts qui représentent les couches de notre Datawarehouse.

Enfin, pour permettre la communication avec votre cluster Redshift, configurez dbt localement avec les informations de connexion à Amazon Redshift en éditant le fichier ~/.dbt/profiles.yml. Vous aurez besoin de l’URL de l’hôte de votre cluster Redshift, du port, de la base de données, du nom d’utilisateur et du mot de passe ou de votre profile iam.

demo_redshift:
send_anonymous_usage_stats: False
outputs:
redshift_demo_db:
type: redshift
method: iam
cluster_id: datawarehouse-demo
host: datawarehouse-demo.*******.********.redshift.amazonaws.com
user: usr_demo_dbt
iam_profile: demo_profile
iam_duration_seconds: 900
port: 5439
dbname: demo_db
schema: public
threads: 4
keepalives_idle: 240
connect_timeout: 10
retries: 1
target: redshift_demo_db

Vous pouvez confirmer la configuration de votre projet avec la commande dbt debug.

Installer les modules dbt

Le fichier packages.yml du projet GitHub contient les modules utilisés dans notre projet dbt. Le seul nécessaire dans cotre cas est dbt-labs/dbt_utils mais d’autres peuvent être ajoutées selon les fonctions utiles à vos modèles dbt.

Utiliser la commande dbt deps pour installer les modules en local et pouvoir y accéder directement depuis votre code.

Développer et alimenter le Datawarehouse avec dbt

Dans les étapes précédentes nous avons préparé la structure de notre projet dbt, défini nos sources de données et configuré notre profil de connexion. Il ne nous reste donc plus qu’à créer les différents modèles dbt, c’est-à-dire l’ensemble des fichiers SQL qui vont définir la logique de transformation de nos données. Rappelons que chaque fichier correspond à une table de notre Datawarehouse et contient les requêtes SQL permettant de la construire en extrayant, transformant et chargeant les données.

La figure 6 vous donne l’exemple d’un de ces fichiers. Il s’agit ici d’une requête permettant la construction de la table stg_client avec une étape de déduplication et l’utilisation d’une fonction importée depuis un module : dbt_utils.star.

Une fois les modèles configurés, vous pouvez exécuter dbt pour alimenter la base Redshift. Utilisez pour cela la commande dbt run pour exécuter l’ensemble des modèles dbt, charger les données et peupler votre Datawarehouse. Notons que si un modèle fait appel à un autre, l’exécution respectera les dépendance grâce au DAG (Directed Acyclic Graph) généré automatiquement par dbt.

Il ne vous reste plus alors qu’à explorer les données de votre Datawarehouse ou encore le requêter avec tout outil de visualisation et d’analyse disposant d’un connecteur Amazon Redshift (Power BI, Tableau Software, etc…)

Conclusion

Dans cet article nous avons pu parcourir quelques-uns des services AWS permettant le stockage, l’organisation et l’accès à des sources de données brutes. Nous avons vu comment, grâce à chacun, il est possible avec une solution ELT comme dbt de construire et alimenter un Datawarehouse dans le cloud.

Nous avons de plus partagé certaines des caractéristiques de dbt mais avons surtout vu comment cet outil s’intègre dans un environnement AWS. Nous ne nous sommes pas penchés ici en détail sur toutes les fonctionnalités que cet outil apporte. Il en propose néanmoins une grande variété comme la mise en place de tests, la génération automatique de documentation, l’orchestration de jobs, l’utilisation de templates et macros Jinja, l’intégration incrémentale des données, etc… Celles-ci vous seront incoutournables lors de la mise en place de projets à plus grande échelle.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *