BigQuery定时查询中run_date与current_date的效果差异问题

两段代码效果差异的核心是选的时间锚点逻辑完全不同，手动执行时结果一致只是特定测试场景下的巧合，放到调度生产环境就会暴露问题：

• current_date是完全依赖运行环境的非确定性函数，返回值直接取执行节点的当前系统日期，受节点时区配置、任务实际启动时间影响极大，和定时任务要统计的业务周期没有强绑定。
  你手动跑SQL的时候，用的是网页查询控制台的会话，时区和你本地一致，也不存在调度排队延迟，同时大部分SQL客户端会给调度内置变量@run_date默认赋值为当前日期，这时候两个函数算出来的过滤日期刚好相等，返回结果自然一致。
  但定时任务跑在调度集群的节点上：首先绝大多数大数据集群默认用UTC时区，和国内东八区差8小时；其次定时任务很容易因为计算资源排队、平台调度抖动，实际启动时间比配置的触发时间晚几个小时，极端情况会跨自然日。这两个问题都会导致current_date算出的日期和你实际要统计的业务日期对不上，要么根本查不到对应数据，要么查出来的日期不属于本次任务的统计范围。
• 绝大多数定时查询的写入逻辑自带周期校验：如果SQL返回的统计日期和本次调度预设的业务日期不匹配，就算SQL本身执行成功、正常返回了结果，调度系统也不会把这部分数据写入目标表，这就是你看到任务日志显示成功，但目标表没更新的直接原因。
• 第二版用的@run_date是调度系统内置的确定性业务时间变量，它的取值和任务什么时候跑、在哪个时区的节点跑完全没关系，只和你配置的调度规则绑定：比如你配置每日调度统计前一天的全量数据，不管任务是准点触发、延迟3小时跑、还是后续补跑几个月前的历史数据，@run_date都会固定返回本次调度对应的业务日期，DATE_SUB(@run_date, INTERVAL 1 DAY)永远能精准命中你要统计的日期，不会出偏差，所以能正常更新目标表。

小提示：你贴的两段SQL里SELECT字段列表最后都多了个多余的逗号，部分SQL引擎会直接报语法错误，正式使用时记得删掉。

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