ETL异常：Receipt进程定时执行无数据，重跑却成功，求技术分析

针对你遇到的ETL每日凌晨12点执行时receipt进程返回0 rows错误，但手动/重新执行正常的问题，以下是具体技术排查方向：

• 数据时间窗口逻辑问题
  检查receipt进程的数据过滤条件，比如是否依赖当日/前一日的时间字段。凌晨12点执行时，部分系统的日期切换可能存在延迟，导致程序读取的日期范围还未生成当日数据，或者前一日数据还未完全落地。比如日志里的Start : 240401是4月1日的数据，凌晨12点执行时，4月1日的源数据可能还在写入过程中，未达到可读取状态，手动执行时数据已完成写入。

• 上游依赖任务未完成
  确认receipt进程是否依赖其他上游数据同步/生成任务。凌晨调度时，上游任务可能因为资源不足、超时等原因未完成，导致receipt读取不到数据；手动执行时上游任务已经完成，所以能获取到数据。可以查看调度系统中上游任务的执行日志，确认其在凌晨12点左右的完成时间是否晚于receipt的启动时间。

• 数据库锁或资源竞争
  凌晨时段可能有其他定时任务（如备份、索引重建、数据归档）在执行，占用了数据库资源或者对源表加锁，导致receipt进程无法读取到数据。手动执行时这些任务已经结束，资源释放，所以能正常读取。可以查询数据库的锁日志、资源占用监控（CPU、IO、连接数），确认凌晨12点左右的资源情况。

• 时区或系统时间差异
  检查ETL调度服务器、源数据库服务器的时区设置是否一致。如果存在时区差，比如调度服务器是UTC时间，源数据库是北京时间，凌晨12点调度时，程序计算的日期范围可能和实际数据的日期不匹配，导致读取不到数据。手动执行时可能因为时间推移，时区计算的范围覆盖了实际数据。

• 临时表/中间数据的清理机制
  如果receipt进程依赖临时表或中间存储的数据，检查这些数据的清理策略是否在凌晨执行。比如凌晨12点刚好触发清理，导致receipt读取时临时表为空；手动执行时清理任务已完成但新的中间数据已生成，或者清理时间窗口错开。

• 调度器的执行上下文差异
  手动执行和调度器执行的环境可能存在差异，比如环境变量、权限、工作目录不同。例如调度器使用的用户没有读取某些源数据的权限，或者环境变量中的日期参数设置错误，手动执行时使用的是当前用户的正确上下文。可以对比两种执行方式的环境参数、权限配置。

内容的提问来源于stack exchange，提问作者data entry