数据资产梳理方法与流程
1. 资产盘点——先知道自己有什么
数据治理的第一步，永远都是资产盘点。
说白了，你要不知道公司到底有哪些数据，那后续的分级分类、权限管控全是空中楼阁。我个人习惯把这步叫做“家底摸底”。
我在一个金融客户的项目里就遇到过，他们说要搞数据分级，结果连业务系统清单都拿不全。光报表库就有七八个没人知道的副本。你想想看，这怎么往下做？
资产盘点的核心目标
- 梳理出所有数据存储位置：数据库、数仓、数据湖、文件服务器、对象存储
- 识别数据的所有者与管理者：业务部门 vs IT 部门
- 建立资产唯一标识：每个数据集给一个全局ID
- 记录基础属性：数据量、更新时间、敏感度初步判断
我建议一开始不要追求完美。先拉出清单，再慢慢补齐细节。完成比完美重要。
2. 数据源发现——自动化是关键
靠人工填Excel？那太慢了。
做过大厂数据治理的都知道，数据源发现必须依赖自动化工具。
我记得有个项目，客户说他们数据源有200个。结果我们跑了扫描器一查，好家伙，光Oracle实例就600多个。人工登记根本不可能发现这些隐藏资产。
数据源发现的两类方法
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 主动扫描 | 网络可达的数据源 | 发现隐藏资产、实时性高 | 需要网络权限，可能影响生产 |
| 被动监听 | 无法直接访问的系统 | 零侵入、安全 | 依赖流量，可能漏掉低频系统 |
我个人习惯的做法是：先做主动扫描做全量发现，再用被动监听做增量捕获。两者互补，基本不会漏。
我曾经踩过的坑：主动扫描时没做流量控制，直接把某个老系统的数据库连接池打满了。从那以后，所有扫描任务我都强制设置并发上限和扫描窗口期。
3. 元数据采集——给数据贴上说明书
数据找到了，但你得知道它长什么样。这就是元数据的事。
元数据分三种，缺一不可：
- 技术元数据：表结构、字段类型、主键、外键、数据量
- 业务元数据：字段的业务含义、字典值、业务负责人
- 管理元数据：数据源归属、更新频率、访问权限、数据质量规则
-- 技术元数据采集示例（MySQL）
SELECT
TABLE_SCHEMA,
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
CHARACTER_MAXIMUM_LENGTH,
IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'performance_schema');技术元数据可以自动化采集，但业务元数据往往需要人工补录。嗯，这个环节最容易被忽略。
我见过一个项目，技术元数据采了一大堆，字段命名全是拼音缩写。人工看半天也不知道“jydm”是什么业务含义。最后分类分级根本没法做。
所以我的建议是：技术采集先行，业务元数据通过数据治理平台的工作流，定向推送给业务部门去补填。别指望一次性填完，分批次迭代。
4. 资产打标——分类分级的起点
所有数据资产梳理好了，元数据也采了，最后一步是打标。
打标就是给每个数据集、每个字段贴上标签。比如：
- 分类标签：客户信息、财务数据、技术日志、监管报表
- 分级标签：L1公开、L2内部、L3敏感、L4绝密
- 管理标签：所有者、数据源类型、存储位置、合规法规
打标的几种策略
| 策略 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 规则匹配 | 根据字段名称、注释、数据内容正则匹配 | 效率高，覆盖全 | 准确率有限，容易误标 |
| 字典映射 | 预置业务字典，字段名命中字典即打标 | 精确度高 | 维护成本高，新字段需更新字典 |
| 机器学习 | 用模型识别数据内容中的敏感信息 | 能发现不规则敏感字段 | 需要训练样本，初期效果差 |
| 人工确认 | 业务方手动勾选标签 | 最准确 | 效率低，无法大规模推广 |
我实际项目的做法是：规则匹配做初筛 + 人工抽查修正。先覆盖90%的常见字段，剩下10%的特殊字段靠人工兜底。
打标要保留审计记录
谁打的标、什么时间打的、打的是什么标签、有没有覆盖历史标签。这些都得记下来。不然合规审计的时候一问三不知。
总结一下这个流程
资产梳理不是一次性工作。你得把它做成一个持续运营的流水线。
- 新系统上线，自动触发数据源发现
- 元数据变更，自动通知相关人确认标签是否需要更新
- 定期全量扫描，发现僵尸数据或未授权副本
我曾经在一个客户那里看到他们把资产梳理做成了季度运动。每季度集中人力搞一周，搞完就扔。结果中间三个月冒出来的新数据根本不进清单。这不是治理，这是糊弄。
数据治理，说到底就是要把“家底摸清”这件事做成常态。流程跑通了，后续的分级、分类、权限、脱敏才能落得下去。