医疗大数据数据上报失败问题完整排查复盘

一、问题描述

业务方反馈，在对外数据上报过程中，存在一条处方数据未成功上报，客户平台无法查询到该记录。整体数据流转链路：ADS 层数据（StarRocks）→ 数据采集同步任务 → MySQL 前置库（bizreport）→ 对外数据上报接口。

二、初步定位步骤

根据业务反馈，登录数据上报平台，定位到具体异常报单信息。

从异常单据中提取最关键唯一标识：处方号，作为整个排查的核心依据。

使用处方号分别查询两张核心业务表：

门诊处方主表：数据存在，字段完整，更新时间正常。

门诊处方代煎子表：无任何匹配记录，全部为空。

初步判断：主表数据正常到达 ADS 层，问题出在子表数据未生成，导致最终上报缺失。

三、排查原则与思路

遇到子表数据缺失，遵循先业务、后技术；先源头、后加工的标准排查逻辑：

第一步：确认业务真实性

首先核查该处方在源端系统（HIS）中的发药方式：

若为自取、自煎，子表不需要数据，属于正常逻辑。

若为代煎、免煎等需要记入子表的类型，则为异常问题。

经确认，该处方属于应进入子表的类型，因此进入技术排查。

第二步：分层技术排查（ODS → ADS）

优先查询 ODS 原始层数据，ODS 最贴近源端，排查成本最低。

结果：ODS 层存在该处方完整数据，说明源头采集正常。

结论：问题出在 ADS 层 ETL 转换逻辑。

四、SQL 逻辑定位详细过程

找到对应子表的数据开发脚本，复制 SQL 到 DataGrip 执行调试。

重点排查：SELECT 字段、JOIN 关联、WHERE 过滤条件。

高效定位技巧：

先注释掉所有 WHERE 条件，仅添加处方号限定，查看是否出数据。

注释全部 WHERE 后，数据正常显示 → 100% 是过滤条件导致数据被屏蔽。

逐步恢复 WHERE 条件，逐行测试，最终定位到异常条件：

AND 发药类型 IN ('01','02')

五、根因分析

查询业务字典含义：

01：代煎

02：自煎

03：免煎（业务新增类型，原有脚本未更新）

异常处方的发药类型为 03（免煎），不在原有过滤范围内，被直接过滤，导致子表无数据，最终上报失败。

六、问题根本原因总结

ETL 脚本中发药类型枚举值硬编码不全，未兼容业务新增的03（免煎）类型，导致符合业务要求的数据被错误过滤，造成数据丢失与上报失败。

七、排查经验与个人收获

1、掌握了 ODS-ADS-MySQL 全链路数据排查方法，具备完整数据问题定位能力。

2、养成先业务判断、后技术排查的规范思维，避免盲目修改代码。

3、掌握WHERE 全注释快速定位法，能高效定位数据丢失类问题。

4、理解业务字典变更对 ETL 逻辑的影响，具备数据质量与数据一致性意识。

5、能够独立完成问题复现、定位、根因分析，并输出标准化排查 SOP。

6、深刻理解数据开发与数据交付岗位核心：保证数据准确、完整、不丢不乱。