三类时间各管一段
事实表通常要区分三类时间：业务时间是事件真正发生的时刻，入仓时间是首次写入数仓的时刻，更新时间是最近一次被变更的时刻。业务时间服务统计口径，入仓时间服务延迟监控与重放排查，更新时间服务幂等与变更审计。只保留一个时间列时，一旦遇到「数据为什么变了」这类问题，链路上就缺少判断依据，只能翻日志去猜。
基本信息
| 业务时间 | 统计口径基准，分区一般由它折算 |
|---|---|
| 入仓时间 | 首次写入时刻，用于延迟监控 |
| 更新时间 | 最近变更时刻，用于幂等与排查 |
| 写入要求 | 入仓时间不因重跑而改写 |
| 典型组合 | biz_ts、etl_in_ts、etl_upd_ts |
典型使用场景
- 统计日粒度指标时按业务时间归属，避免入库延迟影响口径
- 监控链路时延：入仓时间减业务时间得到端到端延迟
- 排查数据变更：用更新时间定位是哪个批次改写了记录
- 幂等写入判断：按业务键配合更新时间取最新版本
- 数据新鲜度告警：分区最大入仓时间超过阈值即触发
三时间列
三时间列
-- 三类时间列各司其职
CREATE TABLE dwd_order (
order_id string,
user_id bigint,
amount decimal(18,2),
biz_ts timestamp COMMENT '业务发生时间',
etl_in_ts timestamp COMMENT '首次入仓时间',
etl_upd_ts timestamp COMMENT '最近更新时间'
) PARTITIONED BY (dt string)
STORED AS ORC;
-- 新鲜度检查：分区内最大的入仓时间
SELECT max(etl_in_ts) AS last_in FROM dwd_order WHERE dt = '2026-10-12';时间列读法
| 时间列 | 用途 | 异常表现 |
|---|---|---|
| biz_ts | 业务统计与分区归属 | 缺失时无法按业务日归属 |
| etl_in_ts | 延迟监控、重放排查 | 被重跑覆盖则延迟判断失效 |
| etl_upd_ts | 幂等与变更定位 | 不更新则看不出数据被改写 |
| 时间空值 | 上游漏字段 | 无兜底会造成分区错乱 |
入仓时间与更新时间的写入要幂等：重跑同一分区时保留首次入库时间，只刷新最近变更时间，否则延迟监控的历史数据会随重跑漂移。
时区要统一声明：若入库时间用服务器本地时间、业务时间用业务时区，两者相减得到的延迟会凭空多出数小时，看起来像链路故障。