数仓实践：浅谈 Kimball 维度建模
本帖最后由 nettman 于 2022-7-21 21:11 编辑问题导读
怎么组织数据仓库中的数据？
怎么组织才能使得数据的使用最为方便和便捷？
怎么组织才能使得数据仓库具有良好的可扩展性和可维护性？
我们不管是基于 Hadoop 的数据仓库（如 Hive ），还是基于传统 MPP 架构的数据仓库（如 Teradata ），抑或是基于传统 Oracle 、MySQL 、SQL Server 关系型数据库的数据仓库，其实都面临如下问题：
[*]怎么组织数据仓库中的数据？
[*]怎么组织才能使得数据的使用最为方便和便捷？
[*]怎么组织才能使得数据仓库具有良好的可扩展性和可维护性？
[*]Kimball 维度建模理论很好地回答和解决了上述问题。
维度建模理论和技术也是目前在数据仓库领域中使用最为广泛的、也最得到认可和接纳的一项技术。今天我们就来深入探讨 Ralph Kimball 维度建模的各项技术，涵盖其基本理论、一般过程、维度表设计和事实表设计等各个方面，也为我们后面讲Hadoop 数据仓库实战打下基础。
度量和环境
维度建模是支持对业务过程的分析，所以它是通过对业务过程度量进行建模来实现的。
那么，什么是度量呢？
实际上，我们通过和业务方、需求方交谈，或者阅读报表、图表等，可以很容易地识别度量。
考虑如下业务需求：
[*]店铺上个月的销售额如何？
[*]店铺库存趋势如何？
[*]店铺的访问情况如何（ pv，uv) ?
[*]店铺访问的熟客占比多少？
“ 这里的销售额、库存、访问量、熟客量就是度量。”
“ 但是，单单谈论度量，是没有意义的。”
度量和环境这两个概念构成了维度建模的基础。而所有维度建模也正是通过对度量和及其上下文和环境的详细设计来实现的。
事实和维度
在 Kimball 的维度建模理论中，“ 度量称为事实，上下文和环境则称为维度。”
通常来说，事实常以数值形式出现，而且一般都被大量文本形式的上下文包围着。
这些文本形式的上下文描述了事实的“ 5个W ”（ When 、 Where 、 What 、 Who 、 Why ）信息，通常可被直观地分割为独立的逻辑块，每一个独立的逻辑块即为一个维度，比如一个订单可以非常直观地分为商品 、买家、卖家等多个维度。
在维度建模和设计过程中，可以根据需求描述或者基于现有报表，很容易地将信息和分析需求分类到事实和度量中。
比如业务人员需求为“按照一级类目，统计本店铺上月的销售额情况”，“按照一级类自”这个描述，很清楚地说明需求方希望对一级类目的销售额进行统计分析，这里的一级类目即为一个维度 。类似的是，“上月”为另一个维度，而销售额明显是事实。
事实表
事实表是维度模型中的基本表，或者说核心表。
事实上，业务过程的所有度量在维度建模中都是存储在事实表中的，除此之外，事实表还存储了引用的维度。
事实表通常和一个 企业的业务过程 紧密相关，由于一个企业的业务过程数据构成了其所有数据的绝大部分，因此事实表也通常占用了数据仓库存储的绝大部分。
比如对于某个超市来说，其 销售的明细数据 通常占其拥有数据的绝大部分且每天还在不断地累计和增长，而商品、门店、员工、设备等其他数据相对来说固定且变化不大。
事实表的一行对应一个度量事件
事实上，每行对应的度量事件可粗可细，比如对某个超市来说，在设计其维度模型时，表示顾客购买事件的事实表的一行即可以记录一张顾客的小票，也可以记录顾客小票的一个子项。
那么我们究竟应该到何种级别呢？
维度建模认为事实表应该包含 最底层的、最原子性 的细节，因为这样会带来最大的灵活性。维度建模中，细节的级别称为事实表的粒度，比如上文顾客购买行为事实表的粒度就应该是小票子项，而非小票。
事实表中最常用的度量一般是数值型和可加类型的
比如小票子项的销售数量、销售金额等，可加性对于数据分析来说至关重要，因为数据应用一般不仅检索事实表的单行数据，而往往一次性检索数百、数千乃至百万行的事实，并且处理这么多行的最有用的和最常见的事就是将它们加起来，而且是从各个角度和维度加起来。
但事实表中的度量并不都是可加的，有些是半可加性质的，另一些则是非可加性质的
半加性事实是指仅仅某些维度可加，例如库存，可以把各个地方仓库的库存加起来，或者把一个仓库不同的商品加起来，但是很明显不能把一个仓库同一商品在不同时期的库存加起来。
银行的账户余额也是半可加事实的例子，可以把不同分行的账户余额加起来或者不同账户人的账户余额加起来，但是不能把不同月份的账户余额加起来。
非可加性事实则根本就不能相加的事实，比如商品的价格以及订单的状态等。
除了存储的事实外，事实表都会包含多个相关的外键。
用于关联和连接相应的维度表。
例如，订单事实表会包含连接到商品表的商品外键、连接到会员表的买家外键、或者连接到门店表的门店外键等。
正是通过这些外键，才能进行各个角度的、各个维度的分析。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表和累积快照事实表。
事务事实表用于承载事务数据，通常粒度比较低，例如产品交易事务事实、 ATM交易事务事实。
周期快照事实表用于记录有规律的、固定时间间隔的业务累计数据，通常粒度比较大，例如账户月平均余额事实表。
累积快照事实表用于记录具有时间跨度的业务处理过程的整个信息，通常这类事实表相对比较少见。
这里需要值得注意的是，在进行事实表的设计时，一定要注意 一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
维度表
维度表是维度建模的灵魂，通常来说，维度表设计得好坏直接决定了维度建模的好坏。
维度表包含了 实表所记录的业务过程度量的上下文和环境，它们除了记录“5 个 W”等信息外，通常还包含了很多的描述字段和标签字段等。
维度表通常有多列或者说多个属性。
实际应用中，包含几十甚至上百属性的维度表并不少见。维度表应该尽可能多地包括 些有意义的文字性描述，以方便下游用户使用。
维度属性是查询约柬条件（ SQL where 条件）、分组（ SQLgroup 语句）与报表标签生成的基本来源在查询与报表需求中， 属性用 by （按）这个单词进行标识。
维度属性在数据仓库中承担着一个重要的角色。
由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源，因此是数据仓库易学易用的关键。在许多方面，数据仓库不过是维度属性的体现而已。
数据仓库的能力直接与维度属性的质量和深度成正比 。
[*]在提供详细的业务用语属性方面所花的时间越多，数据仓库就越好；
[*]在属性列值的给定方面所花的时间越多，数据仓库就越好；
[*]在保证属性列值的质量方面所花的时间越多，数据仓库就越好。
维度表是进入事实表的入口。
丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口， 最好的属性是文本的和离散的， 属性应该是真正的文字而不应是一些编码简写符号。
我们应该通过更详细的文本属性取代编码，力求最大限度地减少编码在维度表中的使用。
有时候在设计数据库时，并不能很确定从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待 ，通常可以这样来做出决定，即看字段是一个含有许多取值并参与运算的度量值（当事实看待），还是一个变化不多并作为约束条件的离散取值的描述（当维度属性看待）。
星形架构和雪花架构
在理解了事实表和维度表之后，接下来的问题就是如何组合它 在维度建模中，存在两种组合维度表和事实表的基本架构：星形架构和雪花架构。
当所有维度表直接连接到事实表时，整个组合的形状类似于星星，所以被称为星形架构。
星形架构是一种非规范化的结构，其数据存储存在冗余，比如考虑商品的维度表，其品牌信息在商品的每一行中都存在，包括其品牌 ID 、名称、品牌拥有者等。
通常很多商品的品牌都是一样的，所以在商品维度表中品牌的信息被重复存储了很多次，也就是存在冗余。
当有一个或者多个维度表没有直接连接到事实表，而是通过其他维度表连接到事实表上时，整个组合的形状就像雪花一样，这种架构被称为雪花架构。
雪花架构是对星形架构维度表的规范化，比如上述的商品表例子，在雪花架构中，其每一行仅存储品牌 ID ，而品牌的所有其他信息（包括品牌名称、拥有者、注册地等所有描述信息）都存储在单独的品牌维度表内。通过品牌 ID 这个外键，商品表可以间接获取到所有品牌描述信息。
雪花架构去除了数据冗余，节省了部分存储，但是也给下游用户的使用带来了不便
如下游用户需要分析品牌的销售额，必须自己先用订单表关联商品表，然后用商品表再关联品牌表。正是由于这一点，在维度建模的实际中， 雪花架构很少得到使用。
有时候简单的方案是最美的、最有力的，也是最有效的
基于星形架构的维度建模就是这种情况 。星形架构牺牲了部分存储的冗余，但是带来了使用上的极度便捷，也使下游用户的使用和学习成本变得非常低。
即使是没有任何技术背景或者维度建模背景知识的业务人员，也很容易理解，更何况目前的存储成本极低，多出的这份存储开销相比后续每次的关联计算、用户使用和学习成本来说，是非常划算的。
星形架构中，每个维度都是均等的，所有维度表都是进入事实表的对等入口，用户可以从任一维度、任一维度属性或者任意多个维度组合、任意多个维度属性组合，方便地对数据进行过滤和聚合（汇总、均值、最大、最小等）操作，而且非常符合业务分析直觉。
业务是多变的，模型的设计必须能够经受住业务多变的需求。在实际设计中，可以通过添加新维度或者向维度表中加入维度属性来满足业务新视角的分析需求。
大多数情况下，数据仓库模型设计中都会采用星形架构，但是在某些特殊情况下 ，比如必须使用桥接表的情况下等，必须使用雪花架构。
维度建模一般过程
维度建模一般采用具有顺序的 个步骤来进行设计，即选择业务过程、定义粒度、确定维度和确定事实。
维度建模的这 个步骤贯穿了维度建模的整个过程和环节，下面逐一介绍。
1. 选取业务过程
业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。
对于一个超市来说，其最基本的业务活动就是用户收银台付款；对于一个保险公司来说，最基本的业务活动是理赔和保单等 。当然在实际操作中，业务活动有可能并不是那么简单直接 ，此时昕取用户的意见通常是这一环节最为高效的方式。
但需要注意的是，这里谈到的业务过程并不是指业务部门或者职能。模型设计中，应将注意力集中放在业务过程而不是业务部门，如果建立的维度模型是同部门捆绑在一起的，就无法避免出现数据不一致的情况（如业务编码、含义等）。因此，确保数据一致性的最佳办法是从企业和公司全局与整体角度，对于某一个业务过程建立单一的、一致的维度模型。
2. 定义粒度
定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明，粒度传递了事实表度量值相联系的细节所达到的程度的信息。其实质就是如何描述事实表的单个行。
典型的粒度定义包括：
[*]超市顾客小票的每一个子项；
[*]医院收费单的明细子项；
[*]个人银行账户的每一次存款或者取款行为；
[*]个人银行账户每个月的余额快照；
对于维度设计来说，在事实表粒度上达成一致非常重要，如果没有明确的粒度定义，则不能进入后面的环节。
在定义粒度过程中，应该最大限度地选择业务过程中最为原子性的粒度，这样可以带来后续的最大灵活度，也可以满足业务用户的任何粒度的分析需求。
3. 确定维度
定义了粒度之后，相关业务过程的细节也就确定了，对应的维度就很容易确定。正如前文所述。
维度是对度量的上下文和环境的描述
通过维度，业务过程度量与事实就会变得丰富和丰满起来。对于订单来说，常见的维度会包含商品、日期、买家、卖家、门店等。
而每一个维度还可以包含大量的描述信息，比如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。
4. 确定事实
确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后，事实和度量一般也很容易确定，比如超市的订单活动，相关的度量显然是销售数量和销售金额。
在实际维度事实设计中，可能还会碰到度量拆分的问题，比如超市开展单个小票满 100减 10 元的活动，如果小票金额超过 10 元，这 10 元的优惠额如何分配到每一个小票子项实际设计中，可以和业务方具体讨论并制订具体的拆分分配算法。
最新经典文章，欢迎关注公众号http://www.aboutyun.com/data/attachment/forum/201903/18/215536lzpn7n3u7m7u90vm.jpg
原文链接：https://blog.csdn.net/BeiisBei/article/details/124905967
页:
[1]