数仓分层架构：阿里四层模型浅析

HongJianLi
1 阅读4分钟

数仓分层架构：阿里四层模型浅析

作为 Web 开发者，在与大数据团队协作时，常遇到“DWD 表”“DWS 指标”等概念。为打通数据链路认知，本文系统梳理阿里实践中广泛采用的 ODS → DWD → DWS → ADS 四层模型，帮助开发者快速理解数据从原始日志到业务报表的流转逻辑。

一、为什么需要数仓分层？

在数据驱动业务的时代，企业每天产生海量数据（订单、日志、用户行为等）。若直接使用原始数据做分析，会面临：

  • ❓ 数据脏乱：源系统字段缺失、编码不统一、存在测试数据

  • ❓ 口径混乱：“日活用户”在不同报表中定义不一致

  • ❓ 查询缓慢：每次分析都需全表 JOIN + 聚合，耗时数分钟

  • ❓ 重复开发：每个团队都写一遍“用户下单统计”逻辑

✅ 解决方案：分层建模
将数据处理过程拆解为 标准化流水线，每层职责清晰、可复用、易维护。

二、阿里四层模型全景图

graph LR
    A["源系统\n(MySQL, Kafka, 日志)"] --> B["ODS\n贴源层"]
    B --> C["DWD\n明细层"]
    C --> D["DWS\n汇总层"]
    D --> E["ADS\n应用层"]

    classDef ods fill:#e6f7ff,stroke:#1890ff;
    classDef dwd fill:#ffe58f,stroke:#faad14;
    classDef dws fill:#b7eb8f,stroke:#52c41a;
    classDef ads fill:#ffadd2,stroke:#eb2f96;

    class B ods
    class C dwd
    class D dws
    class E ads

各层核心职责速览

层级全称中文名核心职责
ODSOperational Data Store贴源层原始数据镜像，结构与源系统一致
DWDData Warehouse Detail明细层清洗、标准化、维度退化后的明细事实
DWSData Warehouse Summary汇总层按主题预聚合的公共指标宽表
ADSApplication Data Service应用层面向具体业务场景的报表/接口

三、各层详解与最佳实践

📌 1. ODS（贴源层）—— 数据的“原始快照”

  • 特点：

    • 结构与源系统完全一致（如 MySQL 表结构）

    • 保留所有历史变更（通过分区或拉链表）

    • 不做任何清洗或转换

  • 存储形式：

    • 关系型数据 → 分区表（按天 dt=2024-06-01）

    • 日志数据 → 原始 JSON/文本文件

  • 示例：

💡 作用：作为数据回溯的“保险”，避免因清洗错误导致数据丢失。

📌 2. DWD（明细层）—— “干净的事实 + 宽表化”

  • 核心任务：

    • 清洗：过滤脏数据（如 amount < 0）、补全缺失值

    • 标准化：统一编码（如 status: 'paid' → 1）

    • 维度退化（Denormalization）：将维表字段打平到事实表

  • 关键原则：

    • 保持最细粒度（每行 = 一个业务事件）

    • 不做聚合

  • 示例：

✅ 价值：提供干净、一致、可复用的明细数据，是后续所有分析的唯一事实来源。

📌 3. DWS（汇总层）—— “公共指标的预计算引擎”

  • 核心任务：

    • 基于 DWD 进行轻度/中度聚合

    • 按业务主题（用户、商品、渠道）组织数据

    • 统一指标口径（如“支付订单数”只在此定义一次）

  • 设计要点：

    • 聚合粒度明确（如 user_id + dt）

    • 包含常用衍生指标（如点击率 = 点击量 / 曝光量）

  • 示例：

⚡ 性能收益：
查询“用户昨日订单总额” → 直接查 DWS（10万行） vs 扫描 DWD（1亿行） → 性能提升 100x+

📌 4. ADS（应用层）—— “面向业务的最后一公里”

  • 特点：

    • 高度定制化：为具体报表、大屏、API 服务

    • 可包含复杂业务逻辑（如留存率、漏斗转化）

    • 数据可能跨多个 DWS 表 JOIN

  • 示例：

🎯 目标：让业务方开箱即用，无需理解底层复杂逻辑。

四、完整电商案例：从 ODS 到 ADS

graph TD
    subgraph 源系统
        A["MySQL: orders"]
        B["Kafka: user_clicks"]
    end

    subgraph ODS
        C["ods_order\n(order_id, user_id, ...)"]
        D["ods_click_log\n(user_id, item_id, ts)"]
    end

    subgraph DWD
        E["dwd_order_di\n(宽表: 订单+商品信息)"]
        F["dwd_click_log_di\n(宽表: 点击+商品信息)"]
    end

    subgraph DWS
        G["dws_user_daily\n(用户日指标)"]
        H["dws_item_hourly\n(商品小时指标)"]
    end

    subgraph ADS
        I["ads_sales_report\n(销售日报)"]
        J["ads_user_retention\n(用户留存)"]
        K["ads_realtime_dashboard\n(实时大屏)"]
    end

    A --> C
    B --> D
    C --> E
    D --> F
    E --> G
    F --> G
    F --> H
    G --> I
    G --> J
    H --> K

🔁 数据流向：
ODS（原始） → DWD（清洗宽表） → DWS（聚合指标） → ADS（业务报表）

五、为什么必须要有 DWD → DWS？

问题无分层方案分层方案（DWD+DWS）
数据质量直接查 ODS，脏数据影响分析DWD 提供干净、统一的明细
查询性能每次全表聚合，响应 > 30sDWS 预计算，响应 < 1s
指标一致性各团队自行定义“日活”，结果冲突DWS 统一口径，一处定义
开发效率重复开发聚合逻辑复用 DWS，专注业务创新
资源消耗高频查询压垮集群DWS 减少 90% 计算量

📌 核心价值：
“DWD 保证数据可信，DWS 保证查询高效。”

六、常见误区与建议

❌ 误区 1：跳过 DWD，直接从 ODS 聚合

  • 风险：脏数据导致指标错误，且无法追溯

  • 建议：DWD 是数仓的“地基”，不可省略

❌ 误区 2：DWS 做过度聚合（如包含所有维度组合）

  • 风险：存储爆炸，维护困难

  • 建议：按高频分析场景设计，遵循“80/20 原则”

✅ 最佳实践

  1. DWD 表命名：dwd_{业务域}_{主题}_di（di=daily incremental）

  2. DWS 表命名：dws_{主题}_{粒度}（如 dws_user_daily）

  3. 维表管理：独立同步到数仓（如 dim_user, dim_item）

  4. 血缘追踪：记录 ODS → DWD → DWS 的依赖关系（便于影响分析）

七、总结

阿里四层模型 = 数据治理的“黄金标准”

  • ODS：保真原始数据

  • DWD：构建可信事实

  • DWS：加速分析查询

  • ADS：赋能业务场景

📌 记住：
“没有分层的数据仓库，就像没有地基的房子——看似快，实则危。”

avatar
文章
阅读
粉丝