累积快照的定位
订单生命周期（下单、支付、发货、签收）适合用累积快照事实表承载：一行对应一个订单，各节点的时间戳记录在同一行上，随事件发生被反复更新。它与事务事实表逐事件追加不同，把跨天完成的同一笔业务收拢成一行，天然适合履约时效与订单漏斗分析。
基本信息
| 粒度 | 一个订单一行，订单号为主键 |
|---|---|
| 节点列 | create_ts、pay_ts、ship_ts、sign_ts |
| 派生列 | 支付时长、发货时长、签收时长、超期标记 |
| 更新方式 | 按订单号 upsert，节点列只填空值不覆盖已有值 |
| 平台差异 | Hive 需要 T+1 合并覆盖；Doris 与 MySQL 支持唯一键 upsert |
典型使用场景
- 履约时效考核：支付到发货、发货到签收的分段耗时，按仓库与商家汇总
- 订单漏斗分析：各节点到达率即转化率，未到达的节点为空，可直接算流失量
- 超期预警：承诺时效内未签收的订单筛出来，推送客服与仓储跟进
- 取消与关闭分析：取消时间单独成列，判断取消集中在前段还是后段
- 补数重跑：迟到订单到达后重跑当天分区，靠订单号幂等覆盖
累积快照建表与合并
累积快照建表与合并
-- 一行一单：节点时间戳为空表示该节点尚未到达
CREATE TABLE fact_order_flow (
order_id string COMMENT '订单号',
create_ts timestamp COMMENT '下单时间',
pay_ts timestamp COMMENT '首次支付成功时间',
ship_ts timestamp COMMENT '首次发货时间',
sign_ts timestamp COMMENT '签收时间',
cancel_ts timestamp COMMENT '取消时间，与签收互斥'
) PARTITIONED BY (dt string) STORED AS ORC;
-- 合并时旧值不能被新批次的空值抹掉
MERGE INTO fact_order_flow t USING stg_order_flow s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.pay_ts = coalesce(s.pay_ts, t.pay_ts);节点与派生指标
| 节点或派生列 | 含义 | 异常表现 |
|---|---|---|
| pay_ts | 首次支付成功时间 | 为空但订单已关闭，说明支付从未成功 |
| ship_ts | 首次出库发货时间 | 长期为空说明仓库积压或单据未推送 |
| sign_ts | 签收时间 | 为空要区分未签收与回传延迟，否则签收率虚低 |
| pay_dur | 支付时长等于支付时间减下单时间 | 出现负值或极大值说明时钟不一致或数据回放 |
| 超期标记 | 按承诺时效派生 | 判定口径变化会让超期率整段跳变 |
节点时间取首达时间：支付重试、拆单多次发货都只记第一次，否则耗时被反复拉长，时效考核结果会随重试次数波动。
取消单与关闭单要单独标记并排除在时效样本之外，混进样本会让履约时效看起来比实际更好，掩盖真实超期问题。