如何高效解决Glue Job中PySpark处理大文件的超时与空间不足问题？

一、文件读取层面优化 #

• 分批加载替代全量读取：别把9个文件一次性读进单个大DataFrame，改成按文件逐个读取处理。比如用spark.read.option("path", "s3://your-target-path/file-pattern")配合循环，处理完一批就释放内存再读下一批，能大幅降低单批次内存占用，减少本地磁盘临时文件的压力。
• 切换列式存储格式：如果当前用的是CSV、JSON这类非列式文件，先转成Parquet或ORC格式再处理。列式存储能减少IO开销，而且Glue对这类格式的读取优化更到位，能显著提升读取速度。另外检查文件是否有合理的分区策略，没有的话先按业务字段（比如日期、数据类型）做分区，后续处理可以只加载需要的分区数据，不用全量扫描。
• 调整读取参数适配文件大小：11GB共9个文件，平均每个约1.2GB。可以把spark.sql.files.maxPartitionBytes从默认的128MB调到1g，让每个文件对应一个RDD分区，避免小文件过多导致的任务调度开销；同时调大spark.sql.files.openCostInBytes（默认4MB），减少频繁打开文件的成本。

二、Glue资源与执行配置优化 #

• 缩紧Worker数量：200个G2X Worker对于11GB的数据来说完全过剩，反而会增加集群调度、节点间通信的额外开销。建议直接降到10-20个G2X，或者换成G1X这类更小的Worker类型，资源匹配数据规模才能提升效率，还能避免节点间磁盘资源的争用。
• 解决本地磁盘空间不足问题："No space left on device"大多是因为Worker本地磁盘的临时Shuffle文件占满了，试试这几个办法：
  • 确保spark.sql.shuffle.spill.compress开启（默认是true），压缩溢出的临时文件；
  • 调整spark.sql.shuffle.partitions，默认200，改成Worker总核数的2-3倍就行（比如10个G2X是80核，设为160-240），缩小每个Shuffle分区的大小；
  • 直接把Glue的临时存储切换到S3，通过--temp-dir参数指定一个S3路径，彻底绕开本地磁盘的限制。
• 开启自适应执行计划：打开spark.sql.adaptive.enabled，让Spark自动根据数据量调整Shuffle分区数、Join策略，不用手动硬调参数，能大幅优化执行效率。

三、业务处理逻辑优化 #

• 先过滤再处理：读取文件后第一时间过滤掉无效行、过期数据或者不需要的字段，从源头减少后续处理的数据量，降低内存和磁盘的压力。
• 优化Shuffle密集型操作：避免大表全量Join、Cartesian Join这类操作，小表直接用broadcast()广播到所有节点，大表Join尽量用分阶段聚合，减少Shuffle的数据量。
• 增量处理替代全量扫描：如果文件是定期新增的，不用每次都处理全部9个文件，记录已处理文件的路径或时间戳，下次只读取新增的文件，能节省大量重复处理的时间。

内容的提问来源于stack exchange，提问作者Muskan Makhija