2、数据资产盘点：范围界定、方法与工具选择
数据资产盘点，说白了就是搞清楚你家底有多少、在哪、长什么样。我见过不少团队，一上来就铺开摊子大干，结果盘了三个月，连自己有多少数据库都说不清。嗯，这里有个关键问题——你得先知道盘什么、怎么盘、用什么盘。
2.1 盘点范围界定：别想一口吃成胖子
很多数据治理项目失败，不是因为技术不行，而是范围没划好。我早期带过一个项目，老板说“把所有数据都盘一遍”，结果团队干了半年，产出就是一张Excel表，还全是错的。
界定范围，我建议你从三个维度切分：
| 维度 | 说明 | 典型问题 |
|---|---|---|
| 业务域 | 按业务流程或部门划分，如客户域、产品域、订单域 | 跨域数据归属不清，重复盘点 |
| 数据层级 | 操作层、分析层、报表层、外部数据层 | 只盘了操作层，忽略了分析层的关键指标 |
| 优先级 | 核心资产 vs 一般资产 vs 待废弃资产 | 什么都想盘，资源不够用 |
范围界定还有一个容易踩的坑——“数据资产”不等于“所有数据”。你想想看，那些临时表、测试数据、过期备份，算资产吗？我个人认为，只有满足“有价值、可管控、可共享”这三个条件的数据，才值得纳入盘点范围。
2.2 盘点方法：自上而下 vs 自下而上
方法就两种，但很多人用反了。我分别说说。
2.2.1 自上而下：先画地图再找路
这种方法，是从业务视角出发。先梳理业务流程，画出数据流转图，再定位每个环节产生了哪些数据资产。
适合场景：
- 公司有清晰的业务流程文档
- 业务部门愿意配合
- 需要快速建立数据资产全景视图
具体步骤：
- 梳理核心业务流程（比如从获客到成交到售后）
- 识别每个流程节点产生的数据实体
- 定义每个实体的Owner、系统来源、存储位置
- 形成业务-数据映射矩阵
优点：速度快，能快速对齐业务语言。业务人员看得懂，愿意签字确认。
缺点：容易遗漏底层细节数据，比如日志、中间表、ETL临时数据。
2.2.2 自下而上：从数据库里翻家底
这种方法，是从技术视角出发。直接扫描数据库、数据仓库、文件服务器，把所有的表、字段、文件都列出来，再反向打标签。
适合场景：
- 业务流程不清晰，文档缺失
- 系统老旧，没人说得清数据在哪
- 需要做数据血缘分析
具体步骤：
- 连接所有数据源（数据库、HDFS、对象存储等）
- 自动扫描元数据（表名、字段名、类型、行数）
- 人工打标签，归类到业务域
- 去重、合并、标记废弃数据
2.2.3 两种方法怎么选？
说实话，没有的好坏。我现在的习惯是“自上而下定框架，自下而上填内容”。
先用自上而下的方法，画出业务数据地图，确定要盘哪些域。然后用自下而上的方法，从系统里拉出实际的数据清单，跟地图做比对。对不上的，要么是地图画漏了，要么是系统里有垃圾数据。
下面这张图，是我常用的盘点流程：
2.3 盘点工具选择：别用手工Excel了
我见过最离谱的，是有人用Excel管理8000张表的元数据。结果呢？版本混乱、字段对不上、Owner信息过期。你想想看，这能叫治理吗？
工具选型，我一般看三个维度：
| 维度 | 关键考量 | 推荐方向 |
|---|---|---|
| 自动化能力 | 能否自动扫描数据库、识别表结构、采集血缘 | 选支持JDBC/ODBC直连的工具 |
| 协作能力 | 业务人员能否直接打标签、提问题、确认Owner | 选有Web界面、支持多人协作的 |
| 集成能力 | 能否对接数据质量平台、数据目录、数据地图 | 选有开放API的，别选封闭系统 |
工具选好了，怎么落地？我分享一个三步走的方法：
- 试点期（1-2周）：选一个业务域，用工具跑一遍。验证自动化扫描的准确率，让业务人员试用打标签功能。
- 推广期（1-2个月）：扩展到所有核心业务域。建立元数据采集的定时任务，每天增量更新。
- 运营期（持续）：建立资产目录的维护机制。每周检查新增表、废弃表，更新Owner信息。
最后说一句，盘点不是一次性工作。数据资产是活的，系统在变、业务在变、人在变。我建议每季度做一次增量盘点，每年做一次全面盘点。只有这样，你的资产目录才不会变成一堆没人看的死文档。