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

张开发
• 2026/4/17 15:02:29 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

医疗大数据数据上报失败问题完整排查复盘
一、问题描述业务方反馈在对外数据上报过程中存在一条处方数据未成功上报客户平台无法查询到该记录。整体数据流转链路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、深刻理解数据开发与数据交付岗位核心保证数据准确、完整、不丢不乱。

更多文章