Spark SQL的DROP PARTITION仅删除元数据，不删除底层文件；真正删数据需先删文件再删元数据，顺序不可颠倒。
直接删元数据不等于删数据，Spark SQL 的 DROP PARTITION 只移除 Hive Metastore 中的分区记录，底层文件（如 HDFS/S3 上的目录）仍存在——这是最常被忽略的风险点。
用 ALTER TABLE ... DROP PARTITION 清理元数据
这是最快、最轻量的方式，适用于你确认底层存储已同步清理，或后续会统一走文件系统级清理流程的场景。
- 语法必须严格匹配分区列名和值格式，例如分区列为
dt且值为字符串'20240925'，写成dt='20240925'；若值含单引号（如'2024-09-25'），需转义为dt='2024-09-25'（Spark 通常自动处理，但 Hive 兼容模式下建议加双引号包裹整个条件） - 支持批量删除多个分区，用逗号分隔：
ALTER TABLE my_table DROP IF EXISTS PARTITION (dt='20240925'), PARTITION (dt='20240926') - 务必加
IF EXISTS，否则遇到不存在的分区会抛出org.apache.spark.sql.AnalysisException - 执行后立即生效于元数据，但
DESCRIBE FORMATTED my_table仍可能短暂显示旧分区信息（缓存延迟），建议刷新：执行REFRESH TABLE my_table
用 MSCK REPAIR TABLE 同步元数据与文件系统
当你手动删了 HDFS/S3 上的分区目录，但 Metastore 还没更新时，这个命令能自动发现并注册新增分区——但它不会删除元数据中存在但文件已丢失的分区。所以它不能替代 DROP PARTITION，而是补位工具。
- 只对 Hive 风格的分区路径有效（如
/path/to/table/dt=20240925/），且要求路径命名严格符合key=value格式 - 执行前确保 Spark 已配置
spark.sql.hive.convertMetastoreParquet=false（默认为 true），否则可能跳过非原生 Parquet 表的修复 - 它是一次性全量扫描，表分区数超万时会明显变慢，不建议高频调用
绕过 SQL、直删底层文件再同步元数据
真正“删数据”的唯一可靠方式：先删文件，再删元数据。否则 DROP PARTITION 后，文件残留可能被新任务误读（尤其当使用 INSERT OVERWRITE 且未指定分区时）。
- 用 Spark 自带的
spark.sparkContext.hadoopConfiguration调用 Hadoop FileSystem API 删除路径，例如：fs.delete(new Path("hdfs://nn:8020/path/to/table/dt=20240925"), true) - 删除 S3 时注意：S3 不是文件系统，
delete()是模拟操作，实际发 DELETE 请求，需确认 IAM 权限含s3:DeleteObject - 删完文件后，再执行
ALTER TABLE ... DROP PARTITION——顺序不能反，否则元数据删除后，文件变成“幽灵数据”，无法通过常规 SQL 管理 - 如果表是外部表（
CREATE EXTERNAL TABLE），Spark 不会自动管理文件生命周期，这一步必须人工介入
为什么不用 INSERT OVERWRITE 过滤重写？
看似通用，实则高风险：它会重写整个表或全部分区，不是“删”，而是“重建”。对大表来说，I/O 和计算开销巨大，且期间表不可用（OVERWRITE 是原子替换，但写入过程占用资源）。
- 仅适用于小表（GB 级以下）或离线维护窗口充足场景
- 必须显式指定
PARTITION子句，否则会覆盖全表：INSERT OVERWRITE TABLE my_table PARTITION (dt) SELECT * FROM my_table WHERE dt NOT IN ('20240925', '20240926') - 若原表有复杂分区结构（多级分区如
dt=20240925/hour=12），WHERE 条件必须覆盖所有层级，漏写会导致部分数据意外保留
真正要删数据，就得承认：Spark SQL 本身不负责文件物理删除。元数据操作快，但只是“撕标签”；文件操作慢，但才是“清垃圾”。两者缺一不可，且顺序不能错——这是线上环境踩坑最多的地方。
