Hadoop Explorer - Écosystème Big Data

Quiz Hadoop Débutant 2 min

Qu'est-ce qu'Hadoop ? — Fondamentaux

Testez votre compréhension des concepts de base de l'architecture Hadoop.

Question : Quel est le rôle principal d'Hadoop dans le traitement des données massives ? Sélectionnez la réponse la plus complète et précise.

A Stocker des données structurées dans des tables relationnelles à grande échelle

B Stocker et traiter des volumes massifs de données de manière distribuée sur un cluster de machines ordinaires

C Remplacer les bases de données SQL pour les applications web haute performance

D Accélérer les calculs scientifiques grâce au GPU computing distribué

Direct Hadoop Débutant 3 min

Les 3 piliers d'Hadoop — Définissez chaque composant

Nommez et décrivez brièvement les 3 composants essentiels de l'écosystème Hadoop de base.

Exercice : Complétez le tableau suivant en associant chaque composant Hadoop à son rôle principal. Rédigez une courte définition pour : HDFS, YARN, MapReduce.

Composant	Acronyme signifie…	Rôle principal
HDFS	Votre réponse…	Votre réponse…
YARN	Votre réponse…	Votre réponse…
MapReduce	—	Votre réponse…

Solution complète

Composant	Acronyme	Rôle
HDFS	Hadoop Distributed File System	Système de fichiers distribué : divise les fichiers en blocs (128 MB par défaut), les réplique (×3) et les distribue sur les DataNodes du cluster.
YARN	Yet Another Resource Negotiator	Gestionnaire de ressources et d'orchestration : alloue CPU/RAM aux applications, planifie et surveille les tâches sur le cluster.
MapReduce	—	Modèle de programmation pour le traitement parallèle : phase Map (transformation), Shuffle (tri/groupement), Reduce (agrégation).

💡 Moyen mnémotechnique : Pensez à Hadoop comme un entrepôt géant : HDFS est le bâtiment (stockage), YARN est le contremaître (gestion des ressources), MapReduce est la chaîne de production (traitement). Hadoop 2.x a découplé YARN de MapReduce, permettant d'exécuter d'autres moteurs (Spark, Tez) sur le même cluster.

Réflexion Hadoop Intermédiaire 8 min

Hadoop vs RDBMS — Quand utiliser lequel ?

Analyse comparative et cas d'usage réels.

Scénario : Une entreprise de e-commerce gère deux systèmes :

Un catalogue produits (1M d'articles, consultations en temps réel, mises à jour fréquentes)
Des logs de clickstream (10 TB/mois, analyse comportementale, reporting mensuel)

Question : Pour chaque cas, justifiez le choix entre un SGBD relationnel et Hadoop. Identifiez 3 critères décisifs qui orientent ce choix.

Analyse de référence

Cas 1 — Catalogue produits → SGBD Relationnel (ex: PostgreSQL)

Transactions ACID requises (cohérence des stocks, prix)
Latence faible (<10ms) pour les consultations utilisateurs
Volume gérable (1M lignes = quelques GB)
Schema strict bénéfique (contraintes d'intégrité)

Cas 2 — Logs clickstream → Hadoop (HDFS + Hive/Spark)

Volume massif (10 TB/mois → 120 TB/an) impraticable en SGBD
Traitement batch acceptable (analyse mensuelle)
Données semi-structurées (JSON logs, pas de schema fixe)
Coût de stockage : HDFS sur commodity hardware vs SAN/SSD

🎯 3 Critères décisifs :

1. Volume
< quelques TB → SGBD
> 1 TB en croissance → Hadoop

2. Latence
Temps réel → SGBD
Batch/analytique → Hadoop

3. Structure
Schema fixe → SGBD
Schema flexible → Hadoop

Calcul HDFS Débutant 5 min

Calcul de blocs et réplication HDFS

Calculez l'espace disque occupé par un fichier dans HDFS.

Problème : Un fichier de 850 MB est stocké dans HDFS avec :

Taille de bloc : 128 MB
Facteur de réplication : 3
Cluster de 5 DataNodes

Combien de blocs ce fichier génère-t-il ?
Quelle est la taille du dernier bloc ?
Combien de copies physiques de blocs existent au total ?
Quel est l'espace disque total occupé sur le cluster ?

Solution détaillée

          1. Nombre de blocs :

            ⌈ 850 MB ÷ 128 MB ⌉ = ⌈ 6.64 ⌉ = 7 blocs

          2. Taille du dernier bloc (bloc 7) :

            850 - (6 × 128) = 850 - 768 = 82 MB

            ⚠️ HDFS n'alloue que l'espace réellement utilisé (≠ 128 MB)

          3. Copies physiques totales :

            7 blocs × 3 répliques = 21 copies de blocs

          4. Espace disque total :

            850 MB × 3 (réplication) = 2 550 MB ≈ 2.49 GB

            Distribué sur 5 DataNodes → ~510 MB par nœud en moyenne

💡 Note importante : Le dernier bloc (82 MB) n'occupe que 82 MB sur disque, pas 128 MB. HDFS stocke la taille réelle du fichier dans le NameNode (métadonnées). Avec la réplication ×3, si un DataNode tombe en panne, les données restent accessibles via les 2 autres copies.

Quiz HDFS Intermédiaire 3 min

NameNode et Secondary NameNode — Rôles et différences

Comprenez le mécanisme de gestion des métadonnées dans HDFS.

Question : Concernant le Secondary NameNode dans Hadoop, quelle affirmation est correcte ?

A Il prend automatiquement la place du NameNode en cas de panne (haute disponibilité)

B Il stocke une copie miroir de tous les blocs HDFS pour la redondance

C Il fusionne périodiquement le FsImage et l'EditLog pour réduire le temps de démarrage du NameNode

D Il gère les requêtes de lecture des clients pour décharger le NameNode primaire

Coding HDFS Avancé 15 min

Lire un fichier HDFS avec l'API Java

Écrivez un programme Java qui lit un fichier depuis HDFS ligne par ligne.

Exercice : Complétez le squelette de code Java suivant pour créer un programme qui :

Se connecte à un cluster HDFS (hdfs://namenode:9000)
Lit le fichier /user/data/ventes.csv
Affiche chaque ligne avec son numéro
Gère proprement les ressources (try-with-resources)

// Complétez les parties marquées TODO
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import java.io.*;
import java.net.URI;

public class HDFSReader {
  public static void main(String[] args) throws Exception {
    
    // TODO 1: Créez la Configuration Hadoop
    Configuration conf = ??? ;
    
    // TODO 2: Obtenez le FileSystem HDFS
    FileSystem fs = ??? ;
    
    Path filePath = new Path("/user/data/ventes.csv");
    
    // TODO 3: Ouvrez le fichier avec try-with-resources
    ??? (BufferedReader reader = ???) {
      String line;
      int lineNum = 1;
      
      // TODO 4: Lisez et affichez chaque ligne
      while (??? != null) {
        System.out.printf("Ligne %d: %s%n", lineNum++, line);
      }
    }
    
    // TODO 5: Fermez le FileSystem
    ???;
  }
}
      

Solution complète

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import java.io.*;
import java.net.URI;

public class HDFSReader {
  public static void main(String[] args) throws Exception {
    
    // 1. Configuration Hadoop
    Configuration conf = new Configuration();
    conf.set("fs.defaultFS", "hdfs://namenode:9000");
    
    // 2. Obtenir le FileSystem HDFS
    FileSystem fs = FileSystem.get(conf);
    // Ou avec URI: FileSystem.get(URI.create("hdfs://namenode:9000"), conf);
    
    Path filePath = new Path("/user/data/ventes.csv");
    
    // 3. try-with-resources → fermeture automatique
    try (BufferedReader reader = new BufferedReader(
           new InputStreamReader(fs.open(filePath)))) {
      String line;
      int lineNum = 1;
      
      // 4. Lecture ligne par ligne
      while ((line = reader.readLine()) != null) {
        System.out.printf("Ligne %d: %s%n", lineNum++, line);
      }
    }
    
    // 5. Fermeture du FileSystem
    fs.close();
  }
}
        

Points clés :

Configuration charge les fichiers core-site.xml et hdfs-site.xml automatiquement si dans le classpath
fs.open() retourne un FSDataInputStream, wrappé dans InputStreamReader pour la lecture texte
Le try-with-resources garantit la fermeture du stream même en cas d'exception
Dépendance Maven : hadoop-client (version correspondant au cluster)

Calcul HDFS Expert 20 min

Dimensionnement RAM du NameNode

Calculez la mémoire nécessaire pour le NameNode d'un cluster de production.

Contexte : Un cluster HDFS de production héberge :

500 millions de fichiers (petits et grands)
2 milliards de blocs
Facteur de réplication moyen : 3

Questions :

Sachant que chaque objet HDFS (fichier ou bloc) consomme ~150 bytes de RAM dans le NameNode, calculez la RAM minimale requise.
Quelle RAM totale recommandez-vous en production (avec marge de 50%) ?
Expliquez pourquoi le NameNode est dit "Single Point of Failure" et comment Hadoop 2.x résout ce problème.

Solution

          1. RAM minimale :

            Objets = 500M fichiers + 2B blocs = 2 500 000 000 objets

            RAM = 2.5 × 10⁹ × 150 bytes = 375 × 10⁹ bytes

            = 375 GB ≈ 366 GiB

          2. RAM recommandée (marge +50%) :

            375 GB × 1.5 = 562 GB → recommander 512 GiB ou 640 GB

            (arrondir au serveur disponible supérieur)

3. NameNode SPOF et solution HA :
Le NameNode stocke en mémoire la totalité de l'arborescence HDFS. Si le NameNode plante, le cluster HDFS devient totalement inaccessible (ni lecture ni écriture possible). C'est un SPOF classique.

Solution Hadoop 2.x — NameNode HA :

Active/Standby NameNode : 2 NameNodes synchronisés via des JournalNodes (quorum de 3+)
Le Standby rejoue les EditLogs des JournalNodes en temps réel
Zookeeper + ZKFC (ZooKeeper Failover Controller) détecte les pannes et déclenche le basculement automatique
Basculement en ~30–60 secondes (configurable)

Quiz YARN Débutant 2 min

ResourceManager vs NodeManager — Qui fait quoi ?

Identifiez les responsabilités de chaque démon YARN.

Question : Lequel de ces rôles est assuré par le ResourceManager (et non le NodeManager) dans YARN ?

A Exécuter les containers de tâches sur un nœud Worker

B Surveiller la santé locale d'un nœud (CPU, RAM, disque)

C Décider de l'allocation globale des ressources entre toutes les applications en cours

D Gérer les logs de chaque tâche Map et Reduce individuelle

Calcul YARN Intermédiaire 10 min

Dimensionnement containers YARN et parallélisme

Calculez le nombre de containers et le parallélisme maximal d'un cluster.

Cluster : 10 nœuds Worker, chacun avec :

RAM totale : 64 GB dont 12 GB réservés pour l'OS et les démons Hadoop
vCPUs : 16 vCPUs dont 2 réservés pour les démons
Container YARN minimum : 1 vCPU, 2 GB RAM

Quelle est la RAM disponible pour YARN par nœud ?
Combien de containers de 1 vCPU / 2 GB peut-on lancer par nœud ? (contrainte CPU et RAM)
Combien de containers en parallèle sur tout le cluster ?
Si un job MapReduce soumet 200 tâches Map, combien de rounds seront nécessaires ?

Solution

          1. RAM disponible YARN par nœud :

            64 GB - 12 GB = 52 GB

          2. Containers par nœud :

            Contrainte CPU : (16 - 2) vCPUs / 1 vCPU = 14 containers

            Contrainte RAM : 52 GB / 2 GB = 26 containers

            → Min(14, 26) = 14 containers/nœud (CPU est le goulot)

          3. Parallélisme total cluster :

            14 containers × 10 nœuds = 140 containers simultanés

          4. Rounds pour 200 tâches Map :

            ⌈ 200 / 140 ⌉ = ⌈ 1.43 ⌉ = 2 rounds

            (Round 1: 140 tâches, Round 2: 60 tâches)

💡 Optimisation : En pratique, il faut aussi prévoir des containers pour l'ApplicationMaster (1 par application). Les schedulers YARN (Capacity/Fair) permettent de partager équitablement le cluster entre plusieurs jobs concurrents.

Réflexion YARN Avancé 12 min

FairScheduler vs CapacityScheduler — Choisir le bon scheduler

Analysez les deux schedulers YARN pour un contexte multi-tenant.

Scénario : Une université utilise un cluster Hadoop partagé entre :

Le département Recherche : jobs longs (>1h), batchs nocturnes, faible priorité en journée
Le département Pédagogie : jobs courts des étudiants (<10 min), haute fréquence, importance en journée
L'administration : jobs critiques rares mais urgents

Question : Quel scheduler YARN choisiriez-vous et pourquoi ? Proposez une configuration de queues adaptée.

Recommandation

→ CapacityScheduler recommandé pour ce cas multi-département avec allocations garanties.

CapacityScheduler
✅ Queues dédiées par département
✅ Capacité garantie (ex: 30% Recherche)
✅ Elasticité : peut utiliser les ressources libres
✅ Priorités par queue
✅ ACL d'accès par queue

FairScheduler
→ Partage équitable dynamique
→ Préferable si tous les users sont équivalents
→ Moins adapté aux SLA distincts
→ Pools de ressources moins rigides

Configuration de queues proposée (capacity-scheduler.xml) :

<!-- Queue Pédagogie : 50% du cluster -->
yarn.scheduler.capacity.root.pedagogie.capacity=50
yarn.scheduler.capacity.root.pedagogie.maximum-capacity=70
yarn.scheduler.capacity.root.pedagogie.priority=10
yarn.scheduler.capacity.root.pedagogie.maximum-am-resource-percent=0.1

<!-- Queue Recherche : 35% du cluster -->
yarn.scheduler.capacity.root.recherche.capacity=35
yarn.scheduler.capacity.root.recherche.maximum-capacity=90
yarn.scheduler.capacity.root.recherche.priority=5

<!-- Queue Administration : 15% garanti, priorité max -->
yarn.scheduler.capacity.root.administration.capacity=15
yarn.scheduler.capacity.root.administration.maximum-capacity=100
yarn.scheduler.capacity.root.administration.priority=100
        

Direct MapReduce Débutant 5 min

WordCount à la main — Simulez MapReduce pas à pas

Tracez manuellement les phases Map, Shuffle et Reduce sur un petit texte.

Texte d'entrée (distribué sur 2 splits) :

Split 1: "hadoop est grand hadoop est puissant"
Split 2: "hadoop traite les données et est rapide"
        

Questions :

Listez toutes les paires (clé, valeur) émises par la phase Map
Montrez le résultat du Shuffle & Sort (regroupement par clé)
Calculez la sortie finale de la phase Reduce

Trace complète

🗺️ MAP OUTPUT
Mapper 1 :
(hadoop, 1), (est, 1), (grand, 1),
(hadoop, 1), (est, 1), (puissant, 1)

Mapper 2 :
(hadoop, 1), (traite, 1), (les, 1),
(données, 1), (et, 1), (est, 1), (rapide, 1)

🔀 SHUFFLE & SORT
(données, [1])
(est, [1, 1, 1])
(et, [1])
(grand, [1])
(hadoop, [1, 1, 1])
(les, [1])
(puissant, [1])
(rapide, [1])
(traite, [1])

📊 REDUCE OUTPUT
(données, 1)
(est, 3)
(et, 1)
(grand, 1)
(hadoop, 3)
(les, 1)
(puissant, 1)
(rapide, 1)
(traite, 1)

💡 Point clé : Le Shuffle est la phase la plus coûteuse de MapReduce car elle implique des transferts réseau entre les nœuds. L'optimisation via les Combiners (mini-Reduce local) permet de réduire les données transférées : ici, chaque Mapper émettrait (hadoop, 2), (est, 2) au lieu de deux (hadoop, 1) séparés.

Coding MapReduce Intermédiaire 20 min

Job MapReduce Java — Calcul de moyenne par catégorie

Implémentez un job MapReduce calculant la note moyenne par matière.

Données d'entrée (notes.csv) :

etudiant,matiere,note
Alice,Math,16
Bob,Math,12
Alice,Info,18
Charlie,Math,14
Bob,Info,15
Charlie,Info,17
        

Sortie attendue : La moyenne par matière
Info → 16.67 | Math → 14.00

Tâche : Implémentez les classes MoyenneMapper et MoyenneReducer en Java.

Solution complète

import org.apache.hadoop.io.*;
import org.apache.hadoop.mapreduce.*;
import java.io.IOException;

// ===== MAPPER =====
public class MoyenneMapper 
    extends Mapper<LongWritable, Text, Text, DoubleWritable> {

  private boolean firstLine = true;

  @Override
  protected void map(LongWritable key, Text value, Context context)
      throws IOException, InterruptedException {
    
    String line = value.toString().trim();
    // Ignorer l'en-tête
    if (firstLine && line.startsWith("etudiant")) {
      firstLine = false;
      return;
    }
    firstLine = false;
    
    String[] parts = line.split(",");
    if (parts.length == 3) {
      String matiere = parts[1].trim();
      double note = Double.parseDouble(parts[2].trim());
      // Émettre : clé=matière, valeur=note
      context.write(new Text(matiere), new DoubleWritable(note));
    }
  }
}

// ===== REDUCER =====
public class MoyenneReducer
    extends Reducer<Text, DoubleWritable, Text, DoubleWritable> {

  @Override
  protected void reduce(Text key, Iterable<DoubleWritable> values, Context context)
      throws IOException, InterruptedException {
    
    double sum = 0;
    int count = 0;
    
    for (DoubleWritable val : values) {
      sum += val.get();
      count++;
    }
    
    double moyenne = (count > 0) ? sum / count : 0;
    context.write(key, new DoubleWritable(Math.round(moyenne * 100.0) / 100.0));
  }
}
        

Points importants :

Le Mapper reçoit (offset, ligne_texte) → émet (matière, note)
Le Reducer reçoit (matière, [note1, note2, ...]) → calcule et émet la moyenne
Utiliser DoubleWritable (et non double) car Hadoop requiert des types sérialisables (Writable)
Le skip d'en-tête en vérifiant startsWith("etudiant") est une approche simple ; en production, utilisez MultipleInputs ou un TextInputFormat personnalisé

Calcul MapReduce Avancé 15 min

Estimation du temps d'exécution d'un job MapReduce

Calculez le temps théorique d'un job et identifiez les goulots d'étranglement.

Job : Traitement d'un fichier de 5 TB sur un cluster de 20 nœuds Worker.

Débit disque HDFS : 200 MB/s par nœud en lecture
Chaque tâche Map traite un bloc de 128 MB
Capacité du cluster : 100 tâches Map simultanées
Overhead par tâche (démarrage JVM, init) : 5 secondes
Ratio données Shuffle : 30% des données en entrée
Débit réseau inter-nœuds : 1 Gb/s par nœud

Combien de tâches Map sont nécessaires ?
Combien de rounds de Map (waves) ?
Quel est le temps estimé pour la phase Map (lecture + traitement) ?
Quel est le volume de données shufflé ? Le temps de Shuffle ?

Solution

          1. Nombre de tâches Map :

            5 TB = 5 × 1024 × 1024 MB = 5 242 880 MB

            Tâches = ⌈ 5 242 880 / 128 ⌉ = 40 960 tâches Map

          2. Rounds (waves) :

            ⌈ 40 960 / 100 ⌉ = 410 waves

          3. Temps phase Map :

            Temps lecture/bloc = 128 MB / 200 MB/s = 0.64 s

            Temps/tâche = 0.64 s + 5 s overhead = 5.64 s

            Temps total Map ≈ 410 waves × 5.64 s = ≈ 38 min 30 s

          4. Shuffle :

            Volume = 5 TB × 30% = 1.5 TB

            Débit réseau total = 20 nœuds × 1 Gb/s = 20 Gb/s = 2.5 GB/s

            Temps Shuffle ≈ 1 536 GB / 2.5 GB/s = ≈ 10 min 14 s

⚠️ Limites du modèle : Cette estimation est optimiste. En réalité : (1) le Shuffle est entrelacé avec la fin du Map, (2) les tâches Speculative Execution peuvent ajouter des overhead, (3) la contention réseau et disque dégrade les performances. Multiplier par 1.5–2x pour une estimation conservative de production.

Quiz MapReduce Expert 5 min

Optimisation avancée — Combiner, Partitioner et Speculative Execution

Identifiez la technique d'optimisation adaptée à chaque problème.

Question : Un job MapReduce présente un problème de data skew : 80% des données se retrouvent dans un seul Reducer car toutes les clés commencent par "A". Quelle est la meilleure approche pour résoudre ce problème ?

A Activer la Speculative Execution pour lancer des copies du Reducer lent en parallèle

B Utiliser un Combiner pour pré-agréger les données avant le Shuffle

C Implémenter un Partitioner personnalisé qui distribue les clés uniformément entre les Reducers

D Augmenter la taille des blocs HDFS pour réduire le nombre de tâches Map

Coding MapReduce Expert 30 min

Jointure MapReduce (Reduce-Side Join) — Sans framework SQL

Implémentez une jointure entre deux datasets avec MapReduce pur.

Datasets :

clients.csv:   id_client, nom, ville
commandes.csv: id_cmd, id_client, montant
        

Objectif : Produire : nom_client → total_commandes_montant

Implémentez :

Un JoinMapper qui lit les deux fichiers (via MultipleInputs) et tague chaque enregistrement
Un JoinReducer qui réalise la jointure en mémoire

Solution — Reduce-Side Join

// === Mapper Clients ===
public class ClientMapper extends Mapper<LongWritable,Text,Text,Text> {
  protected void map(LongWritable k, Text v, Context ctx) throws Exception {
    String[] p = v.toString().split(",");
    if (p.length == 3) {
      // clé = id_client, valeur = "C|nom"
      ctx.write(new Text(p[0].trim()), new Text("C|" + p[1].trim()));
    }
  }
}

// === Mapper Commandes ===
public class CommandeMapper extends Mapper<LongWritable,Text,Text,Text> {
  protected void map(LongWritable k, Text v, Context ctx) throws Exception {
    String[] p = v.toString().split(",");
    if (p.length == 3) {
      // clé = id_client, valeur = "O|montant"
      ctx.write(new Text(p[1].trim()), new Text("O|" + p[2].trim()));
    }
  }
}

// === Reducer (jointure) ===
public class JoinReducer extends Reducer<Text,Text,Text,DoubleWritable> {
  protected void reduce(Text key, Iterable<Text> values, Context ctx) throws Exception {
    String clientName = null;
    double totalMontant = 0;
    
    for (Text val : values) {
      String s = val.toString();
      if (s.startsWith("C|")) {
        clientName = s.substring(2);
      } else if (s.startsWith("O|")) {
        totalMontant += Double.parseDouble(s.substring(2));
      }
    }
    
    if (clientName != null) {
      ctx.write(new Text(clientName), new DoubleWritable(totalMontant));
    }
  }
}

// === Driver (main) ===
MultipleInputs.addInputPath(job, clientsPath, TextInputFormat.class, ClientMapper.class);
MultipleInputs.addInputPath(job, commandesPath, TextInputFormat.class, CommandeMapper.class);
        

⚠️ Limitation : Cette approche bufferise les données "C|" côté Reducer. Si un client a des millions de commandes, l'iterator peut saturer la RAM. Pour les très grands volumes, préférer un Map-Side Join (si un dataset est petit — DistributedCache) ou un framework SQL (Hive, Spark SQL) qui optimise automatiquement le type de jointure.

Réflexion Hadoop HDFS YARN MR Expert 25 min

Architecture d'un pipeline Big Data de bout en bout

Concevez l'architecture complète d'un système d'analyse de logs web.

Contexte : Un site web reçoit 10 millions de visiteurs/jour, générant 50 GB de logs journaliers. L'équipe data doit produire chaque matin un rapport avec :

Top 100 pages les plus visitées
Temps de réponse moyen par endpoint
Taux d'erreurs HTTP (4xx, 5xx) par heure
Analyse des bots vs utilisateurs réels

Concevez le pipeline complet : ingestion → stockage HDFS → traitement → visualisation. Justifiez chaque choix technologique (Flume/Kafka, format de fichier, partitionnement HDFS, choix MapReduce vs Spark).

Architecture de référence

1. 🔄 Ingestion
Apache Flume (agents sur chaque serveur web)
→ Channel mémoire → Kafka topic "web-logs"
→ Flume Sink → HDFS
Pourquoi Kafka ? Buffer de découplage, rejeu possible

2. 🗄️ Stockage HDFS
Format : ORC ou Parquet (compression + columnar)
Partitionnement : /logs/year=2024/month=01/day=15/hour=09/
Réplication : ×3 (standard)
Taille bloc : 256 MB (gros fichiers)

3. ⚙️ Traitement
Apache Spark (vs MapReduce)
→ 10-100× plus rapide (in-memory)
→ API DataFrames (SQL-like)
Schedule : Airflow à 2h du matin
Output : tables Hive agrégées

4. 📊 Visualisation
Apache Superset ou Grafana
Connexion via Hive/Presto/Trino
Dashboard auto-refresh à 6h
Alertes email si erreurs > 5%

💡 Pourquoi Spark plutôt que MapReduce ?
50 GB/jour → 350 GB/semaine. Avec MapReduce, chaque job écrit sur disque entre chaque phase (Map → Shuffle → Reduce → disque). Spark garde les données en mémoire entre les opérations. Pour des analyses complexes (4 métriques = plusieurs passes), Spark est 5–10× plus rapide ici.

MapReduce resterait pertinent si : données > RAM disponible, opérations simples 1-passe, contraintes de licence ou équipe déjà formée.

Exercices & Pratique

Maîtrisez Hadoop par la pratique

Hadoop Core

HDFS — Hadoop Distributed File System

YARN — Yet Another Resource Negotiator

MapReduce — Traitement Distribué

Exercices Intégrateurs — Architecture Complète

Aucun exercice trouvé