银行数据平台的核心资产是信任。当核心系统余额与数仓汇总不一致、当日交易流水与昨日报表对不上时，数据平台的公信力就会崩塌。数据一致性校验不是锦上添花，而是银行数据工程的底线要求。
银行常见的三种数据不一致场景
场景一：T+1 跑批对账差异
银行每日凌晨跑批后，数仓层计算的汇总指标与核心系统直接查出的结果存在差异。原因包括：源数据在抽数过程有遗漏（CDC 延迟或 OGG 故障）、ETL 转换逻辑有 bug、时间窗口截断不一致。
场景二：跨系统一致性漂移
同一客户在零售系统和对公系统的身份信息不一致（如证件号后四位不同），导致风控模型做出错误判断。这种问题往往随着系统割接逐步积累。
场景三：实时与离线数据口径偏离
Flink 实时计算的客户当日交易笔数与 Hive 离线计算的同一口径不一致。这种差异通常源于窗口语义不同。
一致性校验的分层设计
第一层：行级校验
逐行对比新老系统的数据，容忍度设为 0.01 元。
第二层：汇总校验
对跨系统的关键指标做 SUM/COUNT/AVG 对比，自动化对账框架。
第三层：勾稽校验
业务层面的恒等式自动验证，如试算平衡：资产 = 负债 + 所有者权益。
自动修复策略
1. CDC 重放修复
当检测到 ODS 层某张表在某个时间窗口有数据遗漏时，自动触发 CDC 重放：检测到缺失 -> 定位回放时间范围 -> 重新订阅CDC -> 增量补数据 -> 二次校验
2. 血源自愈链路
当 DWS 层指标因 DWD 层修正而异常时，自动触发生成修复作业，只重新计算受影响的下游表，而非全量重跑。
3. 数据版本回退
当修复过程本身引入新的不一致时，支持一键回退到修复前的数据版本（利用 Iceberg 或 Hudi 的快照机制）。
一致性校验平台的架构设计
某股份制银行的数据一致性平台：规则配置中心 -> 校验引擎(Spark定时触发) -> 合格则归档，不一致则分级告警。CRITICAL 级别触发即时修复管道，WARNING 级别触发工单系统+人工确认。
该平台每日自动执行 500+ 条校验规则，覆盖全行 80% 的核心数据链路。
总结
银行数据一致性校验的核心理念： 1. 分层校验：行级逐条、汇总指标、勾稽恒等式，三层缺一不可 2. 自动修复：发现问题不等于解决问题，自动修复链路的闭环能力是关键 3. 分级告警：CRITICAL 自动修复，WARNING 人工确认，INFO 归档备查 4. 版本可回溯：所有修复操作必须有版本可回溯