数据仓库工具箱

数据仓库与Kimball维度建模概览

操作型系统与数据仓库

• 操作型系统：
  保存、更新、删除数据
  一般一次处理一个事物
  不必维护历史数据，只需要修改数据以反映最新的状态
  优化目标是更快的处理事物

• DW/BI系统：
  使用数据
  一般一次处理多个事物
  需要保存数据的变化状态
  优化的目标是高性能的完成用户的查询

  DW/BI系统不是操作型系统记录的拷贝，因为其巨大的差异，理应将这两种系统隔离

DW/BI系统的特征

1. 查询简单、快捷。数据要直观，容易以各种方式组合切分数据，且能短时间返回查询结果。
2. 数据一致性。同名同义性与异名异义性，对不同来源的数据要进行清洗、确保质量。
3. 易扩展。能够简单方便的进行更改，而不破坏现存的数据和应用。
4. 及时展现信息。将原始数据在短时间内转换成可以使用的信息。
5. 安全性。
6. 决策支持。输出是基于数据分析所产生的决策，这是数据仓库核心的影响和价值。
7. 用户易于接受。与操作型系统的不可替代性不同，数据仓库对业务人员来说是可选的。

维度建模

维度建模是展示、分析数据的首选技术的原因在于：

• 以商业用户可理解的方式发布数据
• 提供高效的查询性能

简单性是至关重要的，从简单的数据模型开始是保持设计简单性的基础。业务描述场景的例子：我们在各种各样的市场销售产品，并不断的对我们的表现进行度量。市场、产品、时间是维度，度量可以是销售额或者利润。

ER模型：实体-关系模型，使用3NF范式来划分不同的实体，目的是为了消除冗余。主要用于操作型的系统中，因为对事物的更改仅触及数据库中的小块单一的地方。
维度模型：不完全遵守范式，用户不能理解复杂的关系图，而且用户的查询往往很复杂，对查询性能有高要求。

OLAP与星型模式
OLAP
数据结构为多维数据集（cube），对维度进行了设计（预计算、索引策略），可以方便的切片、切块和上钻下钻。
（类似报表，根据你查询的属性来决定是否上钻下钻。比如查询国家的GDP，再要查询各省的GDP，只需要把省这一属性加入进去就可以了，反之也是一样，不需要重新写查询）
另外就是支持大量的分析函数，比如窗口函数、切片切块函数等。

基于星型模式的维度建模（ROLAP），详细的、原子的信息使用星型模式加载。
OLAP的数据结构差异大，不同的工具之间的建立BI应用比不同关系型数据库之间建立BI更难。
一旦维度发生了变化，就需要全部或部分重新处理数据。因此可以方便的支持事务和周期性快照事实表，但无法处理累计快照事实表。
自身支持特殊的查询语法，能够提供更丰富的数据分析能力，能够提供更多更复杂的安全选项。

Cognos的Powerplay、Hyperion 的Essbase和微软的Analysis Service这些产品都是MOLAP产品。.这类产品将数据从关系数据库（甚至是文本文件、Excel文件）中抽取出来，存储在自己的数据库中。这种数据库跟寻常我们所见的Oracle、DB2这类关系数据库不同之处在于，它是专有格式的，且没有标准的訪问接口。因此，这些产品怎样实现多维存储也都不尽同样，大致的原理是以编程语言中多维数组的方式存放数据。度量值存放在数组的单元格中，而数组每一个维就相应一个维度，当中，维元素就维的坐标。

事实表
“事实”表示某个业务度量。事实表中的每行代表一个度量事件。每行数据都有一个特定级别的粒度。同一事实表中的所有度量必须具有相同的粒度。
度量可分为可加、半可加、不可加三类，对于可加与半可加可以进行有效的汇总。
事实表分为三类：事物、周期性快照和累计快照
不要试图以空字符串或0来表示没有活动发生，仅将发生的活动放入事实表，事实表将变得非常稀疏。

维表
维度是对与度量事件有关的环境的描述。
属性应该包含真实使用的词汇而不是令人迷惑的缩写；尽量少在维度表中使用代码，而应该使用中文描述（两者都保留也可）；如果代码中包含多个含义，比如代码前半部分代表区号，后半部分代表号码，应该拆分成两个维度。
维度一般更关注简单性和可访问性，因为其相较于事实表数据量更小，对于数据冗余的容忍度更高，因此常常被设计为非规范化的。

维度与度量的区分：
如果该列数据经常变化，常参与计算，则通常为度量。如果是一个常量，常用于约束或者标识，则通常为维度。

Kimball的DW/BI架构

DW/BI分为四个部分：

• 操作型源系统
  查询浅显，一次一条的查询。一般不维护历史信息。不与起他操作型系统共享数据。
• ETL系统
  ETL是将数据从源系统导入数据仓库的第一步，ETL数据属于数据仓库的数据。
  需要对数据进行多种处理，如数据清洗、合并数据、复制数据等。
  最后是将数据加载到目标维度模型中，划分维度和事实。此处重点关注维度表的处理，如分配代理键、为代码提供描述、拆分或组合列、组合维度成为宽维度表等。

  虽然可以在ETL过程中对数据进行规范化改造，但同时会增加开发和硬件资源以及人力的负担。因此建立规范化结构并不是最终目标，而应该将主要的精力和资源投入到改进业务决策的维度展现区域中。

• 展现区
  1. 数据应当以维度模型来展现，要么采用星型模式，要么采用OLAP多维数据库。
  2. 展现区必须包含详细的原子数据，仅仅只有汇总数据不能满足业务的查询需求。
  3. 展现区的数据可以围绕业务过程度量事件来构造（业务场景？），业务过程往往有各部门的交叉，所以建立单一事实表时不仅仅从相似性来考虑，应该考虑整个业务流程或业务场景。比如销售只是业务中的一环，还有市场、财务、风控等一系列相关的维度。
  4. 遵守总线结构。保证维度的公共性和一致性。
• 商业智能应用
  查询，数据挖掘，建模

其他 DW/BI架构

1. 独立数据集市架构
   根据业务部门来构建集市，即使不同的集市的数据源是同一个。对于单个的部门集市采取维度建模的方法，但没有采取维度建模理论的核心原则，比如关注细节、根据业务过程建模、利用一致性维度实现一致性和集成等。
   优点是开发成本低，开发便捷。
   缺点是数据冗余和低效，不同部门的数据采用的规则不尽相同，导致数据无法集成，协调问题将会导致业务矛盾。

2. Inmon架构
   与Kimball架构不同之处在于，ETL系统中获得的原子数据保存在满足第三范式的数据库中（EDW企业级数据仓库），协调与集成也应当使用EDW来完成，而且数据仓库的原子数据是开放给用户查询的。
   另外，分析数据库通常以部门为中心而不是围绕业务过程来组织，且通常是保存汇总数据。

3. 混合架构
   使用Inmon的EDW，但EDW与展现层隔离。展现层使用Kimball的一致性维度，既保存原子数据也保存汇总数据。

维度建模神话

1. 维度模型仅包含汇总数据
   因为业务需求的复杂性，汇总数据不可能满足业务的所有需求，因此开放明细数据是必须的。认同这一神话会导致仅在维度结构中保存有限的历史数据。
2. 维度建模是部门级而不是企业级的
   避免多次获取同一个数据源，会产生多个不一致的分析数据库。
3. 维度模型是不可扩展的
4. 维度模型仅用于预测
   设计应该以业务过程为中心，能够适应变化。维度模型应当以最详细的粒度表达数据，可以获得最好的灵活性和可扩展性。
5. 维度模型不能集成
   集成的核心是一致性维度，将一致性维度作为集中的、持久的主数据建立在ETL系统中。

Kimball 维度建模技术

维度建模的步骤

1. 与业务人员交流理解需求，与数据源系统专家交流了解源数据实现。
2. 数据建模人员与业务人员研讨确定模型。
   2.1 选择业务过程
   2.2 声明粒度
   2.3 确认维度
   2.4 确认事实

方便的扩展维度模型

以下情况可以在不更改原有数据的情况下，对模型进行扩展：

• 事实与已存在的事实表粒度一致时，新增列即可。
• 维度与事实表的粒度一致时，新增外键列。
• 在维度表上新增列来扩展维度属性
• 将事实表的粒度降到更细，在维度表上新增粒度更细的属性。

事实表技术基础

• 事实表结构：
  每一行数据对应一个度量事件，存储的是可度量的数值。也包含可选的退化维度和时间戳。

• 可加、半可加与不可加度量：
  可加度量最为灵活，半可加度量如分期余额，不可加度量如百分比。最好是将半可加与不可加的度量拆分成可加的度量。

• 事实表的空值：
  度量可以为空，但是外键（维度列）不能为空，应使用默认值替代。

• 事实的一致性：
  同名同义性，异名异义性

• 事物事实表、周期快照事实表、累计快照事实表：
  最大的区别是时间窗口。
  事物事实表可以是稀疏的。
  周期快照事实表是周期性的，这里的周期指的是数据统计的周期，比如每天、每月、每年一条数据。
  累计快照事实表包含多种度量，可能涉及多个业务过程，且会不定期更新。

• 无事实的事实表：
  没有可以数字化度量的事实，比如客户参与活动的记录。

• 合并事实表：
  双网与直销的办卡申请。

维度表技术基础

维度表有且只有单一的主键。通常扁平且不规范，包含大量文本属性。维度属性常用于查询的条件约束、分组定义和报表的描述性标识。

• 维度代理键：
  即维度表的主键，非源表的自然键。由于数据来源不同且需要保存同一条数据的历史，因此需要另外的无业务含义的代理键。（如自增主键、GUID等）

• 退化维度：
  事实表的维度除了外键以外没有其他内容，这时将这种退化维度放入事实表中。

• 非规范化的扁平维度：
  为了达到简化及速度。

• 多层次维度：
  维度包含多种层次，当层次树的枝干深度不一时，使用回填或桥接表。

• 维度中的空值：
  当有维度行的维度属性为空时，使用描述性的字符串来填充。避免因为数据库系统对空值的处理不一致而导致问题。

• 日期日历维度：
  日期维度作为主键更有意义。

• 杂项维度：
  合并维度。维度之间的组合是有限的，并不是各个维度的笛卡尔积。

• 支架维度：
  维度表引用维度。应该尽量使用事实表来引用维度，不同维度通过事实表最为纽带。

使用一致性维度集成

当不同的维度表的属性具有相同列名和领域内容时，称维度表具有一致性。
当不同的事实表使用同一个一致性维度属性时，这些事实表的数据就可以合并在一张报表中展示。

• 缩减维度：
  在只使用部分维度属性和维度行的时候，需要缩减维度。通常构建聚集事实表时，需要缩减上卷维度。另一种情况是某个维度只能对应到另一个相同粒度的维度的部分行时。

• 价值链：
  业务流程。为价值链上的每一个环节建立事务或者快照。

• 总线架构：
  不同的业务流程在企业级上的结构，通过一致性维度进行集成。

• 总线矩阵：
  一个设计总线架构的工具。行表示业务过程，列表示维度。

处理缓慢变化维

1. 类型0：原样保留
   维度属性不会发生变化，比如成为我行持卡客户的时间。
2. 类型1：重写
   原维度属性的值被新值覆盖。比如是否绑定微信。
3. 类型2：增加新行
   插入一行新的数据。必须有生效时间、失效时间与行标识三个新栏位。比如卡片有效期。
4. 类型3：增加新列
   将旧值与新值放到不同的列中保存。当对生效时间不敏感，且仅需要知道上一次的旧属性时才可使用。不常用。
5. 类型4：增加微型维度
   当维度表数据量庞大，或者维度属性经常变化时，需要将维度属性单独划分为微型维度。
6. 类型5：结合类型1与类型4
   单独划分出微型维度，并在原维度表中设置外键关联到微型维度表。卫星维度表可按照类型2的方式保存历史状态，只需要按照类型1的方式更新原维表即可。
7. 类型6：
   与类型2的不同之处在于，类型2是插入新行，类型6是插入历史，修改当前的行到最新的属性值。

处理维度层次关系

分为固定深度层次与可变深度层次。
可变深度层次转换为固定深度层次。使用默认值或叶子节点的值进行填充。或者使用桥接表结合路径深度的方式。

高级事实表技术

避免蜈蚣事实表。带有层次的维度表，不是按照最低粒度来与事实表建立关联，而是每个层次的维度都与事实表建立关联时，会产生蜈蚣事实表。

数值型是否是度量，需要看其用途。如果数字值用于分组或过滤，应把其看作维度。

避免头指针事实表。该事实表是一种汇总，指向多个其他事实表。在操作型系统中常常出现。（比如说活动指向客群、事件与动作）

多种货币事实，在保存原有货币的事实的情况下，新增一列保存单一标准币种的事实。

同一度量值有多种单位的情况，可以将度量值以公认的标准度量单位存储，再保存标准度量与其他度量的转换系数。

事实表之间绝对不能直接使用公共维度进行关联。应该使用公共维度进行Union。

事实表中与缓慢变化维的类型2类似，也可以加上数据生效时间、失效时间与行标识，来表达事实表中缓慢变化的场景。（如关注与取关微信）

高级维度技术

多值维度与多值桥接表

行为维度

聚集事实维度

动态值范围

步骤维度

审计维度