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

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

作为 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:赋能业务场景

相关推荐
凌云C2 小时前
MCP协议架构模式详解:从基础到多种组合变体
架构
SmartBrain3 小时前
FastAPI 与 Langchain、Coze、Dify 技术深度对比分析
java·架构·fastapi
特立独行的猫a4 小时前
Kuikly多端框架(KMP)实战:现代Android/KMP状态管理指南:基于StateFlow与UDF架构的实践
android·架构·harmonyos·状态管理·kmp·stateflow·kuikly
海兰4 小时前
Elastic Stack 技术栈与无服务器架构核心指南
云原生·架构·serverless
无人装备硬件开发爱好者5 小时前
深入浅出双冗余无人机飞控:架构、软件实现与实战配置 2
架构·无人机
heimeiyingwang6 小时前
向量数据库Milvus的安装部署指南
java·数据库·架构·database
AI资源库6 小时前
stepfun-ai/Step-3.5-Flash模型深入解析
人工智能·语言模型·架构
楚来客6 小时前
具身智能技术架构发展简介
架构
hacklf20087 小时前
数据库高安全—openGauss安全整体架构&安全认证
数据库·安全·架构