📈 Amazon Redshift – DWH, Spectrum & VACUUM

Qu'est-ce qu'Amazon Redshift ?

Amazon Redshift (basé sur PostgreSQL 8.0) est un Data Warehouse (Entrepôt de Données) "entièrement managé" (PaaS) sur AWS. C'est un DWH "historique" du Cloud, conçu pour l'analytique SQL (OLAP) et la Business Intelligence (BI).

Objectif : Exécuter des requêtes SQL complexes (JOIN, GROUP BY, Window Functions) très rapidement sur des volumes massifs (Pétaoctets) de données.

Architecture : MPP (Massively Parallel Processing)

Redshift (comme Teradata ou Netezza) est un DWH MPP (Traitement Parallèle Massif). Une requête n'est pas exécutée par 1 serveur, mais distribuée (parallélisée) sur des centaines de CPU (Slices) qui travaillent en même temps.

Un "Cluster" Redshift est composé de deux types de Nœuds (Instances EC2) :

(Client SQL / BI Tool)
       │
       │ (Connexion SQL, Port 5439)
       ▼
[ 1. LEADER NODE ] (1 Nœud)
   (Le "Cerveau" : Optimizer, Query Planner)
   (Ne stocke pas de données)
   │
   │ (Distribue le plan d'exécution
   │  parallèle aux Nœuds Compute)
   │
   ├────────► [ 2. COMPUTE NODE 1 ] (Le "Muscle")
   │            ├─ [Slice 0 (vCPU)] -> (Stocke/Scanne 1/N)
   │            └─ [Slice 1 (vCPU)] -> (Stocke/Scanne 1/N)
   │
   ├────────► [ 2. COMPUTE NODE 2 ] (Le "Muscle")
   │            ├─ [Slice 2 (vCPU)] -> (Stocke/Scanne 1/N)
   │            └─ [Slice 3 (vCPU)] -> (Stocke/Scanne 1/N)
   │
   ...
   │
   └────────► [ 2. COMPUTE NODE 'N' ]

• Leader Node (Nœud Principal) : (1 par cluster) Le "cerveau" (Control Plane). Reçoit la requête SQL, la parse, l'optimise (plan d'exécution), la compile en C++, et coordonne l'exécution sur les Nœuds Compute.
• Compute Nodes (Nœuds de Calcul) : (1 à 128 nœuds) Les "muscles" (Data Plane). Ils stockent les données (distribuées) et exécutent les tâches (scan, join, aggregate) en parallèle.
• Slices (Tranches) : Chaque Nœud Compute est divisé en "Slices". (1 Slice = 1 vCPU/RAM). C'est l'unité de parallélisme.

Le Leader Node (Nœud Principal) est le point d'entrée (Endpoint) et le "cerveau" (Optimizer) du cluster. Il ne participe pas au scan des données.

Rôles du Leader Node

1. Endpoint (SQL) : Reçoit la connexion SQL (ex: psql, Tableau) sur le port (ex: 5439).
2. Parser/Optimizer (Analyseur) : Parse le SQL, vérifie les permissions, et consulte les statistiques (voir 6.2) pour créer le Plan d'Exécution (Query Plan) le plus efficace (ex: "Quel JOIN en premier ?").
3. Compiler (Compilateur) : (Optimisation) Compile le Plan (SQL) en code C++ (binaire) optimisé.
4. Coordinator (Coordinateur) : Distribue (dispatch) les étapes (segments) du plan compilé aux Compute Nodes (2.2).
5. Aggregator (Agrégateur) : Reçoit les résultats partiels des Compute Nodes, les agrège (ex: SUM final), et renvoie le résultat final au client.

Les Compute Nodes (Nœuds de Calcul) sont les "workers" (muscles) qui stockent les données et exécutent les requêtes.

Slices (Tranches)

Chaque Compute Node est divisé en Slices. Une Slice est l'unité de parallélisme (elle possède sa propre portion de RAM/Disque et 1 vCPU).

Exemple : Un cluster dc2.large (2 Nœuds). Chaque nœud dc2.large a 2 Slices.
Total = 4 Slices (4 vCPUs).

Lorsqu'une table est créée, Redshift distribue (DISTKEY) les données entre les Slices.

(Table 'Ventes', 1M Lignes)
   │
   ├─► [Slice 0] (Stocke 250k Lignes) -> (Exécute 1/4 du 'WHERE')
   ├─► [Slice 1] (Stocke 250k Lignes) -> (Exécute 1/4 du 'WHERE')
   ├─► [Slice 2] (Stocke 250k Lignes) -> (Exécute 1/4 du 'WHERE')
   └─► [Slice 3] (Stocke 250k Lignes) -> (Exécute 1/4 du 'WHERE')

Résultat (MPP) : La requête (SELECT) s'exécute 4x plus vite (en parallèle).

Le choix du type de Nœud (Compute) définit l'architecture de stockage.

Redshift (comme tous les DWH analytiques) utilise un stockage colonnaire.

Ligne (OLTP) vs Colonne (OLAP)

(Ligne 1) [ID_A | Nom_A | Ville_A]
(Ligne 2) [ID_B | Nom_B | Ville_B]
(Ligne 3) [ID_C | Nom_C | Ville_C]

(Fichier Col_ID)   [ID_A | ID_B | ID_C]
(Fichier Col_Nom)  [Nom_A | Nom_B | Nom_C]
(Fichier Col_Ville) [Ville_A | Ville_B | Ville_C]
(Fichier Col_Age)  [Age_A | Age_B | Age_C]

La Clé de Distribution (DISTKEY) est le choix d'optimisation (admin) le plus important. Elle définit comment Redshift "distribue" (répartit) les lignes d'une table sur les Slices (2.2).

Optimisation (DISTKEY=KEY)

Si users et ventes sont DISTKEY(user_id), les lignes (ex: "Bob" et "ses Ventes") sont colocalisées (sur le même Slice). Le JOIN se fait localement (sur le Slice), sans aucun "shuffle" (mélange) réseau (très rapide).

La Clé de Tri (SORTKEY) définit comment les données sont triées (ordonnées) physiquement sur le disque (à l'intérieur d'un Slice).

Objectif : (Similaire au "Pruning" (3.2) de Snowflake) Permettre à Redshift de "sauter" (ignorer) des blocs de disque entiers.

Usage : Mettre la colonne la plus filtrée (WHERE) (souvent la Date) comme SORTKEY.

Exemple (SORTKEY(date))

Si la table est triée par date, les données sont stockées comme ça :

[Bloc 1 (Janv)] [Bloc 2 (Fév)] [Bloc 3 (Mars)] ... [Bloc 12 (Déc)]

Requête : SELECT ... WHERE date = 'Mars'

Résultat : Redshift (grâce au SORTKEY) ne lit que le Bloc 3 (rapide), et ignore (saute) les 11 autres blocs (I/O réduit).

Redshift Spectrum est une fonctionnalité de Redshift qui permet d'exécuter des requêtes SQL directement sur des fichiers stockés dans votre Data Lake (Amazon S3).

Le Problème (Données Froides)

Stocker 10 Pétaoctets de logs (données "froides", rarement requêtées) dans un Cluster Redshift (Stockage local DC2) coûte extrêmement cher (coût des nœuds 24/7).

La Solution (Spectrum)

Vous stockez les 10 Po de logs (froid) sur S3 (très bon marché), et vous ne gardez que 1 To (chaud) dans Redshift (local).

Spectrum vous permet de requêter (SELECT) les données sur S3 sans avoir à les charger (COPY) d'abord dans Redshift.

Requête "Lakehouse" :
SELECT ...
FROM [Table Locale (Chaude)] AS T1
JOIN [Table Externe (Spectrum/S3)] AS T2
ON T1.id = T2.id

Facturation : Vous payez (comme BigQuery) au To scanné (lu) sur S3 par Spectrum.

Pour utiliser Spectrum, vous devez créer (dans Redshift) une Table Externe (EXTERNAL TABLE) qui "pointe" vers les données (fichiers) sur S3.

Le "Metastore" (AWS Glue)

Redshift (Spectrum) a besoin d'un "catalogue" (Metastore) pour savoir où sont les fichiers S3 et quel est leur schéma (colonnes).

Il utilise (généralement) le AWS Glue Data Catalog (le "Metastore" partagé d'AWS, aussi utilisé par Athena, EMR, Databricks).

-- 1. (Optionnel) Créer un "Schéma Externe"
--    lié au Catalogue Glue
CREATE EXTERNAL SCHEMA schema_s3
FROM DATA CATALOG
DATABASE 'ma_db_glue'
IAM_ROLE 'arn:aws:iam::...'

-- 2. Créer la Table Externe (pointant vers GCS)
-- (Note : La définition de la table est dans Glue,
--  Redshift ne fait que la "lire")
CREATE EXTERNAL TABLE schema_s3.logs_externes (
  id INT,
  message VARCHAR(255),
  date DATE
)
PARTITIONED BY (date) -- (Optimisation : Partitions S3)
ROW FORMAT SERDE ...
STORED AS PARQUET
LOCATION 's3://mon-bucket/logs/'

Spectrum est la solution "Lakehouse" d'AWS. Il permet de joindre (JOIN) des données "chaudes" (rapides, locales) avec des données "froides" (lentes, S3).

Exemple (Ventes + Logs)

Problème : Vous voulez analyser les ventes (1 To, table "chaude") et les croiser (JOIN) avec les logs web bruts (5 Po, table "froide").

Sans Spectrum : Vous devez COPY 5 Po de S3 vers Redshift (coût/temps impossible).

Avec Spectrum (JOIN Fédéré)

• ventes_prod (Table Locale RA3, 1 To, Chaude/Rapide)
• logs_s3 (Table Externe (Spectrum), 5 Po, Froide/S3)

SELECT
    v.commande_id,
    l.user_agent
FROM
    ventes_prod AS v
JOIN
    schema_s3.logs_externes AS l
    ON v.user_id = l.user_id
WHERE
    v.date > '2025-11-01'
AND l.date_partition = '2025-11-01'

Flux : Redshift (Leader) est assez intelligent pour :

1. Scanner (rapidement) ventes_prod (local).
2. Pousser (Pushdown) le filtre (user_id) vers Spectrum.
3. Spectrum (couche compute S3) scanne S3 (Parquet) et ne renvoie que les lignes pertinentes.
4. Le Leader Node fait le JOIN final.

La commande COPY est la méthode principale et la plus performante (Bulk) pour charger (ingérer) des données dans une table Redshift (stockage local).

Fonctionnement (Parallèle)

COPY est parallélisé. Le Leader Node demande à tous les Compute Nodes (Slices) de lire (en parallèle) des morceaux des fichiers (depuis S3) et de les ingérer dans leur stockage local.

Exemple (COPY depuis S3)

COPY ma_table
FROM 's3://mon-bucket/data/mon_fichier.parquet'
IAM_ROLE 'arn:aws:iam::...'
FORMAT AS PARQUET;

-- (Exemple CSV)
COPY ma_table
FROM 's3://mon-bucket/data/mon_fichier.csv'
IAM_ROLE 'arn:aws:iam::...'
FORMAT AS CSV
DELIMITER ','
IGNOREHEADER 1;

Bonne Pratique : Pour une performance maximale, chargez plusieurs fichiers (compressés/gzip) de taille similaire (1MB-1GB), idéalement un multiple du nombre de Slices (2.2) du cluster.

WLM (Workload Management) est le "contrôleur de trafic" (QoS) de Redshift. Il gère la priorité et la concurrence des requêtes.

Fonctionnement (Files d'attente - Queues)

WLM (par défaut "Auto WLM") analyse les requêtes et les place dans des files d'attente (Queues) (pools) avec des priorités différentes.

Exemple (Simplifié) :

• Queue 1 (Superuser) : (Priorité Max) Réservée à root (Admin).
• Queue 2 (BI Dashboards) : (Priorité Haute) (ex: USER GROUP 'bi_users'). Donnez 50% de la RAM.
• Queue 3 (ETL Jobs) : (Priorité Basse) (ex: USER GROUP 'etl_users'). Donnez 30% de la RAM.
• Queue 4 (Data Science) : (Priorité Basse) (ex: USER GROUP 'ds_users'). Donnez 20% de la RAM.

Résultat : Si l'ETL (lourd) tourne, il ne peut pas saturer la RAM/CPU allouée à la queue "BI", garantissant que les dashboards (PDG) restent rapides.

C'est la réponse "Auto-scale" de Redshift (similaire au "Multi-Cluster Warehouse" (4.2) de Snowflake).

Le Problème (Pics de Concurrence)

Lundi 9h00. Votre cluster (ex: 4 nœuds) est saturé. Les requêtes (BI) sont mises en file d'attente (Queued) par WLM (5.2).

La Solution (Scaling Éphémère)

Si Concurrency Scaling (Scaling de Concurrence) est activé :

1. Redshift (WLM) détecte la file d'attente.
2. Il démarre (spin-up) automatiquement un nouveau "Cluster de Concurrence" (éphémère) (ex: 4 nœuds) en quelques secondes.
3. Il route les requêtes (en attente) vers ce nouveau cluster.
4. (Si la charge continue) Il démarre un 3ème, 4ème... cluster (jusqu'à 10 par défaut).
5. (Quand le pic est passé) Il arrête automatiquement les clusters éphémères.

Facturation : Facturé à la seconde (similaire à Snowflake). (AWS offre 1 heure "gratuite" par jour pour 97% des cas d'usage).

Le Piège n°2 : Le Leader Node (2.1) (l'Optimizer) a besoin de Statistiques à jour pour créer des plans de requête efficaces (ex: "Combien de lignes ? Quelle est la cardinalité (valeurs uniques) ?").

Si vous chargez (COPY) 1 Milliard de lignes, le Leader Node (sans ANALYZE) pense toujours que la table est vide.

La Solution : ANALYZE

La commande ANALYZE (ou ANALYSE) scanne (échantillonne) la table et met à jour les statistiques (métadonnées) utilisées par l'Optimizer.

-- (Après un 'COPY' ou 'INSERT' massif)
ANALYZE ma_table;

Symptôme (Sans ANALYZE) : Une requête JOIN qui devrait prendre 1 seconde (ex: Nested Loop) prend 1 heure (ex: Hash Join), car l'Optimizer a choisi le mauvais plan d'exécution (basé sur des stats obsolètes).

-- --- GESTION (Cluster) ---
CREATE WAREHOUSE my_wh WITH
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 600;

ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = 'XLARGE';


-- --- INGESTION (COPY) ---
COPY users
FROM 's3://my-bucket/users_data.parquet'
IAM_ROLE 'arn:aws:iam::...'
FORMAT AS PARQUET;


-- --- MAINTENANCE (Cruciale !) ---

-- (Supprimer les lignes "mortes")
VACUUM DELETE ONLY my_table;

-- (Re-trier la table selon le SORTKEY)
VACUUM SORT ONLY my_table;

-- (Mettre à jour les stats pour l'Optimizer)
ANALYZE my_table;


-- --- OPTIMISATION (Définition) ---
CREATE TABLE sales (
  id INT,
  user_id INT,
  sale_date DATE
)
DISTSTYLE KEY -- (DISTKEY = 3.2)
DISTKEY (user_id)
SORTKEY (sale_date); -- (SORTKEY = 3.3)


-- --- REDSHIFT SPECTRUM (4.x) ---

-- (Créer le 'contexte' S3)
CREATE EXTERNAL SCHEMA s3_logs
FROM DATA CATALOG
DATABASE 'my_glue_db'
IAM_ROLE 'arn:aws:iam::...'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

-- (Lire la table S3)
SELECT COUNT(*) FROM s3_logs.my_raw_logs;

-- (JOIN Local (ventes) + S3 (logs))
SELECT *
FROM ventes AS v
JOIN s3_logs.my_raw_logs AS l
  ON v.user_id = l.user_id
WHERE v.sale_date > '2025-01-01';