2. 金融数据基础
在进入重复记录识别与冲突版本处理之前，必须先建立对金融数据本身的系统认知。金融数据的特殊性在于：它同时具备强时效性、强一致性要求、严格审计追溯和跨系统异构等特征。理解数据的类型、来源、格式与质量维度，是判断“什么算重复”“什么算冲突”的前提。
一、核心原理：金融数据的四层认知框架
金融数据可以从四个层次理解：类型决定语义，来源决定可信度，格式决定可解析性，质量维度决定可用性。四者共同构成重复与冲突判定的基础。
- 按业务类型：行情数据（Tick、K线、盘口）、交易数据（委托、成交、撤单）、账户数据（持仓、资金、权益）、参考数据（证券主数据、汇率、利率曲线）、风控与合规数据（限额、预警、报送记录）。
- 按结构类型：结构化（关系表、定长报文）、半结构化（JSON、XML、FIX）、非结构化（公告文本、PDF、邮件确认单）。
- 按时间类型：快照型（每日持仓快照）、流水型（逐笔成交）、状态型（订单状态机）、版本型（主数据多版本）。
关键判断：同一业务实体在不同类型下，重复与冲突的判定规则完全不同。例如行情Tick的“重复”通常指同一时间戳同一价格成交量重复推送；而客户主数据的“重复”则指同一证件号对应多条客户记录。
二、数据来源与常见格式
金融数据来源多样，常见包括交易所直连、券商柜台、第三方数据商、内部核心系统、人工录入与外部文件导入。不同来源的格式差异直接影响后续去重与冲突合并策略。
| 来源 | 典型格式 | 重复风险 | 冲突特征 |
|---|---|---|---|
| 交易所行情 | 二进制、FAST、STEP | 重传、补包导致重复 | 时间戳与序列号不一致 |
| 柜台交易 | FIX、CSV、数据库表 | 撤单重发、回报重复 | 订单状态版本冲突 |
| 第三方数据商 | JSON、XML、Excel | 多批次覆盖导入 | 字段口径与更新时间差异 |
| 人工录入 | 表单、Excel | 重复提交、复制粘贴 | 同名不同证件、同证件不同名 |
格式解析时需特别注意：定长报文依赖字段偏移，CSV依赖分隔符与转义，JSON依赖键路径，FIX依赖标签号。格式解析错误本身就会制造“伪重复”和“伪冲突”。
# 示例：FIX报文片段（简化）
8=FIX.4.4|35=D|11=ORD20240501|55=600519|54=1|38=100|40=2|44=1680.5|60=20240501-09:30:00|
# 字段11为ClOrdID，是订单去重的关键业务主键三、数据质量维度与重复冲突定义
数据质量通常从准确性、完整性、一致性、时效性、唯一性、有效性六个维度衡量。重复与冲突正是唯一性与一致性维度的典型问题。
- 重复记录：同一业务实体在同一数据集中出现多次，可分为完全重复（所有字段一致）和业务重复（业务主键一致但部分字段不同）。
- 冲突版本：同一业务实体存在多条记录，且关键字段取值不一致，无法直接判断哪条为真。冲突可表现为时间冲突、来源冲突、口径冲突和状态冲突。
区分要点：重复强调“多了”，冲突强调“不一致”。实际场景中二者常同时出现——多条记录既重复又互相冲突，需要先识别再合并。
四、案例与场景：一条客户主数据的重复冲突
某券商客户主数据来自柜台、APP和第三方开户系统。同一客户张三出现三条记录：柜台记录证件号110101199001011234，APP记录证件号一致但手机号不同，第三方记录姓名相同但证件号缺失。此时：
- 柜台与APP记录构成业务重复，需按更新时间与来源可信度合并。
- 第三方记录证件号缺失，无法直接判定为同一客户，属于潜在冲突。
- 若强行按姓名合并，可能将同名不同人错误归并，造成合规风险。
处理流程通常为：标准化字段 → 生成业务主键 → 分组候选 → 相似度打分 → 人工复核 → 合并留痕。每一步都依赖对数据类型、来源和格式的准确理解。
五、误区与复盘
常见误区一：把“主键相同”直接等同于“重复”，忽略业务主键与物理主键的区别。误区二：认为字段完全一致才算重复，漏掉业务重复。误区三：冲突时简单取最新记录，未考虑来源可信度与审计要求。误区四：忽略格式解析差异导致的伪重复。
复盘建议：建立数据字典，明确每个实体的业务主键、来源优先级和字段口径；在入库前做标准化与校验；对重复与冲突处理保留完整日志，确保可追溯。只有先理解数据本身，后续的重复识别算法与冲突合并策略才有可靠基础。