下线流程是什么
模型下线是把不再使用或已被替代的表从数仓里安全移除的治理流程：先评估引用范围（血缘 + 查询审计），再通知使用方并把写权限收回转只读，经过观察期确认没有引用后归档删除。它的核心逻辑是「先证明没人用，再动手」，而不是等删掉之后看谁报错。僵尸表长期占用存储与调度资源，还会让新同事误用早已废弃的口径。
基本信息
| 评估手段 | 字段级血缘 + 近 N 天查询审计 |
|---|---|
| 冻结方式 | 收回写权限，转只读 |
| 观察期 | 通常 30 到 90 天 |
| 收尾动作 | 归档留存 + 删除 + 台账登记 |
典型使用场景
- 版本替代：v2 表上线稳定运行后回收 v1 表，避免两套口径并存
- 重复建设合并：两个团队各建了一份订单宽表，合并后下线冗余那份
- 业务过程废弃：老系统退场，对应的 ODS 到 DWD 链路整体下线
- 合规要求：主体已注销或数据超期，需要删除或归档相关明细表
- 成本治理：清理长期无查询、无调度的僵尸表，释放存储与计算资源
下线前的引用与访问检查
下线前的引用与访问检查
-- 1) 血缘：找出所有下游任务与表，生产上应查血缘平台，别只搜 SQL 文本
SELECT * FROM meta_lineage WHERE upstream_table = 'dwd_order_old';
-- 2) 近 90 天查询审计：没有任何记录才允许进入冻结期
SELECT table_name, count(1) AS q_cnt, max(query_time) AS last_q
FROM audit_query_log
WHERE table_name = 'dwd_order_old'
AND query_time > date_sub(current_date, 90)
GROUP BY table_name;
-- 3) 冻结首日收回写权限，让隐性写入任务主动暴露出来冻结期动作节奏
| 阶段 | 动作 | 判定标准 |
|---|---|---|
| T+0 | 收回写权限，转只读 | 有写入任务报错说明存在隐性引用 |
| 观察期内 | 发布公告并跟踪访问 | 出现新访问则暂停下线 |
| 观察期结束 | 归档结构与数据 | 归档可恢复性已验证 |
| 之后 | 删除在线表并登记台账 | 保留归档路径与责任人 |
只读冻结是整条流程里最关键的一步：它会主动让隐性写入任务报错，比人工比对血缘表可靠得多。
删除前确认归档真的可恢复：建表 DDL、数据文件、权限设置、恢复责任人四项齐全，否则等于永久删除。