数据资产盘点与分类：把家底摸清楚
做数据资产评分，第一步不是定指标，而是搞清楚你到底有什么。我见过太多团队上来就设计评分模型，结果盘点时发现连核心业务表都漏了——那评分还有什么意义？
说白了，盘点就是摸家底。你连自己有多少数据、存在哪、谁在用都不知道，后面的评分全是空中楼阁。这一章，我带你走一遍盘点的完整流程，顺便聊聊分类标准怎么落地。
盘点方法论：别上来就全量扫描
很多人一听到盘点，第一反应是「把所有数据库表导出来」。嗯，这确实是个办法，但大概率会把自己淹死。一个中型企业动辄几千张表，你一张张看？不现实。
具体步骤我总结为四步走：
- 确定盘点范围——按业务线、系统、部门划定边界。别贪多，先试点一个域。
- 元数据采集——从数据字典、ER图、数据血缘工具里拉取基础信息。这一步能自动化就自动化。
- 人工校验与补全——机器拉出来的东西经常缺业务描述、缺负责人。找业务方聊，把缺失信息补上。
- 质量初评与标记——顺手做个简单标记：哪些表数据质量差、哪些字段没人用。后面评分时用得上。
我曾经在一个金融项目里，客户说他们有5000张表要盘点。我建议先聚焦「客户信息」和「交易流水」两个域，结果只用了两周就完成了核心资产的梳理。剩下的？慢慢来，不着急。
数据资产分类标准：三个维度，一个都不能少
分类的目的是让资产可查找、可理解、可管理。我推荐用三个维度交叉分类：业务域、系统域、主题域。你想想看，单靠一个维度，就像用一把尺子量三维空间——肯定不够。
| 分类维度 | 定义 | 典型示例 | 谁最关心 |
|---|---|---|---|
| 业务域 | 按业务职能划分 | 客户管理、营销、风控、财务 | 业务部门 |
| 系统域 | 按数据来源系统划分 | CRM、ERP、数据仓库、日志平台 | IT/数据团队 |
| 主题域 | 按数据本身含义划分 | 客户、产品、交易、渠道 | 数据分析师 |
举个例子。一张「客户订单表」，在业务域里属于「销售」，在系统域里属于「ERP系统」，在主题域里属于「交易」。三个标签一打，谁都能快速定位。
核心原则：分类标准要「够用但不冗余」。我建议每个维度下的二级分类不超过10个，否则维护成本会失控。
资产目录构建：从分类到可导航
分类做好了，下一步是把它变成一本「数据字典」——也就是资产目录。目录不是简单的列表，它要支持搜索、浏览、血缘追溯。
我个人习惯用三层结构：
- 第一层：目录入口——按业务域展示，方便业务方快速找到自己关心的数据。
- 第二层：资产清单——每个业务域下，列出所有数据资产（表、文件、API等），附带系统域和主题域标签。
- 第三层：资产详情——字段级描述、数据量、更新频率、负责人、质量评分等。
这里我放一张结构图，帮你理解这三个层次的关系：
构建目录时，我建议用工具辅助。Excel当然也能做，但到了几百个资产时，维护起来就是噩梦。我个人偏好用开源的数据目录工具（比如Apache Atlas或Amundsen），或者自建一个轻量级目录系统。关键是：目录要活，不能是一份死文档。
盘点与分类的常见坑
做这行久了，踩过的坑不少。我挑几个典型的说说：
- 坑一：分类标准太细——有人把业务域分了30多个子类，结果没人记得住。保持简单，10个以内。
- 坑二：只盘点不更新——目录建完就扔在那，半年后新表加了一堆，目录还是旧的。建议每月增量更新一次。
- 坑三：忽略数据血缘——光知道表名没用，你得知道数据从哪来、经过哪些加工、最终流向哪。血缘信息是评分的重要输入。
我曾经在一个电商项目里，客户坚持把所有数据资产按「部门」分类。结果一个跨部门的「用户画像」表，被三个部门同时认领，目录里出现了三条重复记录。后来我们改成「业务域+系统域+主题域」三维分类，才彻底解决冲突。
好了，盘点与分类这部分就聊到这。记住一句话：盘点不是一次性工程，分类不是死规矩。它们是为评分服务的工具，工具要灵活，别让工具绑架了你。