电商交易域多过程建模案例
电商交易域的典型做法是按业务过程分别建事实表：下单、支付、发货、退款，它们共享一致性维度（用户、商品、日期、渠道），并通过退化维度订单号串联。各过程独立声明自己的粒度：订单事实通常是一订单商品行一行，支付事实是一支付流水一行，退款则是负向度量行。跨过程指标在指标层组合计算，而不是把四个过程拼进一张宽事实表。
基本信息
| 业务过程 | 下单、支付、发货、退款 |
|---|---|
| 共享维度 | 用户、商品、日期、渠道先行做成一致性维度 |
| 串联键 | 订单号作为退化维度留在各事实表中 |
| 粒度声明 | 各过程独立声明，互不继承 |
| 负向处理 | 退款不修改支付行，插负向度量行 |
典型使用场景
- 下单分析：按商品与渠道看下单量与下单金额
- 支付分析：按支付方式与时段看支付成功率与支付金额
- 履约分析：发货与签收时效，按仓库与地区分组
- 退款分析：退款率与退款原因，用负向行计算净额
- 转化分析：支付金额与下单金额的比值需在同一维度上重算，不能对已有比率求平均
- 跨过程核对：支付金额应与订单金额在一致维度下可对账
四过程事实表
四过程事实表
-- fact_order / fact_pay / fact_ship / fact_refund
-- 通过 order_id 串联，共享 dim_user / dim_product / dim_date
SELECT p.dt, sum(p.pay_amt) AS paid_amt
FROM fact_pay p
WHERE p.dt = '2026-10-12'
GROUP BY p.dt;
-- 净额：退款以负向行参与，正负自相抵
SELECT order_id, sum(pay_amt) AS net_amt
FROM fact_pay
GROUP BY order_id;
-- 跨过程：下单金额与支付金额按同一维度对齐后比较
SELECT d.category_id,
sum(o.order_amt) AS order_amt,
sum(p.pay_amt) AS pay_amt
FROM fact_order o
JOIN fact_pay p ON o.order_id = p.order_id
JOIN dim_product d ON o.product_sk = d.product_sk
GROUP BY d.category_id;四过程事实对照
| 过程 | 粒度 | 关键度量 |
|---|---|---|
| 下单 | 订单 + 商品 | 下单金额、件数、优惠金额 |
| 支付 | 支付流水 | 支付金额、支付方式、支付时间 |
| 发货 | 包裹或订单 | 发货件数、运费、承运商 |
| 退款 | 退款流水（负向） | 退款金额、退款类型、原单引用 |
各过程分别建表、独立声明粒度，是这类模型最重要的纪律。跨过程指标（支付转化率、退款率）在指标层组合，不在一张宽事实里拼全集；把下单与支付拼进同一行看似省事，一旦出现部分支付、分批支付或支付时间与下单时间跨天，模型立刻无法表达。