摘要本文聚焦数据安全分级落地中的关键难题——如何把“人填的台账”和“机器跑的元数据目录”合并成一张全量数据清单。文章先介绍资源盘点台账的维护方式再讲解数据探查与元数据同步的完整流程随后以“数据源 数据库 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 英文表名 英文字段”为唯一标识才能把两张表精准关联成一张全量数据清单关联键的质量直接决定合并效果。全量清单是治理抓手——清单不只是分类分级的输入其中的“待补充”标记本身就是数据治理的优先级列表按系统归拢后反向推动业务补录比群发邮件有效得多。
