AWS Glue转换150GB TXT至Parquet时遇Java堆内存溢出问题求助

我之前处理过类似的大文件格式转换任务，碰到过一模一样的java.lang.OutOfMemoryError: Java heap space错误，结合AWS Glue的特性，给你几个额外的优化方向，应该能解决你的问题：

• 先拆分超大TXT文件再读取
  如果你的150GB是单个TXT文件，那即使重分区也可能在读取阶段就OOM——因为Spark（Glue基于Spark）默认会把单个大文件分配到一个分区里，单个分区的数据量远超Executor内存承载上限。
  你可以在创建DynamicFrame的时候启用文件拆分选项：

  dyf = glueContext.create_dynamic_frame.from_options(
      connection_type="s3",
      connection_options={"paths": ["s3://your-bucket/path/to/large-file.txt"]},
      format="csv",  # 或者对应你的TXT格式，比如fixed-width
      format_options={
          "splitFiles": True,
          "splitSize": 1024  # 单位MB，根据你的Worker内存调整，比如G.2X Worker可以设为2048
      }
  )
  

  这样Glue会自动把大文件拆分成多个小文件，每个分区的数据量可控，从根源上减少内存压力。

• 调整Glue Worker类型与堆外内存
  你之前只调整了spark.yarn.executor.memory，但Glue的Worker类型直接决定了Executor的基础内存配置：

  • 比如默认的Standard Worker只有8GB内存，换成G.2X Worker（16GB内存）或者G.4X（32GB）能大幅提升单个Executor的承载能力。
  • 同时一定要设置spark.executor.memoryOverhead参数，这是堆外内存，处理大文件时很多临时数据会存在堆外，默认值可能不够。建议设为Executor内存的15%-20%，比如：

    --conf spark.executor.memoryOverhead=4096  # 对应16GB Executor内存，设4GB堆外
    

• 优化数据加载与转换逻辑

  • 只加载需要的字段：如果你的TXT文件包含大量无关字段，在读取后立刻用applyMapping过滤掉不需要的列，减少内存占用。
  • 提前过滤无效数据：比如空行、不符合格式的行，在转换为Parquet之前用filter操作剔除，降低后续处理的数据量。

• 调整Spark内存与分区参数

  • 调整内存分配比例：把spark.memory.fraction从默认的0.6提高到0.7，给执行阶段更多内存（执行大文件转换时，计算内存需求比存储更高）：

    --conf spark.memory.fraction=0.7
    

  • 增加shuffle分区数：spark.sql.shuffle.partitions默认是200，对于150GB数据来说太少，调整到1000甚至2000，避免shuffle时数据集中到少数分区导致OOM：

    --conf spark.sql.shuffle.partitions=1000
    

• 排查数据倾斜问题
  如果你的TXT文件中存在某个字段的取值极度集中（比如某个类别占了80%的数据），会导致数据倾斜，单个分区的数据量远超其他分区。这种情况下：

  • 可以在repartition时指定多个分区键，让数据分布更均匀；
  • 或者先对倾斜字段进行“加盐”处理（比如给字段值加上随机后缀），完成转换后再去掉后缀。

另外，建议查看Glue作业的CloudWatch日志，定位OOM发生的具体阶段（读取、转换还是写入），这样能更精准地调整优化方案。

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