AWS EMR使用Spark Python写入S3上Hive外部表时遇内存泄漏错误

我之前在做Spark写入S3 Hive外部表的任务时，也碰到过这个一模一样的Netty ByteBuf资源泄漏警告。虽然大部分情况下这个警告不会直接让程序挂掉，但长期运行下来可能会导致内存占用飙升甚至OOM，下面是几个我亲测有效的解决思路：

1. 先开启高级泄漏排查，定位根源 #

按照错误提示的建议，先开启Netty的高级泄漏检测，这样能拿到具体的泄漏栈信息，帮你精准定位问题出在哪个模块。在初始化SparkSession的时候加上这些配置：

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .config("spark.driver.extraJavaOptions", "-Dio.netty.leakDetection.level=advanced") \
    .config("spark.executor.extraJavaOptions", "-Dio.netty.leakDetection.level=advanced") \
    .getOrCreate()

重新运行程序后，日志会输出详细的泄漏调用链，比如是S3客户端的连接没释放，还是Spark的文件系统处理逻辑有问题。

2. 升级Spark和Hadoop版本是最彻底的解决方案 #

这个ByteBuf泄漏问题很多是老版本的Spark或Hadoop AWS客户端的已知bug，比如Spark 2.x搭配Hadoop 2.8及以下版本时特别容易出现。建议直接升级到：

• Spark 3.0及以上版本
• Hadoop 3.2及以上版本
  新版本不仅修复了这类资源泄漏问题，还优化了S3读写的性能和稳定性，一举两得。

3. 调整S3相关的配置，减少资源泄漏概率 #

针对S3的读写特性，调整几个关键配置，能有效降低资源泄漏的风险：

spark = SparkSession.builder \
    .config("spark.hadoop.fs.s3a.connection.maximum", "100") \
    .config("spark.hadoop.fs.s3a.fast.upload", "true") \
    .config("spark.hadoop.fs.s3a.connection.timeout", "30000") \
    .getOrCreate()

• fs.s3a.connection.maximum：限制S3连接池的最大连接数，避免过多闲置连接占用资源
• fs.s3a.fast.upload：启用S3的多部分上传优化，缩短单个连接的持有时间
• fs.s3a.connection.timeout：设置连接超时时间，防止连接长期挂起不释放

4. 检查写入格式和压缩配置 #

你用到了自定义的trgFormat和trgCompression，有些小众的格式或压缩算法的实现可能存在资源泄漏问题：

• 尽量使用Spark内置的Parquet/ORC格式，避免第三方实现
• 压缩算法优先选Snappy、Gzip这类经过广泛测试的，避开一些冷门的压缩格式

5. 显式释放DataFrame资源 #

如果你的查询结果DataFrame比较大，Spark会自动缓存部分数据在内存里，写入完成后显式释放缓存能帮助回收相关资源：

df = sqlContext.sql(selectQuery)
df.write.mode("overwrite").format(trgFormat).option("compression", trgCompression).save(trgDataFileBase)
df.unpersist()  # 显式释放DataFrame的缓存资源

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