Lire un plan d'exécution : les 4 signaux à chercher
explain(mode='formatted') et les marqueurs qui comptent : Exchange (shuffle), type de jointure, PushedFilters et PartitionFilters.
Cas d'usage
Diagnostiquer pourquoi une requête lit 2 To au lieu de 20 Go.
Prérequis
PySpark 3.x
Python
q = (
spark.read.parquet("s3a://lake/silver/events")
.filter("event_date = '2026-06-01' AND status = 'paid'")
.join(ref, "product_id")
)
q.explain(mode="formatted")
# À vérifier dans la sortie :
# 1. PartitionFilters: [event_date = 2026-06-01]
# -> le pruning de partition fonctionne (sinon : filtre non poussé,
# cast implicite ou fonction sur la colonne de partition ?)
# 2. PushedFilters: [IsNotNull(status), EqualTo(status,paid)]
# -> predicate pushdown vers Parquet OK
# 3. BroadcastHashJoin vs SortMergeJoin -> la petite table est-elle diffusée ?
# 4. Nombre d'Exchange -> chaque occurrence est un shuffle complet.Résultat
(1) Scan parquet lake.silver.events
Output [5]: [event_id#0, product_id#3, status#4, amount#5, event_date#7]
PartitionFilters: [isnotnull(event_date#7), (event_date#7 = 2026-06-01)]
PushedFilters: [IsNotNull(status), EqualTo(status,paid)]
(4) BroadcastExchange
(5) BroadcastHashJoin [product_id#3], [product_id#12], Inner, BuildRight
Exchange : 1 seul (le broadcast) -> aucun shuffle des events ; 18 Go lus sur 2 To.PySparkexplainCatalystDiagnostic