Shuffles are where Spark jobs go to get expensive: a wide join or aggregation forces data to move across the network, materialize shuffle files, and often spill when memory pressure spikes.
In Microsoft Fabric Spark workloads, the fastest optimization is usually the boring one: avoid the shuffle when you can, and when you can’t, make it smaller and better balanced.
This post lays out a practical, repeatable approach you can apply in Fabric notebooks and Spark job definitions.
1) Start with the simplest win: avoid the shuffle
If one side of your join is genuinely small (think lookup/dimension tables), use a broadcast join so Spark ships the small table to executors and avoids a full shuffle.
In Fabric’s Spark best practices, Microsoft explicitly calls out broadcast joins for small lookup tables as a way to avoid shuffles entirely.
Example (PySpark):
from pyspark.sql.functions import broadcast
fact = spark.read.table("fact_sales")
dim = spark.read.table("dim_product")
# If dim_product is small enough, broadcast it
joined = fact.join(broadcast(dim), on="product_id", how="left")
If you can’t broadcast safely, move to the next lever.
2) Make the shuffle less painful: tune shuffle parallelism
Spark controls the number of shuffle partitions for joins and aggregations with spark.sql.shuffle.partitions (default: 200 in Spark SQL).
- Too few partitions → huge partitions → long tasks, spills, and stragglers.
- Too many partitions → tiny tasks → scheduling overhead, excess shuffle metadata, and unnecessary overhead.
Example (session-level setting):
spark.conf.set("spark.sql.shuffle.partitions", "400")
A decent heuristic is to start with something proportional to total executor cores and then iterate using the Spark UI (watch stage task durations, shuffle read/write sizes, and spill metrics).
3) Let Spark fix itself (when it can): enable AQE
Adaptive Query Execution (AQE) uses runtime statistics to optimize a query as it runs.
Fabric’s Spark best practices recommend enabling AQE to dynamically optimize shuffle partitions and handle skewed data automatically.
AQE is particularly helpful when:
- Your input data distribution changes day-to-day
- A static
spark.sql.shuffle.partitionsvalue is right for some workloads but wrong for others - You hit skew where a small number of partitions do most of the work
Example:
spark.conf.set("spark.sql.adaptive.enabled", "true")
4) Diagnose like you mean it: what to look for in Spark UI
When a job is slow, treat it like a shuffle problem until proven otherwise.
Look for:
- Stages where a handful of tasks take dramatically longer than the median (classic skew)
- Large shuffle read/write sizes concentrated in a small number of partitions
- Spill (memory → disk) spikes during joins/aggregations
When you see skew, your options are usually:
- Broadcast (if feasible)
- Repartition on a better key
- Salt hot keys (advanced)
- Enable AQE and confirm it’s actually taking effect
A minimal checklist for Fabric Spark teams
- Use DataFrame APIs (keep Catalyst in play).
- Broadcast small lookup tables to avoid shuffles.
- Set a sane baseline for
spark.sql.shuffle.partitions. - Enable AQE and validate in the query plan / UI.
- Iterate with the Spark UI: measure, change one thing, re-measure.
References
- Microsoft Fabric — Spark Basics (best practices)
- Apache Spark — SQL Performance Tuning (AQE + spark.sql.shuffle.partitions)
This post was written with help from ChatGPT 5.2
Christopher Finlan 