Athena couvre très bien l'exploration des données, mais il montre ses limites quand on a par exemple des dashboards avec des jointures lourdes entre grosses tables ou même avoir 30 utilisateurs en simultané, à ce moment-là il faut un vrai entrepôt de données. Sur AWS, c’est Redshift Serverless qui va nous servir de DWH.

Dans cet article, on va créer l'entrepôt avec les bons réglages pour éviter la mauvaise surprise de facturation, et ensuite charger la table commandes depuis S3 avec COPY, et enfin répondre à la question qu'on a poser au début de la formation, à savoir on doit utiliser Athena ou Redshift. ;)

Namespace et workgroup

Redshift Serverless sépare deux choses. Le namespace, c'est le stockage, les databases, les users etc... donc tout ce qui persiste. Le workgroup c'est le calcul qui exécute les requêtes et qu'on paye.

Le calcul se mesure en RPU (Redshift Processing Units). On paye donc les RPU à la seconde quand des requêtes tournent, environ 0,49 $ par RPU-heure, et rien du tout quand l'entrepôt est au repos. Pas de requête, pas de facture, c'est tout l'intérêt du Serverless pour apprendre.

Créer l'entrepôt

  1. Ouvre le service Amazon Redshift, menu de gauche "Redshift serverless", puis "Create workgroup".
  2. Nomme le namespace ns-formation et on nomme le workgroup wg-formation.
  3. Base capacity : 32 RPU. on prend le minimum possible car la valeur par défaut est bien plus haute, et comme la facture est proportionnelle aux RPU, la laisser va multiplier le coût de chaque seconde de calcul et pour tester 32 RPU suffit largement pour nos volumes.
  1. Section "Permissions", clique sur "Manage IAM roles" puis "Create IAM role", avec l'accès à notre bucket S3 ibdata-datalake-formation car ce rôle servira au COPY pour lire S3, donc la même logique que ce qu'on vu précédemment avec le crawler et le job Glue.

Ensuite, il faut créer le namespace ns-formation, et définir les identifiants admin (user + mot de passe).

  1. Valide et ensuite il faut attendre quelques minutes pour la mise en place de l'instance.

On check le statut, il doit être "Available"

Se connecter avec Query editor v2

Pas de client à installer car la console embarque déjà un éditeur SQL. Menu de gauche, "Query editor v2", clique sur ton workgroup dans l'arborescence.

L'interface ressemble un peu à Athena, mais attention, on n'est plus dans le même monde car ici les requêtes tournent sur un moteur PostgreSQL like avec la donnée chargée dans l'entrepôt, pas directement à partir des fichiers S3.

Interface redshift

Charger la table avec COPY

On doit créer la table avec des types de données bien précis.

CREATE TABLE commandes (
    commande_id   VARCHAR(10),
    client_id     VARCHAR(10),
    produit_id    VARCHAR(10),
    quantite      BIGINT,
    montant       DOUBLE PRECISION,
    date_commande DATE,
    statut        VARCHAR(20)
);

Puis le chargement. COPY est la commande de chargement massif de Redshift, elle lit S3 en parallèle et c'est le meilleur moyen de charger des volumes (jamais de INSERT ligne à ligne).

COPY commandes
FROM 's3://ibdata-datalake-formation/clean/commandes/'
IAM_ROLE default
FORMAT AS PARQUET;

On charge le fichier commande du bucket clean (995 lignes propres, dédupliquées par le job Glue), au format Parquet donc avec les types embarqués, et IAM_ROLE default utilise le rôle associé au namespace à l'étape de création.

Et si tu as déjà travaillé avec Snowflake, c'est l'équivalent exact du COPY INTO depuis un stage.

Vérification.

SELECT COUNT(*) FROM commandes;
-- 995

SELECT date_trunc('month', date_commande) AS mois, ROUND(SUM(montant), 2) AS ca
FROM commandes
WHERE statut != 'annulee'
GROUP BY 1 ORDER BY 1;

💡
En cas d'erreur au COPY, le message de Redshift est souvent pas clair. regarde le détail est dans la vue système SYS_LOAD_ERROR_DETAIL avec un SELECT * FROM sys_load_error_detail ORDER BY start_time DESC LIMIT 5; et tu vas trouver la raison du rejet.

Athena ou Redshift

La question que je me suis poser lorsque j'ai commencé à utiliser les services AWS. Avec le temps j'ai compris que la réponse est simple et ce n'est ni l'un ni l'autre car chacun à son usage, et les deux cohabitent dans la plupart des architectures.

Athena pour explorer le lake, les analyses ponctuelles et les besoins irréguliers. La donnée reste dans S3 et on paye au scan, c'est ce que j'utilise quotiennement dans ma mission actuelle chez le groupe seb pour explorer les données s3.

Redshift, quand on veut un vrai DWH avec de la BI branchée dessus. Les données sont chargées et organisées pour ça, et donc on paye la puissance de calcul utilisée.

Et il existe aussi un pont entre les deux et c'est Redshift Spectrum qui permet de requêter directement depuis Redshift les tables du data lake présentes dans le Glue Data Catalog, sans avoir à les charger dans Redshift. Le data lake et l’entrepôt peuvent ainsi partager le même catalogue.

Ce que ça coûte

Le workgroup au repos ne facture aucun calcul, et le stockage de nos 995 lignes se compte en fractions de centime. La session du jour avec création comprise et les quelques requêtes doit nous coûter moins de 1 $. Mais attention, chaque requête réveille l'entrepôt avec un minimum de 60 secondes facturées, c'est pour ça qu'il faut regrouper ses manips plutôt que de lancer une requête par heure.

On garde le workgroup pour la suite de la formation, il ne coûte rien entre les sessions. On fera le nettoyage final à la fin de la formation dans le module FinOps.

La checklist finale

  • [ ] Workgroup wg-formation créé
  • [ ] Namespace ns-formation avec son rôle IAM d'accès S3
  • [ ] Table chargée avec COPY depuis la zone clean, 995 lignes
  • [ ] La règle Athena vs Redshift retenue

La suite ?

Toutes les briques du pipeline existent, la Lambda qui range les fichiers, le crawler, le job Glue, l'entrepôt. Mais elles tournent à la main, chacune dans son coin. Prochain article, Step Functions et EventBridge, on les enchaîne dans un pipeline orchestré qui tourne tout seul chaque matin, avec gestion d'erreur et retry.

Aller plus loin

Le programme complet du parcours est sur la page de la formation AWS.

Tu prépares la certification AWS Certified Data Engineer Associate (DEA-C01) ? Redshift Serverless, COPY et le choix entre les magasins de données sont au cœur de l'examen. Pour t'entraîner, j'ai créé des questions d'examen blanc en français.

👉 S'entraîner sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (AWS, Snowflake, dbt, modélisation, coûts) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes

C'est quoi Redshift Serverless ?

La version sans cluster de l'entrepôt Redshift. Le stockage vit dans un namespace, le calcul dans un workgroup mesuré en RPU, facturé à la seconde uniquement quand des requêtes tournent. Au repos, aucun coût de calcul.

C'est quoi un RPU ?

Une Redshift Processing Unit, l'unité de calcul du Serverless. Le workgroup a une base capacity (32 RPU minimum) qui détermine la puissance et le coût par seconde, environ 0,49 $ par RPU-heure sur la région Paris.

Athena ou Redshift, lequel choisir ?

Les deux, chacun son usage. Athena pour l'exploration du data lake et les analyses ponctuelles, payé au scan, sans infrastructure. Redshift pour les requêtes répétées, les dashboards BI et la forte concurrence, avec des latences en millisecondes.

Comment charger des données S3 dans Redshift ?

Avec la commande COPY, qui lit S3 en parallèle. Elle prend le chemin S3, un rôle IAM autorisé à lire le bucket, et le format (Parquet, CSV, JSON). C'est la seule bonne méthode pour les volumes.

C'est quoi Redshift Spectrum ?

La capacité de Redshift à requêter directement les tables du data lake, déclarées dans le Glue Data Catalog, sans les charger dans l'entrepôt. Ça permet de joindre des tables chargées avec des tables restées dans S3, et de garder un seul catalogue pour tout.