alibaba_big_data_road

本文最后更新于：2024年9月29日 下午

《大数据之路》

  • 阿里巴巴出品的经典书籍，这里是一些笔记。推荐阅读原版书籍

数据模型篇

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

  • 数据仓库是一个面向主题的、集成的、 非易失的且随时间变化的数据集合，用来支持管理人员的决策。
  • 好的数据建模会从以下几个方面带来提升：
    • 性能：良好的数据模型可以快速查询数据，减少I/O
    • 成本：减少非必要的数据冗余，计算结果的复用，降低大数据系统中的存储和计算成本
    • 效率：提升使用数据的体验，提高使用数据的效率
    • 质量：良好的数据模型可以改善数据口径的不一致，减少数据计算错误的可能性

OLAP和OLTP系统

  • 埃德加·弗兰克·科德是“关系模型”的发明者，关系型数据数据的鼻祖，之后类似于oracle,mysql相关的产品喷涌而出。OLTP系统（OnLine Transaction Processsing 联机事务处理）主要操作是数据随机读写，一般采用3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题。
  • OLAP（OnLine Analytical Processing联机分析处理）主要面向批量读写，关注在大数据下的复杂查询问题

维度模型

  • Kimball维度建模主要探究需求分析，高层模型，详细模型，和模型审查的过程。一般构建维度模型要经历三个阶段：

    • 第一阶段是高层设计时期，定义业务过程维度模型的范围，提供每种星形模型的技术和功能描述。
    • 第二阶段是详细模型设计时期，对每个星形模型添加属性和度量信息
    • 第三阶段是进行模型的审查，再设计和验证等工作
    • 第四阶段是产生详细设计文档，提交ETL设计和开发

  • 维度模型是数据仓库领域的 Ralph Kimball 大师所倡导的，是目前数仓领域最流行的

  • 维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何能更快速地完成需求分析。同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下

  • 基本步骤

    • 选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
    • 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
    • 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
    • 选择事实。确定分析需要衡量的指标

第九章：数据整合及管理体系

  • OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共用的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似的大数据项目快速落地实现。

9.1概览

  • 体系架构pkIxq74.png
    • 业务板块：根据公司的业务属性，分出几个相对独立的业务板块，业务板块之间重叠性较小
    • 规范定义：设计一套数据规范命名体系，规范定义会在模型设计中体现出来
    • 模型设计：以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实

9.2 规范定义

  • 规范定义指以维度建模作为理论基础 构建总线矩阵，划分和定义数据域、业务过程、维度、度量 原子指标、修饰类型、修饰词、时间周期、派生指标。
    • pkIziHe.png
    • 名词解释pkIztg0.png
  • 指标体系
    • pkopPFH.png
    • 原子指标，修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域
    • 派生指标可以选择多个修饰词，修饰词之间的关系为“或”或者“且”，由具体的派生指标语决定。
    • 派生指标唯一归属一个原子指标 ，继承原子指标的数据域， 与修饰词的数据域无关。
    • 指标命名要清晰。可以参考书本第九章143页的内容
      • pkopV6P.png
    • 派生指标分为三类：事务型指标，存量型指标和复合型指标。
      • 事务型指标 是指对业务活动进行衡量的指标。例如新发商品数、重发商品数、新增注册会员数、订单支付金额，这类指标需维护原子指标及修饰词，在此基础上创建派生指标。
      • 存量型指标：是指对实体对象（如商品、会员）某些状态的统计。例如商品总数、注册会员总数，这类指标需维护原子指标及修饰词，在此基础上创建派生指标，对应的时间周期 般为“历史截至当前某个时间”。
      • 复合型指标：是在事务型指标和存量型指标的基础上复合而成的。例如浏览 UV－下单买家数转化率 有些需要 建新原子指标，有些则可以在事务型或存量型原子指标的基础上增加修饰词得到派生指标。

9.3模型设计

  • 模型层次关系图pkoplfs.png
    • 操作数据层（ ODS ）：把操作系统数据几乎无处理地存放在数据仓库系统中。
    • 公共维度模型层（ CDM ）：存放明细事实数据、维表数据及公共指标汇总数据。 其中明细事实数据、维表数据一般根据 ODS 层数据加工生成 ：公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
      • CDM层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多的采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性。（DWD）同时在汇总数据层，加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。(DWS)
        • 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
        • 公共指标统一加工：基于 OneData 体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。
    • 应用数据层（ADS）：存放数据产品个性化的统计指标数据。根据CDM层和ODS层加工生成
      • 个性化指标加工：不公用性，复杂性
      • 基于应用的数据组装，大宽表集市，趋势指标串
    • 数据模型架构pkopbB8.png
  • CDM层的一些简单的规范：1.高内聚，低耦合。2.数据可回滚（多次运行，结果一致）。3.命名清晰，可理解，一致性（表和字段命名清晰，相同含义字段在不同表命名要相同）

9.4 模型实施

  • Kimball维度建模实施过程：第一个阶段是高层设计时期定义业务过程维度模型的范围，提供每种星型模式的技术和功能描述；第二个阶段是详细模型设计时期，对每个星形模型添加属性和度量信息；第三个阶段是进行模型的审查、再设计和验证等工作；第四个阶段是产生详细设计文档，提交 ETL 设计和开发。

    • 高层模型
      • 高层模型设计阶段的直接产出目标是创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述。确定维表创建初始属性列表，为每个事实表创建提议度量。
    • 详细模型
      • 详细的维度建模过程是为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性。确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填人模型的初步业务规则。
    • 模型审查，再设计和验证
      • 本阶段主要召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计。
    • 提交ETL设计和开发
      • 最后，完成模型详细设计文档，提交ETL 开发人员，进入ETL设计和开发阶段，由 ETL 人员完成物理模型的设计和开发。

  • 阿里OneData体系下的数仓实施过程

    • 数仓实施流程

    • 数据调研

      • 业务调研，业务系统要充分了解，有条件可以多使用，多感受，看数据是怎么流动的。得出业务板块，业务系统的一些信息，可以抽象整理成具体的表

      • 业务调研流程

      • 业务动作

      • 需求调研：与分析师，业务运营人员沟通数据需求

    • 数据域划分：根据业务过程进行归纳，抽象出数据域

      • 数据域划分

    • 构建总线矩阵：在充分的业务调研和需求调研后，就可以构建总线矩阵了。主要是两件事：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

      • 总线矩阵

    • 规范定义：规范定义主要定义指标体系，包括原子指标，修饰词，时间周期和派生指标

    • 模型设计：主要就是CDM层的设计，维度和属性的规范定义。是核心内容

  • OneData实施过程是一个高度迭代和动态的过程,一般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引入评审机制，以确保模型实施过程的正确性。

第十章：维度设计

  • 维度是维度建模的基础和灵魂。在维度建模中，将度量称为事实，将环境描述为维度。维度是用于分析事实所需要的多种环境。
  • 维度所包含的列表示维度的列，称为维度属性。维度属性是查询约束条件，分组和报表标签生成的基本来源。

10.1：维度的基本设计方法

  • 第一步：选择维度或新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有一个维度定义。
  • 第二步：确定主维表。此处的主维表一般是 ODS 表，直接与业务系统同步。以淘宝商品维度为例， auction auctions 是与前台商品中心系统同步的商品表，此表即是主维表。
  • 第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以淘宝商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、 SPU 卖家、店铺等维度存在关联关系。
  • 第四步：确定维度属性。包括两步
    • 从主维表中选择维度属性或生成新的维度属性
    • 从相关维表中选择维度属性或生成新的维度属性。
      • 以淘宝商品维度为例，从主维表（ s_auction_auctions ）和类目、 SPU 、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。
  • 确定维度的几个要点：
    • 尽可能生成丰富的维度属性
    • 尽可能多地给出包括一些富有意义的文字性描述
    • 区分数值型属性和事实
    • 尽量沉淀出通用的维度属性
10.1.3维度的层次结构
  • 维度中的一些描述属性以层次方式或一对多的方式相互关联，可以理解为包含连续主从关系的属性层次。比如企业维度，有行业，产业等，但是行业，产业也是有细分的级别的，一级行业下的某产业。
10.1.4 规范化与反规范化
  • 规范化就是传统OLTP系统中的类似的范式模型（和雪花模型类似）。如果进行反规范化处理，将一些相关维度冗余到主维度表来，可以更加方便查询，对于OLAP系统来说，这是很重要的
    • 规范化处理pkTwFYV.png
    • 反规范化处理pkTwkWT.png
10.1.5一致性维度和交叉探查
  • 迭代式的构建数仓容易导致形成独立的数据集市，导致严重的不一致性。
  • 构建一致性维度要根据总线架构合理划分。下面总结维度一致性的几种表现形式
    • 共享维表。比如在阿里的数仓中，商品，卖家，买家等维度有且只有一个，对这些公共维度进行交叉探查不会有问题。
    • 一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同。比如阿里的商品体系中，有商品维度和类目维度，其中类目维度的维度属性是商品维度的维度属性的子集，且具有相同维度属性和维度属性值。这样基于类目维度进行不同业务过程的交叉探查也不会存在任何问题
    • 交叉属性，两个维度具有部分相同的维度属性，比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，两个维度具有相同的类目属性，则可以在相同的类目属性上进行不同业务过程的交叉探查。

10.2维度设计高级主题

10.2.1维度整合
  • 数据仓库是一个面向主题的，集成的，非易失的且随时间变化的数据集合，用来支持管理人员的决策。
  • 集成是数仓四个特性中最重要的，所以数据由面向应用的操作型环境进入数据仓库后，需要进行数据集成。将面向应用的数据转换为面向主题的数据仓库数据，本身就是一种集成。体现在以下几个方面：
    • 命名的规范统一。表名，字段名统一
    • 字段类型的统一。相同和相似字段的字段类型统一
    • 公共代码和代码值的统一。公共代码及标志性字段的数据类型，命名方式的统一
    • 业务含义相同的表的统一。主要依据高内聚低耦合的理念，在物理实现中，将业务关系大，源系统影响差异小的表进行整合；将业务关系小，源系统影响差异大的表进行分而置之。
10.2.2 水平拆分
  • 维度属性通常可以按照类别或者类型进行细分。比如淘系商品表，根据业务线或行业等可以对商品进行细分，如淘宝的商品，天猫的商品，1688的商品。不同分类的商品，维度属性有相同的也有不同的；比如航旅的商品和普通的淘系商品，都有商品价格，标题，类型等维度属性，但是航旅的商品除了有这些公共属性外，还有酒店，景点，门票等自己独特的维度属性。
  • 那么怎样设计维度才好呢？主要有两种解决方案
    • 方案1：将维度的不同分类实例化为不同的维度，同时在主维表中保存公共属性；
    • 方案2：维护单一维度，包含所有可能的属性
  • 如何选择方案主要考虑以下三个原则：
    • 扩展性：当源系统业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。高内聚，低耦合的思想就是其核心
    • 效能：在性能和成本方面取得平衡。通过牺牲一定的存储成本，达到性能和逻辑的优化
    • 易用性：模型可理解性高，访问复杂度低。用户能方便地从模型中找到对应地数据表，并能够方便地查询和分析。
10.2.3 垂直拆分
  • 处于扩展性，产出时间，易用性等方面地考虑，设计主从维表。主维表存放稳定，产出时间早，热度高的属性；从维表存放变化较快，产出时间晚，热度低的属性。比如阿里数仓中，设计了商品主维表和商品扩展维度，主维表1：30产出，商品扩展维表由于有冗余的产出时间较晚的商品品牌和标签信息，在每日的3：00产出。主维表先产出，对于数仓的稳定和下游应用的产出都有较大的意义。
10.2.4 历史归档
  • 对于每天庞大的数据量，可以对历史数据进行归档

10.3 维度变化

10.3.1缓慢变化维
  • 数仓的重要特点之一就是反应历史变化，所以如何处理维度的变化是维度设计的重要工作之一。维度一般会随时间发生变化。几种处理方式：
    • 重写维度值。采用此方式，不保留历史数据，始终取最新的数据
    • 插入新的维度行。采用此种方式，保留历史数据
    • 添加维度列。
10.3.2 快照维表
  • 在阿里数仓实践中，处理缓慢变化维的方式是采用快照方式。数仓的计算周期一般是每天一次。即每天保存一份全量快照数据。任意一天的事实均可以获取到当天的商品信息 ，也可以获取到最新的商品信息，通过限定日期，采用自然键进行关联即可。
    • 优点:简单，开发维护成本低。使用方便，易于理解
    • 缺点:存储浪费太多。如果每天的变化很少，其实会浪费很多存储空间
10.3.3 极限存储
  • 其实就是采用拉链表的方式构建维度表，既有历史数据，又不会太浪费存储空间。还可以每月做历史数据的清理。缺点是可能对非数仓人员来说，模型理解上有一定门槛。
  • 在实际生产中可以做一些额外处理
    • 在做极限存储前有一个全量存储表 ，全量存储表仅保留最近一段时间的全量分区数据，历史数据通过映射的方式关联到极限存储表。即用户只访问全量存储表，所以对用户来说极限存储是不可见的。
    • 对于部分变化频率频繁的宇段需要过滤。例如，用 户表中存在用户积分宇段，这种字段的值每天都在发生变化，如果不过滤的话，极限存储就相当于每个分区存储一份全量数据，起不到节约存储成本的效果。
    • 其实就是可以做一张
10.3.4 微型维度
  • 如果维度表中的一些属性变化太频繁，可以把这些维度属性放置到新的维表中。
  • 微型维度的创建是通过将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现的。

10.4 特殊维度

10.4.1 递归层次
  • 对于一些递归结构的维度，比如父子类目，省市区街道等，经常会进行上钻下钻的分析，使用递归sql成本较高。在维度模型中，可以对层次结构进行处理
  • 1.层次结构扁平化。把层次打平
    • pkOP3Zj.png
    • 优先使用层次机构扁平化的方式吧，扩展性查但是易用性更好。
  • 2.层次桥接表
    • pkOPwyF.png
10.4.2 行为维度
  • 对一些事实进行一些统计得到的一些维度，称为行为维度，或者事实衍生维度，按照加工方式可分为以下几种：
    • 另一个维度 的过去行为，如买家最近一次访问淘宝的时间、 买家最近 次发生淘宝交易的时间等。
    • 快照事实行为维度，如买家从年初截至当前的淘宝交易金额、买家信用分值 、卖家信用分值等。
    • 分组事实行为维度 ，将数值型事实转换为枚举值。如买家从年初截至当前的淘宝交易金额按照金额划分的等级 买家信用分值按照分数划分得到的信用等级等。
    • 复杂逻辑事实行为维度，通过复杂算法加工或多个事实综合加工得到。如前面提到的卖家主营类目，商品热度根据访问、收藏、加入购物车、交易等情况综合计算得到。
  • 对于行为维度的处理一般有两种：1.冗余进现有的维表中。2.加工成单独的行为维表。主要参考两个原则：
    • 1.避免维度过快的增长。
    • 比如对商品表进行了极限存储，如果将商品热度加入现有的商品维表中，则可能会使每日商品变更占比过高，从而导致极限存储效果较差。
    • 2.避免耦合度过高。比如卖家主营类目，加工逻辑异常复杂，如果融合进现有的卖家维表中，那么过多的业务稠合会导致卖家维表刷新逻辑复杂、维护性差、产出延迟等。
10.4.3 多值维度
  • 一种情况是事实表的一条记录在某维表中有多条记录与之对应。
  • 比如对于淘宝交易订单，买家一次购买了多种商品，如一件毛衣和两双袜子，称为交易父订单 对于每种商品的交易，称为交易子订单：此交易父订单有两个子订单与之对应。假设设计交易父订单事实表，则对于此事实表的每一条记录，在商品表中都有 一到多条记录与之对应。
  • 处理方式
    • 第一种是降低事实表的粒度。比如将交易订单设计为子订单粒度
    • 第二种是采用多字段。比如地产销售中，每次合同签订可能存在多个买受方的情况。对于合同签订事实表，每条记录可能对应多个买受方，由于合同已经是事实表中的最细粒度，无法通过降低粒度的方式来解决。但由于合同签订的买受人一般不会太多，所以一般采用多字段方式。
      • pkOcv7t.png
    • 第三种是桥接表
      • 桥接表的方式
10.4.4 多值属性
  • 维表中某个属性字段同时有多个值，称为多值属性。一般有三种处理方式
    • 第一种：保持维度主键不变，将多值属性放在维度的一个属性字段中。比如商品属性，统一通过k-v对的形式存放在property字段中。这种方式扩展性好，但是使用数据做统计会比较麻烦。
    • 第二种：保持维度主键不变，但是将多值属性拆开，将多值属性放在维度的多个属性字段中。
    • 第三种：就是将多值属性炸开。维度的id和属性id做为联合主键，这种方式使用方便，但是数据会出现很多倍的膨胀。淘宝的商品属性表采用此种方式，数据量达到了几百亿的级别
10.4.5 杂项维度

  • 杂项维度是由操作型系统中的指示符或者标志字段组合而成的，一般不在一致性维度之列。比如淘宝交易订单的交易类型字段，包括话费充值，司法拍卖，航旅等类型；支付状态，物流状态等，它们在源系统中直接保存在交易表中。

  • 这时，通常的解决方案就是建立杂项维度 ，将这些字段建立到一个维表中，在事实表中只需保存一个外键 即可。多个字段的不同取值组成一条记录，生成代理键，存入维表中，并将该代理键保存到相应的事实表字段下。建议不要直接使用所有的组合生成完整 的杂项维表，在抽取

    遇到新的组合时生成相应的记录即可。杂项维度 ETL 过程比一般维度略微复杂些。

第十一章事实表设计

11.1 事实表基础

11.1.1 事实表特性
  • 事实表作为维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和业务过程有关的度量。
  • 事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度有两种表述方式：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义。
  • 作为度量业务过程的事实，一般为整型或浮点型。具有可加性，半可加性和不可加性。
  • 事实表分为三种类型：事务型事实表，周期型快照事实表，累积快照事实表
11.1.2事实表设计原则
  • 尽可能包含所有与业务过程相关的事实
  • 只选择与业务过程相关的事实
  • 分解不可加性事实为可加的组件
  • 在选择维度和事实之前必须先声明粒度
  • 在同一个事实表中不能有多种不同粒度的事实
  • 事实的单位要保持一致
  • 对事实的null值要处理
  • 使用维度退化提高事实表的易用性
11.1.3 事实表设计方法
  • Kimball的维度建模理论，对于维度模型设计采用四步设计方法：1.选择业务过程；2.声明粒度；3.确定维度；4.确定事实
  • OneData理论改进版：
    • 第一步：选择业务过程及确定事实表类型。
      • 明确业务需求之后，对业务过程进行划分，选择我们需要的业务过程，并确定事实表的类型
    • 第二步：声明粒度
      • 即确定事实表中一行数据所表示的业务含义
    • 第三步：确定维度
      • 完成声明粒度之后，也意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了。
    • 第四步：确定事实
      • 事实可以通过回到“过程的度量是什么‘来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。
    • 第五步：冗余维度
      • 即维度退化，在事实表中冗余常用的维度字段，方便下游的查询

11.2 事务事实表

11.2.1 设计过程
  • 任何类型的事件都可以理解为一种事务。比如交易过程中的创建订单，买家付款，物流过程中的揽货，发货，签收，退款中的申请退款，申请小二介入等。都可以被理解成一种事务。事务事实表就是针对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。
  • 1.选择业务过程
    • 选择要分析的业务流程
    • Kimball维度建模理论任务，为了方便进行独立的分析研究，应该为每个业务过程建立一个事实表。但是将不同的业务过程放到同一个事实表也是一个可以考虑的实现方式。
  • 2.声明粒度
    • 业务过程选定之后，就要针对每个业务过程确定一个粒度，即确定事务事实表每一行所表达的细节层次。
  • 3.确定维度
    • 选定好业务过程且确定粒度后，就可以确定维度信息了。在淘宝交易事务事实表设计过程中，按照经常用于统计分析的场景，确定维度包含：买家，卖家，商品，商品类目，发货地区，收货地区，父订单维度以及杂项维度。由于订单的属性较多，比如订单的业务类型，是否无线交易，订单的attributes属性等。对于这些使用较多却又无法归属到上述买卖家或商品维度中的属性，则新建一个杂项维度进行存放。
  • 4.确定事实
    • 作为过程度量的核心，事实表应该包含与其描述过程有关的所有事实。以淘宝交易事务事实表为例，选定三个业务过程一一下单、支付和成功完结。不同的业务过程有不同的事实（度量值）。比如下单业务中的：下单金额，下单数量，下单分摊金额，在支付业务过程中，包含支付金额，分摊油费，折扣金额，红包金额，积分金额；在完结业务过程中包含确认收货金额等。由于粒度是子订单，所以对于一些父订单上的金额需要分摊到子订单上，比如父订单邮费，父订单折扣等。
    • 按照kimball的维度建模理论，经过已上步骤，淘宝交易事务事实表已经成型
      • pA9ZTP0.png
  • 5.冗余维度(维度退化)
    • OneData理论在已上四步的基础上增加了维度退化的一步。这个过程在kimball的维度建模理论中也有所提及；但是阿里数仓出于效率和资源的考虑，将常用维度全部退化到事实表中，使下游分析使用更加方便。
    • 在确定维度时，包含了买卖家维度，商品维度，类目维度，收发货维度等。Kimball维度建模理论建议在事实表中只保存这些维表的外键。而淘宝交易事务事实表在kimball维度建模基础上做了进一步的优化，将买卖星级，标签，店铺名称，商品类型，商品特性，商品属性，类目层级等常用的维度属性冗余进事实表中，提高对事实表过滤查询，统计的效率。
    • pA9epPx.png
11.2.2 单事务事实表

  • 单事务事实表，就是针对每一个业务过程设计一个事实表。可以方便的对每个业务过程进行独立的分析。1688交易流程和淘宝类似，也是下单，支付，发货和完结。在这个四个关键流程中1688选择下单和支付两个业务过程分别设计事务事实表

  • pA9l39A.png

  • pA9lGct.png

11.2.3 多事务事实表

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

  • 多事务事实表有两种设计方式：

    • 1.不同的业务过程的事实使用不同的事实字段存放
    • 2.不同的业务过程的事实使用同一个事实字段进行存放，但需要增加一个业务过程标签用于区分不同的业务过程。

  • 淘宝交易事务事实表（不同事实字段存放）

    • 淘宝交易事务事实表中包含了下单，支付，完结三个业务过程，三个业务过程的粒度都是子订单粒度。没有把发货放到此事务事实表中，是因为发货的粒度比子订单更细（比如拆分发货，聚合发货等多种情况），属于不同粒度上的业务过程。
    • 确定好业务过程和粒度后，下一步就是确定维度和事实。一般来说，对于不同的业务过程和粒度，维度也不完全一致。但在设计淘宝交易事务事实表时，根据分析统计，常用维度比较一致，因此在维度层面可以保证这三个业务过程放到同一个事务事实表中。这里的维度也是在交易过程中比较常见的，如包括买家、卖家、商品、类目、店铺、收发货地区等，无论在哪一个业务过程中，都需要按照这些维度进行统计分析。
    • 将多个业务过程放到同一个事实表中，需要面对如何处理多个事实的问题。交易事务事实表需要包含下单度量，支付度量，成功完结度量。这里的解决方案是针对每一个度量都使用一个字段进行保存,即不同的事实使用不同的字段进行存放。如果不是当前业务过程的度量，则采取零值处理方式。
    • 同一个事实表中包含了多个业务过程，如何在表中进行区分标记呢？这里的解决方案是对每一个业务过程打一个标签，标记当天是否是这个业务过程。比如，针对下单打一个是否当天下单的标签；针对支付，打一个是否当天支付的标签；针对成功完结打一个是否当天成功完结的标签，标签之间互不相干。
    • pA98XUU.png

  • 收藏商品事务事实表

    • 收藏业务一般包含两个业务过程：收藏商品和删除商品。接下来是确定粒度，无论收藏还是删除收藏的商品都是用户对商品的一个操作。

    • 确定好业务过程和粒度后，接下来是确定维度和事实，由于粒度是用户加上商品，所以维度主要是用户维度和商品维度。为了使事实表更加丰富，冗余了商品类目维度和商品所属卖家维度，收藏商品和删除商品业务过程所属的维度是一致的。

    • 收藏和删除商品是两个不同的业务过程，但是确定了相同的粒度和维度，所以考虑设计多事务事实表，将这两个业务过程放到同一个事实表中，只是在不同业务过程的事实上进行区分。

    • 这里的解决方案是使用同一个字段存放不同业务过程的事实，使用标签字段区分不同的业务过程。收藏商品和删除商品的事实主要是商品价格，不过收藏事务事实表更多的是无事实的事实表，一般用于统计收

      藏或者删除的次数。

    • pA9GYGQ.png

  • 多事务事实表的选择

    • 当不同业务过程的度量比较相似，差异不大时，可以采用第二种多事务事实表的设计方式，使用同一个字段来表示度量数据。但这种方式存在 一个问题一一在同一个周期内会存在多条记录。
    • 当不同业务过程的度量差异较大时，可以选择第一事务事实表的设计方式，将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置零表示。这种方式所存在的问题是度量字段零值较多。
11.2.4 两种事实表的对比
  • 哪张设计方式更好，可以从下面这些方面考量。
  • 1.业务过程
  • 2.粒度和维度
  • 3.事实
  • 4.下游业务使用
  • 5.计算存储成本
11.2.5 父子事实的处理方式
  • 以淘宝交易事务事实表来说，选择子订单粒度表示一行数据的含义。一次对于父子订单的情况来说，需要把父订单的下单总额或者支付总额分摊到每个子订单上。通过分摊父订单的金额，将所有业务过程的度量全部带进淘宝交易事务事实表中。
11.2.6 事实的设计准则
  • 1.事实完整性
  • 2.事实一致性
  • 3.事实可加性

11.3周期快照事实表

  • 事务事实表可以很好地跟踪一个事件，并对其进行度量。但是，当需要一些状态度量时，比如账户余额，买卖家星级，商品库存，卖家累积交易额等。则需要聚集与之相关的事务才能进行识别计算。对于这些状态度量，事务事实表是无效率的，而这些度量也和事务度量一样是有用的。因此维度建模理论给出了第二种常见的事实表——周期快照事实表。
  • 快照事实表在确定的时间间隔内对实体的度量进行抽样，这样可以很容易的研究实体的度量值，而不需要聚集长期的事务历史。
  • 特性：快照事实表的粒度通常以维度形式声明；快照事实表是稠密的；快照模型将至少包含一个用来展示半可加性质的事实。
  • 快照事实表的设计步骤可以归纳为：
    • 1.确定快照事实表的快照粒度
    • 2.确定快照事实表采样的状态度量。
11.3.2 案例
  • 1.单维度的每天快照事实表
    • pAPariq.png
  • 2.混合维度的每天快照事实表
    • pAPagQU.png
    • 已上的两类快照事实表都有一个特点——都可以从事务事实表进行汇总产出，这是周期快照事实表的一种常见产出模式。除此之外，还有一种直接使用ods的数据作为周期快照事实表的数据源进行加工。比如淘宝卖家星级，卖家DSR事实表等。
    • pAPdekn.png
  • 3.全量快照事实表
    • 还有一种特殊的快照事实表，即全量快照事实表。
    • pAPdW1f.png
11.3.3 注意事项
  • 1.事务与快照成对设计
    • 数仓维度建模中，对于事务事实表和快照事实表往往是成对设计的，相互补充，以满足更多的下游统计分析需求。特别是在事务事实表的基础上可以加工快照事实表，如淘宝卖家历史至今快照事实表，就是在事务事实表的基础上加工得到的，既丰富了星形模型又降低了下游分析的成本。
  • 2.附加事实
    • 可以附加一些上一个采样周期的状态度量
  • 3.周期到日期度量
    • 针对多种周期到日期的度量设计了不同的快照事实表，比如淘宝卖家财年至今的下单金额，淘宝商品自然年至今的收藏次数等。

11.4累积快照事实表

  • 对于研究事件时间间隔的需求，采用累积快照事实表可以很好的实现。
  • 比如统计买家下单到支付的时长、买家支付到卖家发货的时长、买家从下单到确认收货的时长等。
11.4.1 设计过程
  • 设计过程与事务事实表的设计是一样的。
  • 1.选择业务过程
    • 在前面我们学习到，淘宝交易订单的流转过程有四个事件：买家下单，买家支付，卖家发货，买家确认收货的的四个业务过程。在事务事实表中，我们只关注了下单，支付和确认收货三个业务过程，而在统计事件时间间隔的需求中，卖家发货也是关键环节。所以针对淘宝交易累积快照事实表，我们选择四个业务过程
  • 2.声明粒度
    • 和前面类似，我们依旧是选择子订单粒度，但是对于累积快照事实表来说，一个子订单在此表中只有一条记录
  • 3.确定维度
    • 维度和上面类似，基本都是买家，卖家，店铺，商品，类目，发货地区，收货地区等。四个业务过程的时间字段要进行标明
  • 4.确定事实
    • 包含四个业务过程中对于的事实，即度量值
  • 5.维度退化
  • 为方便分析，冗余一些常用的维度到事实表中
  • pAPweDe.png
11.4.2 特点
  • 1.数据不断更新
    • 会随着业务过程的递进，数据会不断发生变化
  • 2.多业务过程日期
    • 会分别记录多个业务过程发生的时间
11.4.3 特殊处理
  • 非线性过程
    • 对于发生的一些流转，循环过程。需要进行一些统一处理
      • 确定好业务过程要统一
      • 针对关键业务过程构建全面流程。全流程是下单–>支付–>发货–>确认收货。对于缺失的过程，时间字段和事实置为空
      • 循环流程的处理。选择第一次时间还是最后一次时间要和业务方确定
  • 多源过程
    • 对于淘宝交易累积快照事实表，除了上述提到的下单→支付→发货→确认收货流程，假设需要关注交易子订单退款业务或者物流业务，此时会涉及交易、售后、物流 多个业务源系统。
    • 针对多源业务建模，主要考虑事实表的粒度问题。对于淘宝交易累积快照事实表，其粒度是交易子订单。对于退款，由于每个子订单可能存在多次退款，此时如果要将退款相关业务过程加入模型中，则需要和商业用户确定存在多次退款时如何取舍，确保模型粒度不变。
11.4.4 物理实现

  • 第一种是全量表的形式。此全量表一般为日期分区表，每天的分区存储昨天的全量数据和当天的增量数据合并的结果，保障每条记录的状态最新。此种方式适用于全量数据较少的情况。如果数据量很大，

    此全量表数据量不断膨胀，存储了大量永远不再更新的历史数据，对ETL 和分析统计性能影响较大。

  • 第二种是全量表的变化形式。此方式针对数据量大的情况。业务实体一般从生产到消亡都有一个相对较大的时间间隔。

  • 比如针对交易订单，我们以 200 天作为订单从产生到消亡的最大间隔。设计最近 200 天的交易订单累积快照事实 ，每天 的分区存储最近 200 天的交易订单 200 天之前的订单则按照 gmt_create建分区存储在归档表中。

  • 第三种方式是以业务实体的结束时间分区。每天的分区存放当天结束的数据，设计一个时间非常大的分区，比如 3000-12-31 ，存放截至当前未结束的数据。由于每天将当天结束的数据归档至当天分区中，时间非常大的分区数据量不会很大， ETL 性能较好；并且无存储的浪费，对于业务实体的某具体实例，在该表的全量数据中唯一。 比如对于交易订单，在交易累积快照事实表中唯一。

  • 第三种方式，存在一些特殊情况，即业务系统无法标识业务实体的结束时间。

11.5三种事实表的比较

  • pAPfEFK.png
  • 由于事实表种许多日期是在首次加载时不知道的，而且这类事实表在数据加载完成后，可以对其数据进行更新，来补充业务状态变更时的日期信息和事实。

11.6 无事实的事实表

  • 不包含事实或度量的事实表称为无事实的事实表。主要有两类：
    • 第一种是事件类的，记录事件的发生。如用户浏览的日志
    • 第二种是条件，范围或资格类的，记录维度与维度多对多之间的关系。如客户和销售人员的分配情况，产品的促销范围等。

11.7 聚集型事实表

  • 数仓的性能是数仓建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少查询的复杂度，快速响应，同时也有利于减少不同用户访问明细数据带来的结果不一致问题。聚集带来良好的效益，但是对于ETL来说是更多工作内容和挑战。
  • 阿里将使用频繁的公用数据，通过聚集进行沉淀，比如卖家最近一天的交易汇总表，卖家最近N天的交易汇总表等
11.7.1 聚集的基本原则
  • 一致性
    • 聚集后的结果要和明细粒度的统计结果是一致的
  • 避免单一表设计
    • 不要在同一个表中存储不同层次的聚集数据，否则很可能导致重复计算的问题。
    • 在聚集表中有些行按天汇总，有些按月汇总，会导致重复计算，可以对每一行数据加上标识，但是这样不易使用。最好的方式是使用不同的字段，即通过两列存放
  • 聚集粒度可不同
    • 聚集只关心需要查询的维度，可以根据需求随意聚合。
    • 订单涉及的维度有商品、买家、卖家、地域等，比如可以按照商品汇总 天的交易额，可以按照卖家汇总一天的营业额（交易额） 可以按照商品与地域汇总一月的交易额。
11.7.2 聚集的基本步骤
  • 第一步：确定聚集维度
    • 在原始明细模型中会存在多个描述事实的维度 ，如 日期、商品类卖家等，这时候需要确定根据什么维度聚集 ，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。
  • 第二步：确定一致性上钻
    • 这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。当然，我们要做的只是了解用户需要什么，然后按照他们想要的进行聚集。
  • 第三步：确定聚集事实
    • 在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。
11.7.3 公共汇总层
  • 1.基本原则：
    • 数据公用性。汇总的聚集会有第三者使用吗？基于某个维度的聚集是不是经常用于数据分析中？如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。
    • 不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。阿里巴巴以业务过程进行分类，如交易统一划到交易域下，商品的新增、修改放到商品域下。
    • 区分统计周期。在表的命名上要能说明数据的统计周期，如 1d表示最近 天， td 表示截至当天， nd 表示最近 天。
  • 2.交易汇总表的设计
    • pAPX5Kx.png
    • 可以看到一个交易事务事实表就有如此多潜在聚集的方式。下面是一些案例
    • pAPXoqK.png
11.7.4 聚集一些说明
  • 聚集是不跨越事实的
    • 聚集是针对原始星形模型进行的汇总，为了获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。横向钻取是针对多个事实基于一致性维度进行的分析，很多时候采用融合事实表，预先存放横向钻取的结果，从而提高查询性能。因此，融合事实表是 种导出模式而不是聚集。
  • 聚集带来的问题
    • 聚集会带来查询性能的提升，但聚集也会增加 ETL 维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。这一额外工作随着业务复杂性的增加，会导致多数 ETL 人员选择简单强力的方法，删除并重新聚集数据。

数据管理篇

第12章：元数据

技术元数据

  • 技术元数据市存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。常见的技术元数据有：
    • 分布式计算系统存储元数据，如表，列，分区等信息。分区信息、责任人信息、文件大小、表类型，生命周期，以及列的字段名、字段类型、字段备注、是否是分区字段等信息。
    • 分布式计算系统运行元数据。如hive的Job日志，包括作业类型，实例名称，输入输出，sql，运行参数，执行时间，运行日志等信息
    • 数据开发平台中的同步任务，计算任务，任务调度信息。包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
    • 数据质量和运维相关元数据。如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。

业务元数据

  • 业务元数据从业务角度描述了数据仓库中的数据。常见的元数据有：
    • 维度建模元数据，如维度及属性，业务过程，指标等规范化定义，用于更好地管理和使用数据
    • 数据应用元数据，如数据报表，数据产品等的配置和运行元数据。

元数据体系建设

  • 元数据的质量直接影响到数据管理的准确性。元数据建设的目标是打通数据接入到加工，再到数据消费整个链路，规范元数据体系与模型，提供统一的元数据出口，保障元数据产出的稳定性和质量
大数据
书籍

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！