设置fs.hdfs.impl.disable.cache解决Hadoop故障后SparkSQL变慢，是否正常？

哥们儿，咱们把这个问题拆解开唠明白：

为什么fs.hdfs.impl.disable.cache=true能解决移动文件的故障？ #

你碰到的“无法移动源文件...文件系统已关闭”问题，本质是共享的HDFS客户端实例被意外关闭导致的。默认情况下，Hadoop会缓存全局的HDFS客户端实例，多个线程、任务都会复用这个实例。如果某个任务（比如自定义代码的不当操作、组件bug）错误关闭了这个共享客户端，其他任务再调用它时就会触发报错。

当你设置fs.hdfs.impl.disable.cache=true，相当于直接禁用了这个共享缓存——每个需要访问HDFS的任务都会创建全新的独立客户端实例，彼此互不干扰，自然就不会出现“被别人关闭”的问题，故障也就消失了。

为什么SparkSQL查询会变慢？ #

这就是典型的“解决一个问题，引入另一个问题”：

• 默认的HDFS客户端缓存核心作用是避免重复创建客户端的开销。创建HDFS客户端可不是轻量操作，要建立连接、加载配置、做权限校验、初始化各类状态，这些步骤本身就要消耗几秒到十几秒。
• 禁用缓存后，哪怕是读取小表的简单SparkSQL查询，每次执行都得重新走一遍创建客户端的流程。原本查询逻辑本身只需要几百毫秒，现在加上创建客户端的几十秒耗时，整体查询速度自然被拉垮了。

给你的优化建议 #

别把这个参数当长期解决方案，毕竟性能损失太严重，建议从这几个方向着手：

• 排查根本故障原因：检查有没有自定义UDF/业务代码错误关闭了HDFS客户端？或者当前Spark与Hadoop版本存在兼容性bug？部分老版本Hadoop确实存在客户端缓存被意外释放的问题，升级版本可能直接解决。
• 用缓存参数替代禁用：可以尝试设置fs.hdfs.impl.cache.expiry参数（单位为毫秒），给缓存的客户端设置合理的过期时间，既避免长期复用引发的意外关闭问题，又能保留缓存带来的性能优势。
• 临时缓解小查询性能：可以开启Spark的元数据缓存，设置spark.sql.hive.metastore.cache.expiry（比如设为3600秒），减少重复访问Hive元数据的开销，但这只是治标，核心还是要解决HDFS客户端被意外关闭的根本问题。

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