Questions d'entretien PySpark

Vous pouvez écrire du PySpark qui fonctionne et pourtant trébucher ici, car ces questions portent sur ce que fait le moteur, pas sur ce que dit votre code. Les recruteurs commencent souvent par ces questions précisément parce qu'elles distinguent celles et ceux qui ont déjà réglé un job de celles et ceux qui n'en ont fait qu'exécuter un. Cette section couvre les questions sur le modèle d'exécution et ce qu'une réponse complète doit inclure.

• Quelle est la différence entre une transformation et une action ? Les transformations construisent un plan et renvoient un nouveau DataFrame de façon paresseuse ; des actions comme count, collect ou une écriture déclenchent l'exécution. Rien n'est calculé tant qu'une action ne demande pas un résultat.
• Pourquoi l'évaluation paresseuse est-elle utile ? L'optimiseur voit toute la chaîne avant de l'exécuter, il peut donc réordonner les filtres, éliminer des colonnes inutiles et fusionner des étapes.
• Transformation étroite ou large ? Les opérations étroites comme filter et select font en sorte que chaque partition de sortie dépende d'une seule partition d'entrée. Les opérations larges comme groupBy, join et distinct redistribuent les données entre partitions, ce qui constitue un shuffle.
• Qu'est-ce qu'un shuffle et pourquoi est-ce important ? Les données transitent sur le réseau et touchent le disque, formant une limite de stage. C'est généralement l'opération la plus coûteuse d'un job.
• Expliquez job, stage et task. Une action démarre un job, les limites de shuffle le découpent en stages, et chaque stage exécute une task par partition.
• RDD, DataFrame ou Dataset ? Privilégiez les DataFrame, car l'optimiseur Catalyst et l'exécution en colonnes s'appliquent. Les RDD restent utiles pour un contrôle bas niveau. Les Dataset typés sont un concept propre à la JVM ; en Python, la réponse honnête est qu'ils ne s'appliquent pas.

Employez les mots shuffle et stage quand ils ont leur place dans la réponse. Les recruteurs s'en servent comme raccourci pour savoir si vous avez déjà consulté un Spark UI.

La plupart des entretiens PySpark senior sont en réalité des entretiens de performance. Les questions arrivent sous forme de scénarios plutôt que de définitions.

• Une jointure est lente. Que vérifiez-vous ? D'abord la taille de chaque côté. Si l'un tient dans la mémoire d'un executor, diffusez-le en broadcast et évitez complètement le shuffle. Sinon, examinez le partitionnement et l'asymétrie avant de toucher à la taille du cluster.
• Qu'est-ce que l'asymétrie des données et comment la corriger ? Quelques clés concentrent la majorité des lignes, si bien qu'une task tourne longtemps après que les autres sont terminées. Les remèdes incluent le salage de la clé chaude, la diffusion en broadcast du côté le plus petit, ou le filtrage des valeurs nulles qui se retrouvent toutes hachées ensemble. Le signal de diagnostic est l'écart de durée des tasks dans le Spark UI.
• Quand utiliser cache ou persist ? Quand un DataFrame est réutilisé par plusieurs actions et que le recalculer serait coûteux. Mettre en cache quelque chose utilisé une seule fois gaspille de la mémoire, et penser à faire unpersist compte dans les jobs longs.
• repartition ou coalesce ? repartition déclenche un shuffle et peut augmenter ou réduire les partitions de façon uniforme ; coalesce fusionne sans shuffle complet, ce qui est le moyen le moins coûteux de réduire le nombre de fichiers en sortie.
• Pourquoi éviter une UDF Python ? Les lignes sont sérialisées entre la JVM et un processus Python, et l'optimiseur ne voit pas l'intérieur de la fonction. Préférez les fonctions natives, et ne recourez à une UDF vectorisée que si aucune fonction native n'existe.
• Pourquoi collect est-il dangereux ? Il rapatrie le résultat complet vers le driver et peut épuiser sa mémoire.
• Un job échoue par manque de mémoire. Dans quel ordre l'investiguez-vous ? D'abord si c'est le driver ou l'executor, puis l'asymétrie, puis le dimensionnement des partitions, puis la configuration mémoire. Augmenter la mémoire en premier est la réponse qui trahit le manque d'expérience.

Un data engineer passant un entretien pour une équipe plateforme s'est vu demander pourquoi un job nocturne qui tournait depuis un an s'était soudain mis à durer quatre heures. La réponse qui a fait mouche n'était pas un changement de configuration, mais le fait qu'un partenaire en amont avait commencé à envoyer des valeurs nulles dans la clé de jointure, si bien que toutes les lignes nulles se retrouvaient hachées vers la même partition. Les recruteurs récompensent cet ordre : regarder les données avant le cluster.

Les banques de questions liées, classées par poste, se trouvent sous questions d'entretien par poste.

Les questions restantes vérifient si vous avez déjà mis en production un pipeline, plutôt que simplement terminé un tutoriel.

• Comment lire les données efficacement ? Des formats en colonnes comme Parquet, l'élagage de partitions sur la colonne de filtre, et le predicate pushdown. Expliquez pourquoi lire moins d'octets vaut mieux qu'optimiser ce qui se passe ensuite.
• Pourquoi définir un schéma plutôt que de l'inférer ? L'inférence coûte un passage supplémentaire sur les données et peut deviner des types différents d'une exécution à l'autre.
• Comment gérer les valeurs nulles et les doublons ? Les fonctions concernées, en précisant que des clés de jointure riches en valeurs nulles créent de l'asymétrie.
• À quoi servent les fonctions de fenêtrage ? Au classement, aux totaux cumulés et à la déduplication vers le dernier enregistrement par clé, une tâche très courante dans un pipeline.
• Comment écrire le résultat sans produire des milliers de petits fichiers ? Faire un coalesce ou un repartition avant l'écriture, et partitionner la sortie selon une colonne à la cardinalité raisonnable.
• Comment tester du code PySpark ? De petites sessions locales avec des DataFrame de test, et une logique métier isolée dans des fonctions qui prennent et renvoient des DataFrame.
• Comment soumettre et configurer un job ? Le nombre d'executors, les cœurs et la mémoire, ainsi que le raisonnement selon lequel trop de petits executors comme trop peu de gros gaspillent de la capacité.

Les réponses PySpark échouent à l'oral d'une manière reconnaissable. Le candidat sait qu'un shuffle coûte cher mais ne sait pas dire quelles opérations en provoquent un, si bien que la réponse devient une liste d'adjectifs. Lire une banque de questions crée un sentiment de familiarité, et la familiarité n'est pas la même chose qu'une explication délivrée pendant que quelqu'un attend.

Prenez un pipeline que vous avez construit et racontez-le de bout en bout : la lecture, chaque transformation, où tombent les limites de stage, et ce que vous vérifieriez en premier si ça ralentissait. Faites-le à voix haute jusqu'à ne plus avoir besoin de recommencer. S'exercer sur ces questions face à un recruteur IA qui pose des relances se rapproche plus d'un vrai entretien que de relire des notes, et c'est exactement ce pour quoi le mode entretien simulé a été conçu.

Aaron Cao, fondateur de SubcueAI, a construit cet entraînement autour de cet écart à l'oral plutôt qu'autour de la fourniture de questions supplémentaires. En entretien réel, l'application de bureau et le panneau latéral de l'extension navigateur peuvent faire apparaître la structure pendant que le recruteur parle, ce qui aide surtout sur du contenu déjà répété. La configuration prend quelques minutes et est détaillée sur la page tutoriel.