数据仓库维度建模笔记

维度建模模型本质是对关系模型的修补,提出缓慢变化维度的处理方案,使其更适用于记录历史数据,同时由于数据仓库与业务数据库是独立的,因此提出一致性理论,使得新的业务也可以复用原有的数仓表。

数据仓库的建模第一步与关系建模过程一样,从业务过程开始分析,关系模型关注业务过程所需的字段,而服务于分析系统的维度建模,在此基础上还需要关心分析需求的指标(推动埋点的设计);然后构建总线矩阵梳理出原子粒度的维度表与事实表,生成 DWD 层明细表,最后由查询分析需求推动生成上卷汇总粒度的 DWS 层汇总表。

Kimball 维度建模架构

建模流程

  • 数据调研
    • 业务调研(竞争性商业问题、决策制定过程、支持分析需求的指标)
    • 需求分析(关键性能指标)
  • 维度建模设计与研讨
    • 选择业务过程,业务过程是通过组织完成的操作型活动(或者叫事件),例如,获得订单、处理保险索赔、学生课程注册或者每个月每个账单的快照,活动行为将转化为事实表的事实。 (每个业务过程对应企业数据仓库总线矩阵的一行)
    • 声明粒度,原子粒度是基础,上卷汇总粒度以优化性能。
    • 确认维度,维度提供某一业务过程事件所涉及的背景;维度表应包含 BI 所需要的用于过滤及分类事实的描述性属性。(每个维度对应企业数据仓库总线矩阵的一列)
    • 确认事实,事实表应描述业务过程中物理可观察的事件。

数据仓库总线架构

业务过程都会共用一些维度,形成了企业数据仓库的总线,一致化维度和事实看作一组标准的应用程序连接口,可以看作一个数据仓库的总线架构。当有新的业务过程引入数据仓库中,该业务过程可以从总线直接复用一致性的数据。

企业数据仓库总线矩阵,矩阵的行表示业务过程,列表示维度。矩阵中的点表示维度与给定的业务过程是否存在关联关系。 设计小组分析每一行,用于测试是否为业务过程定义好相关的候选维度,同时也能分析每个列,考虑某一维度需要跨多个业务过程并保持一致。

企业数据仓库总线矩阵是 DW/BI 系统的一个总体数据架构,提供了一种可用于分解企业数据仓库规划任务的合理方法,开发团队可以独立的,异步的完成矩阵的各个业务过程,迭代地去建立一个集成的企业数据仓库。 

技术基础

事实表技术基础

事实表结构,事实表应该有数字指标、与维度表关联的外键、也可包含退化维度键和日期。

一致性事实概念,如果相同指标出现不同的事实表,那么要保证计算过程是一致的;同理,相同计算过程的事实表应该同名。

事实表类型

  • 事务性事实表,原子粒度。
  • 周期性快照事实表,周期汇总。
  • 累积性快照事实表,累积汇总。
  • 无事实的事实表,仅描述事件,不包含可供分析的直接指标,但可表达关联性(其实是隐藏了连通关系的指标值)。

维度表技术基础

维度表结构 ,维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。 维度表属性是查询及 BI 应用的约束和分组定义的主要目标。 报表的描述性标识通常是维度表属性的领域值。

维度代理键,数据仓库内部维护的从值 1 开始的主键,目的是解决多业务系统数据源的主键冲突问题(比如不同产品业务内部用户表,可能遇到用户主键冲突)。 日期维度不需遵循代理键规则。

自然键、持久键、超自然键,自然键是业务系统自身规则生成的主键,自然键可能不具有持久性(比如雇员辞职再入职时,可能雇员编号就会发生变更),持久键就是实现包含描述状态变换(也就是未来雇员再入职时,只用修改其状态)。

退化维度,维度除了主键之外没有其他内容。通常会把退化维度直接放在事实表。

维度表类型,

  • 日历日期维度,可不使用维度代理键,直接以 yyyyMMdd 表示。
  • 扮演角色维度,自身与其他表之间有多重有效关系的表。这是维度中最常见的维度。
    例如,基于键 Order Day、Ship Day 和 Close Day,Sales fact 与 Time 存在多重关系。
  • 支架维度(Outrigger Dimensions),一个维度表引用其他维度表,形成雪花模型。支架维度可以减少数据重复存储,以及更新维护的复杂度,但可能会在查询时候创造很多麻烦。
  • 桥接维度,维度或者维度与事实表之间存在多对多关系,就需要建立多值桥接表。桥接维度可能也是缓慢变化维度。
  • 层次维度(Hierarchical Dimensions),维度表是有层次结构的,可以邻接表 Adjacency List 方式构建。相比较,关系模型的层次结构实现玩法更多,可参考:Models for hierarchical data
  • 缓慢变化维度,
    • TYPE 0、1,忽略或覆盖。
    • TYPE 2,拉链表(还有个叫法是 SQL:2011 的 Temporal Table 历史表)。
      在表结构中需要新增三个格外列:行起始日期列、行截止日期列、当前行有效性标识。
      由于更新仅涉及上一版本与当前版的数据,所以大型拉链表可分多分区,定期可把多版本的数据清到新的归档分区里,减少 ETL 运算量,全量获取也只需 Union 一下。
    • TYPE 3,增加新的历史列,并改写标识当前状态的列(相对少见,但是对于 TYPE 2 的拉链表,在查询所有历史状态时候减少了 Group by 或者 Window 计算)。
    • TYPE 4,增加微型维度(Mini Dimensions)。
      微型维度的提出主要是为了解决快变超大维度(Rapidly changing Monster Dimensions)。 以客户维度举例来说,如果维度表中有数百万行记录或者还要多,而且这些记录中的字段又经常变化,这样的维度表一般称之为快变超大维度。对于快变超大维度,设计人员一般不会使用拉链表的缓慢变化维处理方法(TYPE 5),因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。 这时,可将分析频率比较高或者变化频率比较大的字段提取出来,建立一个单独的维度表,事实表通过 Profile Key 关联微型维度表。这个单独的维度表就是微型维度表。
    • TYPE 5 混合双打,增加微型维度及支架(视图)维度。
      当 TYPE 4 的 Profile Key 放在维度表时,那就相当于关联了微型维度表作为支架维度,这使得维度表的描述重新包含了 TYPE 4 抽取出来的字段(TYPE 4 中维度表中是无法得知抽取出来的字段状态,需要关联事实表才能查询出来)。
    • TYPE 6 混合双打,TYPE 2 拉链表 + TYPE 3 历史列,便于直接查询上一个状态。
    • TYPE 7 混合双打,TYPE 7 效果与 TYPE 6 是一样的,只是把历史列的值改成维表的外键,然后使用视图进行关联。因为记录的是外键,相比较于单一或者有限状态,相对来说会灵活一些,但是查询时候复杂度也会高一些。

阿里集团 OneData 维度建模架构

阿里《大数据实践》的思想比较具体,但笔者无实战经验,日后有机会配合实际情况再接着讨论。

建模流程

分层概念

OneModel 模型

OneModel 以维度建模为理论基础,划分和定义业务板块、数据域、业务过程、维度、度量/原子指标、业务限定、时间周期、派生指标,设计出维度表、明细事实表、汇总事实表的过程。

OneModel 的一个核心内容是派生指标的构建方法。在 OneModel 中,派生指标由原子指标、时间周期、业务限定、统计粒度统一定义。

命名规范

ODS

表命名规则:s_{源系统表名}{保留位/delta与否}

  • 增量数据:{project_name}.s_{源系统表名}_delta。
  • 全量数据:{project_name}.s_{源系统表名}。
  • ODS ETL过程的临时表:{project_name}.tmp_{临时表所在过程的输出表}{从0开始的序号}。
  • 按小时同步的增量表:{project_name}.s_{源系统表名}_delta_hh。
  • 按小时同步的全量表:{project_name}.s_{源系统表名}_hh。

表存储方式

  • 增量快照存储,普通流水型数据。
  • 全量快照存储,对于小数据量的缓慢变化维度数据,例如商品类⽬,可直接使⽤全量存储。
  • 全量拉链存储(极限存储),对于大型缓慢变化维度数据,可使用拉链存储。
  • 不使用代理键(国内,直接拿个人身份证 ID 也就行了)。

DIM

表命名规范:dim_{业务板块名称/pub}_{维度定义}[_{自定义命名标签}]

  • 公共区域维表:dim_pub_area
  • A公司电商板块的商品全量表:dim_asale_itm

DWD

表命名规范:dwd_{业务板块/pub}{数据域缩写}{业务过程缩写}[{⾃定义表 命名标签缩写}] {单分区增量全量标识}

单分区增量全量标识为,i 表⽰增量,f 表⽰全量。

  • A电商公司航旅机票订单下单事实表,⽇刷新增量:dwd_asale_trd_ordcrt_trip_di
  • A电商商品快照事实表,⽇刷新全量:dwd_asale_itm_item_df

DWS

表命名规范:dws_{业务板块缩写/pub}{数据域缩写}{数据粒度缩写}[{⾃定义表 命名标签缩写}]{统计时间周期范围缩写}

  • 关于统计实际周期范围缩写,缺省情况下,离线计算应该包括最近⼀天(_1d),最近N天(_nd)和历史截⾄当天(_td)三个表。如果出现 _nd 的表字段过多需要拆分时,只允许以⼀个统计周期单元作为原⼦拆分。即⼀个统计周期拆分⼀个表,例如最近7天(_1w)拆分⼀个表。不允许拆分出来的⼀个表存储多个统计周期。
  • 对于小时表[⽆论是天刷新还是小时刷新],都⽤ _hh 来表⽰。
  • 对于分钟表[⽆论是天刷新还是小时刷新],都⽤ _mm 来表⽰。
  • A电商公司买家粒度交易分阶段付款⼀⽇汇总事实表:dws_asale_trd_byr_subpay_1d
  • A电商公司买家粒度分阶段付款截⾄当⽇汇总表:dws_asale_trd_byr_subpay_td
  • A电商公司买家粒度货到付款交易汇总事实表:dws_asale_trd_byr_cod_nd
  • A电商公司卖家粒度商品截⾄当⽇存量汇总表:dws_asale_itm_slr_td
  • A电商公司卖家粒度商品小时汇总表:dws_asale_itm_slr_hh
  • A电商公司卖家粒度商品分钟汇总表:dws_asale_itm_slr_mm

参考资料

  1. https://www.kimballgroup.com/2013/02/design-tip-152-slowly-changing-dimension-types-0-4-5-6-7/
  2. https://en.wikipedia.org/wiki/Slowly_changing_dimension
  3. https://blog.csdn.net/weixin_32806343/article/details/112558116
  4. https://nlogn.art/wp-content/uploads/2021/05/Kimball_The-Data-Warehouse-Toolkit-3rd-Edition_%E4%B8%AD%E6%96%87%E7%89%88.pdf
  5. https://nlogn.art/wp-content/uploads/2021/05/Kimball_Data_Warehouse_ETL_Toolkit.pdf
  6. https://nlogn.art/wp-content/uploads/2021/05/MaxComputer_1%E6%9E%84%E5%BB%BA%E4%B8%8E%E4%BC%98%E5%8C%96%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93.pdf
  7. https://nlogn.art/wp-content/uploads/2021/06/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%8F%B0%E5%AE%9E%E8%B7%B5_2019.pdf
  8. https://xie.infoq.cn/article/b93875077c776fb0dc9d85858

One Reply to “数据仓库维度建模笔记”

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注