Quiz 04 – Spark SQL et DataFrames : schéma, requêtes et partitionnement

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

Contenus évalués : Parquet contre CSV (format colonne, compression, schéma embarqué) ; vues temporaires avec `createOrReplaceTempView` et requêtes `spark.sql` ; SQLContext et HiveContext comme héritage ; schéma explicite avec `StructType` et types Parquet ; schéma explicite contre `inferSchema` ; DataFrame contre RDD et optimisation Catalyst ; SQL contre API DataFrame ; évaluation paresseuse d'une chaîne `join`, `groupBy`, `agg`, `orderBy` ; règles du `GROUP BY` ; lecture et interprétation des sorties `printSchema`, `show` et du chiffre d'affaires par heure ; écriture `partitionBy` et mode d'écriture ; mode ANSI, `try_divide` et moyenne avec valeurs nulles ; lecture de `explain()`, projection poussée vers Parquet et broadcast join.

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

Dans le TP 4, tu lis data/trips.parquet plutôt que data/trips.csv. Pourquoi Parquet est-il plus rapide à lire que CSV ?

• a) Parquet stocke les données ligne par ligne, ce qui permet de lire chaque course d'un seul bloc.
• b) Parquet est un format colonne, compressé, qui embarque son schéma : pas d'inférence de types à la lecture.
• c) Parquet charge tout le fichier en mémoire dès l'ouverture, ce qui évite les lectures disque ultérieures.
• d) Parquet est un format texte plus compact que CSV, donc plus rapide à analyser ligne par ligne.

Question 2

Que fait cette ligne du TP 4 ?

trips.createOrReplaceTempView("trips")

• a) Elle écrit le DataFrame sur disque sous forme de table nommée trips.
• b) Elle exécute le calcul du DataFrame et met le résultat en cache sous le nom trips.
• c) Elle crée une copie indépendante du DataFrame, modifiable sans toucher à l'original.
• d) Elle donne le nom trips au DataFrame pour l'interroger avec spark.sql, sans écrire ni calculer quoi que ce soit.

Question 3

Le programme de la formation présente SQLContext et HiveContext comme de l'héritage. Dans le TP 4, quel objet sert de point d'entrée pour lire les fichiers, créer les vues et lancer spark.sql ?

• a) La SparkSession créée avec SparkSession.builder, qui regroupe ces fonctions.
• b) Un HiveContext, obligatoire dès qu'on exécute du SQL avec spark.sql.
• c) Un SQLContext, nécessaire pour appeler createOrReplaceTempView.
• d) Le SparkContext récupéré par spark.sparkContext, qui exécute directement les requêtes SQL.

Question 4

Voici un extrait du schéma explicite du corrigé :

schema = StructType([
    StructField("tpep_pickup_datetime", ...),
    StructField("PULocationID", IntegerType()),
    StructField("total_amount", DoubleType()),
])

Quel type le TP retient-il pour tpep_pickup_datetime, et pourquoi ?

• a) TimestampType(), car Spark convertit toujours les horodatages en UTC à la lecture.
• b) StringType(), pour éviter toute erreur de conversion à la lecture du Parquet.
• c) TimestampNTZType(), car l'heure est locale à New York et sans fuseau : ce type évite tout décalage.
• d) DateType(), car seule la date compte pour l'écriture partitionnée par jour.

Question 5

Avec spark.read.schema(schema).parquet(...), tu déclares IntegerType() pour une colonne stockée en INT64 dans le fichier Parquet. D'après le corrigé du TP 4, que se passe-t-il ?

• a) Spark convertit silencieusement les valeurs en entiers 32 bits, en tronquant les plus grandes.
• b) La lecture lève l'erreur PARQUET_COLUMN_DATA_TYPE_MISMATCH, car le type déclaré ne correspond pas au type physique.
• c) Spark ignore ton schéma et applique celui du fichier, puisque Parquet embarque son schéma.
• d) La colonne est lue sans erreur, mais toutes ses valeurs valent null.

Question 6

Au tour de table de fin de journée, on compare le top 10 du TP 2 (RDD, reduceByKey, join) à celui du TP 4 (DataFrame et SQL). Quelle réponse correspond à ce qui a été vu ?

• a) Le DataFrame est plus rapide : Catalyst optimise le plan, avec un broadcast join et une projection poussée vers la lecture Parquet.
• b) Le RDD est plus rapide : c'est l'API bas niveau, sans couche d'optimisation qui ralentit l'exécution.
• c) Les deux sont équivalents : ils utilisent le même moteur, donc exactement le même plan d'exécution.
• d) Le DataFrame est plus rapide uniquement parce qu'il met automatiquement les données en cache.

Question 7

Voici le code de la question 4 du TP 4 :

par_borough = (trips.join(zones, trips.PULocationID == zones.LocationID)
               .groupBy("Borough")
               .agg(F.round(F.sum("total_amount"), 2).alias("ca"), F.count("*").alias("courses"))
               .orderBy(F.desc("ca")))
par_borough.show()

À quel moment Spark lit-il réellement les données et calcule-t-il le classement ?

• a) À l'appel de join, car une jointure doit lire les deux tables.
• b) À l'appel de groupBy, car l'agrégation demande un shuffle.
• c) À l'appel de orderBy, car le tri est la dernière étape de la chaîne.
• d) À l'appel de show(), seule action de la cellule ; les étapes précédentes ne font que construire le plan.

Question 8

Le corrigé écrit les courses avec .withColumn("jour", F.to_date("tpep_pickup_datetime")).write.mode("overwrite").partitionBy("jour").parquet("out/trips_par_jour"). Tu obtiens 31 dossiers jour=…. Qu'est-ce qui détermine ce nombre ?

• a) Le nombre de partitions en mémoire du DataFrame, affiché par trips.rdd.getNumPartitions().
• b) Le nombre de cœurs utilisés par local[*], chaque cœur écrivant son propre dossier.
• c) Le nombre de valeurs distinctes de la colonne jour : le jeu couvre un mois de 31 jours.
• d) Le nombre de fichiers Parquet produits, regroupés ensuite dans un seul dossier par fichier.

Question 9

Un collègue lance spark.sql("SELECT total_amount / trip_distance FROM trips").show(), sans WHERE. Aucune erreur n'apparaît, il en conclut que le mode ANSI est désactivé dans Spark 4. Quel est le bon diagnostic ?

• a) show() ne lit que les 20 premières lignes, qui n'ont pas de distance nulle : la division par zéro n'est jamais calculée.
• b) Il a raison : le mode ANSI est désactivé par défaut et doit être activé à la main.
• c) En mode ANSI, une division par zéro renvoie null, d'où l'absence d'erreur.
• d) En mode ANSI, les erreurs ne sont levées qu'à l'écriture sur disque, jamais avec show().

Question 10

Dans le bonus 1, tu affiches top10.explain() et tu repères le mot Broadcast dans la jointure entre trips et zones. Que fait Catalyst ?

• a) Il diffuse la table trips sur chaque exécuteur, car c'est la table la plus utilisée par la requête.
• b) Il copie la petite table zones (265 zones) sur chaque exécuteur, ce qui évite de redistribuer les 120 000 courses de trips.
• c) Il renvoie le résultat de la jointure au driver, qui le diffuse ensuite à tous les exécuteurs.
• d) Il applique une indication de broadcast écrite explicitement dans la requête SQL du TP.

Question 11

Tu exécutes la première cellule du corrigé : lecture de data/trips.parquet avec le schéma explicite, puis trips.printSchema(). Que t'affiche Spark ?

• a) Les 19 colonnes du fichier, car Parquet embarque son schéma et Spark le restitue en entier.
• b) 5 colonnes, dont tpep_pickup_datetime de type timestamp, car Spark ramène tout horodatage à ce type.
• c) 5 colonnes : tpep_pickup_datetime en timestamp_ntz, PULocationID et DOLocationID en integer, trip_distance et total_amount en double.
• d) 5 colonnes, toutes de type string, car les types ne sont appliqués qu'au premier calcul.

Question 12

Dans le TP 4, trips est lu avec un schéma explicite, mais zones est lu avec spark.read.csv("data/taxi_zone_lookup.csv", header=True, inferSchema=True). Quelle justification tient la route ?

• a) inferSchema oblige Spark à parcourir le CSV pour deviner les types : sur les 265 lignes des zones, ce coût est négligeable, alors que pour les courses le schéma explicite fixe les types et ne garde que les colonnes utiles.
• b) inferSchema ne fonctionne qu'avec CSV, alors que Parquet impose toujours de déclarer un schéma explicite à la lecture.
• c) inferSchema devine les types plus sûrement qu'un schéma écrit à la main : on le réserve donc aux tables de référence, où une erreur de type serait la plus grave.
• d) Sans inferSchema=True, l'option header=True ne peut pas récupérer les noms de colonnes de la première ligne.

Question 13

Un participant simplifie la requête du top 10 :

SELECT z.Zone, z.Borough, ROUND(SUM(t.total_amount), 2) AS ca, COUNT(*) AS courses
FROM trips t JOIN zones z ON t.PULocationID = z.LocationID
GROUP BY z.Zone
ORDER BY ca DESC
LIMIT 10

Que se passe-t-il ?

• a) Spark prend le premier Borough rencontré pour chaque zone et affiche le top 10 sans erreur.
• b) Spark ajoute de lui-même z.Borough au GROUP BY et produit le même résultat que le corrigé.
• c) La requête s'exécute, mais la colonne Borough vaut null sur toutes les lignes.
• d) Spark refuse la requête à l'analyse, avant même toute action : Borough n'est ni dans le GROUP BY ni dans une fonction d'agrégation. C'est pourquoi le corrigé groupe par z.Zone, z.Borough.

Question 14

Pour la question 3b, tu tapes par_heure.show() au lieu de par_heure.show(24). La requête se termine par ORDER BY heure. Que vois-tu ?

• a) Les 24 heures, car show() affiche entièrement tout résultat court.
• b) Les heures 0 à 19 seulement : show() affiche 20 lignes par défaut, et le tri par heure repousse 20 h à 23 h hors de l'affichage.
• c) Les 20 heures les plus rentables, car show() trie le résultat sur la dernière colonne.
• d) Une erreur, car GROUP BY heure produit 24 groupes et show() exige alors un nombre de lignes explicite.

Question 15

Le corrigé Scala écrit la requête par heure avec ORDER BY ca DESC, puis appelle .show(3). Quelles heures apparaissent, et dans quel ordre ?

• a) 0, 1 et 2, comme dans la version Python, puisque show(3) affiche les trois premières heures de la journée.
• b) 17, 18 et 19, dans l'ordre chronologique de la sortie des bureaux.
• c) 18, 19 et 17 : le tri par chiffre d'affaires décroissant place le pic de 18 h (environ 237 600 $) en tête, puis 19 h et 17 h.
• d) Trois heures sans ordre garanti, car un ORDER BY placé après un GROUP BY n'est pas respecté par Spark.

Question 16

En voyant le pic de chiffre d'affaires à 18 h dans la question 3b, un collègue conclut : « À 18 h, les clients paient chaque course plus cher. » Quel est le bon diagnostic ?

• a) Il a raison : un chiffre d'affaires horaire plus élevé implique forcément un montant moyen plus élevé.
• b) Il a raison, puisque ROUND(SUM(total_amount), 0) est calculé sur le même nombre de courses pour chaque heure.
• c) Il a tort : HOUR() lit l'heure en UTC, donc le vrai pic de New York se situe à une autre heure.
• d) Il a tort : le pic vient du nombre de courses à la sortie des bureaux, et le montant moyen varie peu. Pour le vérifier, il faut ajouter AVG(total_amount) à la requête.

Question 17

Dans le TP 4, le top 10 est écrit en SQL (question 3a) et le classement par arrondissement avec l'API DataFrame (question 4). Un participant demande s'il doit réécrire toutes ses requêtes SQL avec l'API DataFrame pour gagner en performance. Que lui réponds-tu ?

• a) Non : spark.sql et l'API DataFrame aboutissent à un plan optimisé de la même façon par Catalyst. Le choix relève de la lisibilité.
• b) Oui : une requête spark.sql est interprétée ligne par ligne, alors que l'API DataFrame est compilée.
• c) Oui, sauf pour les jointures, où seul le SQL permet à Catalyst de faire un broadcast join.
• d) Non, c'est l'inverse : le SQL est plus rapide, car il évite d'exécuter du code Python.

Question 18

Dans la sortie de top10.explain(), la ligne de lecture Parquet de trips ne mentionne que PULocationID et total_amount, alors que ton schéma explicite déclare 5 colonnes. Comment l'expliques-tu ?

• a) Les trois autres colonnes contiennent des valeurs nulles, et Spark les écarte à la lecture.
• b) Le schéma explicite a été ignoré, et Spark a relu le schéma embarqué dans le fichier.
• c) Catalyst pousse la projection vers la lecture : le top 10 n'utilise que ces deux colonnes de trips, et comme Parquet est un format colonne, Spark ne lit qu'elles.
• d) explain() n'affiche jamais que les deux premières colonnes de chaque table, pour rester lisible.

Question 19

Le corrigé calcule le prix moyen par mile sur toutes les courses, sans WHERE :

SELECT ROUND(AVG(try_divide(total_amount, trip_distance)), 2) AS prix_moyen_par_mile FROM trips

Que deviennent les courses de distance nulle dans cette moyenne ?

• a) Elles comptent pour 0 dans la moyenne, qui se trouve donc tirée vers le bas.
• b) La requête échoue dès la première distance nulle, exactement comme sans try_divide.
• c) Elles valent total_amount, car try_divide renvoie le numérateur quand le diviseur est nul.
• d) try_divide renvoie null pour elles, et AVG ignore les null : la moyenne porte sur les seules courses de distance non nulle, comme avec un filtre trip_distance > 0.

Question 20

Tu relances la cellule d'écriture de la question 5 après avoir retiré à la fois shutil.rmtree(...) et .mode("overwrite"). Le dossier out/trips_par_jour existe déjà depuis ta première exécution. Que se passe-t-il ?

• a) Spark ajoute les nouvelles lignes aux dossiers existants, et chaque jour contient alors deux fois ses courses.
• b) L'écriture échoue, car le dossier existe déjà et le mode d'écriture par défaut refuse d'écraser. C'est la raison de mode("overwrite") et du rmtree dans le corrigé.
• c) Spark écrase le dossier sans rien signaler, car overwrite est le mode par défaut dans Spark 4.
• d) Spark crée 31 nouveaux dossiers jour=… à côté des anciens, avec un suffixe pour les distinguer.

Corriger Recommencer

Flashcards

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

Question Pourquoi lire trips.parquet plutôt que trips.csv ?

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