本文的内容来自数据之路
阅读并记录一些知识点和流程

1.为什么需要数据建模

数据爆发带来的挑战:数据进行有序 有结构地分类组织和存储
数据模型是数据组织和存储方法.它强调从业务 数据存取和使用角度合理存储数据,在性能 成本 效率和质量之间取得平衡

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

2.典型数仓建模方法论

ER模型:面对企业业务主题的抽象

高层模型:一个高度抽象的模型,描述主要的主题以及主题间的关系,用于描述企业的业务总体概况。
中层模型:在高层模型的基础上,细化主题的数据项。
物理模型(也叫底层模型):在中层模型的基础上,考虑物存储,同时基于性能和平台特点进行物理属性的设计,也可能做一些表的合并、分区的设计等。

维度模型:从分析决策的需求出发构建模型,为分析需求服务

选择需要进行决策分析的业务
确定粒度
识别维度
选择事实

Data Vault模型

Hub:是企业的核心业务实体,由实体key、数据仓库序列代理键、装载时间、数据来源组成
Link:代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述1:1, 1:n和n:n的关系,而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成
Satellite:是 Hub的详细描述内容,一个Hub可以有多个Satellite,它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成

image.png

Anchor模型

Anchors:类似于Data Vault的Hub,代表业务实体,且只有主键
Attributes:功能类似于Data Vault的Satellite,但是它更加规范化,将其全部k-v结构化,一个表只有一个Anchors的属性描述
Ties:就是Anchors之间的关系,单独用表来描述,类似于DataVault的Link,可以提升整体模型关系的扩展能力
Knots:代表那些可能会在多个Anchors中公用的属性的提炼,比如性别、状态等这种枚举类型且被公用的属性

image.png

3.数仓体系架构

体系架构

命名规范

4.模型设计

模型架构

设计原则

1. 高聚合与低耦合
   将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,将低概率同时访.问的数据分开存储。

2. 核心模型与扩展模型分离
   将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,将低概率同时访.问的数据分开存储。

3. 公共处理逻辑下沉和单一
   越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现,不要让公用的处理逻辑暴露给应用层实现,不要让公共逻辑多处同时存在。

4. 性能与成本
   适当数据冗余可换取查询和刷新性能,但是不宜为了性能而数据冗余

5. 一致性
   具有相同含义的字段在不同表中的命名必须相同,必须使用规范定,义中的名称。

实施流程

分析架构

流量域

一致性维度示例

问题
1.日志数据是不完整的,我是否应该对该数据进行维度补充
2.一条日志数据是单一事实和多维度属性/连接了2张以上的维度表,那么我问题是在哪个流程下确定事实表的外键,以及在etl流程在这个外键应该如何补充
3.如何在已有的维度表和事实表之间添加更多的元素,且不影响原来的关系

5.维度设计

维度是维度建模的基础和灵魂。在维度建模中,将度量称为“事实",将环境描述为“维度”,维度是用于分析事实所需要的多样环境。例如,在分析交易过程时,可以通过买家、卖家、商品和时间等维度描述交易发生的环境

维度所包含的表示维度的列,称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源,是数据易用性的关键。例如,在查询请求中,获取某类目的商品、正常状态的商品等是通过约束商品类目属性和商品状态属性来实现的,统计淘宝不同商品类目的每日成交金额,是通过商品维度的类目属性进行分组的;我们在报表中看到的类目、BC类型(B指天猫, C指集市)等,都是维度属性。所以维度的作用一般是查询约束、分类汇总以及排序等

维度使用主键标识其唯一性,主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有两种:代理键和自然键,它们都是用于标识某维度的具体值。但代理键是不具有业务含义的键,一般用于处理缓慢变化维; 自然键是具有业务含义的键。比如商品,在ETL过程中,对于商品维表的每一行,可以生成一个唯一的代理键与之对应;商品本身的自然键可能是商品ID等。其实对于前台应用系统来说,商品ID是代理键;而对于数据仓库系统来说,商品ID则属于自然键

维度设计的基本方法

选择维度或者确定维度.作为维度建模的核心,在企业级数据仓库中必须确定维度的唯一性
确定主维度表,ODS层
确定相关维表.根据对业务系统表的数据确定表之间的关联
确定维度属性
对于维度属性的几点注意事项
1.尽可能丰富的维度属性,提供给下游的数据分析
2.要包含一些富有意义的文字性描述
3.区别数值型维度属性和事实
4.尽可能沉淀出通用的维度属性

这里的主维度表指的是什么?
数据仓库维度表和数据库中的业务表之间关系

6.维度变化

缓慢变化维

数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化。与数据增长较为快速的事实表相比,维度变化相对缓慢

处理缓慢变化维的三种方式
1.重写维度值,不保留历史维度值,始终采取最新的数据
2.插入新的维度行,保留历史维度值
3.添加新的维度列,一条数据同时属于新的和旧的维度

快照维度

在“维度的基本概念”中,介绍了自然键和代理键的定义,在Kimball的维度建模中,必须使用代理键作为每个维表的主键,用于处理缓慢变化维。但是数据量大的情况下,生成一个全局唯一的代理键难度很大,并且使用代理键会大大增加etl的难度

数据仓库实践中,处理缓慢变化维的方法是采用快照方式。数据仓库的计算周期一般是每天一次,基于此周期,处理维度变化的方式就是每天保留一份全量快照数据。比如商品维度,每天保留一份全量商品快照数据。任意一天的事实均可以获取到当天的商品信息,也可以获取到最新的商品信息,通过限定日期,采用自然键进行关联即可。此方法既有优点,也有弊端。优点是开发简单,维护成本低,理解性好.缺点是储存成本大

极限存储

拉链表的思想,问题是随着时间的推移数据会极大的膨胀,且理解性不是很好,优化的方法有透明表的使用 以分月作为拉链表

微型维度

微型维度的创建是通过将一部分不稳定的属性从主维度中移出,并将它们放置到拥有自己代理键的新表中来实现的。这些属性相互之间没有直接关联,不存在自然键。通过为每个组合创建新行的一次性过程来加载数据。比如淘宝用户维度,用户的注册日期、年龄、性别、身份信息等

微型维度

特殊维度(桥接表 多值维度)

image.png

image.png

怎么选择合适的维度表建模方法
怎么设计出初始的维度表并对它进行迭代更新和处理

7.事实表

事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的度量。事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述:一种是维度属性组合所表示的细节程度,一种是所表示的具体业务含义
作为度量业务过程的事实,一般为整型或浮点型的十进制数值,有可加性,半可加性和不可加性三种类型
维度属性也可以存储到事实表中,这种存储到事实表中的维度列被,称为“退化维度”。与其他存储在维表中的维度一样,退化维度也可以用来进行事实表的过滤查询、实现聚合操作等
事实表有三种类型,事务事实表,周期快照事实表,累积快照事实表,第一种是保留的是原始数据的表,第二种是以规律的,可预见的时间间隔记录事实,第三种是用来表示过程的开始和结束的关键步骤事件,覆盖过程的整个生命周期,伴随着生命周期的变化,数据被不断修改

事实表的设计原则

1. 尽可能包含与业务过程相关的事实
2. 只选择与业务过程相关的事实
3. 分解不可加的事实为可加的组件
   (例如:订单的优惠率应该分解为原价和优惠后的价格)
4. 在选择维度和事实之前必须先声明粒度
   (粒度用于确定事实表中每一行所表示的业务细节层次,决定了维度模型的可扩展性,在设计事实表的时候粒度应该尽可能越细越好,原子粒度可以提供最大限度地灵活性)
5. 在同一个事实表中不能有不同的粒度
6. 对null值的处理尽量用0俩代替
7. 使用维度退化来提高事实表的易用性

事务事实表

单事务事实表

image.png

多事务事实表

image.png

两种事实表的比对

业务过程
对于单事务事实表,一个业务过程建立一个事实表,只反映一个业务过程的事实;对于多事务事实表,在同一个事实表中反映多个业务过程。多个业务过程是否放到同一个事实表中,首先需要分析不同业务过程之间的相似性和业务源系统。比如淘宝交易的下单、支付和成功完结这三个业务过程是存在相似性的,都属于订单处理中的一环,并且都来自于交易系统,因此适合放到同一个事务事实表中

粒度和维度
在考虑是采用单事务事实表还是多事务事实表时,另一个关键点就是粒度和维度,在确定好业务过程后,需要基于不同的业务过程确定粒度和维度,当不同业务过程的粒度相同,同时拥有相似的维度时,此时就可以考虑采用多事务事实表。如果粒度不同,则必定是不同的事实表。比如交易中支付和发货有不同的粒度,则无法将发货业务过程放到淘宝交易事务事实表中

事实
对于不同的业务过程,事实往往是不同的,单事务事实表在处理事实上比较方便和灵活,仅仅体现同一个业务过程的事实即可;而多事务事实表由于有多个业务过程,所以有更多的事实需要处理。如果单一业务过程的事实较多,同时不同业务过程的事实又不相同,则可以考虑使用单事务事实表,处理更加清晰;若使用多事务事实表,则会导致事实表零值或空值字段较多

比对

周期性快照表

快照事实表的设计有一些区别于事务事实表设计的性质。事务事实表的粒度能以多种方式表达,但快照事实表的粒度通常以维度形式声,明;事务事实表是稀疏的,但快照事实表是稠密的;事务事实表中的事实是完全可加的,但快照模型将至少包含一个用来展示半可加性质的事实

单维度快照表

单维度快照表

混合维度每天的快照表

混合维度每天的快照表

全量快照表

全量快照表

累积性快照事实表

适用于具有较明确旗帜时间的短生命周期的业务实体

累积快照事实表的典型特征是多业务过程日期,用于计算业务过程之间的时间间隔。但结合阿里巴巴数据仓库模型建设的经验,对于累积快照事实表,还有一个重要作用是保存全量数据。对于淘宝交易,需要保留历史截至当前的所有交易数据,其中一种方式是在ODS层保留和源系统结构完全相同的数据;但由于使用时需要关联维度,较为麻烦,所以在公共明细层需要保留一份全量数据,淘宝交易累积快照事实表就承担了这样的作用--存放加工后的事实,并将各维度常用属性和订单杂项维度退化到此表中。通常用于数据探查、统计分析、数据挖掘等

特殊处理☆

1.对于非线性过程

(1). 业务过程的统一比如流程结束标志的统一,最开始设计交易累积快照事实表时,以交易完成作为结束标志;进一步了解业务之后,发现交易关闭也是交易结束的一个分支,所以将交易结束作为流程结束、实体消亡的标志,包括交易完成和交易结束两种情况。
(2). 针对业务关键里程碑构建全面的流程比如淘宝交易,全流程可能是下单一支付一发货一确认收货。对于没有支付或没有发货的交易订单,全流程仍然可以覆盖,相关业务过程的时间字段和事实置空。
(3). 循环流程的处理主要问题是解决一个业务过程存在多个里程碑日期的问题。使用业务过程第一次发生的日期还是最后一次发生的日期,决定权在商业用户,而不是设计或开发人员。

2.多源过程

物理实现

第一种方式是全量表的形式。此全量表一般为日期分区表,每天的分区存储昨天的全量数据和当天的增量数据合并的结果,保证每条记录的状态最新。此种方式适用于全量数据较少的情况。如果数据量很大,此全量表数据量不断膨胀,存储了大量永远不再更新的历史数据,对ETL和分析统计性能影响较大。

第二种方式是全量表的变化形式。此种方式主要针对事实表数据量很大的情况。较短生命周期的业务实体一般从产生到消亡都有一定的时间间隔,可以测算此时间间隔,或者根据商业用户的需求确定一个相对交大的时间间隔。比如针对交易订单,我们以200天作为订单从产生到消亡的最大间隔。设计最近200天的交易订单累积快照事实表,每天的分区存储最近200天的交易订单;而200天之前的订单则按照create创建分区存储在归档表中。此方式存在的一个问题是200天的全量表根据商业需求需要保留多天的分区数据,而由于数据量较大,存储消耗较大。(其实对方法一进行了时间上的过滤,行的过滤....)

第三种方式是以业务实体的结束时间分区。每天的分区存放当天结束的数据,设计一个时间非常大的分区,比如3000-12-31,存放截至当前未结束的数据。由于每天将当天结束的数据归档至当天分区中,时间非常大的分区数据量不会很大, ETL性能较好;并且无存储的浪费,对于业务实体的某具体实例,在该表的全量数据中唯一。比如对于交易订单,在交易累积快照事实表中唯一。但是存在极端的情况无法标识业务实体的结束时间,采取的方法有使用其他相关业务系统的结束标识为此标识,方法二和前端业务系统确定口径或者前端归档策略(更新策略和拉链表的一致,etl提取出设置默认时间的数据,那行数据未更新,但是拉链表的构建思想是不一样的,拉建表保留的是全量数据,而这个的目的是结束一个行的生命周期)

三种事实表的比较

三种事实表的比较

聚集型事实表

数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据,可以减少数据库在响应查询时必须执行的工作量,能够快速响应用户的查询,同时有利于减少不同用户访问明细数据带来的结果不一致问题。尽管聚集能带来良好的收益,但需要事先对其进行加载和维护,这将会对给ETL带来更多的挑战。将使用频繁的的公共数据,通过聚集进行沉淀,比如是卖家最近一天的交易汇总表,卖家自然年交易汇总表等这类汇总数据

这一章看了两天,就是对数仓工具箱的加工,不如直接看工具箱,提取一下重要的知识点
1.最重要的就是实践,了解行业的需求,建一个坚固面向数据分析师或者客户的数仓系统
2.维度表的构建,这个要具体结合行业,书中提供了构建的基本步骤,注意一下粒度关键词,书中还提供了构建表之间关系的构建方法论
3.我们不谈论任何具体建表方法,我认为比较重要的就是,维度表和事实表之间的外键主键的构建大致的构建标准,这样才能写出好性能的SQL
4.在ODS层我们要做的就是etl,这是重要的,我们要对采集的数据划分维度和事实,结构化数据,这个怎么有效率的实现是至关重要的!!!
5.在DWD层我们划分好了维度和事实为DWS层的主题建模服务,在DWD层的一致性维表的构建思路(ODS层)也是重要的!!!
6.对于主题建模是面向分析师,然而分析师可能也不知道什么才是重要的指标,主题建模要面向未来,可迭代的面向主题集成我们的报表原始层
7.这一章还讲了一个事实表的类型也是重要,数仓工程师的价值就体现在事实表和维表的设计上
8.了解一下行业术语:缓慢变化维 维度退化 上钻下钻 拉链表 桥接表 非线性过程等
9.还有一个难点:关于对行的更新,怎么做才是有效率的有价值的