3、数据分类与分级：数据分类方法、数据分级标准、基于分类分级的删除策略
3.1 数据分类方法——先分堆，再干活
数据分类，说白了就是给数据贴标签。我刚开始做数据治理那会儿，最头疼的就是面对一堆乱七八糟的数据，不知道从哪下手。
后来我总结了一套方法，核心就一句话：按业务属性分堆。
常见的分类维度有这么几种：
- 按数据来源：业务系统数据、日志数据、外部接口数据、人工录入数据
- 按数据内容：客户信息、交易记录、产品数据、财务数据、运维日志
- 按数据形态：结构化数据、半结构化数据（JSON/XML）、非结构化数据（文档/图片）
- 按数据生命周期：热数据、温数据、冷数据、归档数据
我个人习惯用业务域+数据主题的组合方式。举个例子，在金融行业，我会分成「客户域」「账户域」「交易域」「产品域」等。每个域下面再细分主题，比如客户域下面有「客户基本信息」「客户风险画像」「客户行为偏好」。
我的经验：分类别搞太细。我曾经在一个项目里分了50多个类别，结果运维同事根本记不住，最后全堆在「其他」里。建议控制在10-15个一级分类，每个一级分类下不超过5个二级分类。
3.2 数据分级标准——定级别，定生死
分类是分堆，分级是定优先级。数据分级决定了：哪些数据该删，哪些数据打死不能删。
我常用的分级标准是四级制，你想想看，这跟安全等级差不多：
| 级别 | 名称 | 定义 | 示例 |
|---|---|---|---|
| L4 | 核心数据 | 泄露或丢失会导致重大业务中断或法律风险 | 客户身份证号、银行卡号、交易流水 |
| L3 | 重要数据 | 泄露或丢失会造成较大影响，但可恢复 | 用户联系方式、订单记录、合同文件 |
| L2 | 一般数据 | 泄露或丢失影响有限，可容忍 | 操作日志、系统配置、缓存数据 |
| L1 | 临时数据 | 无业务价值，丢失无影响 | 临时文件、重复备份、过期缓存 |
嗯，这里要注意：分级不是一成不变的。数据会随着时间贬值。比如一条交易记录，刚产生时是L3，过了3年可能就降到L2，过了5年可能直接变成L1。
避坑指南：我曾经在一个项目中，把所有客户数据都标成了L4。结果导致删除策略完全无法执行——谁也不敢删。后来我们引入了「时间衰减因子」，让数据级别随着保存年限自动降级，这才把删除流程跑通。
3.3 基于分类分级的删除策略——该删就删，该留就留
有了分类和分级，删除策略就变得清晰了。说白了就是一张决策表：
| 数据分类 | 数据分级 | 保留期限 | 删除方式 | 是否需要审批 |
|---|---|---|---|---|
| 客户信息 | L4 | 永久保留 | 不删除，仅标记归档 | — |
| 交易记录 | L3 | 5年 | 物理删除+备份保留 | 需要 |
| 操作日志 | L2 | 1年 | 逻辑删除，30天后物理删除 | 不需要 |
| 临时缓存 | L1 | 7天 | 直接物理删除 | 不需要 |
我建议的策略是「三阶段删除」：
- 标记阶段：数据到期后，先打上「待删除」标记，保留30天。这期间如果发现误判，还能抢救回来。
- 逻辑删除阶段：标记满30天后，数据从业务表中移除，但保留在归档表中。此时数据对业务不可见，但DBA还能恢复。
- 物理删除阶段：逻辑删除满90天后，执行物理删除（TRUNCATE或DROP）。这一步不可逆，务必确认。
核心原则：
- L4数据：只归档，不删除
- L3数据：到期后走完整三阶段
- L2数据：走逻辑删除+物理删除，跳过标记阶段
- L1数据：直接物理删除，不留情面
你可能会问：那分类分级怎么落地到自动化脚本里？其实很简单，在数据表里加两个字段就行：
-- 给每张表加上分类分级标签
ALTER TABLE data_catalog ADD COLUMN data_category VARCHAR(50);
ALTER TABLE data_catalog ADD COLUMN data_level INT;
ALTER TABLE data_catalog ADD COLUMN retention_days INT;
ALTER TABLE data_catalog ADD COLUMN delete_strategy VARCHAR(20);
-- 示例：配置一条删除策略
INSERT INTO data_catalog (table_name, data_category, data_level, retention_days, delete_strategy)
VALUES ('order_detail', '交易记录', 3, 1825, 'three_phase');自动化脚本每天跑一次，扫描所有表，根据retention_days和delete_strategy字段，自动执行对应的删除操作。嗯，这就是我常说的「配置驱动删除」——不用改代码，改配置就行。
一个小技巧：我习惯在删除脚本里加一个
--dry-run参数。上线前先跑一遍模拟模式，看看哪些数据会被删，确认无误后再切到正式模式。这招帮我避免过好几次误删事故。
最后说一句：分类分级不是一次性的工作。业务在变，数据在变，你的分类分级标准也得跟着变。我建议每半年review一次，看看有没有新的数据类别出现，有没有旧的类别需要合并。只有这样，你的删除策略才能一直保持有效。