多源数据合并实战：业务语义对齐与可信宽表构建

1. 项目概述：当数据不再“孤岛”，合并不是拼接，而是重建认知逻辑

在真实的数据分析场景里，我几乎没遇到过只靠一个表格就能把问题说清楚的项目。上周帮一家区域连锁餐饮做会员复购归因，光是基础数据就分散在四个系统里：POS机流水存着每笔交易的时间、金额、门店ID；CRM系统里有会员注册时间、手机号、首次到店日期；小程序后台记录着用户点击行为、优惠券领取与核销路径；而外卖平台API返回的则是脱敏后的订单ID、配送地址经纬度、骑手接单时间——四套数据结构完全不同，字段命名五花八门，时间戳精度从秒级到毫秒不等，甚至同一张会员卡在CRM里叫 member_id ，在外卖平台里却映射成 user_ext_id 。这时候，“合并多个数据集”根本不是Excel里点几下VLOOKUP的事，它是一场对业务逻辑的重新校准：你得先搞清楚“一个用户”在不同系统里到底对应哪些实体，再判断“一次消费行为”在各系统中分别被记录了哪几个片段，最后才能决定用什么键、什么方式、在哪个时间粒度上把它们缝合起来。这不是技术操作，而是业务翻译。核心关键词—— 数据合并、多源数据整合、主键对齐、外键关联、数据清洗、字段标准化、时间对齐、业务主键设计 ——每一个词背后都藏着至少三类典型陷阱：比如用手机号做关联，却忽略了用户换号、小号、家庭共用手机号的情况；比如按天聚合订单，却没发现POS系统按营业日切分（凌晨3点算前一天），而外卖平台严格按自然日统计；再比如CRM里的“注册时间”其实是前端表单提交时间，但真正激活账户要等短信验证码回传，中间可能隔了27分钟——这些细节不厘清，合并出来的宽表就是一张充满逻辑裂缝的“鬼图”。这篇文章写给所有正在被多源数据困扰的人：无论你是刚接手新项目的分析师，还是需要向老板解释“为什么ETL流程总卡在第三步”的工程师，或是想自己搭BI看板但被数据对不上焦搞得失眠的产品经理。它不讲抽象理论，只拆解我在过去三年里踩过的37次坑、验证过的5种主流合并策略、以及一套可直接抄作业的检查清单。

2. 多源数据合并的本质：不是技术问题，而是业务语义对齐工程

2.1 合并失败的90%原因，都出在“你以为的相同，其实根本不是同一个东西”

很多人一上来就打开Python写pd.merge()，或者在Tableau里拖拽字段建关系，结果跑出来一堆NaN和重复行，第一反应是“数据质量太差”。但在我经手的62个跨系统合并项目里，真正因原始数据脏乱导致失败的不到12%。绝大多数问题，根子出在 业务语义错位 上。举个最典型的例子：某电商公司想合并APP埋点日志和订单库，目标是分析“用户从点击商品到下单的转化漏斗”。开发同学直接用 user_id 关联，结果发现漏斗里“加购”环节人数比“下单”环节高出4倍。排查三天后才发现：APP埋点SDK用的是设备ID（IDFA/AAID）做匿名用户标识，而订单库的 user_id 是登录态下的账号ID——未登录用户点击商品时，埋点记录的是设备ID，但下单时必须登录，此时订单关联的是账号ID。两个ID之间没有稳定映射关系，尤其在用户频繁切换设备或使用游客模式时。这种情况下，强行用 user_id 合并，等于把苹果和橙子放在同一个篮子里称重。

提示：在动代码前，必须完成一份《业务实体映射表》，明确列出每个数据源中“用户”“订单”“商品”这三个核心实体的唯一标识符（Primary Identifier）、生命周期规则、变更触发条件。例如：

• CRM系统中 member_id ：由系统自动生成，终身不变，注销后不可复用；
• 小程序用户表中 open_id ：微信生态内唯一，但同一用户在不同公众号/小程序下open_id不同；
• 支付宝小程序中 user_id ：支付宝账号体系下全局唯一，但需用户授权获取；
• 埋点日志中 device_id ：设备级标识，重装APP或清除存储后失效。

这个表不能由技术人员闭门造车，必须拉上业务方、产品、运营一起逐条确认。我见过最离谱的一次，是市场部认为“参与抽奖活动的用户”指所有点击抽奖按钮的人，而技术实现时按“完成抽奖动作并获得奖品”的用户来统计——两者重合度不到35%。没有这张表，后续所有合并都是沙上筑塔。

2.2 四类主流合并策略的适用边界与致命缺陷

市面上常提的“左连接”“内连接”“全外连接”，只是SQL语法层面的操作，真正决定成败的是 合并策略的选择逻辑 。根据我实测的5种主流策略，其适用场景和隐藏风险如下：

选择策略的核心原则只有一条： 用最弱的假设，覆盖最强的业务约束 。比如做风控模型，宁可用“时间窗口+设备ID+手机号”三重校验（假设弱），也不单独依赖“手机号”（假设强但易失效）。我在某信贷项目中曾坚持用三重校验，虽然初期开发慢了两周，但上线后关联准确率从73%提升至99.2%，坏账识别延迟从72小时缩短到4.3小时。

2.3 合并前必做的三道“安检”：绕过它们，99%的合并会返工

很多团队把合并当成ETL流水线的最后一个环节，这是巨大误区。真正的合并工作，80%应该在“合并前”完成。我强制推行的三道安检，已帮团队减少67%的返工：

第一道：字段血缘扫描（Field Lineage Scan）
不是简单看字段名，而是逆向追踪每个字段的生成路径。例如，CRM里的 last_order_date 字段，表面看是“最后一次下单日期”，但实际来源可能是：

• 50%来自订单库的 order_time （经ETL加工）
• 30%来自客服系统工单的 resolved_time （标记“用户咨询下单问题”）
• 20%来自人工导入的Excel（字段名为 last_buy_date ，无时间戳）
  如果不做血缘扫描，合并时直接拿这个字段做时间切片，就会把客服工单时间误认为真实下单时间，导致复购周期计算整体偏移2.3天。工具上，我们用Apache Atlas自动抓取元数据，再人工标注业务含义，形成带可信度标签的字段字典。

第二道：空值模式分析（Null Pattern Analysis）
空值从来不是随机出现的。我曾分析某物流公司的运单数据，发现 delivery_time 字段在华东区空值率12%，但在西北区高达89%。深入查证发现：西北区部分网点未部署电子签收设备，仍用纸质单据， delivery_time 需人工补录，而补录率极低。如果合并时对空值统一填“1970-01-01”，整个区域的时效分析就全废了。正确做法是：对每个关键字段，按地理、时间、业务线三个维度做空值率热力图，识别出系统性缺失模式，并针对性设计填充策略（如西北区 delivery_time 用同线路历史均值+GPS轨迹推算）。

第三道：主键分布熵检测（PK Entropy Check）
用信息熵量化主键的“唯一性健康度”。公式为：
$$ H = -\sum_{i=1}^{n} p_i \log_2 p_i $$
其中$p_i$是第i个主键值出现的概率。理想情况（完全唯一）下，H = log₂(N)，N为记录数。若H < 0.8 × log₂(N)，说明存在大量重复主键。某次合并前检测发现CRM的 mobile_phone 熵值仅为3.2（理论值应≥18.5），排查出是销售部门批量导入时，把“暂无”统一填成“13800138000”——这个“假号码”在库里出现了2.7万次。熵检测让我们在合并前就定位到数据源头问题，避免了下游所有分析被污染。

这三道安检平均耗时4.2小时，但能节省后续平均37小时的调试时间。记住：合并不是数据的终点，而是业务理解的起点。

3. 实操全流程拆解：从原始数据到可信宽表的12个关键步骤

3.1 步骤1-3：环境准备与元数据基建（占总工时35%，但决定成败）

步骤1：构建跨源元数据仓库
不用买商业工具，用开源方案即可：

• 用Apache Atlas采集各数据库的schema、字段注释、索引信息；
• 用DBT（Data Build Tool）编写YML文件，定义业务术语（如“有效订单”= status IN ('paid','shipped') AND amount > 0 ）；
• 用Superset搭建元数据看板，支持按业务域搜索字段（搜“复购”，自动列出CRM的 repeat_buy_flag 、订单库的 is_repeat_order 、埋点日志的 event_type='rebuy_click' ）。

关键技巧：在DBT模型中强制添加 meta 标签，例如：

models:
  - name: orders
    description: "所有支付成功的订单，含退款订单"
    meta:
      business_owner: "供应链中心-王磊"
      sls_level: "L2" # L1=原始事实表，L2=轻度聚合，L3=业务宽表
      pii_flag: true # 是否含个人身份信息

这样，合并时一眼就能看出哪些字段涉及隐私，需脱敏处理。

步骤2：统一时间戳标准
所有系统时间必须校准到UTC+0，并存储为TIMESTAMP WITH TIME ZONE类型。实操中，我们用以下三步：

1. 在每台数据库服务器部署chrony服务，同步到阿里云NTP服务器（ntp.aliyun.com）；
2. 对存量数据，用Python脚本批量修正：

# 修正POS系统时间（原为本地时间，无时区信息）
from dateutil import parser, tz
def fix_pos_time(raw_time):
    # 假设POS系统部署在北京，原始时间为东八区时间
    beijing_tz = tz.gettz('Asia/Shanghai')
    utc_tz = tz.UTC
    dt = parser.parse(raw_time).replace(tzinfo=beijing_tz)
    return dt.astimezone(utc_tz).isoformat()  # 输出: 2023-05-20T02:30:00+00:00

3. 新增ETL任务，在写入数据湖前，自动追加 ingest_time_utc 字段（当前UTC时间），用于追踪数据新鲜度。

步骤3：设计主数据桥接表（Master Data Bridge Table）
这是合并的“中枢神经”。以用户为例，桥接表结构如下：

canonical_id 是全局唯一业务主键，格式为 CAN-YYYYMMDD-XXXXX （日期+5位序列号）。 confidence_score 由规则引擎实时计算，例如：手机号+身份证号双匹配得0.98，仅设备ID匹配得0.75。合并时，永远以 canonical_id 为关联键，而非原始系统ID。

3.2 步骤4-7：核心合并逻辑实现（含代码级细节）

步骤4：实现智能主键解析器（Smart PK Parser）
不同系统主键格式千奇百怪，需统一解析。我们用正则+规则引擎实现：

import re
from typing import Dict, Optional

class SmartPKParser:
    # 预定义规则库（可热更新）
    RULES = [
        # CRM系统：CRM-20230520-00123
        (r'^CRM-(\d{8})-(\d{5})$', lambda m: {'system': 'CRM', 'date': m.group(1), 'seq': m.group(2)}),
        # 小程序：wx_abc123_def456 （前缀wx_，中间app_id，后缀open_id）
        (r'^wx_([a-z0-9]{6})_([a-z0-9]{6})$', lambda m: {'system': 'WECHAT', 'app_id': m.group(1), 'open_id': m.group(2)}),
        # 埋点日志：dev_abc123 （dev_开头为测试设备）
        (r'^dev_([a-z0-9]{6})$', lambda m: {'system': 'TRACKING', 'env': 'dev', 'device_hash': m.group(1)}),
    ]
    
    @staticmethod
    def parse(pk: str) -> Optional[Dict]:
        for pattern, handler in SmartPKParser.RULES:
            match = re.match(pattern, pk)
            if match:
                return handler(match)
        return None  # 无法解析，交由人工审核队列

# 使用示例
result = SmartPKParser.parse("CRM-20230520-00123")
# 返回: {'system': 'CRM', 'date': '20230520', 'seq': '00123'}

该解析器嵌入ETL任务，在读取原始数据时自动标注来源系统、提取关键特征，为后续桥接表生成提供输入。

步骤5：桥接表增量更新策略
桥接表不能全量重建（耗时太长），必须增量更新。我们采用“双写+状态机”模式：

• 当新数据进入，先写入 bridge_staging 临时表；
• 启动状态机，对每条记录执行：
  1. 若 source_system + source_id 已存在，且 canonical_id 相同 → 更新 last_updated 和 confidence_score ；
  2. 若 source_system + source_id 已存在，但 canonical_id 不同 → 触发冲突解决流程（人工审核或规则仲裁）；
  3. 若为全新组合 → 分配新 canonical_id ，置 confidence_score 为初始值（如0.8）。
     状态机用Airflow DAG编排，每个环节有超时熔断（如人工审核超2小时自动降级为“待确认”状态）。

步骤6：宽表构建的JOIN顺序优化
合并多张表时，JOIN顺序直接影响性能和结果正确性。我们遵循“小表驱动大表+高选择性条件前置”原则：

1. 先JOIN主数据桥接表（小表，百万级）与核心事实表（如订单表，十亿级），用 canonical_id 关联；
2. 再LEFT JOIN维度表（如商品表、门店表），用外键关联；
3. 最后JOIN行为日志表（百亿级），必须加时间窗口过滤：

-- 错误：先JOIN日志表，再过滤（扫描全表）
SELECT * FROM orders o
LEFT JOIN tracking_log t ON o.canonical_id = t.canonical_id
WHERE t.event_time BETWEEN o.order_time - INTERVAL '30 minutes' AND o.order_time + INTERVAL '30 minutes';

-- 正确：先过滤日志表，再JOIN（利用分区剪枝）
SELECT * FROM orders o
LEFT JOIN (
  SELECT * FROM tracking_log 
  WHERE event_time >= '2023-05-20' AND event_time < '2023-05-21'
) t ON o.canonical_id = t.canonical_id 
  AND t.event_time BETWEEN o.order_time - INTERVAL '30 minutes' AND o.order_time + INTERVAL '30 minutes';

实测显示，正确顺序使查询耗时从47分钟降至2.1分钟。

步骤7：空值与异常值的业务化填充
绝不盲目用均值/众数填充。我们按业务规则分级处理：

• L1级（强业务约束） ：如订单金额为空，必须报错阻断，因为“无金额的订单”违反业务逻辑；
• L2级（可推算） ：如配送距离为空，用起点终点GPS坐标调用高德API实时计算（缓存1小时）；
• L3级（统计填充） ：如用户年龄为空，用同城市、同性别、同消费水平用户的年龄中位数填充，并打标 age_filled_by_median ；
• L4级（标记丢弃） ：如主键完全缺失，整条记录进入 quarantine 隔离区，供数据治理团队分析。
  所有填充操作记录在 data_enrichment_log 表中，包含填充时间、填充规则、置信度，确保可审计。

3.3 步骤8-12：质量保障与交付（让合并结果真正可信）

步骤8：构建合并质量看板
用Grafana搭建实时看板，监控5个黄金指标：

1. 关联成功率 = 关联成功记录数 / 总记录数（目标>99.5%）；
2. 主键冲突率 = 桥接表中 canonical_id 冲突次数 / 总更新次数（目标<0.01%）；
3. 时间偏移中位数 ：各系统时间戳与UTC的偏差（目标<1秒）；
4. 字段完整性率 ：关键字段（如订单金额、用户ID）非空率（目标>99.9%）；
5. 业务逻辑一致性 ：如“下单用户数”在宽表中应等于CRM中 active_users （允许±0.3%误差）。
   看板设置三级告警：黄色（偏离阈值）、红色（超阈值）、黑色（数据中断）。

步骤9：生成合并影响报告（Impact Report）
每次合并任务完成后，自动生成PDF报告，包含：

• 影响范围 ：本次合并影响的下游报表（如“会员复购分析看板”“区域销售日报”）；
• 变更摘要 ：新增字段、修改字段逻辑、废弃字段列表；
• 数据漂移分析 ：与上期相比，关键指标变化率（如“7日复购率”从23.4%→24.1%，+0.7pp）；
• 风险提示 ：如“西北区delivery_time填充率仅62%，建议下周升级GPS设备”。
  报告自动邮件发送给业务方负责人，要求48小时内确认。

步骤10：宽表版本化管理
宽表不是静态快照，而是持续演化的产物。我们用Delta Lake实现：

• 每次合并生成新版本（version=20230520001）；
• 支持时间旅行查询： SELECT * FROM wide_table VERSION AS OF 20230519001 ；
• 业务方可随时回滚到任一历史版本，避免“改坏一个字段，全盘崩溃”。
  版本号规则： YYYYMMDD + 3位序列号 ，每日最多999次合并。

步骤11：下游消费适配层（Consumption Adapter）
为不同下游系统提供定制化接口：

• BI工具（Tableau/Power BI）：提供物化视图，字段名转为业务语言（ canonical_id → 会员唯一编码 ）；
• 机器学习平台：提供Parquet文件，按 canonical_id 分桶，预计算常用特征（如 7日订单数 、 平均客单价 ）；
• 实时API：用Flink SQL构建流式宽表，支持毫秒级查询（ GET /user/{id}/profile ）。
  适配层与宽表物理隔离，确保上游变更不影响下游。

步骤12：建立数据契约（Data Contract）
用JSON Schema定义宽表契约，存于Git仓库：

{
  "title": "会员宽表",
  "type": "object",
  "properties": {
    "canonical_id": {"type": "string", "description": "全局唯一会员编码"},
    "first_order_time": {"type": "string", "format": "date-time", "description": "首次下单时间（UTC）"},
    "total_orders_30d": {"type": "integer", "minimum": 0, "description": "近30天订单数"}
  },
  "required": ["canonical_id", "first_order_time"],
  "x-data-owner": "会员增长中心",
  "x-sla": "freshness: <15min, accuracy: >99.9%"
}

所有下游系统接入前，必须通过契约校验。契约变更需走CR（Change Request）流程，影响评估通过后方可发布。

4. 常见问题与实战排障：那些文档里不会写的血泪教训

4.1 “合并后数据量暴增10倍！”——笛卡尔积陷阱的终极解法

现象：某次合并用户表与优惠券表后，宽表记录数从200万暴涨到2.3亿，远超预期。
根因分析：优惠券表中存在大量 coupon_id=NULL 的测试数据，而用户表中 user_id 无NULL值。当执行 LEFT JOIN 时，NULL值被当作一个特殊键，导致每个用户都与所有NULL优惠券匹配，产生笛卡尔积。
解决方案：

1. 预防 ：在ETL清洗阶段，对所有外键字段强制NOT NULL约束，NULL值统一替换为 __UNKNOWN__ （字符串）或 -1 （整数）；
2. 检测 ：在JOIN前，运行探针SQL：

SELECT COUNT(*) as null_count 
FROM coupons 
WHERE coupon_id IS NULL;
-- 若null_count > 0，立即告警并终止合并任务

3. 修复 ：若已发生，用以下SQL快速清理：

-- 创建临时表，排除NULL键
CREATE TABLE coupons_clean AS 
SELECT * FROM coupons WHERE coupon_id IS NOT NULL;

-- 用clean表重新JOIN
SELECT u.*, c.* 
FROM users u 
LEFT JOIN coupons_clean c ON u.user_id = c.user_id;

经验：所有JOIN操作前，必须对关联字段做 IS NULL 探针，这是我的铁律。

4.2 “时间对不上！明明同一单，POS显示14:30，小程序显示14:32”——系统时钟漂移的实战校准

现象：跨系统时间对比误差普遍在5-15秒，导致时间窗口匹配失败率高达34%。
深层原因：

• POS终端多为Windows CE系统，NTP服务默认关闭；
• 小程序后端部署在Kubernetes集群，节点时钟未配置chrony；
• 外卖平台API返回时间戳为服务端生成，但未提供时钟偏移信息。
  校准方案：

1. 硬件层 ：为所有POS终端安装chrony客户端，指向内网NTP服务器（避免公网依赖）；
2. 应用层 ：在小程序API响应头中增加 X-Server-Time: 1684567890.123 （毫秒级时间戳），客户端收到后计算与本地时间差，作为后续请求的偏移补偿；
3. 数据层 ：对存量数据，用“锚点事件”校准。例如，选取一笔已知的、三方系统均有记录的订单（如CEO亲自下单），计算各系统时间戳与真实时间的偏差，再批量修正。
   实测效果：校准后，时间误差收敛至±0.3秒内，匹配成功率从66%提升至98.7%。

4.3 “为什么合并后，同一个用户的订单金额变成负数？”——货币单位不一致的隐形杀手

现象：某次合并国际站订单后，发现大量订单金额为负值，但原始数据均为正数。
真相：订单库中金额单位为“分”（integer），而财务系统导出的汇率表中金额单位为“美元”（decimal），ETL脚本错误地将“分”直接除以汇率，导致数值缩小100倍，再经四舍五入变成负数。
避坑指南：

• 强制单位声明 ：在元数据中，每个数值字段必须标注 unit 属性，如 amount: {type: integer, unit: "CNY_cent"} ；
• 单位转换检查 ：在JOIN前，自动扫描所有数值字段的 unit ，若单位不一致，强制插入转换函数：

-- 自动注入：当orders.amount.unit='CNY_cent'，而exchange.rate.unit='USD'时
SELECT 
  o.order_id,
  o.amount / 100.0 * e.rate AS amount_usd  -- 先转元，再乘汇率
FROM orders o
JOIN exchange_rate e ON o.currency = e.currency;

• 负值根因分析 ：对所有负值字段，运行专项SQL：

SELECT 
  field_name,
  COUNT(*) as negative_count,
  MIN(value) as min_value,
  MAX(value) as max_value
FROM data_profile 
WHERE value < 0 
GROUP BY field_name;

然后人工核查最小值是否符合业务逻辑（如退款金额可为负，但订单金额绝不能为负）。

4.4 “合并结果每天都不一样！”——非确定性排序引发的幽灵Bug

现象：同一份SQL，每天跑出的宽表中，某用户的最近订单ID（ last_order_id ）不同。
定位过程：

• 排查数据源，确认各系统数据稳定；
• 检查ETL脚本，发现用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time) 取最近订单，但 order_time 存在大量重复值（同一秒内多单）；
• 当 order_time 相同时，数据库默认按物理存储顺序排序，而存储顺序受数据写入批次、压缩算法影响，每日波动。
  根治方案：

1. 排序键增强 ：在ORDER BY中加入唯一性字段，如 ORDER BY order_time, order_id （ order_id 全局唯一）；
2. 业务规则兜底 ：若仍需取“最近”，明确定义“最近”= MAX(order_time) ，再用 ARRAY_AGG(order_id ORDER BY order_time DESC LIMIT 1) 取对应ID；
3. 非确定性检测 ：在质量看板中增加“排序稳定性”指标，对同一用户，连续3天 last_order_id 变化率>5%即告警。
   教训：任何涉及 ORDER BY 的操作，必须确保排序键组合具备唯一性，否则就是埋雷。

4.5 “合并后，BI看板里的数字和我手动算的差0.03%”——浮点数精度丢失的精准修复

现象：财务对账时，宽表汇总的月度GMV与ERP系统差127.89元，相对误差0.03%。
根源：在宽表构建中，对订单金额做了多次 ROUND(amount * rate, 2) 运算，每次四舍五入引入微小误差，累积后放大。
专业解法：

• 全程整数运算 ：金额单位统一为“分”（integer），汇率用 DECIMAL(18,6) 存储，计算时先乘后除：

-- 错误：多次ROUND
ROUND(ROUND(10000 * 6.451234, 2) * 0.98, 2)  -- 误差累积

-- 正确：一次ROUND，且用整数防浮点
ROUND((10000 * 6451234 / 1000000) * 98 / 100, 0)  -- 结果为整数分

• 财务级精度保障 ：对所有涉及金钱的字段，宽表中存储为 DECIMAL(18,2) ，并在DBT模型中添加测试：

tests:
  - dbt_utils.expression_is_true:
      expression: "ABS(gmv_cny - gmv_usd * exchange_rate) < 0.01"

• 差异溯源工具 ：开发专用脚本，输入两组数据（宽表vs ERP），自动输出差异明细：

差异明细：
- 订单ID ORD-20230520-001：宽表=100.00，ERP=100.01，差-0.01
  原因：汇率表中2023-05-20汇率为6.451234，宽表用6.45123，少0.000004
- 订单ID ORD-20230520-002：宽表=200.00，ERP=200.00，一致

精度问题没有“差不多”，财务场景必须做到小数点后两位零误差。

5. 经验沉淀：从项目实践中淬炼出的7条硬核法则

在完成第37个跨系统合并项目后，我把那些反复验证、血泪换来的经验，浓缩成7条可直接执行的法则。它们不是教科书理论，而是我在凌晨三点盯着监控大屏时，用咖啡和挫败感熬出来的真知：

法则1：永远不要相信“主键唯一”的承诺，必须用熵值现场验证
某次上线前，对方DBA拍胸脯保证CRM的 member_id 100%唯一。我们信了，没做熵检测。上线后发现 member_id 重复率0.02%，原因是历史数据迁移时，旧系统用 mobile+name 拼接生成ID，而重名+同号情况频发。从此，所有主键入库前必跑 SELECT -SUM(p * LOG2(p)) FROM (SELECT COUNT(*)/COUNT(*)::FLOAT p FROM table GROUP BY pk) t ，熵值低于阈值直接拒收。

法则2：时间窗口不是参数，而是需要AB测试的业务变量
“±30分钟”不是拍脑袋定的。我们用历史数据做AB测试：对10万笔已知关联的订单，测试±15/±30/±45分钟窗口的匹配成功率与误匹配率，画出ROC曲线，选在曲线上升拐点处（通常成功率92%、误匹配率0.7%）。这个值会随业务变化，每月重测一次。

法则3：空值不是缺失，而是业务信号，必须分类建模