数据仓库进阶 《阿里大数据之路》第二篇 数据模型篇 (完整版)

第8章 大数据领域建模综述

此文章为学习笔记，有兴趣的小伙伴可以根据以下指引获取更多，学习内容链接如下：

视频：【一起啃书】阿里大数据之路数据仓库建模基础理论研读(已完结)_哔哩哔哩_bilibili

书籍：《阿里大数据之路》

8.1 为什么需要数据建模

1. 建模目标：有序、有结构地分类组织和存储 存储在hdfs等文件系统
2. 数据模型含义：就是数据组织和存储的方式，它强调从业务、数据存取和使用角度合理存储数据

• 此处举例：表和模型有什么区别 模型多了一层业务的含义

3. 建模好处：在性能、成本、效率和质量之间取得最佳平衡

• 成本：包括存储成本和计算成本
• 效率：数据质量好，对应效率也会高

8.2 关系型数据库和数据仓库/OLTP和OLAP

1. OLTP是业务数据库系统，一般是关系型数据库,例如Oracle、Informix、DB2，对三范式要求比较高，一般用ER模型建模方式

2. OLAP是决策类的系统，通过对业务系统的在分析，产出决策回流到业务系统中。

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

8.4.1 ER 模型

1. 内容：全企业高度设计一个3NF模型，很少的数据冗余
2. 难点：梳理整个企业的所有的业务实体的抽象 非具体业务流程的抽象
3. 特点：周期长、全面了解企业业务、对建模人员 要求高

8.4.2 维度模型

1. 内容：基于事实和维度的两个因素来构建模型 多冗余

• 类比结构化思维：找出于问题相关的实体，基于实体单个进行考虑

8.4.3 Data Vault模型

略，后续补充

8.4.4 Anchor 模型

略，后续补充

8.5 阿里的数据模型实践综述

1. 过程：

• Oracle时期，部分采用一切维度建模的缓慢变化维方式进行历史数据处理，有两层ODS+DSS—>

• 引入MPP架构的Greenplum，希望改变烟囱式开发的情况，采用ER模型+维度模型，有四层ODL+BDL+IDL+ADL,实践中ER模型产出不行—>

• 以Hadoop的数据存储和MR的数据计算，整合出一套OneData体系，三个内容：指标定义体系、模型设计方法体系以及配套工具

第9章 阿里巴巴数据整合及管理体系

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

• 模型的优化
• 体系:包含数据模型、数据分层、数据主题划分、数据治理、元数据管理、数据安全权限、数仓可视化产品的完整数仓服务体系，核心在于数据驱动核心：数据模型，目标核心：数据服务
• 组织：组织映射到数仓的主题划分（纵向)、分层（横向)，类比图书馆：分好几楼，每楼有不同的区域图书
• 存储：生命周期管理、数据治理

9.1 概述

1. 方法论的核心：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可避免重复建设

• 业务架构：①理解业务的能力，②考验综合能力：业务沟通，③业务复杂处理：业务非一条流程而存在分支，业务随时间、组织调整变化
• 数据研发与数据服务：是未来数仓的发展方向，比如数据质量和数据治理提升数据准确度，数据产品提升数据可视化服务

9.1.1 定位和价值

建设统一的、规范化的数据接入层（ODS)和数据中间层（DWD和DWS)，通过数据服务和数据产品，完成大数据体系建设。

• 规范化：有时受到人员和业务的发展影响，难以进行完全的规范化

9.1.2 体系架构

1. 业务板块：企业层级以及业务部门层级，业务之间有隔离，例如阿里分金融、电商等业务域，蚂蚁的信贷、理财、大安全
2. 数据域：即主题域的划分，例如交易的主题域，信贷的交易可能是放款、还款，财富这一块可能是基金购买、基金赎回，教育类的交易可能是购买课程到学习完成后的过程
3. 指标基础：针对主体与对业务过程进行梳理，然后业务过程中的度量值或者原子指标
4. 派生指标：原子指标即加上修饰词或者修饰类型(理解直接简单的口径),再加上时间的周期，就等于派生指标

• 复杂口径以及简单口径：复杂的需要多个指标进行加减乘除，简单指主体是还是这个指标

• 派生指标= 原子指标+时间周期+修饰词

• 例如：近一个月北京的订单量 花呗支付的金额

5. 汇总5事实表：派生指标组成汇总事实表（把明细数据聚合的事实表，轻度汇总)：无加减乘除，只增加了一些口径

6. 明细事实表： 原子指标组成明细事实表(最原始粒度的明细数据)

7. 后续的事务性事实表，累计快照事实表，周期性快照事实表是针对明细事实表在进行分类划分

8. 维度：

   • 描述实体的
   • 可以进行维度退化，退化到事实表中，从而增加分析维度和口径

流程：确定企业层级和业务部门的数仓，然后去确认主题域，再去梳理业务过程，基础数据就是原子指标，落到DWD形成明细事实表，加上修饰词变成派生指标，形成轻度DWS汇总事实表，维度会经过维度退化和事实表关联。

9.2 规范定义

例如有个电商业务，下面分为很多主题域，例如营销，交易，交易域下面又有支付、订单，支付下面有支付方式，支付方式中花呗这一个修饰词，与支付金额组成一个派生指标，加上周期，即最近一天通过花呗的支付金额有多少，如果在把订单id拿过来和支付指标关联，将会获得更多的分析维度

9.2.1 数仓主题域划分

1. 主题域和业务过程的关系：基于业务中间有什么实体，整个业务过程可以抽象为几个业务大类，然后去划分主题域，所以说业务过程不一定都是主题域，主题域是对业务过程的抽象，一般主题域是可以有好几层的，例如小公司主题域划分到好几层之后，主题域就接近付款、下单等业务过程的粒度了
2. 业务过程： 实践中比较复杂，可能进行循环
3. 几个常见核心主题域：

• 用户：目标是为了实现用户增长，注意用户和客户的区别，客户是用户的子集 ，客户是有真正交易的
• 渠道：例如用户进入app的方式，例如电销平台
• 营销：一般和渠道有密切关系，例如优惠券等营销活动
• 流量：进入app的日志
• 交易：产品下单产生交易
• 财务：交易后产生的财务数据
• 商品：用户下单的商品

给他串起来，用户通过渠道进入app，产生流量日志，浏览商品下单产生了交易，交易后有财务数据，就是整个大的业务流程。

针对不同行业，一般不同的会在交易的主题上，例如电商的下单、支付、退货，教育行业的购买课程并上课，金融行业的放款到最终还款结束

如图

• 电信行业

• 电商行业

9.2.2 指标体系

1. 组成： 包括原子指标、派生指标、修饰类型、修饰词、时间周期
2. 基本原则：

• 组成体系之间的关系
  • 原子指标、修饰类型和修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域，例如：A渠道的支付金额，通过支付可以知道是属于支付主域的，渠道是修饰渠道主题域的，可以是跨域的组合
  • 派生指标可以选择多个修饰词，修饰词之间的关系为“或”或者“且”，例如：新客购买电子品类支付金额，修饰词：新客且电子产品
  • 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。
  • 一般而言，如果遇到同时有两个行为发生，需要多个修饰词、生成一个派生指标的情况，则选择时间靠后的行为创建原子指标，选择时间靠前的行为创建修饰词，例如：A渠道的支付金额，先经历了渠道后才产生的交易，渠道就发生比较前，后再进行消费产生支付金额，原子指标就比较靠后
• 命名规定
  • 根据实际公司而定
  • 尽量使用英文缩写，其次英文，再其次汉语拼音缩写
  • 关于存量指标后面可以加上_stock
  • 时间周期修饰词在后面加_1d,__iw，表示1天或者周
  • 做指标管理，方便后续指标检索，例如：7天A渠道销量，通过下拉框的方式，快速找到，可以和工具搭配起来

3. 操作细则

• 派生指标的种类：事务型指标、存量型指标和复合型指标
  • 事务型指标：是指对业务活动进行衡量的指标。例如：新发商品数，订单支付金额。是修饰词+原子指标
  • 存量型指标：是指对实体对象(如商品、会员)某些状态的统计。例如：商品总数是修饰词+原子指标+周期(一般是历史截至至当前某个时间)
  • 复合型指标：在事务型指标和存量型指标的基础上复合而成。
• 复合型指标的规则
  • 比率型：例如：最近1天店铺首页CTR(点击率)，原子指标为“CRT”，时间周期为“最近1天”，修饰类型为“页面类型”，修饰词为“店铺首页”
  • 比例型：例如：最近1天无线支付金额占比，原子指标为“支付金额占比”，时间周期为“最近1天”，修饰类型“终端类型”，修饰词为“无线”
  • 变化量型：例如：最近1天订单支付金额上1天变化量，原子指标为“订单支付金额”，时间周期为“最近1天”，修饰类型为“统计方法”，修饰词为“上1天变化量”
  • 变化率型：例如：最近7天海外买家支付金额占上7天变化率，原子指标为“支付金额变化率”，修饰类型“买家地域”，修饰词"海外买家"
  • 统计型(均值、分位数等)：例如：自然月日均UV，原子指标为“UV”，修饰类型为"统计方法"，修饰词为“日均”

补充：
PV(访问量)：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
UV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内 相同的客户端只被计算一次。
IP(独立IP)：即Internet Protocol,指独立IP数。00:00-24:00内相同IP地址之被计算一次。

• 其他规则
  • 上下层级派生指标同时存在:如最近1天支付金额和最近1天PC端支付金额，建议使用前者，保留上级，然后把PC段作为维度属性放在物理表中
  • 父子关系原子指标存在时：当父子关系原子指标存在时，派生指标使用子u案子指标创建派生指标。例如PV,IPV(商品详情页PV)，当统计商品详情页PV时，选择子原子指标

9.3 模型设计

9.3.1 指导理论

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

9.3.2 模型层次

1. 三层架构：数据操作层(ODS)、公共维度模型层(CDM)、应用数据层(ADS),主要公共维度模型层一般在不同公司有区别，一般是明细数据层(DWD)、汇总数据层(DWS),有的还有DIM(维度层)

• 注：数仓分层一般和业务无关

2. 操作数据层(ODS):把操作系统的数据几乎无处理的存放在数据仓库系统中。

• 同步：结构化数据增量和全量同步
• 结构化：非结构化(日志)结构化处理并存储
• 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据

3. 公共维度模型层(CDM):

• 存放明细事实数据(DWD)、维表数据(DIM)以及公共指标汇总数据(DWS),其中明细事实数据、维表数据一般根据ODS层数据加工生成，公共指标汇总数据一般根据维表和明细事实数据加工生成

• 采用维度模型方式作为理论基础，更多的采用一些维度退化方法，将维度退化到事实表中，减少事实表和维表的关联，同时特别在汇总数据层，加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

  • 但是注意也不能过多的进行维度退化，如果维度发生变化，除了DIM层维度的改变，也需要将涉及到此维度的DMD层中的表进行重刷，因为可以不常用的放在DIM维护，常用的维度退化到DWS或者DWD中。

  • 有的公司还会在DWS以及DWD中再加一层DWM层或者DWT，主要是放DWS的宽表。
    

  • 但是宽表也不能过长，会存在一下问题：如果存在数据要回溯，会导致特别慢，或者因为宽表依赖的模型比较多，导致产出的失效会特别慢

  • 如果针对比较急的需求，可以在ADS层中先出一张没有在下面的CDM层进行分层做拆分的，如果后续确定长期都要用，再把它放到分层CMD中，有的就继续扩展，没有的就创建

• 其他注意事项：
  • 实际中，一般ODS层的数据不给用，一般会询问说，CDM层是否有数据，有的话就用，没有的话，需要在ODS层拿数据在进行开发。
  • 有的运营直接写脚本，根据他们的脚本做开发，无脚本则是需要跟他们确认好逻辑在进行开发

9.3.3 基本原则

基本原则可以理解为模型构建的基本建议，或者是评估模型的好坏的判断依据

1. 高内聚和低耦合

补充高内聚低耦合：
    通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。
    内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事，它描述的是模块内的功能联系；
    耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

• 使用于DWD层：根据主题划分的时候，主题下面还细分更细的主题，例如二级主题，甚至针对更细的业务流程进行小型规模的设计，目的是降低耦合性，降低不同模型之间对同一个业务的耦合性
  • 数据业务特性：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型
  • 数据访问特性：将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储

2. 核心模型和扩展模型分析

• 扩展模型包括的字段支持个性化或者少量应用的需要，不能让扩展模型的字段过度侵入核心模型，一面破坏核心模型的架构简洁性与可维护性。
• 实际中新加入的扩展模型不会导致超过20分钟延迟，与核心业务不是特别边缘，也是可以融合进去
• 一般优化也可以从核心模型以及扩展模型进行优化，模型的优化一种是合并一种是进行拆分，合并是为了减少和核心业务之间的关联，拆分一般是拆分出扩展模型

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

• 越是底层公共的处理逻辑应该在数据调度依赖的底表进行封装和时间，不要让公共的处理逻辑暴露给到应用层实现，且不要让公共逻辑多处同时存在。
• 公共的逻辑不要散落在很多模型之间，同个逻辑是收总在DWD，或者DWS中，而不是那ODS的出去在很多层加工，如果口径需要发生变化，那涉及的变化就很多，不能实现仅仅在底层单一变化，上层的表进行回溯即可的变化方式

4. 成本和性能平衡

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

5. 数据可回滚

• 处理逻辑不变，在不同时间多次运行数据结果确定不变。、
• 实践中：sql中传DT的一个参数，传到历史分区的，然后参数根据具体的时间选择某一个历史分区确认回滚的数没问题。(我这边没咋懂)
  • 补充：存储过程DT参数 (shuzhiduo.com)
• 回滚数据会不一样一般出现在维表发生了变化的时候

6. 一致性

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

7. 命名清晰、可理解

• 表命名以及表名清洗一致、便于消费者理解使用

  9.4 实施过程

9.4.1 业界常用的模型实施过程

9.4.2 OneData 实施过程

如果公司规模小，使用一些开源组件搭建大数据的平台，如果公司开发能力比较高的，就会自己开发自己一套平台，包括IDE(集成开发环境)以及调度平台，可以自己定制化并且可以迭代设计。

相关平台产品补充：https://zhuanlan.zhihu.com/p/519873005

1. 指导方针

• 搭建数据仓库时，需要进行充分的业务调研(自下而上)和需求分析(自上而下)，主要是根据数据与对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。再次对报表需求进行抽象整理出相关指标体系。使用工具，例如：OneData
  • 业务调研(自下而上)：基于业务往上去搭建，进行业务流程的调研，然后接入业务数据源，在各个业务流程中进行相应的沉淀，例如交易域中有下单，支付，去订单系统以及支付系统中把数据load进来，那么下单和支付的业务模型就有了，现在想要看下下单支付率，就从下单和支付的模型中取就可以
  • 需求分析(自上而下)：从需求角度出发，来了个需求，哦豁，库里没建，现在才找业务部门去接，就整的主动性不是很强，但是自上而下的基于需求来做的数仓很常见在实际生产中，就导致整体没有设计的架构，因此会产生冗余、数据繁重的、业务逻辑暴露在很多层、业务流程不清晰等问题。
  • 实际中，需要两者相辅相成，数据分析部门、或者运营给过来的需求，如果有sql，可以根据sql定位看下他们需要什么样的表和模型，有的就直接用，没有的需要判定是和明细层有关的还是汇总层有关的，如果是汇总的，需要将数据落到汇总层，如果和明细有关的就从业务系统那边接入，遇到有口径的，对以前明细表会做一个打标，产品隔离的，对模型做一个拆分，把需求的脚本中用的数据逻辑分属于汇总或者明细的数据拆开来，放到明细层和汇总层，并归属到某一个特定的业务流程中间，然后用我们写的脚本覆盖原来他的脚本，我们的脚本就是复合自下而上的构建下来的明细层、汇总层的模型的脚本了。

2. 实际工作流

​ (1) 数据调研 :集团架构 业务领域 业务线 主题域 业务流程

• 业务调研：整个阿里集团设计的业务覆盖电商、导航等领域。每个领域又涵盖多个业务线。
• 需求调研：了解分析方向/目的确定后续数仓构建重点

​ (2) 架构设计

• 数据域划分

  • 数据与是面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为时间，如下单、支付、退款。

  • 数据与需要抽象提炼，并且长期维护和更新，但不轻易变动。

  • 划分主题域，既能覆盖当前所有的业务需求，又能在新业务进入时无影响地包含已有的数据域或者扩展新的数据域。

• 构建总线矩阵
  • 明确每个数据域下有哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度

​ (3) 规范定义：定义指标体系，包括原子指标、修饰词、时间周期和派生指标

​ (4) 模型设计

​ (5) 总结

• OneDate实施过程是一个高速迭代和动态的过程，一般采用螺旋式实施方法。在总体架构设计完成后，开始根据数据域进行迭代式模型设计和评审。 引入评审机制，确保模型实施过程的正确性。

第10章 维度设计

10.1 维度的基本概念

10.1.1 维度的基本概念

1. 定义：维度所包含的表示维度的列，成为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。(维度越丰富，易用性就越高)
2. 作用：查询约束、分类汇总以及排序
3. 维度标识：维度使用主键标识其唯一性，主键有两种：代理键和自然键

• 代理键：不具有业务含义的键，一般用于处理缓慢变化维
• 自然键：具有业务含义的键
• 例如：商品维表的每一行，可以生成一个唯一的代理键与之对应，商品本身的自然键可能是商品ID等

10.1.2 维度的基本设计方法

1. 作用：数据仓库的能力直接与维度属性的质量和深度成正比(维度越多，分析能力越强)
2. 设计步骤：

• 第一步：选择维度或新建维度。作为维度建模的核心在企业级数据仓库中必须保证维度的唯一性。例如淘宝商品维度为例，有且只有一个维度定义。
• 第二步：确定主维表。主维表一般是ODS表，直接与业务系统同步。以淘宝商品维度为例：维表是与前台商品中心系统同步的商品表，这边的商品表就是主维表。
• 第三步：确认相关维表。数据仓库是对业务源系统的数据整合，不同业务系统或者同一业务系统的表存在关联性。需要根据对业务的梳理，确认哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。例如淘宝商品维度为例，可以得到商品与类目、SPU、卖家、店铺等维度存在关联关系。
• 第四步：确定维度属性
  • 第一阶段：从主维表中选择维度属性或生成新的维度属性
  • 第二阶段：是从维表中选择维度属性或生成新的维度属性
  • 例如：以淘宝商品维度为例，从主维表和类目、SKU等相关维表中选择维度属性或生成新的维度属性

3. 确认维度属性的几点提示：

• 尽可能生成丰富的维度属性
• 尽可能多的包含一些富有意义的文字性描述
• 区分数值型属性和事实
  • 数值型字段是作为事实还是维度属性，判断依据：如果通常用于查询约束条件或分组统计，则是作为维度属性。如果通常用于参与度量的计算，则是作为事实。
• 尽量沉淀出通用的维度属性(比较重要)
  • 有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，胡总和通过单表不同字段混合处理得到，或者通过单表某个字段进行解析得到。因此需要将更多的通用的维度属性进行沉淀。

10.1.3 维度的层次结构

1. 例如：省-市-区

10.1.4 规范化和反规范化

1. 关系型数据库中，如果需要更改类目，则必须更新商品表和类目表，如果是一对多的关系，商品表可能每次需要更新多至几百万条记录。
2. 将维度的属性层次合并到单个维度中的操作称为反规范化。采用雪花模型，用户在统计分析过程中需要大量的关联操作，使用复杂度高，查询性能很差，而采用反规范化处理，易用性和性能好。
3. 反规范化例子：例如把商品的所有维度都放着这里面，理解为一个小的实体，表达这个实体的数据去描述这个物体。不用再去进行复杂的关联。

10.1.5 一致性维度和交叉探查

1. 一致性维度：在针对不同的数据与进行迭代构建或者并行构建的时候，存在很多需求是对不同数据域或者同一个数据域但是不同业务过程合并在一起观察。

• 如果不同数据域的计算过程使用的维度不一致，就会导致交叉探查无法进行或者结果错误。
• 例如：下面的例子中，两个数据域使用的商品维度不一样，例如一个时间维度属性是yyyy-mm-dd HH:mm:ss，另一个是Unix timestamp，这时候我需要根据商品上架时间做限制，就很复杂。
• 又或者是：你连内容都不一致，商品维度1不包含阿里旅游的商品，商品维度2包含全部的淘系商品，也进行不了交叉探查。

2. 交叉探查：

• 例如：对于日志数据域，统计了商品维度最近一天的PV和UV，同时对于交易数据域，则是统计了商品维度的最新一天的下单GVM。

• 现在就需要将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率等，就叫做交叉探查。

3. 纬度一致性的几种表现形式

• 共享维度：理解为大维表，有且只有一个
• 一致性上卷：其中一个维度的纬度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同。
• 交叉维度：两个维度具有部分相同的维度属性。例如商品维度表中具有类目属性，在卖家维度中具有主营类目属性。

10.2 维度设计高级主题

10.2.1 维度整合

1. 不同应用在设计的过程中，具体差异会表现如下：

• 在编码、命名习惯、度量单位等方面存在巨大的差异。例如性别：有0和1，也有M和F

• 选型不同：处于性能以及扩展性的考虑，或者随技术架构的演变，以及业务的发展，采用不同的物理实现。例如：有的用关系型数据库、有的用NoSQL数据库，甚至存在分库分表

2. 数据集成的表现：

• 命名规范的统一。表名、字段名等统一
• 字段类型的统一。相同和相似字段的字段类型统一。
• 公共代码及代码值的统一。字段类型和命名方式统一。
• 业务含义相同的表统一。
  • 依据高内聚，低耦合理念。将业务系统关系大，源系统影响差异小的表进行整合。
  • 将业务系统关系小，源系统影响差异大的表分而置之。

3. 数据集成的方式

• 采用主从的设计方式：将都有的字段放在主表中(主要基本信息)从属信息分别放在各自的从表中。
• 直接合并：共有的信息和个性信息都放在一个表中。但是有时候union all的时候会出现空值
• 不合并：无法合并存放在多个表中

4. 表级别的整合

• 垂直整合。
  • 即不同的来源表包含相同的数据集，只是存储的信息不同。
  • 比如淘宝用户在源系统中有多个表，如会员基础信息表、会员拓展表、淘宝会员等级信息表等，依据维度设计方法，尽量整合至会员维度模型中。因为是属于同一个群体的用户，因此不会说出现union all后出现多数空值。
• 水平整合。即不同的来源表包含了不同的数据集，不同子集之间无交叉，也可以存在部分交叉。
  • 交叉则去重，不存在交叉，则考虑不同子集的自然键是否存在冲突，不冲突，则将各子集的自然键作为整合后的表的自然键。
  • 另一方式，设置超自然键，将来源表各子集的自然键加工成为一个字段作为超自然键。（即联合主键，阿里采用该方法，并将来源字段作为分区字段）

10.2.2 水平拆分

1. 怎么理解拆分(拆分的三个原则)

• 扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。即高内聚、低耦合的思想。
• 效能：在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化。
• 易用性：模型可理解性高、访问复杂度低。

2. 拆分的两个依据：

• 第一个依据是维度的不同分类的属性差异情况。当维度属性随类型变化较大时。定义一个主维表用于存放公共属性，同时定义多个子维度，除公共属性还包括各自的特殊属性。特点：有重复
• 第二个依据是对业务的关联程度。两个相关性调低的业务，耦合在一起弊大于利，对模型的易用性和稳定性影响较大。例如根据业务线，属于不同的数据集市的拆分

3. 方案参考

• 方案 1 是将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性，适合于当维度属性随类型变化较大的情形

• • 构建商品维度、航旅商品维度：不同分类的商品，其维度属性可能相同，也可能不同。比如航旅的商品和普 通的淘系商品，都属于商品，都有商品价格、标题、类型、上架时间、 类目等维度属性，但是航旅的商品除了有这些公共属性外，还有酒店、 景点、门票、旅行等自己独特的维度属性。

• 方案 2 是维护单一维度，包含所有可能的属性

• • 对淘系商品和 1688 商品构建两个维度，业务分析人员一般只针对本数据集市进行统计分析。1688 业务变更，此维度需要变更， 淘宝业务变更亦然，稳定性很差。

10.2.3 垂直拆分

1. 拆分背景

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

2. 拆分方式

​ 主表和扩展表：例如常用的放一起

3. 使用场景

• 设计了商品主维度和商品扩展维度。其中商品主维度在每日的 1：30 左右产出，而商 品扩展维度由于有冗余的产出时间较晚的商品品牌和标签信息，在每日 的 3：00 左右产出。
• 由于商品扩展维度有冗余的库存等变化较快 的数据，对于主维度进行缓慢变化的处理较为重要。通过存储的冗余和计算成本的增加，实现了商品主模型的稳定和产出时间的提前。

10.2.4 历史归档

1. 归档策略

• 策略1：同前台归档策略，实现前台归档算法，定期对历史数据进行归档。但是成本高，适用于逻辑较为简单，且变更不频繁的情况

数据归档补充资料：进来偷学一招，数据归档二三事儿 | 程序员灯塔 (wangt.cc)

• 策略2：通过对数据库binlog日志解析获取每日增量，通过增量merge全量的方式获取最新的全量数据.
  • 但对前台应用的要求是数据库的物理删除只有在归档时 才执行，应用中的删除只是逻辑删除。

binlog是用于记录数据库表结构和表数据变更的[二进制]日志，比如insert、update、delete、create、truncate等等操作，不会记录select、show操作，因为没有对数据本身发生变更。

• 策略3：数据仓库自定义归档策略。可以将归档算法用简单、直接的方式实现，但原则是尽量比前台应用晚归档、少归档。避免出现数据仓库中已经归档的数据再次更新的情况

10.3 维度变化

10.3.1 缓慢变化维

1. 缓慢变化维的提出：因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较快速的事实表相比，维度变化相对缓慢。例如会员等级
2. 生产中一般根据分区直接进行一个全量的同步了。
3. 处理缓慢变化维的方式

• 第一种：重写纬度值。但是不保留历史数据，始终实是在取新的数据
• 第二种：插入新的维度行。保留了历史数据。代理键的对应也自增起来，但是事实表自增的维护成本比较高
• 第三种：添加维度列。但是维度不断变化，变化频率特别高，那对应的增加的字段就会更多。

10.3.2 快照维表

1. 具体：处理维度变化的方式就是每天保留一份全量快照数据
2. 优点：

• 简单而有效，开发和维护成本低。
• 使用方便，理解性好。数据使用方只需要限定日期，即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。

3. 弊端：主要体现在存储的极大浪费上。是可以通过对应的数据生命周期制度，清除无用的历史数据。

• 生产经验：用拉链表存5年前的数据，5年内的数据采用快照的方式存储，即节约存储成本，全量存储也可以。
• 生产经验：很少看到代理键，一般都是业务主键进行数据的关联以及数据唯一性的确认

10.3.3 极限存储

1. 拉链表含义：

原来的图

拉链表的图

• 图中结束时间很大，表示刚新增进来没有发生变化，或者是已经发生变化了，后面不会变化了
• 因此就stat
• 可以通过限制时间戳字段来获取历史数据。通过限制stat_dt<2016101和end_dt>20160101

2. 拉链表优化：

• 透明化：底层的数据是历史拉链存储，但是上层做一个视图操作或者在Hive里做一个hook，通过分析语句的语法树，把对极限存储前的表的查询转换为对极限存储表的查询。对于下游用户来说，极限存储表和全存储方式是一样的(即整一个视图)
  • select * from A where ds = 20160101;
  • select * from A_Ex=XST where start_dt <=20160101 and end_dt >20160101;
• 分月做历史拉链表：
  • 按和start_dt和end_dt做分区，计算出一年历史拉链表最多产生分区数：365x364/2=66430.分区较多，导致存储压力
  • 按月分区，产生最多分区：12x1+12x(30x29)/2=5232个，会少点

3. 拉链表注意点：

• 在做极限存储前有一个全量存储表，全量存储表仅保留最近一段时间的全量分区数据，历史数据通过映射的方式关联到极限存储表，用户只访问全量存储表，所以说，对用户来说极限存储是不可见的
• 对于部分变化频率频繁的字段需要过滤。例如，用户表中存在用户历史积分字段，这种字段的值每天都在发生变化，如果不过滤的话，极限存储就相当于每个分区存储一份全量数据，起不到节约存储成本的效果。

10.3.4 微型模型

1. 相当于是把经常变化的维度所有的可能做成一个维表，然后加上代理键，通过代理键去关联去过去变化的最新状态。不是很经常去用。
   

10.4 特殊维度

10.4.1 递归层次

维度层次机构，维度属性是层次方式或者一对多相关关联(例如省-市的层级，一对多)，又或是不同维表之间的主从关系，比如商品和类目的关系。本节递归层次看下图

截个图

1. 层次结构扁平化

• 例如：SKU的有层级的类目都放在一个维表里面，使用这张维表和别的表关联就会比较方便，降低成本。

2. 层次桥接表

• 了解用

10.4.2 行为维度

1. 包括

• 指标事实作为维度
• 指标事实分类枚举，例如销量>100为维度
• 行为事实+和分组，例如：点击量、曝光量，例如此sku的点击量
• 复杂逻辑计算，例如近7天sku并且有两次以上购买行为的

2. 定义：如卖家主营品牌维度、用户常用地址维度等类似的维度，如交易、物流等，称之为“行为维度”，或“事实衍生维度”
3. 按照加工方式，划分为以下几类

• 说明

  • 想要那客户的标签做一个维表，是不可以在DWD层的，因为DWD记录的是明细层的数据，一般是一个客户对应多条，因此客户的标签是放在DWS层的，会在DMS层做一个轻度的汇总，再把DWS层指可以用于用户标签的指标加工出来再放到DIM层里面单独建一个行为事实、业务事实的模型。

  • 因此客户的信息分两种，一种是客户实体的属性信息，第二种是客户在DMS层加工出来的轻度汇总的抽取出来可以描述客户的标签的信息

  • 再比如订单维度也可以打上标签

• 分类

  • 另一个维度的过去行为，如买家最近一次访问淘宝的时候
  • 快照事实行为维度，如买家从年初截至当前的淘宝交易金额
  • 分组事实行为维度，如买家从年初截至当前的淘宝交易金额按照金额划分的等级
  • 复杂逻辑事实行为维度。例如买家主营类目、商品热度根据访问、收藏等情况综合计算得到

10.4.3 多值维度

1. 举例：交易父订单和交易子订单 ，针对多个sku，可以把表拆成sku，sku+订单，id的表，这样就可以进行针对sku的具体分析
2. 处理方式

• 降低事实表的维度
• 采用多字段，增加列
• 通用桥接表

10.4.4 多值属性

1. 处理方式：

• 数据结构：保持维度属性主键不变，将多值属性放在维度的一个属性字段中。主要在某一列采用kv模式
• 横向扩展：保持维度属性主键不变，但将多值属性放在维度的多个属性字段中。
• 纵向扩展：维度主键发生变化(类似降低事实表维度)，例如直接拿sku当作主键就好了

10.4.5 维度退化

会将维度属性退化至事实表中

第11章 事实表

11.1 事实表基础

11.1.1 事实表特征

1. 定义：通过描述业务过程的度量来表达业务过程，包含了引用的维度和业务过程有关的度量
2. 事实表中一条记录所表达的业务细节程度被称作粒度

• 粒度反应：维度属性组合所表示的细节程度
• 所表示的具体业务含义

3. 度量有三种类型

• 可加性

• 半可加性：只能按照特定维度汇总，不能对所有的维度汇总

  • 比如库存可以按照地点和商品进行汇总，而按照一年中每个月的库存累加起来就毫无意义

• 不可加性

  • 例如比率型事实

4. 变化程度

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

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

  • 维度退化到单事务型事实表里面和宽表的区别：前者还是代表是解耦业务过程的事实表，宽表是跨业务过程进行融合的表，强调多个业务流程

11.1.2 事务表设计原则

1. 尽可能包含所有与业务过程相关的事实
2. 只选择与业务过程相关的事实

• 在进行主题域划分后的事实表过程中，把相关的业务事实放在这个模型中

3. 分解不可加性事实为可加的组件

• 对相关比率的拆解，在组装。例如订单优惠率的拆解，找出最细的粒度，根据度量值分解为订单原价金额和订单优惠金额两个事实存储在事实表中。

4. 在选择维度和事实之前必须先声明粒度

• 粒度用于确定事实表中每一行所表示的业务的细节层次，决定了维度模型的扩展性
• 在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度一致(维度确定下来后，粒度也能确定)

5. 在同一个事实表中不能有多种不同粒度的事实

6. 事实的单位要保持一致

7. 对事务的null值要处理

8. 使用退化维度提高事实表的易用性

11.1.3 事实表设计方法

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

• 类型就是看是要事务事实表、周期快照事实表、累积快照事实表

1. 第二步：声明粒度，应该选择最细级别的原子粒度
2. 第三步：确定维度
3. 第四步：确定事实

• 可加性、半可加性、非可加性的三种事实类型

4. 第五步：冗余维度

11.2 事务型事实表

11.2.1 设计过程

1. 选择业务过程

• 例如选择交易的业务流程，交易中有下单、支付、发货和成功完结的细的业务流程

2. 确定粒度

• 一个sku对应一个订单是最简单的，复杂的是父订单中的每个sku对应的订单是子订单(父订单id)，甚至子订单子订单还可以拆成好几个运单发货，在具体的业务场景中就是：同一个店铺对应一个父订单–>物流配送—>店铺优惠，10个sku配货的时候从各个不同地方配货 。因此下单和发货是不能放在一个事实表里面的

3. 确定维度
4. 确定事实
5. 冗余维度

11.2.2 单事务事实表

下单度量和支付度量放在两张不同的单事务事实表中

11.2.3 多事务事实表

1、处理方式

• 不同业务过程的事实使用不同的事实字段进行存放(但不是每个列都有值就是了)
• 不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签(要用共性才行)

2. 具体例子

• 淘宝交易事务事实表

  • 包含了下单、支付和成功完结三个业务，这三个业务拥有相同的粒度，都是子订单粒度，比较适合放在一个事实表中

  • 选择业务过程时没有把发货也放到此事务事实表中，原因是发货的粒度比子订单更细，属于不同粒度上的业务过程，因此没有放到一个事实表中。

  • 其实切分原则就是可以依据粒度确定哪些业务过程可以融合成一块

  • 不同的事实使用不同的字段进行存放；如果不是当前业务过程的度量，则采用零值处理方式，因此会显得比较稀疏，例如下图中的下单度量和支付度量根据不同的字段来做的，又或者可以放到一个字段中，1就是下单度量，2就是支付度量

• 淘宝收藏商品事务事实表

• 多事务事实表的选择

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

11.2.4 两种事实表对比分析

1. 业务过程

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

2. 粒度和维度

• 当不同业务过程中的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表

3. 事实

• 单事务事实表在处理上还是比较方便和灵活的，如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑使用单事务事实表
• 多事务事实表在模型上表的数量会少

4. 下游业务使用

• 需要考虑对下游用户的一定的学习成本

5. 计算存储成本

• 单事务事实表成本较多，每个业务过程都需要计算存储一次
• 多事务事实表存储成本较少，不同业务过程融合在一起，降低了存储计算量，但是非当前业务过程的度量存在大于零值

11.2.5 父子事务的处理方式

11.2.6 事实的设计准则

1. 事实完整性
2. 事实一致性
3. 事实可加性

11.3 周期快照事实表

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

2. 需要聚集与之相关的事务才能进行识别计算例如余额，或者聚集事务无法识别，例如温度状态性的度量，事务事实表是无效率的，而这些度量也和度量事务本身一样是有用的，因此就有了快照事实表。

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

11.3.1 特性

1. 特性

• 事务事实表的粒度能以多种方式表达，但是快照事实表的粒度通常以维度形式声明 (是根据维度聚合了的，维度已经限定好了 )

• 事务事实表是稀疏的，但快照事实表是稠密的

• 事务事实表会缺，但是快照事实表是一直有数的

• 事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。

2. 用快照采样状态

• 快照事实表以预定的间隔采样状态度量，这种间隔联合一个或多个维度，将用来定义快照事实表的粒度。
• 因为随着时间跨度越来越大，聚合效率会越来越低，成本会越来越高，才会出现周期快照事实表，比如想要获取YTD的下单金额，需要load1-6月的分区进行sum计算，开销成本就会很高

3. 快照粒度

• 事务事实表是根据业务过程中所涉及的细节程度来描述，但快照事实表的粒度通常是被多维声明的，一般按天来进行，但是不都是

4. 密度与稀疏性

• 事务事实表是稀疏的，只有当天发生的业务过程，事实表才记录改业务过程的事实，如下单、支付，但快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行

5. 半可加

• 指的是不能根据时间维度获取有意义的汇总结果。例如看下不同城市库存的和

11.3.2 实例

1. 步骤归纳为：

• 确定快照事实表的快照粒度
• 确定快照事实表的采样的状态度量

2. 具体例子

• 单维度的每天快照事实表
  • 确定粒度
    • 采样周期为每天、针对卖家、买家、商品、类目、地区等维度的快照事实表，比如淘宝卖家历史汇总事实表、淘宝商品自然月至今汇总事实表，不同的采样粒度确定了不同的快照事实表
  • 确定状态度量
    • 针对这个粒度确定采样的状态度量。维度确认为卖家ID，如图

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

  • 相对单维度的是多了一个买家ID，如图
    

• 单维度和混合维度的快照事实表特点

  • 都可以从事务事实表进行汇总产出，这是周期快照事实表常见的产出模式
  • 还有一种产出模式，即直接使用操作型系统的数据(数据库)作为周期快照事实表的数据源进行加工

• 全量快照事实表

  • 确定粒度
    • 采样周期是每天。采样的维度比较特殊，是针对评价本身，每一条好中评评价就是事实表的最细粒度。
  • 确定状态度量
    • 对于全量快照事实表，再增加一步，即冗余维度，此如好中评快照事实表，冗余子订单维度、商品维度、评论者维度等信息

11.3.3 注意事项

1. 事务与快照成对设计

• 对于事务事实表和快照事实表往往都是成对设计的，互相补充，以便满足更多的下游统计分析需求，特别是事务事实表基础上可以进行加工快照事实表，即丰富了星型模型，有降低了下游分析的成本。

2. 附加事实

• 不光光有天的维度，可能会附加一些上一个采样周期的状态度量，例如每周，每半月

3. 周期到日期度量

• 理解为YTD即可，例如淘宝卖家财年至今的下单金额

11.4 累积快照事实表

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

11.4.1 设计过程

过程于前两种相似，需要注意的是：

累积快照事实表解决的最重要的问题是统计不用业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。例如什么时候下单、什么时候支付、什么时候收获

11.4.2 特点

1. 数据不断更新

例如下图下单、支付、收获状态的时候是不一样的、

• 多事务事实表记录情况

• 累积快照事实表记录情况，只有一条记录，针对此记录一直进行不断的更新

2. 多业务过程日期

11.4.3 特殊处理

1. 非线性过程

• 正常：下单–>支付–>发货–>确认收获
• 关闭订单：下单–>关闭订单
• 退款：下单–>支付–>关闭订单
  • 买家申请退款–>卖家同意退款–>退款达成
  • 买家申请退款–>卖家不同意退款–>退款关闭

2. 处理方式

• 业务过程的统一
  • 最开始是以交易完成作为结束标志；进一步了解业务之后，发现交易关闭也是交易结束的一个分支，所以将交易结束也作为流程结束。
• 针对业务理解里程碑构建全面的流程
  • 针对淘宝交易，全流程可能是下单–>支付–>发货–>确认收货
  • 针对许许多多的业务过程，进行抽象，划分到类别里面，例如下单下面还有更多的细的业务流程，点击确认-支付按钮，支付密码确认等详细，都把它抽象到下单的流程中
  • 例如流量域埋点的数据很多，如何通过模型给隔离开，可以根据业务流程划分，划分到七八个
• 循环流程的处理
  • 关于最近业务过程取第一次发生的日期还是最后一次发生的日期的问题。

3. 多源过程

• 针对多业务过程建模，业务过程可能来自于不同的系统或者源于不同的表。

• 针对多元业务建模，主要考虑事实表的粒度问题

  • 例如淘宝交易累计快照事实表，其粒度是交易子订单，由于子订单会存在多次退款，如需要将退款业务加入模型中，则需要和商业用户确定存在多次退款如何取舍，确保模型粒度不变。

4. 业务过程取舍

• 关于最近业务过程取第一次发生的日期还是最后一次发生的日期的问题。

11.4.4 物理实现

1. 方式一：全量表的形式

• 日期分区表，每天分区存储昨天的全量数据和当天的增量数据合并的结果，保证每天记录的状态更新。使用与数据量不大的情况
• 反思有没有重复的数据：有，从订单的生命周期考虑，如果订单的生命周期结束了，那么这类数据就不会在更新了，根据订单的生命周期进行分区，因此难点就落在了怎么确定生命周期

2. 方式二：全量表的变化形式

• 针对数据较大，可以预测此生命周期的时间间隔，或者根据商业用户的需求确定一个相对较大的时间间隔。
• 例如针对交易订单，我们以200天作为订单从产生到消亡的最大间隔。设计最近200天的交易订单累积快照表。每天的分区存储近200天的交易订单。而200天前的订单则按照gmt_create创建分区存储在归档表中
• 但是还是存在一个问题为200天的全量表根据商业需求需要保留多天的分区数据，只解决了前200天的数据存储，近200依旧要每天分区存一个

3. 方式三：以业务实体的结束时间分区

• 每天的分区存放当天结束的数据，然后使用一个日期很大的分区，例如3000-12-3存放截至当前未结束的数据。
• 数据来源于多个业务流程系统，例如物流系统传过来的数据丢失了，会产生有部分数据是不能通过业务流程及时去更新他的准确状态，导致误差，针对此问题，有两种解决办法：
  • 使用相关业务系统的业务实体的结束状态作为此业务系统的结束标志，比如针对物流订单，可以使用交易订单。
  • 第二种方案：和前端业务系统确定口径或使用前端归档策略。前端系统会定期对历史数据进行归档，避免业务库性能下降，这种情况下，就可以使用前端系统的归档时间作为业务实体的结束日期。

11.5 三种事实表的比较

建议背诵

11.6 无事实的事实表

1. 含义：即不包含事实或度量的事实表

2. 分类：

• 第一种是事实类的，记录事件的发生。例如日志类事实表，比如用户的浏览日志，对于每一次点击，其事实为1，但一般不会保存此事实。
• 第二种是条件、范围或资格类的，记录维度与维度多对多之间的关系

11.7 聚合型事实表

聚合汇总数据，被叫做“公共汇总层”

11.7.1 聚合的基本原则

• 一致性
• 避免单一表设计。不同在同一个表中存储不同层次的聚集数据。例如即存放按天汇总的交易额，又存在按月汇总的交易额。就是一个表中不要放不同的维度。
• 聚集粒度可不同。可以选择不同粒度/维度

11.7.2 聚集的基本步骤

第一步：确定聚合维度

第二步：确定一致性上钻。

第三步：确定聚集事实。

11.7.3 阿里公共汇总层

1. 基本原理

2. 例子：

以卖家、买家、商品聚集的星型模型如图

11.7.4 聚集补充说明

1. 聚集是不跨越事实的
2. 聚集存在的问题：一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。