第3章 数据资产盘点方法论归纳总结
做数据分级分类，第一步永远不是写规则，而是搞清楚你手里到底有什么数据。
我见过太多项目，一上来就拍脑袋定级别，结果盘到一半发现核心系统压根没人认得全字段。所以这一章，咱们好好聊聊数据资产盘点的方法论——说白了，就是怎么把你家数据底裤翻出来晒一晒。
3.1 盘点的核心目标：别为了盘而盘
很多团队把盘点当成一次性的“大扫除”，做完就扔。这个坑我踩过。当年在某金融机构，我们花了三个月盘了2000多张表，结果半年后系统一升级，目录全废了。
真正盘点的目标应该是三个：
- 摸清家底——知道数据在哪、谁管的、长什么样
- 建立基线——为后面的分级分类提供客观依据
- 驱动治理——让盘点结果能持续更新，不是一次性艺术品
核心原则：盘点是过程，不是终点。盘子要能转起来，不是摆着看的。
3.2 盘点前准备：三件事必须做
我习惯把准备阶段叫做“三定”：定人、定范围、定工具。
3.2.1 定人——组建跨职能团队
光靠数据治理组自己是盘不全的。你需要：
- 业务代表：每个域的owner，负责解释表里的字段什么意思
- 技术代表：DBA或数仓开发，能跑脚本拉元数据
- 安全合规：判断哪些数据有法律风险
- 治理专员：负责统一模板和进度管理
3.2.2 定范围——先窄后宽
我曾经接手一个项目，对方想一次盘完所有系统。结果三个月后只盘了30%，因为老系统凭证格式乱七八糟。后来改成“核心业务系统→支撑系统→历史归档系统”分批推进，效率翻了倍。
建议优先级：
- 客户/用户相关数据（身份证、手机号、地址等）
- 财务交易数据（订单、支付、流水）
- 企业敏感商业信息（合同、定价、供应链）
- 内部管理数据（HR、办公系统）
3.2.3 定工具——用自动化辅助人工
纯手工用Excel盘几百张表？那是自虐。我建议至少用元数据管理工具（比如Apache Atlas、Collibra，或者自己写个Python脚本连数据库information_schema）。下面是一个简单的元数据采集示例：
-- MySQL 获取所有表的字段信息
SELECT
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE,
COLUMN_COMMENT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db'
ORDER BY TABLE_NAME, ORDINAL_POSITION;
-- 输出为CSV后配合人工审核嗯，这里要注意：自动化只能拿到技术元数据。业务含义、敏感度这些，还是得靠人填。
3.3 盘点五步法：我的实战流程
这么多年总结下来，我习惯用五步走。下面这张图可以帮你建立全局感：
3.4 不同盘点方式的对比
实际项目中，你可能会纠结用“自顶向下”还是“自底向上”。我的建议是：混合使用。下面这张表帮你选：
| 维度 | 自顶向下（业务驱动） | 自底向上（技术驱动） |
|---|---|---|
| 启动方式 | 先从业务流程、数据流图找核心资产 | 从数据库、文件系统、API 批量拉取 |
| 优缺点 | 容易漏掉非核心但敏感的数据 | 容易产生大量无业务含义的垃圾元数据 |
| 适用场景 | 业务复杂度高、监管要求明确 | 数据量大、缺乏业务文档支持 |
| 典型产出 | 业务数据地图 + 数据谱系 | 元数据清单 + 字段字典 |
| 我推荐占比 | 60% 精力 | 40% 精力 |
小技巧：我一般先让业务方画一张“核心数据流向图”，然后拿这张图去数据库里找对应的表。两边一对照，既保全面又不缺上下文。
3.5 避坑指南：我踩过的三个坑
3.5.1 坑一：忽略了版本和临时数据
曾经有次盘点，所有正式表都列了，唯独忘了开发测试库里有一份客户脱敏数据的全量备份。后来安全审计时发现测试环境居然有生产数据，差点翻车。所以记住：所有环境（开发、测试、预发）的数据资产都要纳入盘点范围，哪怕只是临时表。
3.5.2 坑二：业务术语打架
同一个字段，CRM叫“客户编号”，ERP叫“客户ID”，BI报表叫“Customer_Key”。如果你不统一命名就登记，后面分级分类时你会疯掉。我的做法是：先建立一本业务术语词典，让各个域负责人对一下口径。
3.5.3 坑三：只盘结构化数据，忽略非结构化
很多企业核心机密在Word合同、Excel表格、PDF报告里。别忘了把文件服务器、SharePoint、NAS的目录结构也盘一遍。至少要知道哪些文件夹放了敏感文档。
⚠ 警告：非结构化数据的盘点，千万不要手动一个个打开文件看。用关键词扫描工具（比如Python的正则+DLP小工具）先筛选敏感文件，再抽样人工确认。否则你会在Word文档的海洋里溺亡。
3.6 输出物：一份可用的数据资产目录
盘点完了，总要有个交代。我习惯输出的目录包含以下字段，缺一不可：
| 字段 | 说明 | 示例 |
|---|---|---|
| 资产ID | 全局唯一编号 | DA-2025-0001 |
| 资产名称 | 业务名称 | 客户主数据表 |
| 来源系统 | 数据所在的平台 | CRM系统 |
| 数据格式 | 结构/半结构/非结构 | 结构化（MySQL表） |
| 字段数量 | 关键字段个数 | 58 |
| 敏感字段列表 | 身份证、手机号等标签 | 身份证号、手机号 |
| 数据负责人 | 谁对这个数据负责 | 张三（业务部） |
| 存储位置 | 具体路径或库表名 | mysql://10.0.1.1:3306/crm |
| 访问权限 | 当前谁有权限 | 开发组、运维组 |
| 更新频率 | 多久变动一次 | 每日凌晨全量更新 |
这份目录不需要一次做到完美。我建议第一版先覆盖核心业务系统，边用边迭代。记住：能跑起来的目录，比躺在Wiki里的完美目录有用一百倍。