大数据仓库分层

大数据仓库分层是一套规范化数据流转、降低系统耦合、提升数据复用性与可维护性的设计方法论。其核心逻辑是将数据从 "原始接入" 到 "业务应用" 的全链路拆解为多个职责明确的层级,让每个层级专注于特定任务(如数据清洗、汇总计算、指标输出),最终实现数据资产的高效管理与价值释放。

在行业实践中,分层架构没有绝对统一的标准,但基于维度建模理论 和大数据技术特性,主流架构可分为「五层」(部分场景会简化为四层),从下到上依次为:ODS 层(操作型数据存储层)→ DIM 层(维度层)→ DWD 层(数据仓库明细层)→ DWS/DWT 层(数据仓库汇总层 / 主题层)→ ADS 层(应用数据服务层)

一、分层设计的核心目的

在讲解具体层级前,需先明确分层的 "价值"------ 为何不直接将业务数据导入应用?

  1. 解耦业务与数据:业务系统(如 ERP、CRM)的变更(如字段新增、表结构调整)仅影响底层 ODS 层,上层分析不受波及。
  2. 提升数据复用性:清洗后的明细数据(DWD 层)可支撑多个汇总需求(如用户分析、商品分析),避免重复清洗。
  3. 简化问题定位:数据异常时,可按 "ADS→DWS→DWD→ODS" 逐层回溯,快速定位问题根源(如 ADS 报表错误可能是 DWS 汇总逻辑错,而非 ODS 数据错)。
  4. 优化性能:通过汇总层(DWS/DWT)预计算高频指标,避免上层应用直接查询海量明细数据,降低计算压力。
  5. 统一数据口径:在中间层(如 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 指标加工、可视化对接

总之,大数据仓库分层不是 "技术教条",而是 "因地制宜的设计思路"。需结合业务复杂度、数据量、实时性需求灵活调整,最终实现 "数据高效流转、价值快速释放" 的目标。

相关推荐
IT果果日记28 分钟前
flink+dolphinscheduler+dinky打造自动化数仓平台
大数据·后端·flink
chenglin01630 分钟前
ES_预处理
大数据·elasticsearch·jenkins
AWS官方合作商1 小时前
零性能妥协:Gearbox Entertainment 通过 AWS 和 Perforce 实现远程开发革命
大数据·云计算·aws
武子康2 小时前
大数据-75 Kafka 高水位线 HW 与日志末端 LEO 全面解析:副本同步与消费一致性核心
大数据·后端·kafka
一飞大数据2 小时前
一文搞懂Flink时间语义
大数据
chenglin0163 小时前
ES_文档
大数据·elasticsearch·jenkins
杨荧5 小时前
基于Python的反诈知识科普平台 Python+Django+Vue.js
大数据·前端·vue.js·python·数据分析
A 计算机毕业设计-小途11 小时前
大四零基础用Vue+ElementUI一周做完化妆品推荐系统?
java·大数据·hadoop·python·spark·毕业设计·毕设
君不见,青丝成雪15 小时前
Flink双流join
大数据·数据仓库·flink