Quiz 03 – Spark sur cluster : Standalone, Driver, Executors et HDFS

• Jour 1
• 20 questions
• Seuil de réussite : 70 %
• 21 flashcards

Contenus évalués : rôles du Driver, du Cluster Manager, du Worker et de l’Executor ; `spark-submit`, `--master` et `--deploy-mode` avec un code métier inchangé ; HDFS, NameNode, DataNode, blocs et réplication ; `core-site.xml` et `hdfs-site.xml` ; le `docker-compose.yml` du TP 3, ses ports et la Spark Master UI ; place du mode Standalone face à YARN, Kubernetes et Mesos ; lecture des sorties du TP 3, diagnostic des blocages fréquents et choix d’approche en mode dégradé.

Une seule bonne réponse par question. Toutes les valeurs citées sont celles des TP de la formation. Le corrigé détaillé s’affiche après la correction. Ce quiz prépare le QCM de validation des acquis du dernier jour.

QCM

Question 1

Pendant le TP 3, ton job calcule reduceByKey sur les courses. Quel composant exécute réellement les tâches sur les partitions ?

• a) Le Driver, qui lit trips.csv et fait les additions
• b) Les Executors, lancés sur les Workers
• c) Le Master Standalone, qui reçoit le job sur le port 7077
• d) Le NameNode, qui calcule là où sont stockés les blocs

Question 2

Dans la Partie A, le script start_cluster_local.sh lance un processus org.apache.spark.deploy.master.Master. Quel rôle joue ce processus ?

• a) C’est le Driver : il exécute le main de tp2_cluster.py
• b) C’est un Executor : il traite les partitions de trips.csv
• c) C’est le stockage du cluster : il conserve les données entre deux jobs
• d) C’est le Cluster Manager : il connaît les Workers et attribue leurs ressources aux applications

Question 3

Voici la création de la session dans tp2_cluster.py :

spark = SparkSession.builder.appName("TP3-cluster").getOrCreate()

Pourquoi cette ligne ne contient-elle pas d’appel à .master() ?

• a) Le master est fourni par spark-submit --master. Le même script tourne donc sans modification en local, en Partie A et en Partie B.
• b) Spark détecte tout seul le cluster le plus proche sur le réseau
• c) .master() est incompatible avec getOrCreate() depuis Spark 4
• d) Le master est lu dans core-site.xml, via la propriété fs.defaultFS

Question 4

spark-submit accepte --deploy-mode client (par défaut) ou --deploy-mode cluster. Qu’est-ce que ce paramètre change ?

• a) Le cluster sur lequel tournent les Executors : local, Standalone ou YARN
• b) Le nombre d’Executors alloués au job
• c) L’endroit où tourne le Driver : sur la machine qui lance spark-submit en mode client, sur un nœud du cluster en mode cluster
• d) La source des données : disque local en mode client, HDFS en mode cluster

Question 5

Dans la Partie B, le compose démarre un conteneur namenode et un conteneur datanode. Comment le travail se répartit-il entre les deux ?

• a) Le NameNode garde les métadonnées, c’est-à-dire l’arborescence et l’emplacement de chaque bloc. Le DataNode stocke les blocs eux-mêmes.
• b) Le DataNode garde les métadonnées et le NameNode stocke les blocs
• c) Le NameNode stocke une copie de chaque bloc, le DataNode une copie de secours
• d) Le DataNode est le Worker Spark qui exécute les tâches, le NameNode est le Master

Question 6

Tu veux passer ce cluster en production avec trois DataNodes, et donc trois copies de chaque bloc. Quel fichier modifies-tu, et quelle propriété ?

• a) core-site.xml, propriété fs.defaultFS
• b) hdfs-site.xml, propriété dfs.replication
• c) core-site.xml, propriété dfs.replication
• d) hdfs-site.xml, propriété dfs.blocksize

Question 7

trips.csv pèse environ 12 Mo. Le hdfs-site.xml du TP fixe dfs.blocksize à 134217728 (128 Mo) et dfs.replication à 1. Après le hdfs dfs -put, que montre l’UI HDFS pour ce fichier ?

• a) 1 bloc, stocké en 3 copies
• b) 3 blocs, un par service du compose
• c) 1 bloc, stocké en 1 seule copie
• d) 12 blocs de 1 Mo, en 1 seule copie

Question 8

La Partie B est lancée avec docker compose up -d. Depuis ton navigateur, tu veux vérifier l’application, le worker et le nombre de cœurs utilisés. Quelle URL ouvres-tu ?

• a) http://localhost:9870
• b) http://localhost:7077
• c) http://localhost:4040
• d) http://localhost:8080

Question 9

Partie A, bonus : tu lances un second worker sur ton portable de 4 cœurs, puis tu relances le spark-submit sur les 120 000 courses. Le job n’est pas plus rapide. Quelle est l’explication la plus probable ?

• a) Le second worker est ignoré tant que le nombre de workers n’est pas déclaré dans le code
• b) Les deux workers se partagent les mêmes cœurs physiques, et sur ce volume le coût de coordination dépasse le gain
• c) reduceByKey ne peut pas se répartir sur plus d’un worker
• d) Sans HDFS, toutes les tâches sont envoyées au premier worker

Question 10

Ton entreprise dispose déjà d’un cluster Hadoop géré par YARN. Pour y lancer tp2_cluster.py, que fais-tu ?

• a) Tu changes la valeur de --master dans spark-submit, sans toucher au code. YARN joue alors le rôle de Cluster Manager à la place du Master Standalone.
• b) Tu ajoutes obligatoirement .master("yarn") dans le code, car spark-submit ne sait parler qu’au Master Standalone
• c) Tu installes un Master Standalone sur chaque nœud YARN, car YARN ne fait que stocker les données
• d) Tu réécris le job en DataFrames, car YARN ne sait pas exécuter de RDD

Question 11

Partie A. Tu as lancé start_cluster_local.sh sans variable d’environnement particulière, puis le spark-submit. La sortie contient ces lignes :

Master : spark://127.0.0.1:7077 — données : data
...
Top 10 des zones de départ — calculé sur 2 cœurs du cluster

D’où vient ce « 2 » ?

• a) Du nombre de partitions de trips.csv : un fichier de 12 Mo est lu en 2 partitions
• b) Des cœurs physiques du portable, comme avec local[*]
• c) Du worker démarré par le script avec --cores 2, car WORKER_CORES vaut 2 par défaut
• d) Du nombre de stages du job, puisque reduceByKey provoque un shuffle

Question 12

Partie B, bonus. Tu décommentes spark-worker-2 dans docker-compose.yml, tu relances docker compose up -d puis le spark-submit. Combien de cœurs la Spark Master UI affiche-t-elle maintenant pour le cluster ?

• a) 2, car spark-worker-2 remplace spark-worker-1
• b) 2, car il faut redémarrer le Master pour qu’il accepte un nouveau worker
• c) 3, car le second worker n’a qu’un cœur, comme dans la Partie A
• d) 4, car chaque worker du compose est lancé avec --cores 2

Question 13

Dans la Partie B, tu exécutes :

docker compose exec namenode hdfs dfs -put /workspace/data/trips.csv /workspace/data/taxi_zone_lookup.csv /data

Pourquoi le chemin /workspace/data/trips.csv existe-t-il dans le conteneur namenode ?

• a) Le compose monte la racine du dépôt (../..) sur /workspace dans ce conteneur
• b) La commande hdfs dfs -mkdir -p /data a créé /workspace juste avant
• c) /workspace est un répertoire HDFS déjà rempli au démarrage du NameNode
• d) Docker copie automatiquement le dossier courant dans chaque conteneur

Question 14

Partie A. Ton notebook du TP 2 est encore ouvert. Pendant l’exécution du spark-submit, tu ouvres http://localhost:4040 et tu n’y vois que les jobs du notebook, pas ceux de « TP3-cluster ». Que se passe-t-il ?

• a) En mode Standalone, une application lancée par spark-submit n’a pas d’UI propre : tout passe par le port 8080
• b) Le port 4040 est déjà pris par la session du notebook : l’UI de « TP3-cluster » est sur le port 4041
• c) getOrCreate() a récupéré la session du notebook, donc le job tourne dans le notebook
• d) L’UI d’application n’existe qu’avec --deploy-mode cluster

Question 15

Partie A. Le spark-submit échoue aussitôt avec Connection refused sur le port 7077. Quel diagnostic retiens-tu ?

• a) HDFS n’est pas démarré : il faut lancer le conteneur namenode avant de soumettre
• b) Le code ne contient pas .master("spark://127.0.0.1:7077") : il faut l’ajouter
• c) Le Master n’est pas démarré ou écoute sur une autre IP : vérifie http://localhost:8080 et SPARK_LOCAL_IP=127.0.0.1
• d) 7077 est le port de l’UI : il faut soumettre le job sur le port 8080

Question 16

Partie A. Tu as lancé start_cluster_local.sh depuis un terminal où le venv n’était pas activé. Le job démarre, puis les Executors meurent avec Python in worker has different version. Que fais-tu ?

• a) Tu alignes SPARK_VERSION dans .env sur ton pip show pyspark
• b) Tu augmentes la mémoire du worker, limitée à 1 Go par le script
• c) Tu relances simplement spark-submit : le Driver envoie son interpréteur Python aux Executors
• d) Tu arrêtes le cluster, tu fais export PYSPARK_PYTHON=$(which python) venv activé, puis tu relances le worker

Question 17

Tu as installé PySpark 4.2.0. Depuis ton poste, tu soumets tp2_cluster.py au Master du compose, publié sur le port 7077. Tu n’as pas modifié SPARK_VERSION, dont la valeur par défaut est 4.0.0. Le job échoue avec Incompatible Spark version. Quelle correction appliques-tu ?

• a) Tu alignes SPARK_VERSION dans .env sur ton pip show pyspark, ici 4.2.0, en vérifiant le tag sur hub.docker.com, puis tu relances docker compose up -d
• b) Tu changes HADOOP_VERSION, car c’est l’image apache/hadoop qui fixe la version de Spark
• c) Tu recrées ton venv avec la version de Python de l’image Docker
• d) Tu supprimes .env : le compose prend alors automatiquement la version installée par pip

Question 18

Ton équipe veut lancer le même job sur un vrai cluster de trois machines. Un collègue propose de garder la commande de la Partie A, avec le chemin data. Quel est ton avis ?

• a) Aucun problème : le Driver lit le fichier et l’envoie aux Executors
• b) Ça marchera à condition de passer dfs.replication à 3
• c) Ça ne marchera pas : chaque worker doit voir les données. Il faut un stockage partagé, HDFS ou un stockage objet (S3, ADLS), et un chemin comme hdfs://…
• d) Il suffit de convertir les données en Parquet pour que les workers y accèdent

Question 19

Un collègue cherche sbin/start-master.sh dans le SPARK_HOME de ton venv et ne le trouve pas. Pourquoi start_cluster_local.sh passe-t-il par spark-class ?

• a) start-master.sh a été supprimé de Spark 4 et remplacé par spark-class
• b) Les scripts sbin/ ne sont pas livrés avec pip install pyspark. spark-class lance directement la classe Master, et une distribution complète (tar.gz) fournit bien sbin/start-master.sh.
• c) start-master.sh démarre un ResourceManager YARN, pas un Master Standalone
• d) spark-class démarre le Master et le Driver en une seule commande

Question 20

Le matin du TP 3, docker compose up -d échoue chez plusieurs participants : le proxy bloque l’accès à hub.docker.com. Quelle approche retiens-tu pour garder l’objectif du TP ?

• a) Supprimer le TP 3 : sans HDFS, il n’y a pas de cluster Spark
• b) Lancer spark-submit --master local[*] avec le chemin hdfs://namenode:8020/data
• c) Remplacer le chemin des données par hdfs://localhost:9870/data
• d) Faire uniquement la Partie A : un cluster Standalone avec le PySpark déjà installé, et les données lues en local avec tp2_cluster.py data

Corriger Recommencer

Flashcards

Cliquez sur une carte pour la retourner. Mélangez-les pour une révision active.

Question Qui exécute réellement les tâches sur les partitions dans un job Spark ?

◀ Précédente Retourner Suivante ▶ Mélanger 1 / 21