中间表治理

维度三：产出状态。这张表的调度任务还在跑吗？最后一次产出数据是什么时候？任务是否已经暂停或下线？任务已经停了但表还在占存储的情况非常常见。

表资产分级治理

盘点完之后，把所有表分成四类：

等级	定义	处置方案
核心表	日常报表/接口依赖，有SLA要求	重点维护，有质量监控和告警
常规表	有下游使用，但不是核心链路	正常维护，定期Review
低频表	偶尔被查，但有保留价值	降低调度优先级，考虑冷存储
废弃表	90天无查询、无下游、无产出	走下线流程，回收存储

废弃表下线流程

直接删太危险，要有流程：

第一步：标记（Deprecated）。给疑似废弃的表打标记，加到表注释里。比如「[DEPRECATED 2025-01-15] 原用户分析临时表，已被dws_user_wide替代。计划2025-02-15下线。」

第二步：通知（至少两周）。在团队群/文档里公告：以下XX张表标记为废弃，计划于XX日下线，如有使用请反馈。实际操作中90%不会有人反馈，但这两周缓冲期非常重要——万一有个季度跑一次的任务正好依赖这张表。

第三步：软删除（移到回收站）。不直接DROP，先改名移到回收站schema保留30天。这期间如果有人发现需要，可以快速恢复。

第四步：物理删除。30天后无人认领，执行DROP释放存储。

预防中间表泛滥

治理是治标，预防才是治本：

① 命名约束：tmp表必须带日期后缀（tmp_user_analysis_20250115），可以配置自动策略：tmp_开头且超过30天的表自动进入下线流程。

② 审批机制：在非tmp命名空间建表需要审批，避免随意建表污染正式库。

③ 定期巡检：每月跑一次表资产盘点脚本，自动输出报告——本月新增表、废弃表候选、存储Top10表、90天零查询表。

④ 成本归因：把存储成本分摊到团队/个人。当你发现自己建的tmp表每月烧了500块，就会主动清理了。

面试加分提示 这题体现的是你的数据资产管理意识，属于中高级岗位的加分项： 「我在接手数据组时做过一次全量表盘点。600多张表里有效的只有三分之一，400张是tmp表、废弃表和重复建设。我做了三件事：第一，建立表分级机制，把核心表、常规表、低频表、废弃表区分开；第二，对废弃表走标记→通知→软删除→物理删除的四步流程，两个月下线了150张表，释放了约2TB存储；第三，制定预防措施，tmp表强制带日期后缀且30天自动清理，非tmp建表需要审批。」 关键：有数字（600张/150张/2TB）+ 有流程 + 有预防。