电商链路分层实例
以电商交易域为例：ODS 贴源订单与退款数据，保留原始字段与编码；DWD 做去重、状态规范化与维表关联，形成订单明细；DWS 按门店与商品两个维度做日汇总；ADS 输出看板结果，供业务在上班前查看。每层的产出时间按「层-小时」排布并留出缓冲，补数严格按 ODS 到 ADS 的顺序逐层重跑。这条链路的价值在于把口径统一固化在中间层，看板、财务与运营取的是同一份数字。
基本信息
| 链路对象 | ods_order、ods_refund 到 dwd_trade_order_di，再到 dws_trade_store_day、dws_item_sku_day，最后到 ads_sale_board_day |
|---|---|
| 产出时间 | ODS 01:30、DWD 02:30、DWS 04:00、ADS 05:30 |
| 核心口径 | 仅统计已支付订单，退款单独处理，不在明细层抵消 |
| 补数顺序 | 严格按 ODS 到 DWD 到 DWS 到 ADS 逐层重跑 |
| 排查顺序 | 看板异常先检查 DWS 输入，再向上游逐层追查 |
| 缓冲要求 | 层间留出足够窗口，上游延迟时下游等待 |
典型使用场景
- 早间看板：把核心 ADS 排在上班前产出，业务到岗即可看到前一日结果
- 商品维度分析：dws_item_sku_day 支撑商品与 SKU 的日销售分析
- 退款对账：ods_refund 与 DWD 订单状态比对，核对退款笔数与金额
- 补数重跑：按层顺序逐层执行，避免用未更新的上游算出错误下游
- 链路优化：定位最耗时环节（通常是明细去重与维表关联）再针对性调优
DWS 汇总任务示例
DWS 汇总任务示例
-- DWS 依赖 DWD，仅计算当日分区
INSERT OVERWRITE TABLE dws_trade_store_day PARTITION (dt='2026-10-12')
SELECT store_id,
count(DISTINCT order_id) AS order_cnt, -- 订单数按去重计数
sum(pay_amt) AS pay_amt -- 支付金额求和
FROM dwd_trade_order_di
WHERE dt = '2026-10-12'
AND order_status = 'PAID' -- 口径：仅已支付订单
GROUP BY store_id;
-- 产出后立即校验：行数与金额落在预期区间
SELECT count(*) AS rows_cnt, sum(pay_amt) AS amt
FROM dws_trade_store_day WHERE dt = '2026-10-12';链路分层与产出时间
| 层 | 对象 | 产出时间 | 职责 |
|---|---|---|---|
| ODS | ods_order、ods_refund | 01:30 | 贴源落地，保留原始字段 |
| DWD | dwd_trade_order_di | 02:30 | 去重、状态规范化、维表关联 |
| DWS | dws_trade_store_day、dws_item_sku_day | 04:00 | 门店与商品维度日汇总 |
| ADS | ads_sale_board_day | 05:30 | 看板结果，直接对接业务 |
产出时间按层排布时要留出缓冲：上游延迟时下游应当等待，而不是按计划时间抢跑，否则会把空数据或半成品写进下游分区。
补数不能跳层。直接重跑 ADS 会用到尚未更新的 DWS 数据，任务成功、数字看着正常，实际口径仍旧，业务侧很难察觉。