Databricks-Spark-Assoc Troubleshooting and Tuning DataFrame Apps Practice Question
A developer notices that a Spark DataFrame job on Databricks is running slowly and the Spark UI shows that many tasks are reading from a Delta table with a large number of small files. The job performs a filter on a date column and then aggregates results. Which optimization technique will most directly improve read performance in this scenario?
⚠ Common exam trap
The trap here is thinking that caching or increasing partition size will fix slow reads caused by many small files, when the core issue is file count and compaction is needed.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run OPTIMIZE on the Delta table to compact small files into larger ones.
The small files problem in Delta Lake causes slow reads because each file requires a separate open and read operation. Compacting small files into larger ones with OPTIMIZE reduces the number of files, improving I/O efficiency. This is the most direct fix for the described symptom of many tasks reading small files, leading to faster filter and aggregation performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase spark.sql.files.maxPartitionBytes to read more data per task.
Why it's wrong here
Increasing maxPartitionBytes may reduce the number of partitions, but it does not solve the small files issue; each small file still requires a separate read operation. This setting controls how data is split into partitions, not how files are organized. It could even lead to larger partitions that are less efficient if the files are small.
- ✓
Run OPTIMIZE on the Delta table to compact small files into larger ones.
Why this is correct
OPTIMIZE compacts small files into larger, more efficient files, reducing the number of file opens and improving read throughput. This directly addresses the small files problem, which is a common cause of slow reads in Delta Lake. After compaction, the job will read fewer files, leading to faster scan and aggregation.
- ✗
Set spark.sql.autoBroadcastJoinThreshold to -1 to disable broadcast joins.
Why it's wrong here
Disabling broadcast joins has no impact on reading small files from a Delta table. This setting is relevant for join strategies, not file scanning. The scenario involves a filter and aggregation, not a join, so this change would not affect read performance. It is unrelated to the small files problem.
- ✗
Enable Databricks Delta Cache to cache the table files on local SSDs.
Why it's wrong here
Delta Cache can speed up repeated reads of the same data, but it does not address the underlying issue of many small files. The initial read will still suffer from the overhead of opening numerous files. The filter and aggregation would benefit more from reducing file count or skipping data, which Delta Cache alone does not provide.
About these practice questions
This Databricks-Spark-Assoc question is part of Courseiva's 295-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-Spark-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-Spark-Assoc exam.