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

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

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


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

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

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

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

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

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

✅ 解决方案:分层建模

将数据处理过程拆解为 标准化流水线,每层职责清晰、可复用、易维护。


二、阿里四层模型全景图

源系统

(MySQL, Kafka, 日志)

ODS

贴源层

DWD

明细层

DWS

汇总层

ADS

应用层

各层核心职责速览
层级 全称 中文名 核心职责
ODS Operational Data Store 贴源层 原始数据镜像,结构与源系统一致
DWD Data Warehouse Detail 明细层 清洗、标准化、维度退化后的明细事实
DWS Data Warehouse Summary 汇总层 按主题预聚合的公共指标宽表
ADS Application 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

ADS

DWS

DWD

ODS

源系统

ads_sales_report

(销售日报)

ads_user_retention

(用户留存)

ads_realtime_dashboard

(实时大屏)

dws_user_daily

(用户日指标)

dws_item_hourly

(商品小时指标)

dwd_order_di

(宽表: 订单+商品信息)

dwd_click_log_di

(宽表: 点击+商品信息)

ods_order

(order_id, user_id, ...)

ods_click_log

(user_id, item_id, ts)

MySQL: orders

Kafka: user_clicks

🔁 数据流向:

ODS(原始) → DWD(清洗宽表) → DWS(聚合指标) → ADS(业务报表)


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

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

📌 核心价值:

"DWD 保证数据可信,DWS 保证查询高效。"


六、常见误区与建议

❌ 误区 1:跳过 DWD,直接从 ODS 聚合
  • 风险:脏数据导致指标错误,且无法追溯

  • 建议:DWD 是数仓的"地基",不可省略

❌ 误区 2:DWS 做过度聚合(如包含所有维度组合)
  • 风险:存储爆炸,维护困难

  • 建议:按高频分析场景设计,遵循"80/20 原则"

✅ 最佳实践
  1. DWD 表命名:dwd_{业务域}_{主题}_didi=daily incremental)

  2. DWS 表命名:dws_{主题}_{粒度}(如 dws_user_daily

  3. 维表管理:独立同步到数仓(如 dim_user, dim_item

  4. 血缘追踪:记录 ODS → DWD → DWS 的依赖关系(便于影响分析)


七、总结

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

  • ODS:保真原始数据

  • DWD:构建可信事实

  • DWS:加速分析查询

  • ADS:赋能业务场景

相关推荐
沐风清扬1 小时前
RuoYi-Cloud微服务架构核心技术揭秘
微服务·云原生·架构
Walter先生2 小时前
实时行情系统设计:从协议选择到高可用架构,再到数据源选型
后端·架构·实时行情数据源
Hilaku2 小时前
前端资质越高,越来越不敢随便升级框架?
前端·javascript·架构
AI服务老曹2 小时前
企业级视频中台的协议兼容性架构:基于 GB28181 与 RTSP 的全品牌设备统一接入方案
架构·音视频
得帆云2 小时前
企业AI原生架构深度拆解(下):从编排到交互,解锁AI落地的关键环节
人工智能·架构·ai-native
Carino_U3 小时前
全面理解mysql架构
mysql·adb·架构
renhongxia13 小时前
TrustTrade:人类启发的选择性共识降低大型语言模型交易代理的决策不确定性
人工智能·微服务·语言模型·自然语言处理·架构·机器人·知识图谱
dreamxian3 小时前
微服务1 -- MybatisPlus
java·微服务·架构
梦梦代码精3 小时前
Dify + 扣子 + n8n + BuildingAI:从零搭建写作自动化平台,踩坑与实战全记录
运维·人工智能·架构·gitee·开源·自动化
Mintopia3 小时前
企业落地 AI-Coding 的“权限与数据红线”简单版:能用到什么程度
人工智能·架构