1. 数据资产下线概述
大家好，我是老张。做数据治理这些年，踩过不少坑，也填过不少坑。今天咱们聊聊数据资产下线——这个听起来简单、做起来全是雷的活儿。
先问个问题：你手头有多少张表、多少个接口、多少套报表，是三年没人碰过的？我猜不少。我见过最夸张的项目，一个数仓里躺着 40% 的“僵尸表”，没人敢删，也没人说得清它们是干嘛的。
1.1 什么是数据资产下线
说白了，就是把不再需要的数据资产，从生产环境里安全地移除掉。注意“安全”两个字——不是直接 drop table 就完事了。
数据资产下线包括但不限于：
- 表下线——物理表、视图、中间表
- 任务下线——ETL 脚本、调度任务、数据管道
- 接口下线——数据 API、数据服务
- 报表下线——BI 看板、固定报表、数据产品
- 模型下线——机器学习特征、算法模型
核心原则：下线不是删除，是“从可用状态变为不可用状态，并保留可回溯能力”。
我习惯把下线分成三个阶段：识别→执行→验证。每个阶段都有坑，后面咱们慢慢聊。
1.2 为什么需要下线
你可能会想：“放着就放着呗，又不占地方。”嗯，真不是这么回事。
我经历过一个真实案例：某金融客户，数仓里 2000+ 张表，实际活跃的不到 600 张。剩下的 1400 张表，每年光存储成本就烧掉 80 多万。更可怕的是，有一次新同事误把一张“废弃表”当成了源表，跑了一周的数据，全废了。
所以，为什么要下线？我总结了几点：
| 维度 | 具体问题 | 不处理的后果 |
|---|---|---|
| 成本 | 存储、计算、运维资源浪费 | 每年多花几十万到上百万 |
| 安全 | 废弃资产可能包含敏感数据 | 数据泄露风险、合规审计不通过 |
| 效率 | 数据目录混乱，找表像大海捞针 | 开发效率下降，新人上手慢 |
| 质量 | 废弃表被误引用，产生脏数据 | 报表出错、决策失误 |
| 治理 | 资产生命周期不完整 | 治理成熟度低，无法通过数据管理认证 |
避坑指南：我曾经在一个项目里，直接删了一张“看起来没人用”的表。结果第二天业务方炸了——那张表是季度报表的中间结果，虽然平时没人查，但季度末必须跑。从那以后，我定了个规矩：下线前必须做至少一个完整周期的依赖分析。
1.3 下线的业务驱动与技术驱动
数据资产下线，从来不是技术团队自己拍脑袋就能干的事。它背后有两股力量在推：
业务驱动
业务方才是下线的“第一发起人”。常见场景：
- 业务变更——产品线调整、业务规则变化，旧报表不再需要
- 系统迁移——从旧系统换到新系统，老数据源要下线
- 合规要求——数据保留期限到了，必须销毁（比如 GDPR、个人信息保护法）
- 成本优化——业务部门预算压缩，主动要求清理冗余资产
我记得有个电商客户，每年双十一后会清理一批“活动专用表”。这些表平时根本用不上，但占着大量存储。业务方主动提需求，我们配合做下线，双方都很顺畅。
技术驱动
技术侧的下线，更多是“被动发现”的。我常用的方法：
- 血缘分析——跑一遍全链路血缘，找出没有下游依赖的“孤岛表”
- 访问审计——查过去 90 天、180 天的访问日志，零访问的表标记为“待下线”
- 存储分析——按存储大小排序，TOP 10 的大表如果没人用，优先处理
- 任务依赖——检查调度系统，没有任务依赖的表可以下线
小技巧：我习惯在数仓里建一张 asset_lifecycle_meta 表，记录每张表的“最后访问时间”“最后修改时间”“下游依赖数”。每个月跑一次，自动生成“待下线清单”。这样就不用每次都手动查了。
业务驱动和技术驱动，其实是两条腿走路。业务方知道“要不要”，技术侧知道“能不能”。两者对齐了，下线才能安全落地。
1.4 知识体系总览
下面这张图，是我自己梳理的数据资产下线知识框架。你可以把它当成整个课程的“地图”：
这张图里，我把驱动因素分成了三类：业务、技术、合规。后面每个章节，都会围绕这些维度展开。你可能会发现，有些场景是多个驱动叠加的——比如“合规要求”往往同时是业务需求和技术改造。
好了，第一章就聊到这儿。记住一句话：数据资产下线，不是“要不要做”的问题，而是“怎么做才安全”的问题。后面咱们一步步拆解。