A company is using AWS Glue to run ETL jobs that transform data from multiple sources into a data lake on S3. The jobs are scheduled to run hourly. Recently, the jobs have been failing intermittently with 'MemoryError' exceptions. The data volume has grown over time. The data engineer needs to resolve this issue cost-effectively. Which action should be taken?
More DPUs and larger worker types provide more memory to handle larger data volumes.
Why this answer
The 'MemoryError' exception indicates that the Glue job is running out of memory as data volume grows. Increasing the number of DPUs (Data Processing Units) and using a larger worker type (e.g., from Standard to G.1X or G.2X) provides more memory and compute capacity per worker, allowing the job to handle larger datasets without failing. This is the most cost-effective approach because it scales resources only as needed, avoiding over-provisioning.
Exam trap
The trap here is that candidates may confuse memory errors with data skew or partitioning issues, leading them to choose repartitioning (Option D) instead of recognizing that the root cause is insufficient total memory for the growing dataset.
How to eliminate wrong answers
Option B is wrong because S3 timeout settings control how long the job waits for S3 operations, not the memory allocation; memory errors are unrelated to network timeouts. Option C is wrong because switching from Spark to Python shell would drastically reduce processing capability and memory, likely causing the job to fail entirely on large datasets, not solve the memory issue. Option D is wrong because repartitioning data with Spark's repartition method can increase parallelism but does not directly increase the total memory available to the job; it may even cause more memory pressure if partitions are increased without adding resources.