3、数据资产盘点方法论：识别数据源、数据采集与映射
做数据分类分级，第一件事不是贴标签，而是搞清楚你手里到底有什么数据。
很多团队一上来就拿着分类分级标准往数据库里套，结果发现——
「这个表是干什么的？那个字段谁建的？数据从哪里流进来的？」
一问三不知。
这就好比你要整理一间堆满杂物的仓库，但你连仓库里放了什么、东西从哪来的都不清楚，怎么可能分得清楚？
所以，数据资产盘点才是数据分类分级真正的第一步。
我个人习惯把这个过程拆成三个环节：识别数据源 → 数据采集 → 数据映射。下面一个一个讲。
3.1 识别数据源：搞清楚数据在哪里
什么是数据源？说白了就是产生或存储数据的地方。在真实的企业环境里，数据源远比你想的多。
我在项目中遇到过一家中型互联网公司，光关系型数据库就七个，还有几十个MongoDB、ES集群、消息队列、以及几百个Excel表格。很多业务数据根本没有进数据库，而是散落在邮件附件和共享网盘里。
识别数据源，你可以从这么几个维度去排查：
| 数据源类型 | 典型例子 | 识别难度 |
|---|---|---|
| 关系型数据库 | MySQL、PostgreSQL、Oracle | 低（有DBA配合就行） |
| NoSQL / 大数据组件 | HBase、MongoDB、Elasticsearch、ClickHouse | 中 |
| 接口 / API | HTTP接口、gRPC、WebSocket | 高（需要研发协助） |
| 文件 / 日志 | CSV、TXT、XML、JSON日志 | 高（很多是无管理的） |
| 消息队列 | Kafka、RabbitMQ、RocketMQ | 中 |
| SaaS / 云平台 | 钉钉、Salesforce、阿里云OSS | 中 |
个人经验：识别数据源时，不要只盯着IT部门问。你还要找业务部门聊——他们手上经常有「自主开发的Excel管理台账」「微信群里流转的数据统计表」，这些都是潜在的敏感数据源。
识别完数据源之后，下一步就是——怎么把这些数据拉回来。
3.2 数据采集：把数据拉上「流水线」
采集不是简单的复制粘贴。尤其是在跨系统、跨部门、跨环境的情况下，采集方案需要仔细设计。
我一般把采集分为两大类：结构化数据采集和非结构化/半结构化数据采集。
3.2.1 结构化数据采集
这类采集主要针对关系型数据库、数据仓库里的表。常用方式是JDBC/ODBC直连，或者用数据同步工具，比如DataX、Canal、Kettle。
嗯，这里要注意一个坑：采集全量表和采集增量表是不一样的。
避坑指南：我曾经在一个电商项目中吃过亏。当时采集订单表时只做了全量采集，结果数据量太大，直接把源库IO打满了。后来才改成「首次全量 + 后续增量（基于时间戳/流水号）」，才稳住生产环境。
3.2.2 半/非结构化数据采集
这类数据包括日志文件、JSON、图片、PDF等。采集方式往往不是直接拉入数据库，而是先上送到对象存储（OSS、MinIO）或者消息队列，再到数据湖里统一处理。
举个例子，用户行为日志通常采集到Kafka，再由Spark/Flink消费解析。你想想看，如果直接把几十T的日志往MySQL里灌——那是不现实的。
| 采集方式 | 适用场景 | 工具举例 |
|---|---|---|
| JDBC/ODBC直连 | 结构化的数据库表 | DataX、Sqoop |
| CDC（变更数据捕获） | 实时增量同步、减少对源库影响 | Canal、Debezium、Maxwell |
| 日志采集 | 服务器日志、应用日志 | Filebeat、Flume、Logstash |
| API拉取 | SaaS系统、第三方平台 | 自定义脚本 + 调度 |
3.2.3 采集频率与策略
采集不是一锤子买卖。对于数据分类分级来说，数据源是动态的，系统在变，业务在变，数据表结构也在变。
所以采集策略要区分好：
- 全量采集：初始化时做一次，后续定期覆盖（比如每周一次）。
- 增量采集：日常跑批，拉取新增或变更的数据。
- 事件触发采集：DDL变更、表结构变化时自动重新采集。
我曾经给一个金融机构做数据治理时，设定了一个规则：核心业务表每天做一次增量采集，非核心表每周一次全量。这样既保证了时效性，也不给源库造成压力。
3.3 数据映射：把散落的数据「对上号」
数据源识别完了，数据也采集回来了。然后呢？你会发现不同系统里的同名数据，可能含义完全不同。
举个例子，A系统的「customer_name」是中文全名，B系统的「customer_name」是拼音，C系统压根没有这个字段而是叫「user_name」。如果不做映射，后面的分类分级全是错的。
数据映射做的其实就是三件事：
- 字段级映射：源系统字段和目标系统字段之间的对应关系。
- 值域映射：同一个业务含义在不同系统中值表示方式的不一致。比如性别字段：A系统用「男/女」，B系统用「M/F」，C系统用「0/1」。
- 元数据对齐：统一字段的数据类型、长度、约束。
数据映射的产出物就是一张「数据血缘关系表」或「字段映射矩阵」。有了它，你才能清楚地知道：哪张表里的哪个字段，最终对应到哪个业务概念上。
3.3.1 映射的两种模式
- 自动映射：通过扫描元数据，基于字段名相似度（如Levenshtein距离）或样本数据分析，自动生成映射关系。适合数据量大的场景。
- 手工映射：业务人员或数据管理员手工逐字段确认。精度高，但耗时。适合核心敏感字段。
在实际项目中，我通常是先用自动映射跑一遍，生成候选映射关系，再让业务方人工review和修正。这样效率和准确率都能兼顾。
3.4 本章核心流程：一张图说清
好了，前面讲了很多，用一个完整的流程把它们串起来。
3.5 实战中可以这样落地
我给你一个我在团队里推过的「三步法」，拿来就能用：
- 第一周：和DBA、架构师、业务负责人各开一次会，拿到数据库清单和系统拓扑图。整理出第一版数据源清单。
- 第二周：选择核心业务系统，搭通采集链路（先跑一次全量，再配置增量）。不要一上来就贪多，先打通3~5个核心系统，跑通流程。
- 第三周：输出字段映射矩阵。找业务方确认核心敏感字段（比如身份证、手机号、银行卡号），这些必须手工复核映射关系。
对了，这里有个小技巧：输出映射矩阵时，可以用Excel加自定义宏，把「字段名相似度超过80%」「同值不同格式的字段」标注出来，辅助人工审核。我曾经用这个办法把一个4000+字段的映射工作缩短了将近一半的时间。
资产盘点做扎实了，后面所有的分类分级、风险评估、脱敏策略，才有了真实可信的数据底座。千万别图快跳过这一步——磨刀不误砍柴工。数据资产盘点是分类分级的基石，基石不稳，后果你知道的。