How Spark Splits Data Across the Cluster
A Spark DataFrame is physically split into partitions, independent chunks of rows distributed across the cluster's executors, and the number of partitions determines the degree of parallelism available for a job. Each partition is processed by a single task on a single core, so a DataFrame with 200 partitions running on 50 cores will schedule four waves of tasks. Partitioning is inherited from the source, such as HDFS block size or Kafka topic partitions, unless explicitly changed with repartition or coalesce.
Cricket analogy: It's like splitting a stadium's ticket-checking gates by turnstile — each gate handles its own queue of fans independently, and more open gates mean more people get through per minute.
What Triggers a Shuffle
A shuffle happens whenever data with the same key must be physically moved between partitions so it can be combined, which occurs during wide transformations like groupBy, join, distinct, and repartition. During a shuffle, each executor writes shuffle files to local disk, and every other executor that needs a given key range reads across the network to pull matching records, an all-to-all data movement pattern that is by far the most expensive operation in a Spark job. Minimizing shuffles, for example by using reduceByKey instead of groupByKey, or broadcasting a small table in a join, is the single biggest lever for Spark performance tuning.
Cricket analogy: It's like a mid-tournament player draft where every franchise must trade players to consolidate all all-rounders onto one squad — everyone ships players across the league simultaneously, and that all-to-all trade window is the costliest part of the auction.
# Wide transformation -> triggers a shuffle
sales_by_region = orders.groupBy("region").sum("total")
# Repartition: full shuffle to exactly 50 partitions
orders_repart = orders.repartition(50, "region")
# Coalesce: cheap local merge down to 10 partitions, no shuffle
small_output = orders.filter(orders.region == "APAC").coalesce(10)
# Broadcast join avoids shuffling the large 'orders' table
from pyspark.sql.functions import broadcast
joined = orders.join(broadcast(regions_lookup), "region_id")
small_output.write.parquet("s3://out/apac_orders/")
Controlling Partition Count and Skew
The number of shuffle output partitions is controlled by spark.sql.shuffle.partitions, defaulting to 200 regardless of cluster size, which is often wrong for both small jobs, where 200 tiny partitions add scheduling overhead, and huge jobs, where 200 partitions are too few and each grows too large. Data skew, where one key like a null or a dominant customer ID holds a disproportionate share of rows, causes a single task to take far longer than the rest; salting, appending a random suffix to the skewed key before aggregating and stripping it afterward, spreads that hot key across multiple partitions.
Cricket analogy: It's like fixing an over-rate problem by adding more overs than the format needs — a T20 innings padded to 200 balls when only 120 are needed just wastes time between deliveries, the same way an oversized shuffle partition count adds scheduling overhead.
spark.sql.shuffle.partitions defaults to 200 regardless of data size. As a starting point, size it so each output partition holds roughly 128MB-200MB of data, then let Adaptive Query Execution (spark.sql.adaptive.enabled, on by default in modern Spark) automatically coalesce partitions that turn out too small at runtime.
Coalesce vs. Repartition
repartition(n) performs a full shuffle to redistribute data into exactly n partitions of roughly equal size, which is useful when you need to increase partitions or fix severe skew, but it's expensive because every row moves across the network. coalesce(n) instead merges existing partitions locally without a full shuffle, so it can only reduce the partition count, and it's the right choice after a heavy filter has left you with mostly-empty partitions that you just want to consolidate before writing output cheaply.
Cricket analogy: It's like the difference between a full squad re-draft, where every player's franchise is reassigned from scratch, versus simply merging two under-strength domestic teams for a friendly — the redraft is expensive and total, the merge is cheap and local.
coalesce(n) can only reduce partition count and does so without a full shuffle — but calling coalesce(1) after a wide operation on a large dataset forces all the data onto a single task, often creating a severe bottleneck or an out-of-memory error. Use repartition() instead if you actually need an even redistribution.
- A DataFrame is split into partitions, the unit of parallelism for Spark tasks.
- Wide transformations like groupBy, join, and distinct trigger shuffles; narrow transformations don't.
- spark.sql.shuffle.partitions (default 200) controls shuffle output partition count and often needs tuning.
- Data skew causes straggler tasks; salting or AQE's skew join handling can fix it.
- repartition(n) does a full shuffle and can increase or decrease partitions; coalesce(n) merges locally and only decreases them.
- Broadcasting a small table avoids shuffling a large one entirely in a join.
Practice what you learned
1. Which operation is most likely to trigger a shuffle in Spark?
2. What is the default value of spark.sql.shuffle.partitions?
3. What is the key difference between repartition() and coalesce()?
4. What problem does key-salting address?
5. Why is broadcasting a small lookup table in a join beneficial?
Was this page helpful?
You May Also Like
Lazy Evaluation and the DAG
How Spark defers execution of transformations into a logical plan and only runs work when an action forces it, using a DAG of stages for both optimization and fault tolerance.
Joins in Spark
How Catalyst chooses between broadcast hash joins and sort-merge joins, why the choice matters for performance, and how to diagnose and fix skewed joins.
The Catalyst Optimizer
How Spark SQL's Catalyst optimizer moves a query through analysis, logical optimization, physical planning, and code generation, plus how Adaptive Query Execution improves on it at runtime.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics