3、数据资产分类与分级：业务分类法、技术分类法、数据敏感度分级（L1-L4）
数据资产分类与分级，说白了就是给数据「上户口」和「定密级」。
我见过太多团队，一上来就搞大数据平台，结果数据湖变成了数据沼泽。为什么？因为没人知道哪些数据重要，哪些数据敏感，哪些数据可以随便用。嗯，这就是我们今天要解决的问题。
3.1 业务分类法：从业务视角给数据贴标签
业务分类法，核心是回答「这个数据属于哪个业务领域」。我个人习惯，先画业务全景图，再往下拆。
核心原则：业务分类必须与企业的价值链对齐。脱离业务场景的分类，都是自嗨。
3.1.1 一级分类：按业务域划分
我建议按以下维度进行一级分类：
- 客户域：客户基本信息、客户画像、客户行为、客户评价
- 产品域：产品目录、产品定价、产品库存、产品生命周期
- 交易域：订单数据、支付数据、退款数据、结算数据
- 营销域：活动数据、渠道数据、投放数据、转化数据
- 供应链域：采购数据、物流数据、仓储数据、供应商数据
- 财务域：预算数据、成本数据、收入数据、报表数据
- 人力域：员工信息、组织架构、考勤数据、薪酬数据
我在项目中遇到过，某零售企业把「会员积分」归到了财务域，结果营销部门每次取数都要走财务审批，效率极低。后来改到客户域，问题迎刃而解。
3.1.2 二级分类：按业务过程细化
一级分类定方向，二级分类定场景。举个例子：
| 一级分类 | 二级分类 | 典型数据实体 |
|---|---|---|
| 客户域 | 客户基本信息 | 客户主数据、联系方式、证件信息 |
| 客户域 | 客户行为 | 浏览记录、点击日志、搜索关键词 |
| 客户域 | 客户评价 | 评分数据、评论内容、投诉记录 |
| 交易域 | 订单数据 | 订单头、订单行、订单状态变更 |
| 交易域 | 支付数据 | 支付流水、支付渠道、退款记录 |
小技巧：二级分类不要超过3层。超过3层，业务人员就记不住了，分类就变成了摆设。
3.2 技术分类法：从技术视角给数据定性
技术分类法，回答的是「这个数据长什么样、怎么存、怎么用」。你想想看，同样的客户姓名，在OLTP库、数据仓库、日志文件里，处理方式能一样吗？
3.2.1 按数据结构分类
- 结构化数据：关系表、CSV文件。有固定schema，SQL一把梭。
- 半结构化数据：JSON、XML、YAML。schema灵活，但仍有规律。
- 非结构化数据：文本、图片、音视频。没有固定格式，处理最头疼。
我记得有一次，业务方说「我们数据都在Excel里」，结果打开一看，一个单元格里塞了5000字的JSON。这就是典型的「自以为结构化」的坑。
3.2.2 按数据时效性分类
| 分类 | 定义 | 典型场景 |
|---|---|---|
| 实时数据 | 秒级/毫秒级延迟 | 风控、实时大屏、推荐系统 |
| 准实时数据 | 分钟级延迟 | 交易对账、库存同步 |
| 批量数据 | T+1或更长周期 | 报表、BI分析、模型训练 |
| 静态数据 | 几乎不变 | 字典表、配置数据、历史归档 |
3.2.3 按数据生命周期分类
我个人习惯把数据分为：
- 热数据：频繁访问，需要高性能存储（如SSD、内存）
- 温数据：偶尔访问，可以放普通磁盘
- 冷数据：几乎不访问，归档到廉价存储或磁带
- 冰数据：合规保留，但永远不会被业务访问
避坑指南：我曾经见过一个团队，把所有数据都放在SSD上，成本高得离谱。后来一分析，80%的数据是冷数据，根本没必要。分类对了，存储成本能降60%。
3.3 数据敏感度分级：L1-L4
数据分级，核心是回答「这个数据泄露了会怎样」。这不是IT部门拍脑袋定的，而是合规、业务、安全三方一起定的。
3.3.1 分级标准
| 级别 | 名称 | 定义 | 典型数据 |
|---|---|---|---|
| L1 | 公开数据 | 泄露后无影响或影响可忽略 | 产品名称、公开价格、公司介绍 |
| L2 | 内部数据 | 泄露后造成轻微影响 | 内部流程文档、非敏感报表 |
| L3 | 敏感数据 | 泄露后造成较大影响 | 客户联系方式、交易记录、员工薪资 |
| L4 | 高度敏感数据 | 泄露后造成严重合规/声誉风险 | 身份证号、银行卡号、医疗记录、生物特征 |
3.3.2 分级管控策略
不同级别，管控力度完全不同：
- L1：无需审批，全员可访问，可对外发布
- L2：需内部认证，禁止外传，默认脱敏展示
- L3：需业务Owner审批，加密存储，访问留痕
- L4：需双人审批，加密+脱敏，严格审计，禁止导出
关键点：分级不是一成不变的。同一个数据，在不同场景下级别可能不同。比如「客户手机号」，在客服场景是L3，在营销场景可能需要脱敏到L2。
3.4 分类分级的落地框架
说了这么多，怎么落地？我画了一张图，把整个逻辑串起来。
3.5 实操建议：如何快速启动
很多团队一上来就想把全公司的数据都分类分级，结果搞了半年还没出成果。我建议：
- 先做核心域：挑2-3个最核心的业务域（比如客户域、交易域）先做，跑通流程
- 用80/20法则：先覆盖80%的高频数据，剩下的20%慢慢补
- 工具辅助：用数据目录工具（如Apache Atlas、Collibra）自动扫描和打标
- 持续迭代：分类分级不是一次性工程，每季度review一次
我的经验：启动阶段，别追求完美。先让业务Owner认领自己的数据，打上粗粒度的标签。有了第一版，后面就好改了。最怕的是「等我们想清楚了再做」——永远等不到那一天。
3.6 常见误区
- 误区一：分类分级是IT的事——错！业务Owner必须参与，否则分类没人认
- 误区二：级别越高越好——L4数据管控成本极高，过度定级反而影响业务效率
- 误区三：一次搞定——业务在变，数据在变，分类分级必须动态调整
- 误区四：忽略技术分类——只做业务分类不做技术分类，存储和计算策略没法落地
我曾经踩过的坑：某次项目，我们把所有客户数据都标成了L4，结果业务方每次取数都要走三天审批，直接影响了营销活动的上线速度。后来重新梳理，把「脱敏后的客户画像」降到了L2，效率提升了好几倍。
分类分级这件事，说白了就是「把数据管起来」的第一步。做好了，后面的数据治理事半功倍；做不好，数据湖迟早变数据沼泽。