3、数据资产盘点：数据资产识别、数据资产目录构建、数据血缘与流转分析、数据质量评估
数据资产盘点，说白了就是搞清楚你家底儿到底有多少数据、这些数据长什么样、从哪来到哪去、质量靠不靠谱。很多团队一上来就急着定分类分级标准，结果发现连自己有哪些数据都不清楚——嗯，这活儿就干不下去了。
我个人习惯把数据资产盘点拆成四个步骤：识别 → 编目 → 画血缘 → 评质量。每一步都有坑，咱们一个一个说。
核心观点：没有经过盘点的数据资产，分类分级就是空中楼阁。盘点不是一次性工作，而是持续运营的基础。
3.1 数据资产识别：摸清家底
数据资产识别，就是把你组织里所有有价值的数据找出来。别以为这很简单——我在项目中遇到过，光一个中型企业的数据库就有上百个，加上文件服务器、数据湖、API接口，没个系统方法根本理不清。
我建议从三个维度入手：
- 存储位置：数据库、数据仓库、数据湖、文件服务器、云存储、SaaS应用
- 数据类型：结构化（表、视图）、半结构化（JSON、XML、日志）、非结构化（文档、图片、音视频）
- 业务归属：客户数据、产品数据、交易数据、风控数据、运营数据
实用技巧：别指望手工梳理。用自动化工具扫描数据库元数据、文件系统目录、API文档，能省80%的力气。我习惯先用工具跑一遍，再人工补漏。
识别完成后，需要给每个数据资产打上标签。至少包含：
| 标签维度 | 示例值 | 说明 |
|---|---|---|
| 资产名称 | 客户信息表 | 业务可读的名称 |
| 技术名称 | t_customer_info | 数据库中的物理名称 |
| 数据源类型 | MySQL / HDFS / S3 | 存储引擎或平台 |
| 业务域 | 客户域 / 产品域 | 所属业务领域 |
| 数据量级 | 500万行 / 2TB | 规模估算 |
| 更新频率 | 实时 / 每日 / 每月 | 数据新鲜度 |
3.2 数据资产目录构建：给数据安个家
识别完资产，下一步就是建目录。你想想看，一个图书馆没有目录，找本书得翻遍所有书架——数据也一样。
数据资产目录的核心作用就三个：找得到、看得懂、管得住。
我个人习惯用分层结构来组织目录：
- 主题域层：按业务领域划分，比如客户域、产品域、交易域、风险域
- 业务对象层：每个主题域下的具体业务实体，比如客户域下的「个人客户」「企业客户」
- 数据实体层：具体的表或文件，比如「个人客户基本信息表」
- 数据属性层：字段级别的描述，比如「姓名」「身份证号」「手机号」
注意：目录不是一次建完就完事了。数据在变，业务在变，目录必须持续维护。我建议至少每季度做一次目录刷新。
建目录时，有几个坑要避开：
- 命名不规范：同一个字段在不同系统里叫法不同，比如「客户ID」vs「cust_id」vs「customer_number」——统一映射到标准名称
- 描述缺失：字段含义不写清楚，别人看不懂。比如「status」字段，是订单状态还是用户状态？取值范围是什么？
- 分类混乱：同一个数据出现在多个分类下，导致重复和歧义
避坑指南：我曾经见过一个团队，目录建了3000多条，但没人维护，半年后一半以上的条目已经过时了。目录一定要有负责人，每个主题域指定一个数据管家。
3.3 数据血缘与流转分析：数据从哪来，到哪去
数据血缘，说白了就是数据的「族谱」。它能回答三个问题：
- 这个数据是从哪个源系统来的？
- 经过了哪些加工处理？
- 被哪些下游系统或报表使用了？
为什么要做血缘分析？我给你讲个真实案例。有一次，某个报表的数据突然对不上了，业务部门追着问。如果没有血缘图谱，你得一个个系统去查，可能查三天都找不到根因。有了血缘，顺着链路一看——哦，中间有个ETL任务改了字段映射，问题五分钟定位。
血缘分析的粒度可以分三级：
| 粒度 | 描述 | 适用场景 |
|---|---|---|
| 表级血缘 | 表与表之间的依赖关系 | 数据链路梳理、影响分析 |
| 字段级血缘 | 字段级别的映射和转换 | 数据溯源、问题排查 |
| 任务级血缘 | ETL任务、SQL脚本之间的依赖 | 调度优化、故障定位 |
流转分析则关注数据在系统间的移动路径。我建议用一张流转图把以下信息画清楚：
- 源系统 → 数据采集 → 数据清洗 → 数据存储 → 数据服务 → 数据消费
- 每个环节的输入输出是什么
- 流转频率和时效要求
实用技巧：如果团队没有现成的血缘工具，可以先从SQL解析入手。解析ETL脚本中的INSERT/SELECT语句，能自动提取字段级血缘。我早期就是这么干的，虽然粗糙，但够用。
3.4 数据质量评估：数据到底能不能用
数据质量评估，就是给数据「体检」。数据质量不行，分类分级做得再好也没用——你想想看，一个质量差的数据，分了级又怎样？用起来全是坑。
我通常从六个维度评估数据质量：
| 维度 | 定义 | 常见问题 | 评估方法 |
|---|---|---|---|
| 完整性 | 数据是否缺失 | 空值、缺失字段 | 统计空值率 |
| 准确性 | 数据是否真实反映业务 | 数值错误、名称错误 | 抽样比对源系统 |
| 一致性 | 不同系统间数据是否一致 | 同一客户在不同系统里信息不同 | 交叉比对 |
| 及时性 | 数据是否在预期时间内可用 | 数据延迟、过期未更新 | 监控时间戳 |
| 唯一性 | 数据是否有重复 | 重复记录、主键冲突 | 去重统计 |
| 规范性 | 数据格式是否符合标准 | 日期格式不统一、编码不规范 | 格式校验 |
评估结果可以用一个质量评分来量化。我习惯的做法是：
- 每个维度设定权重（比如完整性30%、准确性30%、一致性20%、及时性10%、唯一性5%、规范性5%）
- 每个维度打分（0-100分）
- 加权计算总分
关键点：质量评估不是一次性的。我建议建立持续监控机制，每天/每周自动跑质量检查脚本，发现问题及时告警。质量分数低于阈值的资产，在分类分级时要特别标注。
避坑指南：我曾经遇到一个项目，团队花了两周做质量评估，出了厚厚一本报告，但没人跟进整改。结果报告就躺在那里落灰。记住：评估的目的是改进，不是交差。每个质量问题都要有责任人、有整改计划、有跟踪闭环。
好了，数据资产盘点的四个步骤就讲到这里。识别是基础，目录是骨架，血缘是脉络，质量是血液——四者缺一不可。把这四步走扎实了，后面的分类分级才能站得住脚。