● 淘宝商城数仓分层建设方案（ODS → ADS）

以"订单 + 会员 + 履约"三大核心域为例，完整演示从源到应用的分层落地。

---

一、整体分层架构

ADS 应用数据层 ──→ 报表 / 看板 / API / 算法特征
↑
DWS 汇总数据层 ──→ 主题宽表（用户主题、店铺主题、商品主题）
↑
DWD 明细数据层 ──→ 事实表（订单事实、履约事实、支付事实）
DIM 维度层 ──→ 会员维、商品维、店铺维、地区维、时间维
↑
ODS 贴源数据层 ──→ 原始业务数据（与源库结构一致）
↑
源系统 交易库 / 会员库 / 履约库 / 日志

---

二、ODS 层（贴源层）

定位：原样落地，保留原始数据；不做清洗，只做同步和分区。

命名规范：ods_{业务系统}{表名}{增量类型}

┌───────────────────────────┬───────────────────┬────────────────┬──────────┐
│ 表名 │ 来源 │ 同步方式 │ 分区 │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_trade_order_di │ 交易库 order 表 │ 增量（binlog） │ dt（日） │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_trade_order_item_di │ 交易库订单明细 │ 增量 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_trade_payment_di │ 支付库 payment 表 │ 增量 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_member_user_df │ 会员库 user 表 │ 全量快照 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_member_level_df │ 会员等级表 │ 全量 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_logistics_shipment_di │ 履约库 shipment │ 增量 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_logistics_track_di │ 物流轨迹表 │ 增量 │ dt │
├───────────────────────────┼───────────────────┼────────────────┼──────────┤
│ ods_log_app_click_di │ 客户端埋点日志 │ 增量 │ dt, hour │
└───────────────────────────┴───────────────────┴────────────────┴──────────┘

关键点：

• 字段、类型与源库一致，只增加 dt、etl_time 等技术字段
• 大表用增量（_di），小维表用全量（_df）
• 历史数据保留 30~90 天，重要表归档到冷存储

---

三、DIM 维度层

定位：构建一致性维度，供所有事实表关联使用。

┌────────────────────┬────────────────────────────────────────────┬─────────────────┐
│ 维表 │ 说明 │ 类型 │
├────────────────────┼────────────────────────────────────────────┼─────────────────┤
│ dim_member_user_df │ 会员维表（含等级、注册渠道、生命周期阶段） │ 缓慢变化维 SCD2 │
├────────────────────┼────────────────────────────────────────────┼─────────────────┤
│ dim_item_df │ 商品维表（类目、品牌、价格段） │ SCD2 │
├────────────────────┼────────────────────────────────────────────┼─────────────────┤
│ dim_shop_df │ 店铺维表（店铺类型、所属商家、所在地） │ 全量 │
├────────────────────┼────────────────────────────────────────────┼─────────────────┤
│ dim_region_df │ 地区维（省市区编码标准化） │ 全量 │
├────────────────────┼────────────────────────────────────────────┼─────────────────┤
│ dim_date │ 日期维（自然日、周、月、节假日、双11标记） │ 静态 │
└────────────────────┴────────────────────────────────────────────┴─────────────────┘

示例：dim_member_user_df 字段

user_id, nick_name, gender, age_segment, register_date, register_channel,
member_level, level_start_date, member_status, life_cycle_stage,
city, province, is_deleted, start_date, end_date, is_current

---

四、DWD 明细数据层

定位：基于业务过程建模，每个业务过程一张事实表；做清洗、脱敏、维度退化、口径统一。

命名规范：dwd_{域}{业务过程}{粒度}_{增量类型}

1. 交易域

dwd_trade_order_create_di（下单事实表）
order_id, parent_order_id, user_id, item_id, sku_id, shop_id,
buy_qty, item_price, order_amount, discount_amount, payable_amount,
order_create_time, order_source(APP/H5/小程序),
province_code, city_code,
– 退化维度
item_cate_1_id, item_cate_2_id, brand_id, shop_type,
dt

dwd_trade_order_pay_di（支付事实表）
order_id, user_id, pay_amount, pay_method, pay_time, pay_status, dt

dwd_trade_order_refund_di（退款事实表）

2. 会员域

dwd_member_register_di（注册事实）
dwd_member_login_di（登录事实）
dwd_member_level_change_di（等级变更事实）

3. 履约域

dwd_logi_shipment_di（发货事实）
shipment_id, order_id, user_id, shop_id, warehouse_id,
ship_time, expected_arrive_time, actual_arrive_time,
carrier_code, shipping_fee, weight, dt

dwd_logi_delivery_di（妥投事实）
dwd_logi_track_di（物流轨迹明细）

DWD 关键加工逻辑

• 数据清洗：手机号脱敏、地址标准化、异常订单过滤（金额为负、测试订单）
• 维度退化：把高频用的维度字段（类目、品牌、城市）冗余进事实表，减少 join
• 口径统一：例如"有效订单 = 已支付且未全额退款"，在 DWD 层就明确定义

---

五、DWS 汇总数据层

定位：按主题域、按统计周期做轻度聚合，构建宽表，避免重复计算。

命名规范：dws_{主题}{统计周期}{粒度}

1. 用户主题

dws_user_trade_1d（用户交易日汇总）
user_id, dt,
order_cnt_1d, order_amount_1d, pay_order_cnt_1d, pay_amount_1d,
refund_order_cnt_1d, refund_amount_1d,
buy_item_cnt_1d, buy_cate_cnt_1d

dws_user_trade_nd（用户交易多周期汇总：1d/7d/30d/90d）
user_id,
pay_amount_1d, pay_amount_7d, pay_amount_30d, pay_amount_90d,
pay_order_cnt_1d, pay_order_cnt_7d, pay_order_cnt_30d,
last_pay_date, first_pay_date, dt

dws_user_logi_nd（用户履约体验汇总）
user_id, avg_delivery_hours_30d, on_time_rate_30d, refund_rate_30d, dt

2. 店铺主题

dws_shop_trade_1d
shop_id, dt, gmv_1d, pay_amount_1d, pay_buyer_cnt_1d,
new_buyer_cnt_1d, old_buyer_cnt_1d, refund_amount_1d

dws_shop_logi_1d（店铺履约表现）

3. 商品主题

dws_item_trade_1d
item_id, dt, expose_cnt, click_cnt, add_cart_cnt, pay_qty, pay_amount,
pay_buyer_cnt, refund_qty

4. 履约主题

dws_logi_carrier_1d（按物流商汇总）
carrier_code, dt, ship_cnt, on_time_cnt, on_time_rate,
avg_delivery_hours, complaint_cnt

---

六、ADS 应用数据层

定位：直接服务于报表、看板、API、算法。一个应用一张表，强业务属性。

命名规范：ads_{业务方向}_{应用名}

1. 经营看板类

ads_gmv_overview_1d（大盘 GMV 日报）
dt, total_gmv, total_pay_amount, total_pay_buyer_cnt,
new_buyer_cnt, gmv_yoy, gmv_mom,
mobile_gmv, pc_gmv,
top1_cate_id, top1_cate_gmv

ads_double11_realtime（双11实时大屏，源自实时链路）

2. 会员运营类

ads_member_rfm（RFM 会员分层）
user_id, R_score, F_score, M_score, rfm_segment(重要价值/重要发展/流失预警…), dt

ads_member_lifecycle（会员生命周期分布）
dt, lifecycle_stage(新客/成长/成熟/衰退/流失), user_cnt, gmv_contribution

ads_member_churn_predict（流失预测特征宽表，喂给算法）

3. 商家服务类

ads_shop_score_1d（商家评分）
shop_id, dt, trade_score, service_score, logistics_score, total_score, rank

4. 履约监控类

ads_logi_timeliness_1d（履约时效监控）
dt, region, carrier_code, ship_cnt, on_time_rate, sla_breach_cnt

ads_logi_exception_alert（异常订单预警，供客服系统）

---

七、典型数据流示例：用户的"近30天支付金额"

ods_trade_order_di
ods_trade_payment_di
│
▼ 清洗、关联、退化维度
dwd_trade_order_pay_di
│
▼ 按用户聚合多周期
dws_user_trade_nd (pay_amount_30d)
│
▼ 打分、分层
ads_member_rfm
│
▼
BI 看板 / 营销系统 API

---

八、建设过程中的关键工程要点

┌──────────┬──────────────────────────────────────────────────────────────────────┐
│ 维度 │ 实践 │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 调度 │ DolphinScheduler / Airflow，按层级依赖编排，ODS→DIM/DWD→DWS→ADS │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 数据质量 │ 每层加 DQC 规则：主键唯一、非空、波动率、枚举值校验 │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 元数据 │ 表/字段血缘、口径文档、Owner 必填 │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 存储 │ ODS/DWD 用 ORC+Zstd 列存；ADS 小表可入 ClickHouse/StarRocks 加速查询 │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 实时 │ 双11等场景增加实时链路：Flink + Kafka，构建 ADS 实时表与离线对账 │
├──────────┼──────────────────────────────────────────────────────────────────────┤
│ 安全 │ 手机号、身份证在 DWD 层脱敏；ADS 按角色授权 │
└──────────┴──────────────────────────────────────────────────────────────────────┘

---

一句话总结

▎ ODS 是"原始仓库"，DWD/DIM 是"标准化原料"，DWS 是"半成品",ADS 是"成品"。
▎ 业务需求来了，理想状态是 80% 直接查 ADS，15% 查 DWS，5% 才下钻到 DWD —— 这就是分层建设的价值。