Spark SQL复用表名时出现陈旧表缓存问题排查

疑问1：脚本继续运行是否意味着Spark已刷新缓存并重试任务，最终失败任务已完成？ #

是的。Spark任务调度自带容错机制，当单个Task因文件不存在抛出FileNotFoundException时，只要不是整个Job依赖完全缺失的致命错误，Spark会自动重试该Task（默认重试次数由spark.task.maxFailures控制，默认是4次）。如果重试时，新表的文件已经创建完成，Task就能正常读取数据完成执行，所以整个脚本会继续运行。

但要注意：这类警告说明存在执行时序问题，虽然最终任务能完成，但会有部分Task重复执行，造成不必要的资源浪费，长期运行会积累额外开销。

疑问2：为何显式删除表仍会触发该警告？ #

核心原因是Spark的执行计划异步性和元数据/缓存不一致，具体细节：

• 惰性执行导致时序混乱：Spark的SQL语句是延迟执行的，你写的DROP TABLE、CREATE TABLE AS SELECT并不会立即执行，而是先转换成逻辑计划，直到遇到Action操作（比如count()、show()或后续依赖该表的操作）才会触发实际运行。这就可能出现：前一阶段依赖旧AiTemp表的Task还在排队执行，你已经执行了DROP TABLE删掉了HDFS上的文件，此时Task去读取就会报文件不存在。
• 元数据缓存未及时更新：就算显式执行了DROP TABLE，Spark Catalog的元数据缓存（包括Driver和Executor端）可能没同步刷新。Executor可能还保留着旧表的文件路径缓存，Task执行时还是会指向已被删除的旧文件。
• UNCACHE TABLE的局限性：UNCACHE TABLE只会清除Spark内存中缓存的表数据，无法清理Executor端持有的文件路径元数据，也解决不了执行计划异步带来的时序问题。拆分CREATE TABLE AS为CREATE TABLE LIKE+INSERT INTO只是改变了表的创建方式，没触及核心问题。

可行解决方案 #

• 强制触发执行计划落地：在DROP TABLE之后、CREATE TABLE之前，加一个Action操作强制前面的删除逻辑执行完毕，比如执行spark.sql("SELECT 1").collect()，或者调用spark.catalog.clearCache()清除所有缓存。
• 避免重复复用表名：改用带版本号或时间戳的表名（比如AiTemp_20240520_1430），从根源上杜绝旧文件路径被重复引用的问题。
• 强制刷新元数据：执行DROP TABLE后，调用spark.catalog.refreshTable("AiTemp")（即使表已删除，也能强制Catalog刷新元数据，避免旧路径残留）；如果环境允许，可设置spark.sql.catalogImplementation=hive，借助Hive Catalog更及时的元数据同步能力。
• 调整并行度减少冲突：如果是Task并行执行导致的时序重叠问题，适当降低任务并行度，减少旧Task和新表创建操作的同时运行概率。

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