Noos
PT EN
RAN-DBDEA-00052
Ranvier · DBDEA

Exam DBDEA Topics: transformation Difficulty: medium

A shuffle-heavy silver aggregation repeatedly fails with a java.lang.OutOfMemoryError raised inside an executor while tasks build their aggregation buffers; the driver stays healthy. The compute runs a worker configuration with a small heap per executor. Which configuration change addresses the root cause most directly?

Options (Reading Mode) Click to filter discussion →
  1. A. Increase executor memory (larger worker type or higher spark.executor.memory)
  2. B. Increase spark.driver.memory so the driver can buffer bigger aggregation results
  3. C. Increase spark.sql.autoBroadcastJoinThreshold so the large table is broadcast to every executor
  4. D. Decrease spark.executor.memory so Spark automatically splits oversized tasks
Reveal answer

Correct answer: Increase executor memory (larger worker type or higher spark.executor.memory)

Reference: https://docs.databricks.com/aws/en/compute/configure

02 — The Myelin Layer · Canonical Discussion

Where the exam tries to trick you — and how those who passed solved it.

0 Passed

contributed to this question

Answer Distractor Matrix Click an option to filter or open its dissection.
✦ Consolidated Synthesis (Wiki) rev. #1 (baseline) · CC BY-SA 4.0
Start synthesis for this question →

No community synthesis consolidated for this question yet. Below is the verifiable official starting point — if you passed the exam, open the option dissection.

Official Answer (A): Increase executor memory (larger worker type or higher spark.executor.memory)

⚓ Official Documentation Anchor: https://docs.databricks.com/aws/en/compute/configure
Ranvier · DBDEA

Contribute to this Question

Your contribution builds your Orbital Sheath

Peer contributions

No public contribution yet. Be the first who passed to explain why the distractors trick candidates — your contribution builds your Orbital Sheath.