金融数据分类分级实战系列三：生成全量数据清单

摘要：本文聚焦数据安全分级落地中的关键难题——如何把“人填的台账”和“机器跑的元数据目录”合并成一张全量数据清单。文章先介绍资源盘点台账的维护方式，再讲解数据探查与元数据同步的完整流程，随后以“数据源 + 数据库 + Schema + 英文表名 + 英文字段”五级联合键为锚点，把两张表精准关联成一张全量清单，并给出关联不上、关联冲突两类常见问题的处理方案。最后从落地角度给出四条实操建议，强调台账与元数据互补、关联键质量先行，以及用“待补充”标记驱动数据治理。

TL;DR：人填的台账和机器跑的元数据目录，两套数据怎么合成一张全量数据清单？本篇用“五级联合键”把两张表精准合并，让台账的业务属性与元数据的技术属性互补，最终生成一张既能支撑分类分级、又能驱动数据治理的全量清单。

上一篇我们把 23 项定级要素嵌入调研问卷，让业务系统负责人批量填写字段信息。问卷是收回来了——但一堆 Excel 搁在那儿，元数据同步也跑出了一堆表和字段。两张表怎么合到一起？全量数据清单怎么生成？本篇就来解决这件事。

本篇你将学到：

• 台账与元数据，为什么缺一不可？——搞懂“人填的台账”和“机器跑的元数据”各自的短板，以及它们如何互相补位，拼出完整的字段画像。
• 五级联合键，如何精准合并两张表？——用“数据源 + 数据库 + Schema + 英文表名 + 英文字段”作为唯一锚点，把台账和元数据目录合并成一张全量数据清单。
• 全量清单，如何成为治理抓手？——清单不只是分类分级的输入，更是发现数据盲区、反向推动业务补录的治理利器。

先复盘一下目前的进度。第一篇我们吃透了 JR/T 0197-2020 标准的定级逻辑；第二篇从标准里提炼出了 23 项定级要素，做成了一张字段信息采集表——业务系统负责人按表填报，收集了各系统的字段级数据。

同时，平台的数据探查也跑了一遍——连上各个数据库，把元数据全部同步回来了：几百张表、上万个字段，字段属性拉得清清楚楚。

现在问题来了：人填的台账和机器跑的元数据目录，两套东西怎么合成一张全量数据清单？

这就是本篇要解决的问题。具体来说三件事：台账怎么建、元数据怎么来、两张表怎么合。

01 资源盘点台账维护

1.1 台账本质上是问卷的“汇总版”

资源盘点台账不是什么新概念——它就是调研问卷回收数据的集中存放处。它的数据结构和上一篇的“字段信息采集表”完全一致：同样的列分组（基础信息/数据使用/数据存储/数据传输/安全管控），同样的 23 项定级要素列。

台账和问卷的关系，一句话说清楚：

1.2 两种维护方式

• 调研问卷自动导入
  调研任务完成后，平台可一键将填报的信息导入台账。包括数据资源全局信息、应用系统信息、数据库信息、数据表信息。

• 手动录入 / 批量导入
  对于没纳入调研的系统（比如刚上线的系统、正在交接的系统），支持在台账界面逐条新增字段记录，也可以用 Excel 模板批量导入——模板列结构和台账完全一致，下了就能填、填了就能导。

台账建好之后不是一劳永逸的。新系统上线要新增字段记录，加密方式升级要更新对应字段属性，平台支持记录每次变更的历史版本，也支持按半年/一年的周期自动触发复审提醒。

好，台账这边搞定。但台账里只有“人知道”的字段信息——哪些字段台账里有没有？台账记录的字段属性跟数据库里的实际情况一致吗？要回答这些问题，得靠数据探查。

02 数据探查

2.1 为什么光有台账不够？

台账有个先天局限：它只能覆盖“被人关注过的”系统。业务系统负责人在台账里填了哪些字段，哪些字段就有记录；没被纳入调研的系统、被遗漏的表、字段台账里就什么都没有。

而且台账里记录的字段属性——“该字段是否加密？” “数据权限如何？”——毕竟是人判断的，和数据库里的实际状态可能存在偏差。

所以还需要数据探查来补两张底牌：

• 全——连接数据库，把元数据跑一遍，得到一个“机器看到的字段全集”
• 准——字段类型、长度、主键约束这些技术属性，数据库不会说谎

数据探查在平台上的操作路径很清晰，四步走完：

2.2 数据连接配置

平台支持连接主流关系型数据库（MySQL、Oracle、PostgreSQL、SQL Server 等），通过 JDBC 连接串配置，填好主机地址、端口、数据库名和凭证。连接信息中的密码/密钥类字段加密存储，配置完成后可以点"测试连接"验证连通性。

2.3 数据源管理

一个数据连接下可以管理多套数据库/实例——比如同一个 MySQL 实例下的交易库、客户库、风控库，各自作为独立数据源。

2.4 元数据同步

选定数据源后，平台自动扫描并同步库 → 表 → 字段三层元数据。同步内容包括：英文表名、英文字段、字段类型、字段长度、是否主键、是否允许为空、字段注释。

首次同步是全量的——整个数据源从头到尾扫一遍。后续支持增量同步，只拉取新增或变更的表和字段，效率高得多。

2.5 元数据目录

同步完成后，按"数据源 → 数据库 → Schema → 表 → 字段"分层目录组织，支持按表名/字段名搜索、按字段类型筛选，每一层的统计数字都一目了然。

03 生成全量数据清单

现在手里有两张表了——一张是人填的台账（有定级信息但不够全），一张是机器跑的元数据目录（够全但只有技术属性）。接下来要做的，就是把它们合成一张全量数据清单。

3.1 两张表的差异与互补

关联逻辑一句话说清楚：以元数据目录为基准，去台账里找匹配的字段信息。元数据目录里有的字段，全量清单里一定有；台账里有但元数据目录里没有的字段，不会出现在清单中——因为那意味着台账记了一个"数据库里不存在"的字段，需要核对核实。

3.2 关联流程三步走

1.确定关联范围

选择要生成全量清单的数据源/数据库范围，勾选要关联的台账记录来源（按系统分组，默认全选）。

2.执行字段级关联

以元数据目录中的"数据源名称 + 数据库名称 + Schema 名称 + 英文表名 + 英文字段"为唯一标识，在台账中查找匹配的记录：

✅ 匹配上：技术属性（元数据目录）+ 业务属性 + 23 项定级要素（台账）→合并为完整记录
⚠ 未匹配：技术属性保留，业务属性和定级要素留空 →标记"待补充"

3.输出全量数据清单

每个字段包含完整信息面：
技术属性（来自元数据目录）：数据源、数据库、Schema、英文表名、英文字段、字段类型、长度、是否主键……
业务属性（来自台账）：字段别名、中文表/字段名、是否存入数据中台……
定级要素（来自台账）：明文展示、数据权限、涉外出境、加密方式等 23 项

3.3 关联中的两个常见问题

问题一：关联不上

台账中尚未收录该字段的记录——常见于新上线的系统或漏调研的表。平台的处理方式：自动标记"待补充"并在清单中高亮；支持手动从台账中选择一条字段记录绑定；也支持直接在清单中补录定级要素信息，补录数据自动同步回台账。

问题二：关联冲突

同一字段在台账中有多条记录——比如核心交易系统负责人填了一份，数据仓库团队也填了一份，两份数据不一致。平台默认以最新提交版本为准（基于时间戳），同时保留历史版本可查；冲突字段标"多版本"标记，支持人工选择以哪个版本为准。

3.4 全量清单的价值不止于分类分级

全量清单建好之后，它的价值远不止为分类分级提供输入：

• 对数据资产管理者：这是一张"数据家底表"——有哪些数据库、哪些表、每个字段的技术属性，清清楚楚。
• 对数据安全从业者：每个字段不仅知道它"是什么"，还知道它的数据权限、加密状态、涉外出境等定级相关属性。
• 对数据治理团队：清单中"待补充"的标记，就是治理任务的优先级列表——哪些字段的信息还不完整，按系统归拢一下，直接推送给对应负责人去补。

全量清单 ≠ 分级范围

一张清单可能涵盖几百张表、上万个字段——但不是所有字段都需要做数据安全分级（比如配置表、日志中间表）。

后面的文章，我们会详细介绍如何从这张清单中精准圈定本次分级范围、创建分级任务、配置自动分级策略、启动 AI 辅助分类分级，以及 AI 给出的分级结果到底靠不靠谱？人工怎么复核？这些问题。

04 落地建议

1.先跑通一条业务线：

别一上来就全系统铺开。选一条核心业务线（比如核心交易系统及其关联数据库），把"数据连接 → 元数据同步 → 台账关联 → 全量清单"完整走通一遍，验证关联逻辑和字段覆盖率，再推广到其他系统。

2.关联键的质量提前抓：

"数据源 + 数据库 + Schema + 英文表名 + 英文字段"五级联合键是全量清单关联的唯一锚点。如果源头元数据里数据源/Schema 命名混乱、表名和字段命名不规范（拼音缩写、无意义编码），关联效果会大打折扣。建议在数据探查阶段同步推进元数据规范化——至少确保数据源和 Schema 命名规范、英文表名唯一、英文字段可读。

3.台账是持续工程：

新系统上线、字段变更、加密升级——台账需要持续维护。建议在平台中设置"台账待办"提醒，字段信息缺失或长时间未更新的自动纳入待办列表，反向推动业务负责人补录。

4.用“待补充”驱动数据治理：

全量清单中标记为"待补充"的字段，本质上就是数据治理的盲区。先把"待补充"字段按所属系统归类，反向推送给业务系统负责人补录。这比发一封"请大家更新台账"的群邮件有效得多。

05 总结

总结

回顾本篇，核心可以浓缩为三点：

• 台账与元数据互补——台账承载“人知道”的业务属性和定级要素，元数据目录提供“机器看到”的技术属性，两者缺一不可，合并后才是完整的字段画像。
• 五级联合键是合并的锚点——以“数据源 + 数据库 + Schema + 英文表名 + 英文字段”为唯一标识，才能把两张表精准关联成一张全量数据清单，关联键的质量直接决定合并效果。
• 全量清单是治理抓手——清单不只是分类分级的输入，其中的“待补充”标记本身就是数据治理的优先级列表，按系统归拢后反向推动业务补录，比群发邮件有效得多。