数据仓库进阶 - 01 《阿里大数据之路》第二篇数据模型篇 _数据模型

满堂花醉三千客，一剑霜寒十四洲。这篇文章主要讲述数据仓库进阶 - 01 《阿里大数据之路》第二篇数据模型篇相关的知识，希望能为你提供帮助。
第8章大数据领域建模综述8.1 为什么需要数据建模

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

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

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

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

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

OLTP是业务数据库系统，一般是关系型数据库,例如Oracle、Informix、DB2，对三范式要求比较高，一般用ER模型建模方式
OLAP是决策类的系统，通过对业务系统的在分析，产出决策回流到业务系统中。

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

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

8.4.2 维度模型

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

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

8.4.3 Data Vault模型
略，后续补充
8.4.4 Anchor 模型
略，后续补充
8.5 阿里的数据模型实践综述

过程：

Oracle时期，部分采用一切维度建模的缓慢变化维方式进行历史数据处理，有两层ODS+DSS--->
引入MPP架构的Greenplum，希望改变烟囱式开发的情况，采用ER模型+维度模型，有四层ODL+BDL+IDL+ADL,实践中ER模型产出不行--->
以Hadoop的数据存储和MR的数据计算，整合出一套OneData体系，三个内容：指标定义体系、模型设计方法体系以及配套工具

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

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

9.1 概述

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

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

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

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

9.1.2 体系架构

文章图片

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

复杂口径以及简单口径：复杂的需要多个指标进行加减乘除，简单指主体是还是这个指标
派生指标= 原子指标+时间周期+修饰词
例如：近一个月北京的订单量花呗支付的金额

汇总5事实表：派生指标组成汇总事实表（把明细数据聚合的事实表，轻度汇总)：无加减乘除，只增加了一些口径
明细事实表：原子指标组成明细事实表(最原始粒度的明细数据)
后续的事务性事实表，累计快照事实表，周期性快照事实表是针对明细事实表在进行分类划分
维度：
- 描述实体的
- 可以进行维度退化，退化到事实表中，从而增加分析维度和口径

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

文章图片

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

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

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

给他串起来，用户通过渠道进入app，产生流量日志，浏览商品下单产生了交易，交易后有财务数据，就是整个大的业务流程。
针对不同行业，一般不同的会在交易的主题上，例如电商的下单、支付、退货，教育行业的购买课程并上课，金融行业的放款到最终还款结束
如图

电信行业

文章图片
电商行业

文章图片

9.2.2 指标体系

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

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

操作细则

派生指标的种类：事务型指标、存量型指标和复合型指标
- 事务型指标：是指对业务活动进行衡量的指标。例如：新发商品数，订单支付金额。是修饰词+原子指标
- 存量型指标：是指对实体对象(如商品、会员)某些状态的统计。例如：商品总数是修饰词+原子指标+周期(一般是历史截至至当前某个时间)
- 复合型指标：在事务型指标和存量型指标的基础上复合而成。
复合型指标的规则
- 比率型：例如：最近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 模型层次

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

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

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

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

公共维度模型层(CDM):

存放明细事实数据(DWD)、维表数据(DIM)以及公共指标汇总数据(DWS),其中明细事实数据、维表数据一般根据ODS层数据加工生成，公共指标汇总数据一般根据维表和明细事实数据加工生成
采用维度模型方式作为理论基础，更多的采用一些维度退化方法，将维度退化到事实表中，减少事实表和维表的关联，同时特别在汇总数据层，加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。
- 但是注意也不能过多的进行维度退化，如果维度发生变化，除了DIM层维度的改变，也需要将涉及到此维度的DMD层中的表进行重刷，因为可以不常用的放在DIM维护，常用的维度退化到DWS或者DWD中。
- 有的公司还会在DWS以及DWD中再加一层DWM层或者DWT，主要是放DWS的宽表。

文章图片

但是宽表也不能过长，会存在一下问题：如果存在数据要回溯，会导致特别慢，或者因为宽表依赖的模型比较多，导致产出的失效会特别慢
如果针对比较急的需求，可以在ADS层中先出一张没有在下面的CDM层进行分层做拆分的，如果后续确定长期都要用，再把它放到分层CMD中，有的就继续扩展，没有的就创建

文章图片

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

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

高内聚和低耦合

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

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

核心模型和扩展模型分析

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

公共处理逻辑下沉及单一

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

成本和性能平衡

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

数据可回滚

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

一致性

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

命名清晰、可理解

表命名以及表名清洗一致、便于消费者理解使用
9.4 实施过程

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

指导方针

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

实际工作流

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

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

?(2) 架构设计

数据域划分
- 数据与是面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为时间，如下单、支付、退款。
- 数据与需要抽象提炼，并且长期维护和更新，但不轻易变动。
- 划分主题域，既能覆盖当前所有的业务需求，又能在新业务进入时无影响地包含已有的数据域或者扩展新的数据域。