reduceByKey impose le même type en entrée et en sortie, ce qui rend une moyenne impossible. Les trois agrégateurs qui lèvent cette contrainte.
Un cache mal placé ralentit un job. Les niveaux de persist, la différence RDD/DataFrame, l’unpersist oublié, et le cas où seul checkpoint suffit.
Deux méthodes au même argument, deux travaux différents. Démonstration avec glom(), le piège du coalesce(7) qui reste à 5, et la règle pour choisir.
Un RDD n’est pas une table, ni une List plus grosse. Ce que le distribué retire (index, évaluation immédiate), et en quoi Spark SQL diffère du SQL.
Une vue temporaire n’est ni une table, ni un cache. Sa portée, sa durée de vie, le préfixe global_temp qui piège tout le monde, et l’équivalent Scala de l’exemple PySpark.
Spark déduit le nombre de partitions des cœurs qu’il croit avoir. Le code pour afficher ce chiffre, d’où il vient, et le piège des deux réglages.
Quatre opérations qui se ressemblent et un choix qui change la facture cloud. Pourquoi reduceByKey bat groupByKey, et les pièges du tri de clés.
Oui, Spark relit tout le fichier pour deviner les types. Mais le vrai problème n’est pas la lenteur : c’est le type qui change et casse le pipeline sans erreur.
Un join qui met une heure au lieu de trois minutes, c’est la stratégie choisie. Broadcast, sort-merge, skew : quand chacun s’applique et comment forcer.
Comment écrire en Parquet ou Delta Lake sans noyer le stockage : partitionnement, taille des fichiers, et le moment où Delta devient indispensable.
Vos jobs tournent avec 200 partitions par défaut, et c’est presque toujours faux. La règle des 128 Mo, repartition, coalesce et l’AQE de Spark 3.
Une partition est une tâche potentielle, pas un cœur. L’exécution par vagues, et comment inspecter les partitions avec mapPartitionsWithIndex.
Trois API pour le même moteur, mais un seul optimiseur les comprend. Pourquoi le DataFrame gagne presque toujours, et les trois cas où le RDD reste indispensable.
Le word count de Spark décortiqué ligne par ligne en Scala : flatMap, map, reduceByKey, saveAsTextFile sur un cas concret, avec les pièges classiques.
Les tutoriels écrivent tantôt `sc.parallelize`, tantôt `spark.read` sans dire ce que sont ces objets. La différence, l’historique, et lequel utiliser.
On répète que Scala est plus rapide que PySpark. C’est vrai dans un cas précis et faux ailleurs. Ce qui se passe sous le capot, et comment choisir.
Une UDF est une boîte noire pour Catalyst : plus de codegen, plus de pushdown. Ce que vous perdez, et comment la remplacer par des fonctions natives.
map, filter, select ne lancent aucun calcul. count, collect, write si. Comprendre la frontière transformation / action évite 80 % des mauvaises surprises en Spark.