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.

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.

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