Which of the following statements about joining a large fact table with a small dimension in Spark is true?

• A. A typical approach is to collect the dimension to the driver and then join.
• B. Sorted join is always faster than broadcast join.
• C. Broadcasting the smaller DataFrame to all workers minimizes data movement.
• D. Joins should be avoided entirely.

Answer: (C)

When joining a large fact table with a small dimension in Spark, the efficient approach is to broadcast the small dataset to all executors. This lets each worker hold a copy of the tiny side and perform the join locally against its portion of the big table, avoiding expensive shuffles of the large dataset across the cluster. By minimizing data movement and network I/O, the join often runs much faster, provided the small dataset fits in memory on each executor. Spark can do this automatically if the small dataset is under the auto broadcasting threshold, or you can force it with an explicit broadcast.

Collecting the dimension to the driver is risky because it can exhaust driver memory and still requires distributing that data to all workers, which undermines scalability. A join being implemented as a sorted or hashed operation isn’t guaranteed to be faster in all cases, and saying that joins should be avoided entirely isn’t realistic—there are optimized strategies, like broadcasting the small side, that typically yield the best performance here.