大数据从业者必读书籍《数据仓库工具箱》-第二章笔记

第二章：Kimball维度建模技术概述

2.1基础概念

Kimball架构建模过程概述。

• 收集业务需求与数据实现

  在建模工作开始前，项目组必须理解业务需求与源数据的实际情况，了解业务的需求(关键性指标，竞争性商业问题，决策制定过程，分析支持需求)。

  同时也要和源系统专家交流，了解访问数据可行性。

• 写作维度建模讨论

  维度模型不应该由哪些不懂业务以及不了解业务需求的人来设计，多方写作是成功的关键。

• 维度设计4步骤

  • 选择业务过程
  • 声明粒度
  • 确认粒度
  • 确认事实

  需要根据业务需求与底层数据源，按照业务过程，粒度，维度，事实声明来确认表名，列名，示例领域值与业务规则，必须有业务人员参与制定，以确保涵盖正确的业务。

• 业务过程

  业务过程是组织完成的操作型活动，业务过程必须建立并获取性能度量，转换为事实表中的事实。

  每个业务过程对应企业数据仓库总线矩阵的一行。

• 粒度

  声明粒度是维度设计的重要步骤。

  粒度用于确认某一事实表的行表示什么。

  同时粒度越细，数据仓库就越健壮，业务人员用起来就越得心应手。

  同一事实表的粒度最好高度统一。

• 维度

  维度提供围绕某一业务过程中所涉及的“谁、什么、何处、何时、为什么、如何”等背景。维度表提供了用于过滤及分类的描述性属性，对粒度进行足够细致的划分就可以将所有可能存在的维度区分开。

  维度表是数据仓库的灵魂，因为维度表包含确保DW/BI系统能够被用作业务分析的入口。

  主要的工作应当放在数据治理与维度表开发方面。

• 用于度量的事实

  事实涉及来自业务过程的度量，基本都以数量值表示。一个事实表行与粒度存在一对一关系。

  比如上班时长表（上班时间，加班时间），上班时间可以拆分成签到时间，签退时间形成一个维度表，加班时间就是一个数值，加了几个小时的班是一个度量。

• 选择维度模型

  星型模式(事实表与维度表一对多)，OLAP模式，星座模式(事实表与维度表多对多)，一般主流是星座模式来提高维度表的复用性。

• 维度模型扩展性

  维度模型对数据关系发生变化具有灵活的适应性。必须保证：

  • 当事实与存在的事实表粒度一致时，可以创建新列。
  • 通过建立新的外键列，可以将维度关联到已有的事实表上，前提是维度列与事实列粒度保持一致。
  • 可以在维度表上通过建立新列添加属性。
  • 可以使事实表的粒度更原子化，方法时在维度表上增加属性，然后以更细的粒度重置事实表，小心保存事实表及维度表的列名。

2.2 事实表技术基础

Kimball架构建模时事实设计过程概述。

• 事实表结构

  发生在现实世界的操作型事件，其所产生的可度量数值就是事实表的字段。

  从粒度来看，事实表一行对应一个度量事件，因此事实表的设计完全依赖于物理活动。

  除了数字度量外，事实表还包含外键和与其相关联的维度。

• 可加、半可加、不可加事实

  事实表根据灵活性与用途将数字度量分为三类，可以与事实表关联的任意维度汇总的是可加事实，可以操控某些维度但不能操控全部维度的是半可加事实，本身是操作后的度量（比例，占比等）是不可加事实。在设计时应该解决不可加事实的出现，尽可能使用半可加事实来描述不可加事实。

• 事实表中的空值

  事实表可以存放空值度量，所有的聚集函数也可针对空值事实处理。

  外键不能存在空值，否则会导致违反参照完整性的情况发生。

• 一致性事实

  所有事实表中出现的度量应当是唯一的，如果无法避免，相同物理含义的度量可以用不同的度量名来分辨。

• 事务事实表

  事务事实表的一行对应空间后时间上某点的度量事件。事务事实表是可维度化且可被表达的事实表，应该确保数据有最小粒度来保证最大健壮性。

• 周期快照事实表

  是事务事实表汇总的某一标准周期，如某天，某周，某月。粒度是周期性的，而不是个体的事务。

• 累积快照事实表

  累积快照事实表是在事务开始时就创建，当事务到达固定的流程时填写对应的度量，在事务结束后这一行才算输入完成。

  例如去某宝买东西，浏览就算是事务开始，然后好评才算事务结束，中间所有的度量都是某宝固定好的或者说预测好的。

• 无事实的事实表

  用来记录一个事件的事实表，没有相关的度量，例如记录一天内学生上了什么课，应该有天，学生，老师，地点，课程等本身就很细的外键，没有相关的度量。

• OLAP多维数据库

  是对事务事实表进行简单的数字化上卷操作，目的是为了提高查询性能。

  现在网上有很多开源的OLAP数据引擎可以使用。

• 合并事实表

  将相同粒度表示的事实合并为一个单一的合并事实表。比如现货销售与销售预测合并为一张事实表，比起进行下钻，这样做可使对现货及预测任务的分析工作变得简单快捷。

2.3 维度表技术基础

Kimball架构建模时维度设计过程概述

• 维度表结构

  每个维度表都包含单一的主键列（对外提供代码）。维度表的主键可以作为与之关联的任何事实表的外键，前提是维度表描述的环境与事实表完全对应。

  维度表通常是宽表，包含大量低粒度的文本属性。

  例如：

  代码	标识	子公司	部门	姓名
  010101	1-2:子公司代码;3-4:部门代码;5-6:姓名代码	非洲旅行社	驻非导游部门	非浪
  020202	1-2:子公司代码;3-4:部门代码;5-6:姓名代码	亚太地区招商公司	专业团队表演部门	非舞

  这样我们连接事实表就需要给一个外键，就不用把这三个字段作为度量添加到事实表中。

  以操作代码与指示器作为属性，最强有力的维度属性采用冗长的描述填充。

  维度表属性是查询的约束与分组定义的主要目标。

• 维度代理键

  唯一主键，这个主键不是系统自带的主键，是我们根据业务需求制定的代码（比如身份证号）。系统管理员必须对代码进行统一管理。

• 自然键、持久键和超自然键

  自然键受业务规则影响，不被系统控制。例如小A辞职后，那么雇员ID肯定会发生变化。我们希望可以为该雇员创建单一键，这就需要建立新的持久键以确保这样的情况下雇员ID保持持久性不会发生变化。这样的键被称为持久超自然键。

• 下钻

  下钻是分析数据的最基本的方法。仅需要在查询上增加一个行头指针，新行的头指针是一个维度属性，附加SQL语言的group by表达式。

• 退化维度

  当一个维度表除了主键为没有其他内容（发票编号，交易编号等等）。这种退化维度被放到事实表中，清楚的表明没有关联的维度表。退化维度常见于交易与累计快照事实表中。

• 非规范化扁平维度

  非规范化偏平维度是在借鉴数据湖后，Kimball明白规范化维度终究有穷尽的时候，非规划化的多对一固定深度层次引入扁平维度行的不同属性。

  非规范化维度能够实现维度建模的双重目标：简化及速度。

• 多层次维度

  例如时间与空间（地域），都有多个层次。所以在这些情况下，同一维度可以存在不同的层次。

• 文档属性的标识与指示器

  维度表中应当有对代码的描述。

• 维度表的空值属性

  维度表不要存在空值，推荐用描述性字符串替换空值。

• 日历日期维度

  时间维度是最基本，最重要的独立维度。

  功能：能够让事实表按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。

  不要奢望SQL给你计算双十一或者六一八。

  日历日期维度通常包含许多维度：周，月份，财务周期，国家节假日等等，而且日期不用存放一个日期类型，存放一个YYYYMMDD的整数类型或字符串会更方便。

• 扮演角色的维度

  唯一属性列名（维度行）被称为角色。

• 杂项维度

  事务性商业过程通常会产生一系列混杂、低粒度的标识与指示器。与其让他们各自定义不同的维度，不如把他们汇总在一起形成杂项维度。

• 雪花维度

  星型维度是一个事实表周围有维度表，雪花维度是维度表也有维度表。
  
  应该避免雪花维度的使用，这样会影响查询性能，而且非规范扁平维度表也可以做到相同的效果。

• 支架维度

  维度可以包含对其他维度的引用，例如银行账户维度可以引用时间维度。被引用的辅助维度叫做支架维度。支架维度应该少用，比较维度之间的连接应该靠事实表完成。

2.4 使用一致性维度集成

• 一致性维度

  当不同维度表的属性具有相同列名和领域内容时，称维度表具有一致性。

  利用一致性维度属性与每个事实表关联，可以将来自不同事实表的信息汇总到一张报表中。

  一致性维度一旦被共同定以后，就可以被所有事实表重用，该方法可获得分析一致性并减少未来开发的开销，因为不需要重新创建。

• 缩减维度

  将维度的列或行部分提取出来组成。

  当构建聚集事实表时需要缩减上卷维度。

  当商业过程自然地获取粒度级别较高的数据时，也需要缩减维度。

• 跨表钻取

  跨表钻取就是每个查询的行头包含相同的一致性属性时，使不同的查询能够针对两个或更多的事实表进行查询。

• 价值链

  价值链用来表示组织中主要业务的自然流程。

  每一条价值链都应该有一个原子事务表。

• 总线架构

  总线架构通过关注业务过程将DW/BI系统分隔成可管理可运用的模块。

  同时也支持可管理敏捷实现对应企业数据仓库总线矩阵。

  总线架构与数据平台是独立的。

• 总线矩阵

  总线矩阵是用于设计并与企业数据仓库总线架构交互的基本工具。

  行表示业务过程，列表示维度。

  总线矩阵的实现细节是一个粒度更细化的总线矩阵，其中扩展每个业务过程行以展示特定事实表或OLAP多维数据库。

• 机会/利益方矩阵

  在确认总线矩阵后，可以通过替换包含业务功能的维度规划处不同的矩阵。

  机会/利益方矩阵用于区分哪些业务过程分组应该与过程中心行相关。

2.5 维度属性的变化

• 类型0：原样保留

  维度属性值不会发生变化，因此事实表以原始值分组。

  类型0适合做标记为“原型”的情况，比如信用卡积分等等。

• 类型1：重写

  维度行中原有的属性值被新值覆盖。此技术破坏了历史情况，尽管不需要建立额外的维度行，但是他会影响聚集事实表或OLAP数据引擎的重复计算。

• 类型2：增加新行

  在维度表中增加新行，新行采用修改的属性值。

  使用该方法的前提是维度主键更具有一般性。

  增加行时，必须增加三个额外的列：①行有效的日期/时间戳列；②行截止日期/时间戳列;③当前行标识。

  这样是避免多行描述统一对象（假设A入职某公司后离职，那么A肯定会在人员维度表中留存，多年后A再次入职该公司，那么A在维度表中就有两条记录）。

• 类型3：增加新属性（列）

  一般进行类型0或类型1操作，这种操作不太常用。

• 类似4：增加微型维度

  假设有一个几百万行的销售维度表，那么技术人员肯定不愿意再往里面添加记录，而且他本身查询也到达了瓶颈。

  这样为了优化查询，可以在这个维度表上产生一个销售微型维度表，将活性高的数据提出组成一个小表来供查询。

  将维度中的一组属快速变化并划分为微型维度。

  微型维度被称为快速变化魔鬼维度(魔鬼?)。

• 类型5：增加微型维度及类型1支架

  在类似4上加解读，例如有销售额字段，假设值是123.45，那我干脆弄成1-50,51-100,101-150，…这样的对数据进行整合效果岂不是更好。

• 类型6：增加类型1到类型2维度

  类型6建立在类型2基础上，同时嵌入到类型1中。本质上就是按照类型2读取有效行，按照类型1进行分组或过滤。

  现在HBASE或HIVE默认都是类型6。

• 类型7：双类型1和类型2维度

  类型7是一种混合技术，适合沉淀了大量数据，对新数据频繁使用，对旧数据也有使用需求的场景。

  第一个类型1维度仅展示活性最高的属性值，第二个类型1和第一个类型2组成类型6对历史概要进行展示。

  类型7可以理解为基于类型6及类型1支架。

2.6维度层次的变化

• 固定深度位置的层次

  是多对一关系的一种，例如产品–>品牌–>类别–>部门。这些定义都是固定的，他们的层次也就有了商定的名字。

  固定深度是最容易理解和查询的层次关系，他也能提供可预测、快速的查询性能。

• 轻微参差不齐/可变深度层次

  这种层次没有固定的层次深度，但是层次深度有限。

  地理层次深度通常包含3-6层。

  与其使用复杂的机制构建可变深度层次，不如直接构建固定深度层次

• 具有层次桥接表的参差不齐/可变深度层次

  可变深度层次本身难以建模，而且查询时弊端多多。这些问题可以使用层次桥接表来解决。

  桥接表对每个可能的路径保留一行，确保能够遍历所有层次的形式，采用标准的SQL来实现。

  说白了就是给可变深度层次设置路线表，所有的位置都有一个记录负责导航。

• 具有路径字符属性的可变深度层次

  可以在维度表中采用路径字符属性，以避免使用桥接表。

  路径字符方法也难于构建可变路径层次的变化，可能需要标记整个层次。

2.7 高级事实表技术

• 事实表代理键

  代理键可用作所有维度表的主键。

• 蜈蚣事实表

  如果维度有日期维度，月份维度，季度维度，年维度，而且还全部保存在一个事实表中。这些维度本身就有赘述的地方，不如全部归结到日期维度上，然后细化日期维度的粒度。

  被这样重复的维度包裹的事实表就是蜈蚣事实表，乍一看好像都有用，其实也都没用。

• 属性或事实的数字值

  如果数字用于计算，则属于事实表；如果数字用于过滤或确认分组，则属于维度表。

• 日志/持续时间事实

  有的业务流程中有许多延迟点，这些延迟点是需要进行记录，方便以后优化业务流程，但是与其在需要的时候再去进行时间戳运算，不如直接建立一个日志事实表，根据过程的开始点为每个度量步骤存储一个时间延迟。

• 头/行事实表

  头指针行指向行级别事实表，将头指针行与多个事务行关联。这样的结构一般用于操作型交易系统。

• 分配的事实

  多数情况下，应该避免建立头指针级别的事实表，除非这样的聚集能够获得查询性能上的改善。

• 利用分配建立利润与损失事实表

  ①必须有C级别领导支持，②关于利润，亏损，投入金额都需要最细粒度，③过程最好使用ETL完成。

• 多种货币事实

  货币事实表应当包含一对属性和一个维度：前者包含以真实币种表示的事实，后者包含以整个事实表统一的单一标准币种表示的事实，维度是用于区分事务的真正货币。

• 多种度量事实单位

  某些业务过程需要事实以多种度量单位表示，比如面向业务用户的，面向消费者的，面向运输方面的。但是如果事实表包含大量事实，不如将事实以公认的标准度量单位存储。这样的事实表可以按照不同用户的观点进行转换，只需要选择适当的转换系数。

• 年-日事实

  YTD值应该使用BI应用后OLAP多维数据库进行计算，而不是在事实表查询。

• 多变SQL以避免事实表间的链接

  绝不应该跨事实表的外键来处理两个事实表的连接操作。

  要采用跨钻方式使用两个事实表，并对结果按照公共行头指针属性值，进行排序-融合操作以产生正确的结果。

• 针对事实表的时间跟踪

  缓慢变化维度的类型2

• 迟到的事实

  是指如果用于新事实行的多数当前维度内容无法匹配输入行的情况。

  出现这种情况必须搜索相关维度以发现有效的维度键。

2.8 高级维度技术

• 维度表连接

  维度表的连接必须通过事实表

• 多值维度与桥接表

  如果出现单一事实对应多个维度（例如一个人监察出多个疾病，他就会得到多个诊断结果）。

  在此情况下必须通过一组维度键通过桥接表使一组中的每个诊断都与事实行关联。

• 随时间变化的多值桥接表

  必须基于缓慢变化类型2维度，来保证N对多的正确连接，桥接表必须包含有效期时间戳。

• 标签的时间序列行为

  用户的行为标签应该在设计用户维度时提前建立好位置。

• 行为研究分组

  通过客户已有行为标签进行多次迭代分析，来发现复杂的客户行为。通过BI应用来分析是不现实的。

  我们可以提取标签的持久键自成简单表来进行研究，这些表被称为行为研究分组、

• 聚集事实作为维度属性

  商业用户对于基于聚集新能度量的客户维度感兴趣，例如去年花费超过一定额度的用户。

  聚集性能度量将增加ETL处理的负担，但是可以方便BI的分析功能。

• 动态值范围

  如果查询价值20-30元商品的销售情况，肯定会使用自定的行头来进行查询，而不是在ETL中进行定义。

  行定义可以通过在小值范围维度表实现，通过大于连接或小于连接而与事实表实现连接，可以直接通过SQL的CASE语句实现。

• 文本注释维度

  将自由注释放在文本注释维度，使该注释维度成为对应事实表的一个外键。

• 多时区

  应有通用时间与本地时间，在受影响的事实表中设计双外键，用于连接两个不同角色的日期维度表

• 度量类型维度

  当事实表每行存储着稀疏的事实时，可以考虑建立度量维度，通过度量维度将事实表变成单一事实。

  不推荐这样做。

• 步骤维度

  用于记录用户浏览深度。

• 热交换维度

  假设有一行股票的事实，将这个事实推送给不同投资人维度，每个投资人对这个事实的看法和切入角度肯定都不同。

  同一事实表与相同维度的不同拷贝交替搭配。

• 抽象通用维度

  把用户维度，雇员维度，客户维度混合成一个人维度。

  他们虽然都是人，但是他们有不同的属性。

  抽象通用维度应该避免使用。

• 审计维度

  审计维度–>元数据管理。

• 最后产生的维度

  客户购买特定商品的自然键，在实时ETL过程中即便客户还没有确认下来，但是也必须建立特殊的维度行，哪怕用未知数来表示。

2.9 特殊目的模式

• 异构产品的超类与子类模式

  金融服务不同于其他业务类型，因为他们有广泛的产品。

  不可能建立一个事实表来把所有的业务全部装填进去，但是可以建立单一的超类事实表，该事实表有所有账户类型的事实表，然后系统地划分出不同子类建立不同的和维度相关联的事实表。

  超类是核心，子类是事实表。

• 实时事实表

  实时事实表–>实时数仓。

• 错误事件模式

  错误事件模式–>数据治理。

  当数据质量屏幕检测到错误时，该记录会被存储在特殊的维度模式。

  粒度为单独错误事件和相关错误详细事实表，相关错误详细事实表粒度为参与错误事实的每个表中的列。

总结

这一章主要阐述了Kimball架构的设计流程与步骤，事实表与维度表的建模，维度的变化类型，在Kimball中一切维度变化都可以使用缓慢变化维度来诠释。
数仓的特殊目的也是现在很看重的地方，比如元数据管理，实时数仓，数据治理等等。