4. 数据治理核心概念

银行账户与产品数据迁移，表面上是“把数据从旧系统搬到新系统”，实质上是一次对数据资产的重构。如果缺乏治理视角，迁移往往变成“搬完即失控”：字段含义漂移、口径不一致、敏感数据裸露、监管报送对不上。因此，理解数据治理的核心概念，是迁移项目从“技术搬运”升级为“资产交付”的前提。

一、数据治理框架：迁移的顶层约束

数据治理框架回答的是“谁、依据什么、对哪些数据、做什么决策”。它通常由治理组织、制度流程、技术工具和度量机制四部分构成。在迁移场景中，框架的价值在于把迁移目标与全行数据战略对齐，避免项目组各自为政。

• 治理组织：数据治理委员会、数据所有者、数据管理员、迁移项目组，明确决策与执行边界。
• 制度流程：数据标准管理、变更审批、质量稽核、安全分级等制度，迁移必须遵循而非绕过。
• 技术工具：元数据平台、数据质量平台、数据脱敏工具、血缘分析工具，为迁移提供可观测能力。
• 度量机制：以数据质量得分、标准覆盖率、问题闭环率等指标衡量迁移成效。

二、数据质量：迁移成败的硬指标

数据质量通常从完整性、准确性、一致性、唯一性、及时性、有效性六个维度衡量。迁移过程中，质量问题的典型表现是：账户主键重复、产品代码在旧系统存在但新系统无对应、客户证件号格式不统一、余额与分户账不平。

质量治理的方法流程可归纳为“定义—测量—分析—改进—监控”闭环：

1. 定义规则：针对账户号、产品码、余额、状态等关键字段制定可执行的校验规则。
2. 测量基线：在迁移前对源系统数据做全量剖析，形成质量基线报告。
3. 分析根因：区分是源系统录入问题、接口转换问题，还是映射规则缺失。
4. 改进修复：在迁移脚本或清洗层中固化修复逻辑，并保留修复痕迹。
5. 持续监控：迁移后对新系统关键字段设置常态化质量监控。

以下是一个迁移前质量校验的伪代码示例，用于识别账户主键与产品映射的异常：

-- 检查账户号重复
SELECT account_no, COUNT(*) AS cnt
FROM src_account
GROUP BY account_no
HAVING COUNT(*) > 1;

-- 检查产品代码在新系统无映射
SELECT a.account_no, a.product_code
FROM src_account a
LEFT JOIN map_product p ON a.product_code = p.old_code
WHERE p.new_code IS NULL;

-- 检查余额与分户账不平
SELECT account_no, balance, sub_ledger_balance
FROM src_account
WHERE ABS(balance - sub_ledger_balance) > 0.01;

三、元数据与数据标准：让迁移“有据可依”

元数据是“描述数据的数据”，分为技术元数据（表结构、字段类型、长度）、业务元数据（业务含义、口径、责任人）和管理元数据（权限、血缘、变更记录）。迁移中，元数据是映射设计的依据：没有业务元数据，字段映射只能靠猜；没有血缘元数据，问题追溯只能靠翻代码。

数据标准则是对关键数据项的统一定义，包括命名规范、数据类型、取值范围、编码规则。例如“客户号”在全行必须统一为18位、不可为空、全局唯一；“账户状态”必须使用标准代码集，不能旧系统用“A”、新系统用“01”。

四、数据安全与合规：迁移的红线

银行数据迁移涉及大量客户身份信息、账户余额、交易流水，属于高敏感数据。安全合规要求贯穿迁移全生命周期：迁移前完成数据分级分类，迁移中对敏感字段脱敏或加密，迁移后保留完整审计日志，确保可追溯、可问责。

合规方面还需关注：数据出境限制、个人信息保护要求、监管报送口径一致性。迁移后的数据必须能够支撑反洗钱、征信、监管统计等下游应用，否则迁移就失去了业务价值。

五、误区复盘：治理缺失的典型代价

• 只做映射不做标准：字段能搬过去，但口径不一致，报表对不上。
• 只做清洗不做监控：迁移当天数据干净，三个月后质量再次劣化。
• 只做脱敏不做审计：敏感数据被谁访问、何时导出，无法回答。
• 只做技术不做组织：问题无人决策，整改推不动，项目组疲于救火。

把治理框架、质量、元数据、标准、安全合规五者视为一个整体，迁移项目才能从“一次性搬运”转变为“可持续运营的数据资产交付”。