通过Zeppelin查询Glue Data Catalog表时出现缓存报错

该异常是Spark侧缓存的数据源元数据与Glue Data Catalog更新后的实际S3文件信息不一致导致：

• Spark查询过表/分区后，会默认缓存分区路径、S3文件eTag、数据块偏移量等元数据。当实时任务覆盖写对应分区的parquet文件、同步更新Glue分区信息后，Spark执行计划仍持有旧版本文件的eTag和偏移量，访问S3时文件校验不通过就会抛出该异常
• 偶发可通过重试恢复的原因是：部分查询未命中旧缓存、或任务重试时触发了局部元数据重拉，拿到了最新的文件信息就可以正常执行；手动执行refresh table <table_name>、重启解释器本质都是强制清空缓存，所以能临时恢复，但没有解决元数据自动同步的问题。

按落地成本、效果优先级排序，不需要采用全表定时刷新的低效方案：

1. 配置层自动元数据同步（无业务侵入，最优方案） #

调整Spark配置，从机制上避免元数据长期不一致，不需要额外开发逻辑：

• 配置元数据缓存自动过期：设置spark.sql.metadataCacheTTLSeconds=300（数值可根据自身分区更新频率调整，分区更新越频繁值设得越小，建议不低于60秒避免Glue接口压力过大），超过TTL的元数据会自动重新拉取，不会长期使用旧缓存
• 配置分区级TTL：设置spark.sql.hive.metastore.partitionTTL=300s，配合spark.sql.hive.manageFilesourcePartitions=true，只对过期的分区重拉元数据，比全量清缓存性能损耗小很多
• 配置任务自动重试兜底：设置spark.task.maxFailures=3，遇到文件拉取失败时任务会自动重试，重试过程会重新拉取对应文件的最新元数据，大部分偶发不一致问题可以自动恢复，不需要人工处理
• 注意：不要关闭S3 eTag校验，会导致读到损坏/未写完的文件，引发数据正确性问题。

2. 精准分区刷新（适合有明确分区更新链路的场景） #

如果分区更新是由己方实时/离线任务触发，不要定时刷全表，只在分区写入完成后刷新对应单分区即可，开销仅为全表刷新的1%不到：

• 分区数据写入、Glue分区信息更新完成后，执行REFRESH TABLE <库名>.<表名> PARTITION (<分区列名>=<分区值>)，仅清空刚更新的单分区缓存，不影响其他正常分区的缓存命中率
• 如果是Spark Structured Streaming写分区，可以直接在foreachBatch钩子中嵌入该刷新逻辑，写完立刻同步刷新，查询侧完全无感知。

3. 临时故障处理 #

遇到偶发报错时，优先执行单分区刷新语句，不要直接全表refresh或者重启Spark解释器，避免清空全量缓存引发整体查询延迟飙升。

• 定时全量刷新所有表：会清空所有表的元数据缓存，后续所有查询都要重新拉取Glue、S3元数据，集群计算压力、Glue接口压力都会陡增，查询性能会明显下降，资源浪费严重
• 完全关闭Spark元数据缓存：所有查询都实时请求Glue、S3拉取元数据，整体查询性能会下降30%以上，高并发场景下极易触发Glue接口限流，反而引发更多故障。

内容的提问来源于stack exchange，提问作者Oliver Sepúlveda