Avoiding shuffle operations in Apache Spark - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to cache the DataFrame and avoid shuffle during repeated actions.

Apache Spark

df.[1]()

Drag options to blanks, or click blank then click option'

Acache

Bcollect

Cshow

Dcount

Attempts:

3 left

💡 Hint

Common Mistakes

Using collect() causes data to be moved to the driver, not avoiding shuffle.

Using show() only displays data but does not cache it.

Using count() triggers computation but does not cache.

Using cache() stores the DataFrame in memory, avoiding shuffle for repeated operations.

2fill in blank

medium

Complete the code to avoid shuffle by using a broadcast join.

Apache Spark

from pyspark.sql.functions import broadcast
joined_df = large_df.join([1](small_df), 'id')

Drag options to blanks, or click blank then click option'

Acollect

Bpersist

Cbroadcast

Dcache

Attempts:

3 left

💡 Hint

Common Mistakes

Using cache() does not affect join shuffle.

Using collect() brings data to driver, not distributed.

Using persist() is similar to cache but does not broadcast.

Broadcasting the smaller DataFrame avoids shuffle by sending it to all nodes.

3fill in blank

hard

Fix the error in the code to avoid shuffle by using partitioning correctly.

Apache Spark

df = df.repartition([1])

Drag options to blanks, or click blank then click option'

A'id'

B10

Cdf

DNone

Attempts:

3 left

💡 Hint

Common Mistakes

Passing an integer causes full shuffle.

Passing the DataFrame itself is invalid.

Passing None does not repartition.

Repartitioning by a column name avoids shuffle by grouping data by that column.

4fill in blank

hard

Fill both blanks to create a DataFrame with partitioning and avoid shuffle on writes.

Apache Spark

df.write.partitionBy([1]).mode([2]).save('path/to/data')

Drag options to blanks, or click blank then click option'

A'category'

B'overwrite'

C'append'

D'id'

Attempts:

3 left

💡 Hint

Common Mistakes

Using append mode may cause shuffle on write.

Partitioning by an ID may not group data well.

Using wrong mode causes data duplication.

Partitioning by a column and using overwrite mode helps avoid shuffle and manage data writes efficiently.

5fill in blank

hard

Fill all three blanks to create a dictionary comprehension that avoids shuffle by filtering and mapping correctly.

Apache Spark

result = [1]: [2] for k, [2] in [3] if [2] > 10

Drag options to blanks, or click blank then click option'

Ak

Bv

Cdata.items()

Dk.upper()

Attempts:

3 left

💡 Hint

Common Mistakes

Using k instead of k.upper() does not transform keys.

Iterating over data instead of data.items() causes error.

Filtering on key instead of value causes wrong results.

The comprehension uses k.upper() as key, v as value, iterating over data.items(), filtering values greater than 10 to avoid shuffle by reducing data.

Practice

1. What is the main reason to avoid shuffle operations in Apache Spark?

easy

A. Shuffle operations move data across the network and slow down jobs

B. Shuffle operations increase memory usage on a single node only

C. Shuffle operations reduce the number of partitions automatically

D. Shuffle operations improve job speed by parallelizing tasks

Solution

1. Step 1: Understand what shuffle does

   Shuffle moves data between nodes in the cluster, causing network traffic.

2. Step 2: Impact of shuffle on performance

   This data movement slows down Spark jobs because of network delays and disk I/O.

3. Final Answer:

   Shuffle operations move data across the network and slow down jobs -> Option A

4. Quick Check:

   Shuffle = network data move = slow [OK]

Hint: Shuffle means data moves across nodes, causing slowdowns [OK]

Common Mistakes:

• Thinking shuffle only affects memory, not network
• Believing shuffle speeds up jobs by parallelism
• Confusing shuffle with partition reduction

2. Which Spark function reduces the number of partitions without causing a shuffle?

easy

A. repartition()

B. sortBy()

C. groupBy()

D. coalesce()

Solution

1. Step 1: Identify functions that change partitions

   repartition() causes shuffle; coalesce() reduces partitions without shuffle.

2. Step 2: Understand coalesce behavior

   coalesce() merges partitions without moving data across nodes, avoiding shuffle.

3. Final Answer:

   coalesce() -> Option D

4. Quick Check:

   coalesce = reduce partitions no shuffle [OK]

Hint: Use coalesce() to reduce partitions without shuffle [OK]

Common Mistakes:

• Choosing repartition() which triggers shuffle
• Confusing groupBy() with partition functions
• Assuming sortBy() reduces partitions

3. Given the code below, what is the number of shuffle operations triggered?

rdd1 = sc.parallelize([('a', 1), ('b', 2), ('a', 3)])
rdd2 = rdd1.reduceByKey(lambda x, y: x + y)
rdd3 = rdd2.coalesce(1)
rdd4 = rdd3.mapValues(lambda x: x * 2)

medium

A. 2

B. 0

C. 1

D. 3

Solution

1. Step 1: Identify shuffle triggers in code

   reduceByKey triggers a shuffle; coalesce with default shuffle=False does not trigger shuffle.

2. Step 2: Count shuffle operations

   Only reduceByKey causes shuffle, so total shuffle count is 1.

3. Final Answer:

   1 -> Option C

4. Quick Check:

   reduceByKey = 1 shuffle, coalesce no shuffle [OK]

Hint: Only reduceByKey triggers shuffle here [OK]

Common Mistakes:

• Assuming coalesce always triggers shuffle
• Counting mapValues as shuffle
• Ignoring reduceByKey shuffle

4. Identify the error in this Spark code that causes an unnecessary shuffle:

df = spark.read.csv('data.csv')
df2 = df.repartition(5)
df3 = df2.coalesce(2)
df4 = df3.groupBy('col1').count()

medium

A. Reading CSV causes shuffle

B. Using repartition before coalesce causes an extra shuffle

C. groupBy does not cause shuffle

D. coalesce cannot reduce partitions after repartition

Solution

1. Step 1: Analyze repartition and coalesce usage

   repartition causes shuffle; coalesce reduces partitions without shuffle but after repartition it may be redundant.

2. Step 2: Understand shuffle impact

   Calling repartition then coalesce causes shuffle first, then reduces partitions without shuffle, causing extra shuffle than needed.

3. Final Answer:

   Using repartition before coalesce causes an extra shuffle -> Option B

4. Quick Check:

   repartition then coalesce = extra shuffle [OK]

Hint: Avoid repartition before coalesce to reduce shuffle [OK]

Common Mistakes:

• Thinking coalesce always triggers shuffle
• Believing groupBy never triggers shuffle
• Assuming reading CSV triggers shuffle

5. You have a large dataset partitioned into 100 partitions. You want to reduce it to 10 partitions without shuffle and then perform a groupBy operation. Which sequence of operations avoids unnecessary shuffle?

hard

A. Use coalesce(10) first, then groupBy()

B. Use repartition(10) first, then groupBy()

C. Use groupBy() first, then coalesce(10)

D. Use repartition(10) twice before groupBy()

Solution

1. Step 1: Reduce partitions without shuffle

   coalesce(10) reduces partitions without shuffle, ideal before groupBy.

2. Step 2: Perform groupBy after reducing partitions

   groupBy triggers shuffle, so reducing partitions first with coalesce avoids extra shuffle.

3. Final Answer:

   Use coalesce(10) first, then groupBy() -> Option A

4. Quick Check:

   coalesce then groupBy = minimal shuffle [OK]

Hint: Coalesce before groupBy to minimize shuffle [OK]

Common Mistakes:

• Using repartition causes unnecessary shuffle
• Doing groupBy before reducing partitions
• Calling repartition multiple times unnecessarily