大数据仓库分层是一套规范化数据流转、降低系统耦合、提升数据复用性与可维护性的设计方法论。其核心逻辑是将数据从 "原始接入" 到 "业务应用" 的全链路拆解为多个职责明确的层级,让每个层级专注于特定任务(如数据清洗、汇总计算、指标输出),最终实现数据资产的高效管理与价值释放。
在行业实践中,分层架构没有绝对统一的标准,但基于维度建模理论 和大数据技术特性,主流架构可分为「五层」(部分场景会简化为四层),从下到上依次为:ODS 层(操作型数据存储层)→ DIM 层(维度层)→ DWD 层(数据仓库明细层)→ DWS/DWT 层(数据仓库汇总层 / 主题层)→ ADS 层(应用数据服务层) 。
一、分层设计的核心目的
在讲解具体层级前,需先明确分层的 "价值"------ 为何不直接将业务数据导入应用?
- 解耦业务与数据:业务系统(如 ERP、CRM)的变更(如字段新增、表结构调整)仅影响底层 ODS 层,上层分析不受波及。
- 提升数据复用性:清洗后的明细数据(DWD 层)可支撑多个汇总需求(如用户分析、商品分析),避免重复清洗。
- 简化问题定位:数据异常时,可按 "ADS→DWS→DWD→ODS" 逐层回溯,快速定位问题根源(如 ADS 报表错误可能是 DWS 汇总逻辑错,而非 ODS 数据错)。
- 优化性能:通过汇总层(DWS/DWT)预计算高频指标,避免上层应用直接查询海量明细数据,降低计算压力。
- 统一数据口径:在中间层(如 DWS)定义统一的指标逻辑(如 "订单金额 = 支付金额 + 优惠金额"),避免不同应用重复计算导致口径不一致。
二、主流分层架构详解(五层模型)
以下按 "从下到上" 的顺序,详细拆解每个层级的定位、核心任务、数据特点、技术选型及典型案例(以电商业务为例)。
1. 第一层:ODS 层(Operational Data Store,操作型数据存储层)
定位
数据仓库的 "入口",直接对接业务系统,保留原始业务数据的形态,不做过多加工,仅完成 "数据落地" 与 "历史归档"。
核心任务
- 数据同步 :将业务数据库(MySQL、Oracle)、日志(用户行为日志)、API 接口等数据源的原始数据同步到数据仓库。
- 同步方式:
- 全量同步:适用于小表(如商品类目表),每天全量覆盖。
- 增量同步:适用于大表(如订单表),通过
CDC(变更数据捕获)
、时间戳、日志解析等方式同步新增 / 修改数据。
- 同步方式:
- 数据归档:按时间分区存储原始数据(如按天分区),支持历史数据回溯(如排查 3 个月前的订单异常)。
- 轻量处理:仅做 "格式转换"(如 JSON 转 Parquet)、"脏数据标记"(不删除,仅标记无效数据),不改变数据业务含义。
数据特点
- 粒度:与业务系统一致(如订单表的每一条原始记录)。
- 完整性:保留所有字段(包括冗余字段、状态码等)。
- 时效性:近实时或准实时(如 CDC 同步延迟 < 10 分钟)。
技术选型
- 存储:HDFS(海量数据)、HBase(实时查询需求)、Kudu(实时 + 批量混合场景)。
- 同步工具:Flink CDC、DataX、Sqoop、Canal(MySQL 日志解析)。
电商案例
- 表名:
ods_orders
(订单原始表)、ods_user_behavior_log
(用户行为日志表)。 - 字段:包含
order_id
(订单 ID)、user_id
(用户 ID)、pay_status
(支付状态码,如 1 = 未支付、2 = 已支付)、create_time
(创建时间)、raw_json
(原始日志 JSON,用于回溯)。
2. 第二层:DIM 层(Dimension Layer,维度层)
定位
存储分析维度相关的数据,是构建 "维度模型" 的核心(维度是分析的视角,如 "用户""商品""时间")。
核心任务
- 维度数据整合:将分散在业务系统中的维度数据(如用户信息在用户系统、商品信息在商品系统)统一汇聚到 DIM 层。
- 维度属性补全:补充维度的静态属性(如用户的 "注册时间""所属地区",商品的 "品牌""类目")。
- 维度层级构建:支持多层级分析(如 "商品类目" 分为 "一级类目→二级类目→三级类目","时间" 分为 "年→季→月→日")。
- 缓慢变化维度(SCD)处理 :
- SCD1:直接覆盖旧值(如商品的 "库存数量",变化频繁且无需历史追溯)。
- SCD2:新增行保留历史版本(如用户的 "所属部门",需追溯 "2023 年用户属于 A 部门,2024 年转到 B 部门"),通过
start_date
/end_date
/is_current
标记有效期。
数据特点
- 粒度:单维度的最小单元(如一个用户、一个商品、一天)。
- 稳定性:数据变化频率低(如用户的 "性别" 几乎不变,商品的 "品牌" 变化少)。
- 关联性:为上层 DWD/DWS 层提供关联维度(如订单明细关联用户维度获取 "用户地区")。
技术选型
- 存储:Hive(批量维度)、HBase(实时维度查询)、ClickHouse(高并发维度查询)。
电商案例
- 表名:
dim_user
(用户维度表)、dim_product
(商品维度表)、dim_date
(时间维度表)。 - 字段(
dim_user
):user_id
(用户 ID)、user_name
(用户名)、register_time
(注册时间)、region
(所属地区)、start_date
(生效开始时间)、end_date
(生效结束时间)、is_current
(是否当前版本)。
3. 第三层:DWD 层(Data Warehouse Detail,数据仓库明细层)
定位
数据仓库的 "核心明细层",对 ODS 层原始数据进行清洗、整合、标准化,生成 "干净、一致、可直接分析的明细事实数据"。
核心任务
- 数据清洗 :
- 剔除无效数据:删除测试数据(如
user_id=0
的订单)、重复数据(如重复提交的日志)。 - 处理缺失值:通过默认值(如 "未知地区")、关联补全(如通过
user_id
关联 DIM 层补全用户信息)修复缺失字段。 - 格式标准化:统一日期格式(如
2024-05-01
替代20240501
)、编码映射(如pay_status=2
映射为 "已支付")。
- 剔除无效数据:删除测试数据(如
- 数据整合 :
- 关联维度:将 ODS 层的事实数据(如订单)与 DIM 层的维度数据(如用户、商品)关联,补充分析所需的维度属性(如订单关联用户得到 "用户地区")。
- 拆分宽表:将 ODS 层分散的表(如订单表、订单支付表)合并为一张明细宽表(如
dwd_order_detail
,包含订单基本信息 + 支付信息)。
- 保留明细粒度:不做汇总,仅做 "明细级加工",确保数据可追溯到最细业务单元(如每一笔订单的每一个商品明细)。
数据特点
- 粒度:业务事实的最小粒度(如订单明细中的 "一个商品")。
- 质量:干净、一致、无冗余,是上层汇总的 "数据基石"。
- 灵活性:可支撑任意维度的下钻分析(如从 "全国销售额" 下钻到 "某地区某商品的销售额")。
技术选型
- 计算:Spark SQL、Flink SQL(支持批量 / 实时加工)。
- 存储:Hive(批量明细)、Iceberg/Hudi(支持增量更新的明细)。
电商案例
- 表名:
dwd_order_detail
(订单明细宽表)。 - 字段:
order_id
(订单 ID)、user_id
(用户 ID)、user_region
(用户地区,关联 dim_user)、product_id
(商品 ID)、product_brand
(商品品牌,关联 dim_product)、order_amount
(订单金额)、pay_time
(支付时间)、pay_status
(支付状态,已映射为中文)。
4. 第四层:DWS/DWT 层(Data Warehouse Service/Topic,数据仓库汇总层 / 主题层)
定位
基于 DWD 层的明细数据,按业务主题 / 分析维度进行汇总计算,生成 "预计算的汇总数据",减少上层应用的重复计算,提升查询效率。
这一层通常分为两类:
- DWS 层(汇总层):面向 "高频通用需求" 的轻量汇总,粒度较细(如按 "用户 + 天""商品 + 周" 汇总),支持灵活的跨主题分析。
- DWT 层(主题层):面向 "长期稳定主题" 的全量汇总,粒度较粗(如按 "用户全生命周期""商品全生命周期" 汇总),聚焦单一业务主题(如用户主题、商品主题)。
核心任务
- 确定汇总维度与指标 :
- 维度:按业务常用分析维度汇总(如时间维度:天 / 周 / 月;用户维度:用户 ID / 用户地区;商品维度:商品 ID / 商品品牌)。
- 指标:计算业务核心指标(如 "订单数、销售额、支付转化率、用户活跃度")。
- 分层汇总 :
- 轻度汇总(DWS):按 "小粒度周期" 汇总(如按 "用户 + 天" 汇总 "用户当日下单次数 / 金额")。
- 重度汇总(DWT):按 "大粒度主题" 汇总(如按 "用户" 汇总 "用户注册至今的总下单次数 / 累计消费金额")。
- 支持增量更新:基于 DWD 层的增量数据(如当日新增订单),增量更新汇总结果(如当日用户汇总数据 = 历史汇总 + 当日明细汇总),避免全量重算。
数据特点
- 粒度:比 DWD 层粗,按 "主题 + 维度" 聚合(如 "用户 + 天""商品 + 月")。
- 效率:预计算完成,上层应用直接查询汇总结果,响应时间从 "分钟级" 降至 "秒级"。
- 复用性:同一汇总数据可支撑多个应用(如 "用户日活跃度" 可同时用于 "运营日报" 和 "用户画像系统")。
技术选型
- 计算:Spark SQL(批量汇总)、Flink SQL(实时汇总,如实时用户活跃度)。
- 存储:Hive(批量汇总)、ClickHouse(实时高频汇总)、Kudu(实时更新汇总)。
电商案例
层级 | 表名 | 汇总维度 | 核心指标 |
---|---|---|---|
DWS | dws_user_order_daily | 用户 ID + 日期 | 当日下单次数、当日下单金额、当日支付次数 |
DWS | dws_product_sales_weekly | 商品 ID + 周 | 本周销量、本周销售额、本周退款次数 |
DWT | dwt_user_profile | 用户 ID | 总下单次数、累计消费金额、首次下单时间、最近下单时间 |
DWT | dwt_product_profile | 商品 ID | 总销量、累计销售额、上架时间、热销地区 TOP3 |
5. 第五层:ADS 层(Application Data Service,应用数据服务层)
定位
数据仓库的 "出口",直接对接业务应用场景,将 DWS/DWT 层的汇总数据加工为 "业务可用的最终指标",满足报表、dashboard、API 接口等需求。
核心任务
- 指标最终加工:基于 DWS/DWT 层数据,计算业务定制化指标(如 "月度 GMV 同比增长率""区域销售额占比")。
- 数据格式适配:按应用需求调整数据格式(如 JSON 格式供 API 调用,CSV 格式供报表下载)。
- 性能优化:针对高频查询场景(如实时 dashboard),采用列式存储、索引等技术提升查询速度。
数据特点
- 粒度:完全匹配业务需求(如 "日报表" 按 "日期 + 区域","月报表" 按 "月份 + 商品类目")。
- 时效性:按需提供(如实时 dashboard 需秒级更新,月度报表需 T+1 更新)。
- 易用性:数据直接可用,无需业务人员再加工。
技术选型
- 存储:ClickHouse(实时报表)、Impala(交互式查询)、MySQL(轻量报表)、Redis(高频缓存指标)。
- 应用对接:Superset(可视化 dashboard)、FineBI(BI 报表)、自研 API 服务(供业务系统调用)。
电商案例
- 表名:
ads_sales_daily_report
(每日销售报表)、ads_user_activity_monthly
(月度用户活跃度报表)。 - 字段(
ads_sales_daily_report
):日期、总销售额、总订单数、支付转化率(支付订单数 / 总订单数)、TOP3 热销地区、TOP3 热销商品。
三、数据流转与 ETL/ELT 实践
大数据仓库的分层本质是 "数据流转的过程",核心依赖ETL(Extract-Transform-Load) 或ELT(Extract-Load-Transform) 技术:

2. ETL vs ELT(大数据场景的选择)
- ETL:传统数仓常用,先在 "外部工具"(如 DataStage)清洗转换数据,再加载到仓库。适用于小数据量、清洗逻辑简单的场景。
- ELT :大数据场景主流,先将原始数据加载到 ODS 层(Load),再在仓库内部(如 Hive/Spark)进行转换(Transform)。优势:
- 支持海量数据:无需提前清洗,直接加载原始数据。
- 灵活迭代:转换逻辑修改时,无需重新抽取数据,仅重跑仓库内的任务。
四、分层架构的优势与注意事项
1. 核心优势
- 可维护性:每层职责单一,修改某一层(如 DWD 层清洗逻辑)不影响其他层。
- 数据质量可控:问题可逐层回溯(如 ADS 数据错→查 DWS→查 DWD→查 ODS),便于定位根因。
- 资源优化:汇总层预计算减少重复计算,降低集群资源消耗。
- 业务适配性:支持从 "明细分析" 到 "宏观指标" 的全场景需求(如分析师查 DWD 做深度分析,运营看 ADS 报表)。
2. 注意事项
- 避免过度分层:小型业务无需区分 DWS 和 DWT,可合并为 "汇总层",避免复杂度上升。
- 明确粒度标准:每层数据的粒度需提前定义(如 DWD 是明细、DWS 是 "用户 + 天"),避免粒度混乱导致分析错误。
- 管理数据血缘:通过工具(如 Atlas、DataHub)记录数据从 ODS 到 ADS 的流转关系,便于排查问题和合规审计。
- 生命周期管理:按层级设置数据保留周期(如 ODS 保留 1 年、ADS 保留 3 个月),避免存储资源浪费。
五、技术栈总结(以 Hadoop 生态为例)
层级 | 核心技术组件 | 核心作用 |
---|---|---|
ODS | Flink CDC/DataX、HDFS/HBase | 数据同步、原始数据存储 |
DIM | Hive/HBase、Spark SQL | 维度数据存储与加工 |
DWD | Spark SQL/Flink SQL、Hive/Iceberg | 明细数据清洗、宽表构建 |
DWS/DWT | Spark SQL/Flink SQL、ClickHouse/Kudu | 汇总计算、预计算存储 |
ADS | ClickHouse/Impala、Superset/FineBI | 指标加工、可视化对接 |
总之,大数据仓库分层不是 "技术教条",而是 "因地制宜的设计思路"。需结合业务复杂度、数据量、实时性需求灵活调整,最终实现 "数据高效流转、价值快速释放" 的目标。