最全耗时n年，38页《数据仓库知识体系(2)

2401_84181368

已于 2024-05-04 17:51:18 修改

阅读量1.2k

点赞数 13

分类专栏：程序员文章标签：数据仓库大数据

于 2024-05-04 17:51:17 首次发布

本文链接：https://blog.youkuaiyun.com/2401_84181368/article/details/138446568

版权

个人理解：只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。

1.3 累积快照事实

用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改；

个人理解：要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。

2、三种事实表对比

	事务事实表	周期快照事实表	累积快照事实表
时期/时间	离散事务时间点	以有规律的、可预测的	用于时间跨度不确定的不断变化的工作流
日期维度	事务日期	快照日期	相关业务过程涉及的多个日期
粒度	每行代表实体的一个事务	每行代表某时间周期的一个实体	每行代表一个实体的生命周期
事实	事务事实	累积事实	相关业务过程事实和时间间隔事实
事实表加载	插入	插入	插入与更新
事实表更新	不更新	不更新	业务过程变更时更新

3、事实表设计 8 大原则

原则 1**：尽可能包含所有与业务过程相关的事实**
分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；
原则 2**：只选择与业务过程相关的事实**
如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
原则 3**：分解不可加性事实为可加的组件**
如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
原则 4**：在选择维度和事实之前必须先声明粒度**
因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；
粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
每个维度和事实必须与所定义的粒度保持一致；
设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
原则 5**：在同一个事实表中不能有多种不同粒度的事实**
粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；
订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；
如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；
疑问：怎么判断不同事实的粒度是否相同？
原则 6**：事实的单位要保持一致**
如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；
原则 7**：对事实的** null 值要处理
原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
处理：用 0 代替 null ；
原则 8**：使用退化维度提高事实表的易用性**
易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；

1. 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；

在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样；
思路：通过增加冗余存储，减少计算开销，提高使用效率；

4、事实表设计方法

Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实；

当前的互联网大数据环境，维度模型的设计，是基于 Kimball 的四步维度建模方法进行了更进一步的改进：

第一步：选择业务过程及确定事实表类型
如淘宝的一个交易订单，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”；
如选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”；
如是选择 “买家付款” 这个业务过程，还是选择 “创建订单” 和 “买家付款” 这两个业务过程，具体根据业务情况来定；
思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程；
以实例说明：如何选择业务过程？如何确定事实表类型？

1. 分析业务的生命周期，业务过程通常使用行为动词表示业务执行的活动；
明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；
根据业务需求，选择与维度建模有关的业务过程；
根据所选的业务过程确定事实表类型；

第二步：声明粒度
粒度的作用：
粒度的选择：尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性；

1. 灵活性：支持无法预期的各种细节层次的用户需求；
对于订单级别，粒度可以定义为最细的订单级别；（如，父子订单，事实表的粒度可以定 “子订单级别” ；）
粒度的声明，意味着精确定义事实表的每一行所表示的业务含义；
明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录；

第三步：确定维度
如，淘宝订单 “付款事务事实表” 中，粒度为 “子订单”，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等；
完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了；
选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；
第四步：确定事实
确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致；
思路：可以通过回答 “过程的度量是什么” 来确定；
注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到不可加性事实）

四、多维体系结构

在Kimball的维度建模的数据仓库中，关于多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。

1、总线架构

多维体系结构(总线架构) 数据仓库领域里，有一种构建数据仓库的架构，叫Multidimensional Architecture（MD），中文一般翻译为“多维体系结构”，也称为“总线架构”（Bus Architecture）。

多维体系结构的创始人是数据仓库领域中最有实践经验的Kimball博士。多维体系结构主要包括后台（Back Room）和前台（Front Room）两部分。后台也称为数据准备区（Staging Area），是MD架构的最为核心的部件。在后台，是一致性维度的产生、保存和分发的场所。同时，代理键也在后台产生。前台是MD架构对外的接口，包括两种主要的数据集市，一种是原子数据集市，另一种是聚集数据集市。

原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。

2、一致性维度

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。

一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。

在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。

例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

3、一致性事实

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。

为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：**第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。**如果业务要求或事实上就不能保持一致