表越来越多、存储成本爆炸，你怎么管理表的生命周期？
先说结论
表生命周期管理的核心是两件事：分层设置保留策略 和 自动清理僵尸表。前者控制数据的留存时间，后者清理不再使用的表。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据治理里表生命周期管理是被低估的能力。我待过的每家公司都有同样的问题：Hive里有上千张表，但真正有人用的可能只有几百张。剩下的表每天在耗费计算资源和存储资源，没人管。今天把我在出海硬件公司建设的表生命周期管理体系讲清楚。
分层保留策略
不同层次的表，数据价值和重建成本不同，保留时间也不同：
| 层次 | 保留时间 | 原因 |
|---|---|---|
| ODS（原始层） | 30天 | 原始数据可以从源系统重新拉取，不需要长期保留 |
| DWD（明细层） | 90天 | 明细数据体量大，保疐90天足够覆盖多数回溯场景 |
| DWS（汇总层） | 1-2年 | 汇总数据体量小，历史对比价值大 |
| ADS（报表层） | 永久或按需 | 报表数据体量最小，保留成本极低 |
实现方式：自动分区清理作业
-- 每天执行的分区清理脚本（以ODS层保疐30天为例）
ALTER TABLE ods_user_event
DROP IF EXISTS PARTITION (dt < '${30天前的日期}');
-- 在Databricks里更简单
VACUUM ods_user_event RETAIN 720 HOURS; -- Delta Lake的清理命令我在出海硬件公司把这个逻辑写成了一个通用的清理作业，读取一张配置表（记录每张表的保留策略），每天自动执行。不需要每张表单独写清理逻辑。
僵尸表自动发现和清理
“僵尸表”就是没人用但仍在消耗资源的表。我建了一个监控机制：
第一步：采集查询日志 从Hive MetaStore或平台审计日志中提取每张表的最后查询时间。
第二步：标记僵尸表 超过30天没有被查询过的表标记为“僵尸表”。
第三步：通知负责人确认 发通知给表的owner，确认是否可以删除。给一周的确认期，超时无回复则自动删除。
效果：上线半年后，清理了200+张僵尸表，释放了20TB存储空间，每月节省了约3000美元的AWS存储费用。
实战踩坑：谁来定表的owner？
僵尸表清理最难的不是技术，而是“谁负责这张表”。很多表创建的时候没有标注owner，人员离职后没人接手。
我的做法是：建表时必须填写owner和用途说明，否则不允许建表。这个规矩在DataWorks和Databricks里都可以通过元数据管理强制执行。
总结
表生命周期管理的核心：分层设置保留策略 + 僵尸表自动清理 + 建表必须标注owner。面试时能说清楚这套体系和具体效果（清理200+表、节省存储费用），说明你不只是写ETL的，还有治理思维。
下一篇聊一个我最有成就感的项目：1000+埋点事件精简到100+，我是怎么做埋点治理的？
你们公司有清理僵尸表的机制吗？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长