数据仓库建模基础理论研读

数仓建模目标

        有序、有结构地分类组织和存储。

        数据模型就是数据组织和存储方法，它强调从业务、数据存储和使用角度合理存储数据。模型体现了表之间的关联关系，而关系是业务的抽象。

        面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性， 一直是大数据系统建设不断追求的方向。

数仓建模优势

• 性能： 良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐。 
• 成本： 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
• 效率： 良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
• 质量： 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

定位和价值

        建立统一的、规范化的数据接入层（ODS）和数据中间层（DWD和DWS），通过数据服务和数据产品，完成数据公共层建设。

典型的数据仓库建模方法论

1. 范式建模
   主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
   这种建模方式在范式理论上符合 3NF，这里的 3NF 与 OLTP 中的 3NF 还是有点区别的：关系数据库中的 3NF 是针对具体的业务流程的实体对象关系抽象，而数据仓库的 3NF 是站在企业角度面向主题的抽象。 从流程上看是自上而下的

• 具有以下三个条件:
  • 每个属性值唯一，不具有多义性 ;
  • 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
  • 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
• 优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。
• 缺点：表的数量多；查询时关联表较多使得查询性能降低。

2. 维度建模 Kimball模型从流程上看是自下而上的，即从数据集市-> 数据仓库 -> 分散异构的数据源。Kimball是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经 ETL 转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。

• 优点：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。
• 缺点：数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性。

数仓体系

        数据域面向架构，主题域面向业务。

        事实表分为明细事实表（事务性事实表、累计快照事实表、周期性事实表）和轻度汇总事实表。

        模型设计以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义）。

指标体系

        原子指标、派生指标、衍生指标。

        原子指标必须挂靠在某个业务过程下。

        派生指标唯一归属一个原子指标，继承原子指标的数据域， 与修饰词的数据域无关。

        派生指标可以分为三类： 事务型指标、存量型指标和复合型指标。

模型设计：

        数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

        把表数据模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），其中公共维度模型层包括明细数据层（DWD）和汇总数据层（DWS）。

• 操作数据层（ODS）：

  • 把操作系统数据几乎无处理地存放在数据仓库系统中。
  • 同步：结构化数据增量或全量同步到MaxCompute 。
  • 结构化：非结构化（日志）结构化处理并存储到MaxCompute。
  • 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。

• 公共维度模型层（CDM）：

  • 存放明细事实数据、维表数据及公共指标汇总数据， 其中明细事实数据、维表数据一般根据ODS 层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
  • CDM层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。
  • 其主要功能如下：
    • 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
    • 公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。
    • 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。

• 应用数据层（ADS）：

  • 存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。
  • 个性化指标加工：不公用性、复杂性（指数型、比值型、排名型指标）。
  • 基于应用的数据组装： 大宽表集市、横表转纵表、趋势指标串。

判断模型优劣基本原则

1. 高内聚和低辑合

• 降低业务过程之间的耦合性。
• 从数据业务特性和访问特性两个角度来考虑：
  • 将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；
  • 将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

2. 核心模型与扩展模型分离

• 不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。

3. 公共处理逻辑下沉及单一

• 不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。

4. 成本与性能平衡

• 适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

5. 数据可回滚

• 处理逻辑不变，在不同时间多次运行数据结果确定不变。

6. 一致性

• 具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。

7. 命名清晰、可理解

维度设计

        维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

        维度的作用一般是查询约束、分类汇总以及排序等。

        维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有两种：代理键和自然键，它们都是用于标识某维度的具体值。但代理键是不具有业务含义的键， 一般用于处理缓慢变化维；自然键是具有业务含义的键。

        数据仓库的能力直接与维度属性的质量和深度成正比。

• 维度设计方法：

  1. 选择维度或新建维度

  • 作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。

  2. 确定主维表

  • 此处的主维表一般是ODS表。

  3. 确定相关维表

  • 根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

  4. 确定维度属性

  • 第一个阶段是从主维表中选择维度属性或生成新的维度属性；
  • 第二个阶段是从相关维表中选择维度属性或生成新的维度属性。

• 确定维度属性的几点提示：

  1. 尽可能生成丰富的维度属性；

  2. 尽可能多地给出包括一些富有意义的文字性描述；

  3. 区分数值型属性和事实；

  • 如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常用于参与度量的计算， 则是作为事实。

  4. 尽量沉淀出通用的维度属性。

• 维度的层次结构：

  • 维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。

  • 在属性的层次结构中进行钻取是数据钻取的方法之一。

  • 将维度的属性层次合并到单个维度中的操作称为反规范化。分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。采用雪花模式，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。

• 一致性维度和交叉探查：

  • 当存在重复的维度，但维度属性或维度属性的值不一致时，会导致交叉探查无法进行或交叉探查结果错误。
  • 维度格式和内容不一致两种类型。    时间格式

• 维度设计高级主题：

  • 数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合。

• 应用之间的差异具体表现在如下几个方面：

  • 应用在编码、命名习惯、度量单位等方面会存在很大的差异。
  • 应用出于性能和扩展性的考虑，或者随技术架构的演变，以及业务的发展，采用不同的物理实现。

• 数据由面向应用的操作型环境进人数据仓库后，需要进行数据集成。将面向应用的数据转换为面向主题的数据仓库数据，本身就是一种集成。

  • 命名规范的统一
  • 字段类型的统一
  • 公共代码及代码值的统一
  • 业务含义相同的表的统一

• 维表的整合：

  1. 第一种是垂直整合，即不同的来源表包含相同的数据集，只是存储的信息不同。
  2. 第二种是水平整合，即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。（设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键。通常采用将来源表各子集的自然键作为联合主键的方式，并且在物理实现时将来源字段作为分区字段）

• 水平拆分：

  • 原则：
    • 扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。
    • 效能： 在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化。
    • 易用性：模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表，并能够方便地查询和分析。
  • 依据：
    • 第一个依据是维度的不同分类的属性差异情况。当维度属性随类型变化较大时，将所有可能的属性建立在一个表中是不切合实际的。定义一个主维度用于存放公共属性；同时定义多个子维度，其中除了包含公共属性外，还包含各自的特殊属性。
    • 第二个依据是业务的关联程度。两个相关性较低的业务，稠合在一起弊大于利，对模型的稳定性和易用性影响较大。

• 垂直拆分：

  • 某些维度属性的来源表产出时间较早，而某些维度属性的来源表产出时间较晚；或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用； 或者某些维度属性经常变化，而某些维度属性比较稳定。

• 缓慢变化维：

  • 缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。与数据增长较为快速的事实表相比，维度变化相对缓慢。
  • 处理方式：
    1. 重写维度值。不保留历史数据，始终取最新数据。
    2. 插入新的维度行。采用此种方式，保留历史数据，维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联。
    3. 添加维度列。采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。
  • 处理缓慢变化维的方法是采用快照方式。数据仓库的计算周期一般是每天一次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据。
  • 优点：
    • 简单而有效，开发和维护成本低。
    • 使用方便，理解性好。数据使用方只需要限定日期，即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。
  • 弊端：
    • 主要体现在存储的极大浪费上。

• 行为维度：

  1. 指标事实
  2. 指标事实分类枚举
  3. 行为事实+分组
  4. 复杂逻辑计算

事实表设计

• 事实表基础：

  • 事实表 = 维度 + 度量

• 度量反映指标

  • 事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
  • 维度的组合表现事实表的粒度。
  • 事实表中一条记录所表达的业务细节程度被称为粒度。
  • 通常粒度可以通过两种方式来表述：
    • 一种是维度属性组合所表示的细节程度：
    • 一种是所表示的具体业务含义。

• 事实表度量分类：

  • 可加性、半可加性、不可加性

• 通常事实表要细长得多，行的增加速度也比维表快很多。

• 维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”

• 事实表有三种类型： 事务事实表、周期快照事实表和累积快照事实表。

  • 事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为“原子事实表”。
  • 周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。
  • 累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点， 当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。

• 事实表设计原则：

  • 原则1 ：尽可能包含所有与业务过程相关的事实

  • 原则2 ：只选择与业务过程相关的事实

  • 原则3 ： 分解不可加性事实为可加的组件

  • 原则4 ：在选择维度和事实之前必须先声明粒度

  • 原则5 ： 在同一个事实表中不能有多种不同粒度的事实

  • 原则6 ：事实的单位要保持一致

  • 原则7 ： 对事实的null值要处理（建议用零值填充）

  • 原则8 ：使用退化维度提高事实表的易用性

• 事实表设计方法：

  • 第一步： 选择业务过程及确定事实表类型

    • 结合主题划分。

  • 第二步：声明粒度

    • 应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。

  • 第三步： 确定维度

    • 选择能够描述清楚业务过程所处的环境的维度信息。

  • 第四步： 确定事实

    • 基于业务需求场景。
    • 需要将不可加性事实分解为可加的组件。

  • 第五步： 冗余维度

    • 通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

• 事务事实表

  • 事务事实表可以很好地跟踪一个事件，并对其进行度量。

  • 明确清晰业务的执行过程。

  • 设计过程：

    1. 选择业务过程
    2. 确定粒度
    3. 确定维度
    4. 确定事实
    5. 冗余维度

  • 单事务事实表，即针对每个业务过程设计一个事实表，可以方便地对每个业务过程进行独立的分析。

  • 多事务事实表， 将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。

    • 多事务事实表在设计时有两种方法进行事实的处理： 

      • ①不同业务过程的事实使用不同的事实字段进行存放；

      • ②不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。

    • 当不同业务过程的度量比较相似、差异不大时，可以采用第二种多事务事实表的设计方式，使用同一个字段来表示度量数据。但这种方式存在一个问题——在同一个周期内会存在多条记录。
    • 当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式，将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置0表示。这种方式所存在的问题是度量字段0值较多。
    • 业务过程的切分可以参考过程中的事实粒度，这也是划分二级主题的一个参考原则。

• 两种事实表对比：

  1. 业务过程

  • 分析不同业务过程之间的相似性和业务源系统

  2. 粒度和维度

  • 当不同业务过程的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表。

  3. 事实

  • 单事务事实表在处理事实上比较方便和灵活，仅仅体现同一个业务过程的事实即可。

  • 而多事务事实表由于有多个业务过程， 所以有更多的事实需要处理。

  • 如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑使用单事务事实表，处理更加清晰； 若使用多事务事实表， 则会导致事实表零值或空值字段较多。

  4. 下游业务使用

  • 单事务事实表对于下游用户而言更容易理解， 关注哪个业务过程就使用相应的事务事实表；而多事务事实表包含多个业务过程，用户使用时往往较为困惑。

  5. 计算存储成本
  • 当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实相对不多时，此时可以考虑使用多事务事实表，不仅其加工计算成本较低，同时在存储上也相对节省，是一种较优的处理方式。

• （周期）快照事实表——状态度量

  • 无法在时间维度进行汇总。

  • 如果用事实表处理，随着时间跨度变大，聚集效率会越来越低，成本越来越高。

  • 用于：

    1. 需要聚集与之相关的事务才能进行识别计算；
    2. 聚集事务无法识别。

  • 快照事实表在确定的间隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。

  • 快照事实表特性：

    1. 事务事实表的粒度能以多种方式表达，但快照事实表的粒度通常以维度形式声明；
    2. 事务事实表是稀疏的，但快照事实表是稠密的； 
    3. 事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。

  • 具体说明：

    1. 用快照采样状态

    • 快照事实表以预定的间隔采样状态度量。这种间隔联合一个或多个维度，将被用来定义快照事实表的粒度，每行都将包含记录所涉及状态的事实。

    • 一般的间隔周期以天为单位。

    2. 快照粒度

    • 事务事实表的粒度可以通过业务过程中所涉及的细节程度来描述，但快照事实表的粒度通常总是被多维声明，可以简单地理解为快照需要采样的周期以及什么将被采样。

    • 快照周期不一定都按天来进行，也可以按照月或者季度来统计。

    3. 密度与稀疏性

    • 事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实；而快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行，

    • 稠密性是快照事实表的重要特征。

    4. 半可加性

    • 在快照事实表中收集到的状态度量都是半可加的。

    • 半可加性事实不能根据时间维度获得有意义的汇总结果。

    • 虽然不能汇总，但可以计算一些平均值。

  • 构建过程：

    1. 确定快照事实表的快照粒度。

    2. 确定快照事实表采样的状态度量。

  • 类型：

    1. 单维度的每天快照事实表

    2. 混合维度的每天快照事实表

    3. 全量快照事实表

  • 注意事项：

    1. 事务与快照成对设计

    • 丰富了星形模型，又降低了下游分析的成本。

    2. 附加事实

    • 一般在设计周期快照事实表时会附加一些上一个采样周期的状态度量。

    3. 周期到日期度量

• 累计快照事实表

  • 对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。

  • 累积快照事实表解决的最重要的问题是统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。

  • 特点：

    1. 数据不断更新

    2. 多业务过程日期

• 三种事实表比较

  • 事务事实表记录的事务层面的事实，用于跟踪业务过程的行为，并支持几种描述行为的事实，保存的是最原子的数据，也称为“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插人，数据就不能更改，其更新方式为增量更新。

  • 周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，如余额、库存、层级、温度等，时间间隔为每天、每月、每年等，典型的例子如库存日快照表等。周期快照事实表的日期维度通常记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值或状态度量。事实表的数据一旦插人就不能更改，其更新方式为增量更新。

  • 累积快照事实表被用来跟踪实体的一系列业务过程的进展情况，它通常具有多个日期字段，用于研究业务过程中的里程碑过程的时间间隔。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，而且这类事实表在数据加载完成后，可以对其数据进行更新，来补充业务状态变更时的日期信息和事实。

文中观点结合《大数据之路：阿里巴巴大数据实践》