BigQuery 导出的 event_date 按 UTC 分区 日报跟后台差八小时

SELECT DATE(TIMESTAMP_MICROS(event_timestamp), 'Asia/Shanghai') AS dt,
       COUNT(*) AS pv
FROM `project.analytics_123456.events_*`
WHERE event_name = 'page_view'
GROUP BY dt ORDER BY dt DESC;

从 BigQuery 导出的日报，event_date 分区按 UTC 切，和后台按上海时区显示的日报相比，每天晚上八点后的数据全跑到第二天。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。

原因不复杂，event_date 是事件时间按媒体资源时区换算后的日期，但分区表按 UTC 写入，导出时又直接拿分区日期当业务日期，跨时区就会错位八小时。后台报表用的是媒体资源时区，两边口径不同。

「event_date 时区」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。

处理上按这个顺序：导出时用 event_timestamp 重新按目标时区换算日期，别直接用分区名；确认媒体资源时区设置，团队内部统一一个口径；把换算后的日期和后台日报抽样对一遍，重点看二十点之后的订单。

改完只确认一件事：二十点后的事件落在当天，导出的日报和后台逐日对齐，差值只剩正常的处理延迟。