AWS Glue表异常丢失 Pyspark保存表触发Py4JJavaError问题咨询

该异常由Glue数据目录与Lake Formation的元数据同步断裂导致：Spark使用Overwrite模式写Glue表时会先触发删表逻辑，若该步骤的事务中途中断，会导致表的可见性索引标记被移除，但实际元数据条目仍残留在数据目录中，最终出现"可通过get-table/直接URL访问、可查询，但控制台搜索不到、删除时报EntityNotFoundException"的不一致状态。首次出现的Spark断言错误，就是Spark确认表已删除的校验逻辑和残留的元数据冲突导致的。

• 首先验证元数据残留状态：执行aws glue get-table --database-name <目标库名> --name <目标表名>，检查返回参数中IsRegisteredWithLakeFormation字段状态、Parameters下的Spark源配置是否完整，同时确认返回结果中DatabaseName是否和你操作的库完全一致（存在跨库同名表缓存导致的异常案例）。
• 校验Lake Formation权限同步状态：执行aws lakeformation list-permissions --resource-type table --resource '{ "DatabaseName": "<目标库名>", "Name": "<目标表名>" }'，如果能返回权限记录但Glue控制台不可见，可确认是双系统元数据不同步问题。
• 确认表对应S3路径的所有权：检查S3路径下的对象ACL是否归属当前AWS账号，若路径被跨账号写入对象，Glue目录遍历会自动跳过该表，也会触发同类隐藏现象。
• 核对Spark写入配置：确认你使用的EMR版本是否低于6.x，低版本EMR中spark.sql.sources.partitionOverwriteMode=dynamic和saveAsTable的Overwrite模式同时使用时，有极高概率触发元数据写入事务中断。

• 优先使用批量删除接口清理残留：单表删除接口的元数据校验逻辑更严格，很多时候批量删除接口可绕过校验清理残留，执行命令：aws glue batch-delete-table --database-name <目标库名> --tables-to-delete <目标表名>。
• 若批量删除仍失败：先在Lake Formation控制台给当前操作用户授予该表的Super权限，再执行删除操作；如果还是报错，先执行aws lakeformation deregister-resource --resource-arn arn:aws:s3:::<表对应的S3路径>解绑资源，再执行删表操作。
• 极端情况的修复方案：创建一张和原表结构、分区完全一致的临时表，执行CREATE TABLE <目标库名>.<目标表名> LIKE <目标库名>.<临时表名>补全缺失的元数据索引，之后即可正常删除该表。
• 后续规避方案：避免直接使用saveAsTable的Overwrite模式写Glue表，改为先删除目标分区再写入，或使用insertInto配合动态分区覆写，减少整表Overwrite触发的元数据事务风险。

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