Partie 3 – Hadoop, HDFS et Spark sur un cluster

• 13h00 – 15h00
• Apports et démonstration du cluster : 50 min
• TP 3 : 50 min (13h50 – 14h40)
• Partage : 20 min

Et si vos données ne tenaient plus sur un seul disque ? Où les stocker, et comment calculer dessus ?

HDFS : stocker un gros fichier sur plusieurs machines

HDFS (Hadoop Distributed File System) découpe chaque fichier en blocs (128 Mo par défaut) et réplique chaque bloc sur plusieurs machines (3 copies par défaut en production).

trips.csv (384 Mo, exemple)  →  Bloc 1 │ Bloc 2 │ Bloc 3   (128 Mo chacun)

NameNode – le sommaire            DataNode 1   DataNode 2   DataNode 3
  Bloc 1 → DN1, DN3               Bloc 1       Bloc 2       Bloc 3
  Bloc 2 → DN1, DN2               Bloc 2       Bloc 3       Bloc 1
  Bloc 3 → DN2, DN3
                                   ◀── heartbeat régulier de chaque DataNode ──

Composant	Rôle	Point d’attention
NameNode	Connaît l’arborescence et la position de chaque bloc. Ne stocke pas les données.	Point critique : en production, on le double (haute disponibilité).
DataNodes	Stockent les blocs, envoient un heartbeat régulier au NameNode.	Si l’un tombe, les copies des autres prennent le relais et HDFS re-réplique.
Blocs répliqués	Une machine tombe, rien n’est perdu.	Réplication 3 en production, 1 dans notre TP (un seul nœud).

Le lien avec la partie 2 : Spark lit les blocs en parallèle, 1 bloc ≈ 1 partition, et lance la tâche sur la machine qui détient le bloc (data locality) : le calcul va aux données.

🔍 Vulgarisation : Le NameNode et les DataNodes (l'analogie de la grande bibliothèque)

Imaginez une immense bibliothèque qui doit conserver une encyclopédie géante de 384 Mo (trips.csv) :

• Le découpage en blocs : au lieu d’un livre trop lourd pour une seule étagère, on le découpe en 3 tomes de 128 Mo (Bloc 1, Bloc 2, Bloc 3).
• La réplication (×3) : par sécurité contre l’incendie, chaque tome est imprimé en 3 exemplaires et rangé dans 3 salles différentes (DataNode 1, DataNode 2, DataNode 3).
• Le NameNode (le bibliothécaire à l’accueil) : il n’a aucun livre derrière son comptoir. Il possède uniquement un grand cahier en mémoire vive où est écrit :
  • « Tome 1 → Salles 1 et 3 »
  • « Tome 2 → Salles 1 et 2 »
  • « Tome 3 → Salles 2 et 3 »
• Le Heartbeat (signe de vie) : toutes les 3 secondes, le gardien de chaque salle appelle l’accueil : « Ici Salle 2, tout va bien ! ». Si la Salle 2 ne donne plus signe de vie pendant 10 minutes, le bibliothécaire la barre de son cahier et demande aux Salles 1 et 3 de refaire immédiatement une copie des tomes qui étaient dans la Salle 2.

🧮 Calcul concret : Pourquoi HDFS fait-il des blocs de 128 Mo (et pas de 4 Ko comme sur votre disque dur) ?

Sur votre ordinateur (NTFS ou ext4), un bloc disque fait 4 Ko. Pourquoi HDFS choisit-il 128 Mo (32 768 fois plus gros) ? Pour deux raisons mathématiques :

1. Éviter d’exploser la RAM du NameNode :
   • Le NameNode garde l’emplacement de chaque bloc en mémoire vive (RAM) (environ 150 octets de métadonnées par bloc).
   • Pour stocker 100 To de données avec des blocs de 128 Mo ($\approx 800,000$ blocs), le NameNode n’utilise que 120 Mo de RAM !
   • Avec des blocs de 4 Ko (25 milliards de blocs), il faudrait plus de 3 700 Go de RAM rien que pour tenir le sommaire !
2. Rentabiliser le déplacement de la tête de lecture (seek time) :
   • Trouver le début d’un bloc prend ~10 millisecondes ; lire 128 Mo d’un trait prend ~1 seconde à 128 Mo/s. Le temps de recherche devient négligeable (< 1 %).

Deux fichiers de configuration à connaître

Fichier	Question à laquelle il répond	Propriété clé
core-site.xml	Où est le système de fichiers par défaut ?	fs.defaultFS = hdfs://namenode:8020
hdfs-site.xml	Comment stocker ?	dfs.replication (nombre de copies), dfs.blocksize, dfs.namenode.name.dir

core-site.xml

<property><name>fs.defaultFS</name><value>hdfs://namenode:8020</value></property>

<!-- hdfs-site.xml -->
<property><name>dfs.replication</name><value>3</value></property>   <!-- 1 en TP -->

Spark trouve ces fichiers via la variable HADOOP_CONF_DIR. Lecture depuis Spark : spark.read.csv("hdfs://namenode:8020/data/trips.csv").

8020 ou 9000 ?

Le port RPC du NameNode est 8020 dans la configuration par défaut de Hadoop 3 et dans l’image apache/hadoop utilisée au TP 3. Beaucoup de tutoriels anciens montrent 9000, l’ancien port par défaut de Hadoop 1 et 2 : il ne fonctionne que si fs.defaultFS le déclare explicitement. Règle : le port de vos chemins hdfs:// est toujours celui de fs.defaultFS, et au TP 3 c’est 8020. L’interface web du NameNode est sur le port 9870.

Spark sur un cluster : le mode Standalone

            ┌───────────────────┐
            │ Driver            │  exécute votre programme, construit le DAG, planifie les tâches
            │ SparkContext      │
            └───┬───────────┬───┘
   demande      │           │ envoie les tâches directement aux Executors
   des ressources           │
            ┌───▼───────────┼──────────────────────────────┐
            │ Cluster Manager (Master, port 7077)         │  attribue CPU et mémoire
            └───┬───────────┼──────────────────────────────┘
        ┌───────▼─────┐ ┌───▼─────────┐
        │ Worker 1    │ │ Worker 2    │  machines qui hébergent les Executors
        │  Executor   │ │  Executor   │  processus qui exécutent les tâches et gardent le cache
        └─────────────┘ └─────────────┘

Rôle	Fait quoi
Driver	Exécute votre programme et planifie les tâches
Cluster Manager	Attribue les ressources (CPU, mémoire)
Worker	Machine qui héberge un ou plusieurs Executors
Executor	Processus JVM qui exécute les tâches et garde les données en cache

Le Driver demande des ressources au Cluster Manager, qui lance des Executors sur les Workers ; ensuite le Driver envoie directement les tâches aux Executors.

🔍 Cycle de vie complet : Que se passe-t-il seconde par seconde quand vous lancez spark-submit ?

Voici les 6 étapes exactes qui s’enchaînent lorsque vous appuyez sur Entrée après spark-submit :

1. Démarrage du Driver : votre programme Python/Scala démarre et crée la SparkSession.
2. Négociation avec le Cluster Manager (Master : port 7077) : le Driver dit au Master : « J’ai besoin d’Executors avec tant de cœurs et de RAM ».
3. Création des Executors sur les Workers : le Master ordonne aux machines Workers de démarrer des processus JVM Executors. Les Executors s’enregistrent directement auprès du Driver.
4. Construction du DAG et interrogation du NameNode (port 8020) : dès que votre code atteint une action (count(), takeOrdered()), le Driver demande au NameNode HDFS : « En combien de blocs est découpé trips.csv et sur quelles machines sont-ils ? ».
5. Envoi des tâches (Data Locality) : le Driver découpe le job en stages puis en tâches (1 tâche par bloc/partition) et les envoie directement aux Executors situés sur les mêmes machines que les blocs HDFS.
6. Retour du résultat et libération : chaque Executor calcule sa partition en mémoire et renvoie uniquement le petit résultat final (ex. le top 10) au Driver.

Avec une distribution Spark complète : sbin/start-master.sh puis sbin/start-worker.sh spark://<hôte>:7077 (start-slave.sh n’existe plus depuis Spark 3). Avec pip install pyspark, le dossier sbin/ n’est pas livré : le script du TP 3 lance les mêmes classes avec spark-class.

Choisir son gestionnaire de cluster

Gestionnaire	Pour quel contexte ?	Dans Spark 4
Standalone	Démarrer simplement, cluster dédié à Spark	Inclus, idéal pour apprendre (nos TP)
YARN	Cluster Hadoop existant, sur site	Très répandu en entreprise
Kubernetes	Cloud, conteneurs, ressources partagées	Choix courant des nouveaux projets
Mesos (+ Marathon)	Cluster privé multi-frameworks	Supprimé en 4.0 : à connaître pour migrer un existant

# Le même script (jour1/TP3_cluster/tp2_cluster.py dans le dépôt), seul --master change :
spark-submit --master spark://127.0.0.1:7077       jour1/TP3_cluster/tp2_cluster.py data   # Standalone (TP 3)
spark-submit --master yarn                         jour1/TP3_cluster/tp2_cluster.py data   # YARN
spark-submit --master k8s://https://<api>:6443     jour1/TP3_cluster/tp2_cluster.py data   # Kubernetes

Message clé : le code métier ne change pas, seul --master change. C’est pour cela que tp2_cluster.py ne contient pas de .master() : le master vient de la ligne de commande.

À vous de jouer

→ TP 3 – Le fil rouge sur un cluster + HDFS (50 min)

Partage et remédiation

• Que se passe-t-il si un worker s’arrête pendant le job ? Le Driver détecte la perte, les tâches en cours sont relancées sur un autre Executor, les partitions perdues sont recalculées grâce à la lignée.
• Pourquoi un fichier découpé en blocs se lit-il plus vite ? Chaque bloc est lu par une tâche différente, en parallèle, sur la machine qui le détient.
• Pourquoi deux workers sur un portable ne vont-ils pas plus vite ? Ils se partagent les mêmes cœurs physiques et le coût de coordination dépasse le gain. Un cluster ne paie qu’avec de vraies machines et de vrais volumes.
• À retenir : le Driver planifie, les Executors exécutent, HDFS stocke.

Transition : « Les données et le calcul sont distribués. Et si vous pouviez écrire du SQL sur des téraoctets ? » → Partie 4 – Structured API et Spark SQL