2. 数据链路全景与排障地图

复盘数据出现缺失或错配时，最忌讳的做法是“看到报表不对就直接查报表”。报表只是链路末端的一个投影，真正的问题往往发生在更早的环节。要把排障做快做准，必须先建立一张覆盖全链路的地图：数据从哪里产生、经过哪些系统、在每一跳发生了什么变换、最终以什么口径被消费。本节围绕“产生—采集—传输—存储—计算—应用”六个环节，梳理每一环的典型风险点，并给出可落地的排障定位方法。

一、六个环节的职责与边界

产生环节是业务系统写入原始数据的时刻，包括订单落库、埋点上报、设备上报、人工录入等。此环节的核心风险是“源头就没有”：字段未采集、必填校验缺失、客户端在弱网下丢事件、业务状态机异常导致记录未生成。采集环节负责把源数据抽取出来，常见形态有数据库增量抽取、日志采集、接口拉取、消息订阅。风险集中在抽取条件写错（时间窗口、状态过滤）、增量位点丢失、采集任务失败但未告警。传输环节是数据在系统间的搬运，包括消息队列、文件同步、API 调用。风险是乱序、重复、延迟、字段截断与编码不一致。

存储环节决定数据落地后的形态，如数仓分层表、对象存储文件、缓存。风险包括分区写错、覆盖写、主键冲突去重、Schema 演进不兼容。计算环节完成清洗、关联、聚合与指标加工，风险最隐蔽：关联键类型不一致导致关联不上、NULL 参与运算、口径变更未同步、任务依赖未就绪就开跑。应用环节是报表、看板、下游接口与模型，风险是缓存未刷新、筛选条件默认值、权限过滤、指标版本混用。

二、用“行数—命中率—口径”三步定位

面对一个“昨日订单报表少了 12%”的反馈，不要立刻打开 SQL 全表扫描。建议按固定顺序做三步核对，每一步都从应用端往上游回溯，找到第一个出现异常的环节即可停止。

第一步看行数趋势。取应用层指标对应的明细表，按天统计行数与主键去重数，与近 7 天均值对比。若行数骤降，问题大概率在产生、采集或存储；若行数正常但金额异常，则转向第二步。例如某日明细行数从日均 8.6 万降到 5.2 万，而源库订单表当日实际写入 8.5 万条，说明丢失发生在源库之后、明细表之前，应优先检查采集任务的增量位点与抽取过滤条件。

第二步看关联命中率。错配的典型表现是“数据都在，但关联不上”。对关键关联做命中率统计：left join 后统计右表主键为 NULL 的比例。若命中率从 99.2% 跌到 76%，常见原因是关联键类型不一致（如订单号一边是字符串、一边是数值，导致 '00123' 与 123 不相等）、前后空格、大小写差异或编码不同。排查时可直接对两表键做抽样比对：

-- 示例：检查关联键类型与格式差异（示例数据，非实测）
select
  count(*)                                   as 左表行数,
  sum(case when b.order_id is null then 1 else 0 end) as 未命中行数,
  sum(case when b.order_id is null then 1 else 0 end) * 1.0 / count(*) as 未命中率
from dwd_order_detail a
left join dim_order b
  on trim(a.order_id) = trim(cast(b.order_id as varchar))
where a.dt = '2024-06-01';

第三步比对口径版本。若行数与命中率都正常，但汇总值对不上，多半是计算口径或应用层问题：指标定义是否在近期变更、NULL 是否被计入分母、去重维度是否一致、看板缓存是否未刷新。此时应调出指标口径文档与计算 SQL，逐字段核对，而不是继续在数据里“捞”。

三、把风险点固化成排障地图

排障地图的价值在于把“经验”变成“可复用的检查顺序”。建议为每个环节维护一张最小检查表：产生环节核对必填字段与状态机；采集环节核对任务状态、位点、抽取窗口；传输环节核对消息积压、重复率、字段长度；存储环节核对分区、主键、Schema 变更记录；计算环节核对依赖就绪、关联命中率、NULL 处理；应用环节核对缓存时间、筛选默认值、指标版本号。

需要强调的是，链路中的每个环节都可能“看起来正常但实际已偏移”。例如采集任务显示成功，但抽取的是 T-2 分区；传输没有报错，但消息被重复消费；计算任务按时产出，但依赖的上游表当天是空分区。因此排障地图不能只看“成功/失败”状态，还要看数据本身的量与质：行数是否符合预期、主键是否唯一、关联是否命中、空值率是否突变。把这些指标做成每日基线监控，缺失与错配就能在进入应用层之前被发现，复盘时也更容易还原问题发生的第一现场。