4. 数据分类方法：按业务域、数据类型、数据来源、生命周期分类
分类这件事，听起来好像很简单——把数据打个标签嘛。但我在项目里踩过的坑告诉我，分类方式选错了，后面分级、打标、权限控制全都得重来。
数据分类，说白了就是回答三个问题：这是什么数据？从哪来的？处在什么阶段？ 每个问题对应一种分类维度。咱们一个个来看。
4.1 按业务域分类
这是最直观的方式。公司有什么业务，数据就跟着业务切块。我见过很多企业刚开始做分类时，上来就用这个维度——因为业务部门自己最清楚。
举个例子：
- 客户数据（CRM系统里的姓名、电话、地址）
- 财务数据（发票、合同金额、银行账号）
- 人力资源数据（员工工资、绩效、身份证号）
- 研发数据（源代码、设计文档、测试用例）
每个业务域的数据特征差异很大。财务数据对准确性和合规要求极高；研发数据则更关注知识产权保护。我在一个金融项目里就碰到过这种冲突：财务部想把所有合同都定为「机密」，但业务部说合同里很多条款需要共享给客户看。你看，光按业务域分还不够，得和后面的维度配合。
4.2 按数据类型分类
这个维度更贴近技术实现。我记得最早在搞数据治理时，我们团队把数据分成三大类：结构化、半结构化、非结构化。后来发现这太粗了，根本没法指导具体操作。
现在业界更流行按「数据性质」分：
| 类型 | 说明 | 典型例子 |
|---|---|---|
| 个人身份信息（PII） | 能直接或间接识别到具体个人 | 身份证号、手机号、人脸照片 |
| 敏感商业信息 | 泄露会损害公司利益 | 财报、战略规划、客户名单 |
| 技术数据 | 技术资产、知识产权 | 源代码、算法模型、架构图 |
| 运营/日志数据 | 系统运行产生的记录 | 访问日志、错误堆栈、性能指标 |
为什么这样分有用？因为不同类型对应不同的保护策略。PII 数据得注意隐私合规，GDPR、个保法都盯着它；源代码这种技术数据，重点防泄露和篡改。我记得有个客户，一开始把所有数据混在一起定级，后来发现运维日志里居然有明文密码……嗯，那个项目我专门给他们补了一课。
4.3 按数据来源分类
你想想看，数据是从哪流进来的？不同类型的来源，可信度、时效性、责任边界完全不一样。
常见来源分类：
- 内部系统生成（自产）—— 比如 ERP、CRM 里的业务数据
- 用户主动提交 —— 注册信息、工单、反馈
- 第三方接口/合作方 —— 征信报告、物流状态、支付回调
- 公开/爬取数据 —— 新闻、社交媒体、开源数据集
这里有个避坑点：我曾在一个项目里发现，业务方把从第三方采购的数据默认当成「内部数据」对待，结果供应商那边数据出问题，连带把我们自己的合规流程也拖下水了。所以按来源分类时，一定要标注数据所有者和责任方。
4.4 按生命周期分类
这个维度很多人会忽略。数据不是静态的，它在不同阶段价值不同、风险也不同。
我习惯把生命周期切成五个阶段：
- 采集/生成 —— 数据刚被创建或获取
- 存储/加工 —— 写入数据库，清洗，计算
- 使用/传输 —— 被查询、导出、共享给下游
- 归档/冷存 —— 不再频繁使用，转入低成本存储
- 销毁 —— 彻底删除或覆写
每个阶段的风险点不一样。比如「采集」阶段容易产生过度采集问题——我见过有的 APP 在注册时就把通讯录权限要走了，这就是生命周期的开头就没管好。而到了「销毁」阶段，很多人觉得删掉文件就行了，其实磁盘上的数据块可能还能恢复……嗯，这又是个大坑。
4.5 四种维度的协同关系
为了帮你更直观地理解这四种分类维度怎么配合，我画了一张图。你可以把业务域看作水平切分，数据类型看作垂直切分，来源和生命周期则是额外两个辅助维度——最终形成一张立体的分类网格。
实际做分类的时候，我建议你按照这个顺序来：先定业务域，再选数据类型，接着看来源，最后评估生命周期阶段。每多一个维度，分类粒度就细一层，后面做分级也会更准。
好了，这四种分类方法聊完了。每种都有它的用处，也有它的局限。关键是要根据你企业的业务特点和数据现状来灵活组合，别生搬硬套什么「最佳实践」——因为最好的实践，永远是能落地的那一套。