一口气看懂数仓模型设计ODS-CDM-ADS三层架构

剑客狼心

已于 2025-01-22 10:19:45 修改

阅读量1.2k

点赞数 37

文章标签：大数据数仓模型 ODS CDM ADS

于 2025-01-22 10:19:09 首次发布

本文链接：https://blog.csdn.net/weixin_51020083/article/details/145294365

版权

1. 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描

2. 公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标

3. 建立一致性维度：建立一致的数据分析维表，降低数据计算口径和算法不统一的风险

按照之前Onedata的介绍OneData体系详解数仓模型设计可以按照以下三个主要层次进行规划：操作数据层（ODS）、公共维度模型层（CDM，包括 DWD 和 DWS）、应用数据层（ADS）。

这个分层逻辑不考虑业务关系，和业务没关系。

操作数据层 (ODS)：

操作数据层用于存储从业务系统直接同步的原始数据，目标是保证数据的完整性和原始性，哪怕是非结构化数据也鲜少处理。

ODS对原始数据进行基础清洗（如去重、字段格式化），确保数据的质量。

公共维度模型层 (CDM)：

存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成，公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
CDM 层又细分为DWD层和DWS层,分别是明细数据层和汇总数据层,采用维度模型方法作为理论基础,更多地采用一些维度退化手法将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性;同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

问题来了：

什么是维度退化？

在传统的维度建模中，事实表存储的是业务活动的度量值（如销售金额、销售数量），而维表存储的是业务相关的属性信息（如产品名称、类别）。事实表和维表之间通过外键关联。

例如下面这个，sales Fact table是事实表，周围有时间维度、产品/项目维度、地点维度等维度表，每个维度表只存储该维度相关的数据，因此对于企业级别的查询能够减少join的多表连接，提高查询效率。

维度退化是指将维表中的某些维度属性直接放入事实表中，而不是通过外键关联。这种方式简化了查询逻辑，减少了表之间的关联操作。

也就是说，如果查询频繁需要事实表和维表关联，可以将常用的维度属性直接放在事实表中，减少关联操作，从而提高查询效率。

以下是需要维度退化的常见情况清单，适用于优化数据模型的场景：

1. 高基数维度

定义： 维度的值非常多且唯一性强，关联维表没有太大意义。
例子：
- 订单编号（Order ID）
- 用户 ID（User ID）
- 设备 ID（Device ID）

原因： 高基数维度如果单独建维表会导致维表膨胀，占用大量存储空间，同时查询时关联性能较差。

2. 维度简单、不涉及多属性

定义： 维度的属性较少，通常只有一个值，不需要复杂的层次或关联。
例子：
- 日期字段（Date）
- 状态字段（Order Status，如“已支付”、“待支付”）

原因： 如果维表只有一个属性或非常少的属性，单独建表意义不大。

3. 维度属性与事实表强相关

定义： 维度的属性是事实表的关键组成部分，与事实表具有很强的直接关系。
例子：
- 商品 SKU（用于唯一标识单个商品）
- 交易类型（Transaction Type，如“退款”或“充值”）

原因： 强相关属性放在事实表中更加直观，减少数据关联的复杂性。

4. 维度的查询使用频繁

定义： 查询时维度字段经常被直接使用，且关联操作成为性能瓶颈。
例子：
- 时间字段（例如“销售日期”或“交易时间”）
- 分类字段（例如“一级分类”或“国家”）

原因： 如果查询频繁且每次都需要关联维表，直接退化到事实表中可以显著提升性能。

5. 维度退化后能提升事实表的易用性

定义： 对于业务分析人员，直接查询事实表的字段比多表关联更方便。
例子：
- 地区名称（如“华东”、“华北”）
- 用户注册来源（如“APP”、“网页”）

原因： 对非技术人员，简单字段直接放在事实表中更容易理解和使用。

6. 减少表关联的场景

定义： 查询需要减少事实表和维表的关联次数，以提高性能。
例子：
- 销售订单的时间戳（直接存储具体时间，而不是关联时间维表）
- 客户级别（如“VIP”、“普通用户”）

原因： 减少多表关联操作，提高查询效率。

以下是需要维度退化的常见情况清单，适用于优化数据模型的场景：

1. 高基数维度

定义： 维度的值非常多且唯一性强，关联维表没有太大意义。
例子：
- 订单编号（Order ID）
- 用户 ID（User ID）
- 设备 ID（Device ID）

原因： 高基数维度如果单独建维表会导致维表膨胀，占用大量存储空间，同时查询时关联性能较差。当然一般也不会给这种高基数的字段单独建一个维度表。

2. 维度简单、不涉及多属性

定义： 维度的属性较少，通常只有一个值，不需要复杂的层次或关联。
例子：
- 日期字段（Date）
- 状态字段（Order Status，如“已支付”、“待支付”）

原因： 如果维表只有一个属性或非常少的属性，单独建表意义不大。

3. 维度属性与事实表强相关

定义： 维度的属性是事实表的关键组成部分，与事实表具有很强的直接关系。
例子：
- 商品 SKU（用于唯一标识单个商品）
- 交易类型（Transaction Type，如“退款”或“充值”）

原因： 强相关属性放在事实表中更加直观，减少数据关联的复杂性。

4. 维度的查询使用频繁

定义： 查询时维度字段经常被直接使用，且关联操作成为性能瓶颈。
例子：
- 时间字段（例如“销售日期”或“交易时间”）
- 分类字段（例如“一级分类”或“国家”）

原因： 如果查询频繁且每次都需要关联维表，直接退化到事实表中可以显著提升性能。

5. 维度退化后能提升事实表的易用性

定义： 对于业务分析人员，直接查询事实表的字段比多表关联更方便。
例子：
- 地区名称（如“华东”、“华北”）
- 用户注册来源（如“APP”、“网页”）

原因： 对非技术人员，简单字段直接放在事实表中更容易理解和使用。

6. 减少表关联的场景

定义： 查询需要减少事实表和维表的关联次数，以提高性能。
例子：
- 销售订单的时间戳（直接存储具体时间，而不是关联时间维表）
- 客户级别（如“VIP”、“普通用户”）

原因： 减少多表关联操作，提高查询效率。

7. 需要建立宽表的场景

定义： 汇总数据需要形成宽表，便于业务快速查询分析。
例子：
- 用户维度中“用户 ID”、“用户名称”直接存储到事实表。
- 订单维度中“订单号”、“下单时间”直接存储到事实表。

原因： 宽表设计中，直接存储关键维度字段更符合快速查询需求。

8. 维度的历史变化不敏感

定义： 维度的值变化较少，或历史变化不需要重点关注。
例子：
- 产品的简单分类（如“电子产品”）
- 订单的支付状态（如“已支付”、“未支付”）

原因： 如果维度值变化少，退化到事实表可以减少历史记录的复杂性。

9. 临时性或非核心维度

定义： 维度仅用于某些场景的临时性分析，不需要长期维护。
例子：
- 临时活动的标识（如“促销活动 ID”）
- 特定时期的特定标签（如“节日促销标记”）

原因： 临时字段单独建维表不划算，直接退化到事实表更高效。

10. 数据仓库优化场景

定义： 优化数据仓库查询性能或存储设计的场景。
例子：
- 大规模报表查询时减少关联操作的字段
- 数据冗余较高的字段（例如用于唯一标识的字段）

原因： 数据仓库中的优化通常需要权衡冗余和性能，维度退化是常用手段。

什么是宽表化？

宽表化手段和维度退化有一定关联，但并不完全等同。

宽表化是数据建模中的一种设计策略，旨在通过将多个表中的数据整合到一个表中，减少数据查询时的表关联操作，从而提高查询性能和开发效率。宽表化可以理解为对数据仓库中的数据进行“扁平化”处理，使其在查询时更直观、简单。

宽表化通常会包含维度退化的操作，但宽表化不仅限于维度退化，还包括以下内容：

维度退化： 将维度字段直接存储在事实表中。
指标汇总： 将多个指标预先计算并存储在宽表中，减少实时计算成本。
关联数据的整合： 整合多个事实表和维度表的数据，形成一个完整的宽表。

为什么维度退化不一定导致宽表化

维表仍然存在：
在维度退化后，原维表中未退化的字段仍然保留，查询时可能依然需要关联维表，表结构并没有完全宽表化。
仅退化部分字段：
维度退化仅选择高频使用的字段，不会整合所有维度表字段，因此事实表不会成为一个完全的宽表。
目标不同：
维度退化专注于优化某些高频查询场景，而宽表化追求的是将所有相关数据整合，面向即席查询或分析场景。

下面是对 CDM 层主要功能 的详细解释，包括关键概念和作用：

1. 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描

含义：
通过将具有相似业务逻辑或关联关系的数据整合到一张明细宽表中，将多个表的分散信息集中，减少查询时需要的表关联操作，提升查询效率。
实现方式：
- 明细宽表：
  将事实表中的高频字段和相关维度表的字段进行整合，形成一张宽表。例如，将订单事实表和用户维度表、商品维度表的常用字段组合到一个表中。
- 复用关联计算：
  针对高频使用的关联逻辑（如用户、商品和订单的连接关系）提前计算并固化在宽表中，避免重复计算。
- 减少数据扫描：
  查询时直接使用宽表，无需在运行时对多张表进行扫描和关联操作，大大提升了性能。
举例：
- 原始结构：
  用户表、商品表、订单表分开存储。
- 宽表化后：

2. 公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标

含义：
在 CDM 层构建统一的公共指标体系，确保所有统计指标在命名、计算逻辑和业务口径上保持一致性，为上层的数据产品、业务分析提供一致性的数据基础。
实现方式：
- 命名规范：
  定义统一的指标命名规则，例如“订单支付金额”统一命名为 order_payment_amount，所有业务部门必须遵循相同的名称。
- 口径一致：
  确保每个指标的统计范围、时间周期等业务逻辑一致。例如，订单金额是否包含退款金额，是否按下单时间还是支付时间计算。
- 算法统一：
  对所有公共指标的计算逻辑进行统一封装。例如，用户活跃度的计算标准为 7 天内登录次数。

3. 建立一致性维度：建立一致的数据分析维表，降低数据计算口径和算法不统一的风险

含义：
在 CDM 层创建统一的维度表，作为所有数据分析的基准，避免各部门或团队在使用维度时因口径和算法不同而产生数据不一致的情况。
实现方式：
- 维表标准化：
  定义统一的维度表结构和内容，例如用户维度表统一包含用户 ID、姓名、等级、注册时间等字段，所有团队使用相同的用户维度表。
- 消除冗余：
  对业务中常见的维度（如商品分类、时间、区域）进行归一化存储，避免多处维护，降低冗余带来的不一致风险。
- 提供一致性接口：
  对外提供统一的查询接口或服务，确保所有团队使用相同的维度数据。
举例：
- 时间维度：
  时间维度表统一定义每一天的日期、周、月、季度、年份等字段，供所有查询或报表生成使用。
- 商品分类维度： 商品分类表统一规定了每个商品的分类路径，例如“电子产品 > 手机 > 智能手机”。

为什么要区分明细数据层和汇总数据层？

区分明细数据层（DWD, Detail Wide Data）和汇总数据层（DWS, Data Warehouse Summary），是数据仓库设计中的重要策略，其目的是为了更好地满足不同类型的数据处理需求，平衡查询性能与数据灵活性。以下是详细原因和两者的角色分工：

明细数据层保留了详细信息，但数据量通常非常大，直接在明细数据上查询容易导致高延迟、性能差。
- 比如：查询“每天的销售总金额”时，从数亿条订单数据中聚合计算非常耗时。
汇总数据层将常用的业务指标提前计算并存储，可以显著提高查询速度，减少重复计算和资源消耗。

明细数据层和操作数据层的区别

数据来源

操作数据层（ODS）：
- 数据直接来源于业务系统（如订单系统、用户管理系统等）。
- 是对业务系统数据的近乎无加工存储，主要作用是实时或准实时地同步业务系统数据到数据仓库。
- 数据通常是原始的，可能包含业务系统的日志记录、操作记录等。
明细数据层（DWD）：
- 数据基于ODS层进行清洗、规范化后生成，去除了数据冗余和噪声，提升了质量。
- 数据在业务逻辑上进行了轻量加工，例如字段转换、数据整合（合并多数据源）、轻量计算等。

数据结构和规范

操作数据层（ODS）：
- 保持业务系统的原始数据结构，字段名和数据格式通常直接与业务系统一致。
- 缺少统一的命名规范或数据格式，适配性较低。
- 举例：订单数据可能包含原始的字段命名，如 order_id、user_id、amount_paid。
明细数据层（DWD）：
- 采用统一的命名规范和维度建模方法，字段名、数据类型、表结构都经过规范化处理。
- 对数据进行轻量加工，以便后续分析和处理。
- 举例：同样的订单数据可能会被规范化为 order_number、customer_id、payment_amount。

应用数据层（ADS）

应用数据层（ADS，Application Data Service）是数据仓库分层架构中的最顶层，主要服务于具体的业务需求和数据应用场景。它是基于 公共维度模型层（CDM，包括 DWD 和 DWS 层） 或直接使用 操作数据层（ODS） 数据加工生成的，属于高度针对性的数据层。

数据特点

聚合性强：
- ADS 层的数据通常是聚合后的结果数据（如总和、平均值、最大值等）。
- 可能按天、周、月等时间周期提供汇总数据。
数据量较小：
- ADS 层通常只保留业务需要的数据，不像明细数据层那样存储所有细粒度数据。
- 数据表结构设计精简，方便调用和理解。
与业务强相关：
- 数据字段、命名和存储逻辑都紧密贴合具体的业务场景。

电商平台的报表系统：

CDM 层：
- 明细数据层（DWD）：
  订单明细表，包含用户每次下单的详细信息（订单号、商品ID、下单时间、金额等）。
- 汇总数据层（DWS）：
  商品销售汇总表，按商品ID和日期汇总销售额、销量。
ADS 层：
- 电商销售报表表：
  为前端运营提供每日商品销量TOP 10，按商品类目统计。