1. 课程导入

在金融行业，数据是定价、风控、清算、监管报送与客户服务的共同底座。只要同一笔交易、同一个客户、同一只证券或同一条行情被系统重复接收、重复落库，或在多个上游之间出现版本不一致，后续的估值、对账、风险敞口和监管指标就可能被系统性放大或扭曲。重复记录与冲突版本并不是“脏数据”这么简单，它往往意味着资金口径不一致、账实不符、审计线索断裂，甚至触发合规风险。本课程面向数据工程师、数据治理人员、金融系统开发与运维人员，以及需要参与数据质量整改的业务分析师，目标是把“发现—判定—合并—留痕—验证”的完整处理链路讲清楚，并落到可执行的工程实践上。

1.1 为什么金融数据会重复与冲突

重复与冲突的根源通常不在单一系统，而在数据从产生到消费的整条链路。常见来源包括：上游多次推送同一笔交易，消息中间件至少一次语义导致重复消费，批处理任务重跑或补数未做幂等，多个业务系统各自维护客户或证券主数据，历史迁移时新旧编码并存，以及人工录入与外部数据源覆盖造成同一实体多个版本。金融场景的特殊性在于，很多数据带有时间、金额、状态和机构维度，任何一处不一致都可能改变最终口径。

• 重复记录：同一业务事实被多次写入，表现为完全相同的行、仅流水号不同的行，或同一业务键下多条有效记录。
• 冲突版本：同一业务键对应多个不同属性值，例如客户风险等级、交易状态、证券代码、汇率或持仓数量不一致。
• 时间维度冲突：同一记录在不同时间点被修改，但缺少生效时间、失效时间或版本号，导致“当前值”无法判定。
• 跨系统冲突：交易系统、清算系统、数据仓库与监管报送系统对同一事实的记录不一致，且没有统一的主数据或对账基准。

1.2 核心概念：业务键、版本键与冲突消解

处理重复与冲突的第一步，是明确“什么算同一条数据”。在金融数据中，物理主键往往只是数据库自增 ID，不能代表业务唯一性。真正需要定义的是业务键，例如“交易日期 + 交易流水号 + 机构代码”或“客户号 + 产品代码 + 持仓日期”。当同一业务键出现多条记录时，再通过版本键判断新旧，例如更新时间、序列号、CDC 位点或生效日期。冲突消解则是根据规则选择保留哪一版，常见策略包括“最新时间优先”“权威源优先”“状态优先级优先”“金额汇总而非覆盖”等。

1.3 整体课程框架与处理流程

本课程共 30 章，围绕“识别—判定—消解—验证—治理”展开。前段建立概念与分类，中段进入 SQL、批处理、流式去重、主数据对齐与冲突消解规则，后段覆盖对账、风控、监管报送、审计留痕与平台化治理。每一章都会给出可复用的检查清单、参数配置或代码片段，帮助你把方法带回真实系统。

下面这张图展示了金融数据从多源接入到重复识别、冲突判定、消解合并与验证输出的核心路径。它强调的不是简单步骤，而是“同一业务键下多版本如何被判定和收敛”的数据流关系。

1.4 典型场景与常见误区

在真实项目中，重复与冲突往往同时出现。例如某支付机构在日终对账时发现同一笔交易在交易库和清算库中各有一条记录，金额相同但状态不同；又例如某券商在客户风险等级更新时，旧系统和新系统分别写入不同等级，导致适当性校验结果不一致。处理这类问题时，不能只看“哪条最新”，还要看数据来源的权威性、业务生效时间和监管口径。

下面给出一个最小化的重复识别 SQL 片段，用于按业务键统计重复情况。实际使用时需要把业务键替换为你的真实字段，并注意分区与索引。

SELECT
  trade_date,
  trade_no,
  inst_code,
  COUNT(*) AS cnt,
  COUNT(DISTINCT status) AS status_cnt,
  MAX(update_time) AS latest_time
FROM dwd_trade_detail
GROUP BY trade_date, trade_no, inst_code
HAVING COUNT(*) > 1
ORDER BY cnt DESC, latest_time DESC;

如果查询结果显示 cnt > 1 且 status_cnt > 1，说明同一业务键下既有重复又有状态冲突，需要进入冲突消解流程；如果 status_cnt = 1，则更可能是物理重复或重复推送，可以优先考虑幂等去重。无论哪种情况，都建议先写入临时问题表，再执行合并，避免直接修改生产数据。