AWS EMR运行PySpark作业后期卡顿，中断重跑恢复正常，求原因及优化方法

连续执行卡顿、中断重跑正常的核心原因 #

• Driver端元数据膨胀：连续执行1500条SQL的过程中，所有临时视图schema、RDD血缘、作业执行统计、shuffle元数据都会持续累积在Driver内存中，执行到后期元数据体量过大，会导致Driver GC频率升高、SQL解析和任务分发逻辑阻塞，但还未达到OOM阈值，所以常规监控看不到明显异常。中断重跑时Driver进程全新启动，没有历史元数据占用，运行效率自然恢复正常。
• Executor内存碎片化与临时对象累积：长时间运行的Executor进程会累积大量弱引用对象、未清理的临时shuffle缓存，即使配置了G1GC，也会出现内存碎片化、GC停顿时间变长的问题，极端情况会出现YARN误判Executor失联导致任务反复重试。重跑时Executor进程是新启动的，内存空间干净没有碎片，任务执行效率不受影响。
• 中间缓存老化失效：创建的临时视图如果做了缓存，长时间运行后会出现缓存块丢失、命中率下降的问题，后续SQL执行时需要反复重算之前的依赖链路，越到后期重算成本越高。而中断后从卡住的规则重跑，不需要缓存前面1400条规则的中间结果，没有重算开销。
• EMRFS S3连接耗尽：连续写入S3的过程中会累积大量处于TIME_WAIT状态的网络连接，后期连接池被占满后新的写入请求会卡住等待空闲连接。重跑时网络连接全部重置，所以写入速度恢复正常。

参数调优 #

• 调整Driver配置：将spark.driver.memory提升至20G，同时给Driver新增G1GC配置：--conf spark.driver.extraJavaOptions="-XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=35 -XX:ConcGCThreads=4"，新增--conf spark.driver.maxResultSize=8g避免返回结果撑爆Driver内存。
• 调整并行度配置：当前spark.default.parallelism和spark.sql.shuffle.partitions设置为10过低，建议调整为总核数的2-3倍（集群总共有20个Executor核，建议设置为40~60），提升资源利用率，避免单Task处理数据量过大。
• 开启自动清理配置：新增两个参数：--conf spark.cleaner.referenceTracking.cleanCheckpoints=true、--conf spark.cleaner.periodicGC.interval=10min，让Spark定期清理过期元数据、无效缓存资源。
• EMRFS连接优化：新增参数--conf spark.hadoop.fs.s3.maxConnections=100提升S3连接池上限，--conf spark.hadoop.fs.s3.connectionTimeout=300000避免连接超时。
• Parquet读写优化：新增参数--conf spark.sql.parquet.mergeSchema=false、--conf spark.sql.parquet.filterPushdown=true、--conf spark.hadoop.parquet.enable.summary-metadata=false，减少不必要的元数据生成和读写开销。

作业逻辑优化 #

• 定期释放无用资源：每执行200~300条SQL后，主动调用spark.catalog.dropTempView("不需要的视图名")删除无用临时视图，同时对不再使用的DataFrame调用unpersist()释放缓存空间。
• 中间结果做Checkpoint：对需要长期复用的核心中间结果，写入S3临时路径做Checkpoint，切断RDD血缘链路，避免血缘过长导致的元数据爆炸，同时减少失败重算成本。
• 拆分大作业：将1500条SQL拆分为5_{6个独立小作业，每个作业执行200}300条规则，跑完一个作业销毁Spark上下文再启动下一个，从根源上避免元数据、内存、连接的累积问题，和手动中断重跑的逻辑一致但无需人工介入。

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