AWS Glue写入PostgreSQL内存溢出，求适配集群的配置参数

结合你的集群规格（3个AWS Glue G.2X节点，单节点8vCPU/32GB内存）以及代码执行时的OOM报错，以下是针对性的配置优化和代码调整方案：

一、核心Spark内存配置（Glue作业参数） #

在Glue作业的作业参数中添加以下Spark配置项：

Driver端配置 #

• --conf spark.driver.memory=16g：G.2X默认Driver内存为8GB，提升至16GB可覆盖repartition、Schema推导等Driver端操作的内存需求
• --conf spark.driver.cores=4：分配4核给Driver，匹配内存规格，避免CPU瓶颈拖慢内存处理效率

Executor端配置 #

Glue G系列节点默认1个Executor对应1个工作节点，配置如下：

• --conf spark.executor.memory=24g：预留8GB给操作系统和Glue服务进程，剩余24GB全部分配给Executor堆内存
• --conf spark.executor.cores=8：使用节点全部8核，最大化CPU利用率
• --conf spark.executor.instances=3：对应3个工作节点，充分利用集群资源
• --conf spark.executor.memoryOverhead=4g：额外分配4GB堆外内存，应对序列化、JNI调用等场景，避免堆外内存溢出

二、代码层面优化 #

1. 调整分区策略 #

• 你当前设置repartition(12)，但3个Executor总共有24核，建议改为repartition(24)，让分区数匹配Executor总核数，均衡任务负载
• 如果数据读取后的分区已经相对合理，可改用coalesce(24)替代repartition：coalesce是窄依赖操作，无需shuffle，能大幅降低Driver和Executor的内存压力

2. JDBC写入参数优化 #

• 你的batchsize=2000000过大，单批次200万条数据会占用大量Executor内存，建议调整为50000-100000，平衡写入速度与内存占用
• 添加全局配置--conf spark.sql.shuffle.partitions=24：让shuffle分区数与repartition数量一致，避免额外的shuffle开销

3. 数据处理细节优化 #

• 读取Parquet时无需option("header", "true")：Parquet是列存格式自带Schema，该参数仅适用于CSV类文本格式，去掉可减少不必要的解析开销
• 多次explode操作会大幅膨胀数据量，建议在explode后尽早过滤无关字段，减少内存占用

三、辅助配置补充 #

• --conf spark.sql.autoBroadcastJoinThreshold=-1：禁用自动广播表，避免大表广播到Driver导致内存溢出
• --conf spark.memory.fraction=0.7：调整Executor内存分配比例，70%用于计算与存储，30%用于缓存，适配数据转换场景

四、错误排查建议 #

• 查看Glue作业的Executor日志，确认OOM发生在Driver还是Executor：如果是Executor日志报错，说明Executor内存仍需调整；如果是Driver日志，可再小幅提升spark.driver.memory
• 用df.count()查看explode后的数据量，评估实际内存需求——多次explode后的数据量可能是原始16GB的数倍，这也是OOM的核心诱因之一

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