3. 数据资产盘点与分类：如何识别待下线资产、资产分类标准（热/温/冷数据）、优先级排序
好，咱们进入正题。数据资产下线，第一步不是动手删，而是先搞清楚——你到底有哪些资产？哪些该留？哪些该走？
我见过不少团队，上来就拍脑袋说“这个表三年没用了，删了吧”。结果删完第二天，财务对账系统崩了。为什么？因为那张表被一个定时任务悄悄引用着。所以，盘点与分类，是下线的“地基”。地基没打牢，后面全是坑。
3.1 如何识别待下线资产
说白了，就是给数据资产做“体检”。你得有一套标准，来判断哪些资产已经“生命垂危”。我个人习惯从三个维度入手：
- 访问频率：过去90天、180天、365天，有没有人读？有没有人写？
- 最后修改时间：ETL任务还在跑吗？数据还在更新吗？
- 依赖关系：有没有下游任务、报表、API在引用它？
嗯，这里要注意。很多工具只能看到“直接依赖”，但“间接依赖”才是杀手。我曾经遇到过一个案例：一张表看起来半年没人查，但它的数据被另一个视图引用，那个视图又被一个核心报表引用。如果直接下线那张表，整个报表链都会断掉。
我的小技巧： 在识别阶段，先拉一份“全量资产清单”，然后逐项打标。别信直觉，信数据。用元数据管理工具（比如Apache Atlas、DataHub）自动采集访问日志，比人工问“这表还有用吗”靠谱得多。
3.2 资产分类标准：热/温/冷数据
分类这事，不同公司有不同叫法。但核心逻辑是一样的：根据数据的“活跃度”来分层。我习惯用“热/温/冷”这个模型，简单直接。
| 分类 | 访问频率 | 更新频率 | 典型场景 | 下线策略 |
|---|---|---|---|---|
| 热数据 | 每天/每小时被访问 | 实时或准实时更新 | 在线交易、实时风控、用户行为分析 | 原则上不下线，只做归档或压缩 |
| 温数据 | 每周/每月被访问几次 | 定期更新（如每日跑批） | 月度报表、历史趋势分析、中间层宽表 | 评估是否可降级为冷存储，或合并到归档库 |
| 冷数据 | 超过90天无人访问 | 已停止更新 | 历史快照、过期日志、已废弃项目的中间表 | 优先进入下线候选清单 |
你想想看，这个分类标准其实是在回答一个问题：“如果我把这份数据删了，业务会疼吗？” 热数据删了，业务立刻停摆；温数据删了，月底报表出不来；冷数据删了……嗯，可能根本没人发现。
避坑指南： 我曾经遇到过“假冷数据”。一张表看起来半年没人查，但每年年底审计时，财务部门会手动跑一次查询。这种数据虽然“冷”，但有“硬性合规需求”。所以，分类不能只看技术指标，还要结合业务日历和合规要求。
3.3 优先级排序：先下谁，后下谁？
分类完了，你手里可能有一堆“冷数据”。但别急着全删。资源有限，你得排个优先级。我一般用“风险-收益”矩阵来排：
- 高收益 + 低风险：优先下线。比如那些明确无人使用、无依赖、无合规要求的过期数据。
- 高收益 + 高风险：谨慎处理。比如数据量很大但依赖关系复杂，需要先做依赖梳理。
- 低收益 + 低风险：可以批量处理。比如一些临时表、测试表，直接清理。
- 低收益 + 高风险：暂时不动。比如数据量小但被核心系统引用，动它不如不动。
为什么会这样？因为下线的本质是“减负”，不是“添乱”。如果为了省1TB存储，结果搞崩了一个核心报表，那得不偿失。
注意： 优先级排序时，一定要把“合规要求”放在最前面。有些数据即使没人用，但法律规定必须保留（比如金融交易日志、医疗记录）。这类数据不能下线，只能归档到合规存储中。
3.4 知识体系图：盘点与分类的核心逻辑
下面这张图，是我自己总结的“数据资产下线前盘点与分类”流程。你可以把它当作一个检查清单来用。
3.5 实操建议：从清单到行动
光有理论不行，我给你一个可以直接用的“下线候选清单”模板。每次做盘点时，按这个格式输出：
| 资产名称 | 分类 | 最后访问时间 | 依赖数量 | 合规要求 | 优先级 | 建议操作 |
|---|---|---|---|---|---|---|
| ods_order_log_2020 | 冷 | 2023-01-15 | 0 | 无 | 高 | 直接下线 |
| dwd_user_profile_v1 | 温 | 2024-03-10 | 3 | GDPR | 中 | 先梳理依赖，再归档 |
| tmp_etl_test_2024 | 冷 | 2024-06-01 | 0 | 无 | 高 | 直接清理 |
嗯，这个模板看起来简单，但实际用起来很有效。我建议你每季度做一次这样的盘点，把结果发给相关方确认。别自己闷头干，数据资产是大家的，下线也得大家同意。
最后说一句： 盘点与分类不是一次性工作。数据是活的，业务在变，合规要求在变。把“定期盘点”变成一种机制，而不是一次性的“运动式治理”。这样，你的数据资产才能一直保持健康。