Accueil›Blog›Test Spark

Tests prêts à l'emploi

Test Spark : un exercice de traitement distribué avec ses pièges de performance

Ce test vérifie si un candidat comprend vraiment le calcul distribué, ou s'il a juste « fait du Spark ». On donne un traitement simple en apparence, mais qui cache un piège de performance classique : la jointure d'une grosse table avec une petite. Corrigé et signaux inclus.

Data Builder·Juillet 2025·10 min de lecture·Test Spark · data engineering · performance

Sommaire

L'exercice
Le piège de performance
Le corrigé
Grille par niveau

Le cœur du test : la conscience du shuffle (déplacement de données entre machines). Un vrai profil sait qu'une jointure naïve entre grosse et petite table déclenche un shuffle coûteux, évitable par un broadcast.

1L'exercice

La consigne

« Calcule le CA par catégorie : une grosse table de commandes, une petite table de produits. »

Commandes fait des milliards de lignes ; produits en fait quelques milliers. Le candidat doit joindre les deux et agréger — en évitant le piège de performance.

commandes  : ~1 milliard de lignes (produit_id, montant)
produits   : ~5 000 lignes (id, categorie)
-- Objectif : CA total par categorie

2Le piège de performance

La consigne

Une jointure naïve déclenche un shuffle massif.

Par défaut, Spark redistribue les deux tables sur le cluster pour les joindre (sort-merge join) : sur un milliard de lignes, c'est très coûteux. La petite table peut au contraire être diffusée (broadcast) à tous les nœuds.

Piège : laisser Spark faire un sort-merge join qui shuffle la grosse table.
Bon réflexe : broadcaster la petite table pour éviter le shuffle.
Red flag : utiliser .collect() sur un milliard de lignes (fait tout planter).

3Le corrigé

La consigne

Un broadcast join, et une agrégation propre.

La solution efficace diffuse la petite table de produits, ce qui évite de déplacer la grosse table. Le candidat doit expliquer pourquoi — c'est ça qu'on évalue.

from pyspark.sql import functions as F

resultat = (
    commandes
    .join(F.broadcast(produits), commandes.produit_id == produits.id)
    .groupBy("categorie")
    .agg(F.sum("montant").alias("ca"))
)
# broadcast(produits) evite de shuffler le milliard de lignes de commandes.

Broadcast de la petite table : pas de shuffle de la grosse.
Agrégation par catégorie après la jointure.
Aucun collect() : tout reste distribué.

Signal d'alerte : le vrai marqueur : le candidat sait expliquer pourquoi le broadcast évite le shuffle. Réciter « j'utilise broadcast » sans comprendre le shuffle ne suffit pas — creusez le pourquoi.

4Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Écrit une jointure qui fonctionne	Obtient le bon résultat	Utilise collect() sur un gros volume
Confirmé	Connaît le broadcast join	Broadcaste la petite table	Laisse un shuffle massif se produire
Senior	Explique le shuffle	Justifie le broadcast par le coût	Applique broadcast sans comprendre
Lead	Optimise et diagnostique via la Spark UI	Sait aussi quand Spark est inutile	Ajoute Spark là où un script suffirait

Home›Blog›Spark test

Ready-to-use tests

Spark test: a distributed-processing exercise with its performance traps

This test checks whether a candidate truly understands distributed computing, or just ‘did Spark’. You give a seemingly simple job that hides a classic performance trap: joining a large table with a small one. Answer and signals included.

Data Builder·July 2025·10 min read·Spark test · data engineering · performance

Contents

The exercise
The performance trap
The answer
Level grid

The core of the test: awareness of the shuffle (data movement between machines). A real profile knows a naive join between large and small tables triggers a costly shuffle, avoidable with a broadcast.

1The exercise

The task

‘Compute revenue by category: a large orders table, a small products table.’

Orders has billions of rows; products a few thousand. The candidate must join them and aggregate — while avoiding the performance trap.

commandes  : ~1 milliard de lignes (produit_id, montant)
produits   : ~5 000 lignes (id, categorie)
-- Objectif : CA total par categorie

2The performance trap

The task

A naive join triggers a massive shuffle.

By default, Spark redistributes both tables across the cluster to join them (sort-merge join): on a billion rows, that's very costly. The small table can instead be broadcast to all nodes.

Trap: letting Spark do a sort-merge join that shuffles the large table.
Good reflex: broadcasting the small table to avoid the shuffle.
Red flag: using .collect() on a billion rows (crashes everything).

3The answer

The task

A broadcast join, and a clean aggregation.

The efficient solution broadcasts the small products table, avoiding moving the large table. The candidate must explain why — that's what we assess.

from pyspark.sql import functions as F

resultat = (
    commandes
    .join(F.broadcast(produits), commandes.produit_id == produits.id)
    .groupBy("categorie")
    .agg(F.sum("montant").alias("ca"))
)
# broadcast(produits) evite de shuffler le milliard de lignes de commandes.

Broadcast the small table: no shuffle of the large one.
Aggregation by category after the join.
No collect(): everything stays distributed.

Warning signal : the real marker: the candidate can explain why the broadcast avoids the shuffle. Reciting ‘I use broadcast’ without understanding the shuffle isn't enough — probe the why.

4Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	Writes a join that works	Gets the right result	Uses collect() on a large volume
Mid-level	Knows the broadcast join	Broadcasts the small table	Lets a massive shuffle happen
Senior	Explains the shuffle	Justifies the broadcast by cost	Applies broadcast without understanding
Lead	Optimizes and diagnoses via the Spark UI	Also knows when Spark is pointless	Adds Spark where a script would do

Test Spark : un exercice de traitement distribué avec ses pièges de performance

1L'exercice

2Le piège de performance

3Le corrigé

4Grille par niveau

Spark test: a distributed-processing exercise with its performance traps

1The exercise

2The performance trap

3The answer

4Level grid

Vous recrutez un profil data ?