ODS、DWD、DWS、ADS 数据分层与建模

数据分层不是把表名改成四个前缀，而是为每一层定义稳定的粒度、责任和重算方式。分层越清晰，指标越容易复用和追溯。

四层职责

• ODS：保留来源系统的原始记录，尽量少改字段，支持回放。
• DWD：完成清洗、类型统一、去重和维度补全，形成可复用明细。
• DWS：按主题域汇总，如用户日、商品日、门店日。
• ADS：面向报表、接口和运营页面的应用数据。

一个订单明细事实表的粒度可以定义为“一行代表一个订单商品行”。只要粒度写清楚，金额、数量和退款的计算就不会被重复 JOIN 放大。

维度模型示例

事实：fct_order_item
  order_id, user_id, sku_id, shop_id, paid_at, amount
维度：dim_user、dim_sku、dim_shop、dim_date
汇总：dws_shop_day、dws_sku_day
应用：ads_revenue_dashboard

缓慢变化维度要明确是覆盖更新还是保留历史版本。需要复盘历史订单时，通常用版本号和生效时间保存当时的归属。

指标口径要成为契约

“成交用户数”是支付成功的去重用户，还是创建订单的用户？指标定义应包含名称、粒度、过滤条件、时间字段、去重键、负责人和示例 SQL。下游只能引用已发布指标，不能私自复制一份逻辑。

增量与回补

增量任务使用业务更新时间或 CDC 位点，但要处理迟到数据、时区和重复事件。每天保留可重跑的批次参数，回补时只覆盖受影响的分区，并重新计算下游汇总。

分层后的验收

每批数据都检查行数、主键唯一性、金额非负、维度关联率、时间范围和与来源系统的对账差异。失败批次进入隔离区，不能用默认值静默吞掉。

分层的最终目的，是让每个数字都能从 ADS 追溯到 DWS、DWD、ODS 和原始事件，任何口径变化都有版本和影响范围。