数据仓库模型设计V2.0

一、数仓建模的意义

数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后,数据才能得到高性能、低成本、高效率、高质量的使用。

  • 高性能:良好的数据模型能够帮助我们快速查询所需要的数据。

  • 低成本:良好的数据模型能减少重复计算,实现计算结果的复用,降低计算成本。

  • 高效率:良好的数据模型能极大的改善用户使用数据的体验,提高使用数据的效率。

  • 高质量:良好的数据模型能改善数据统计口径的混乱,减少计算错误的可能性。

二、数据仓库建模方法论

2.1、ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度,用实体关系(Entity Relationship,ER)模型来描述企业业务,并用规范化的方式表示出来,在范式理论上符合3NF。

2.1.1、实体关系模型

实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象,例如学生、班级,关系是指两个实体之间的关系,例如学生和班级之间的从属关系。

2.1.2、数据库规范化

数据库规范化是使用一系列范式设计数据库(通常是关系型数据库)的过程,其目的是减少数据冗余,增强数据的一致性

这一系列范式就是指在设计关系型数据库时,需要遵从的不同的规范。关系型数据库的范式一共有六种,分别是第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF)。遵循的范式级别越高,数据冗余性就越低。

2.1.3、三范式

2.1.3.1、函数依赖

函数依赖是指关系中属性间(或者说是表中字段间)的对应关系。

  • 完全函数依赖

    • 书上定义的意思基本是:如果存在 X 属性集(注意是集合,说明是联合主键)决定 唯一的 Y ,且 X 中的任一子集都不能决定 唯一的 Y,则 Y 完全依赖于 X。

    • 例如:学生数学成绩完全由该学生的学号和数学课决定,所以数学课成绩完全依赖于(学号,数学课)

  • 部分函数依赖

    • 定义和完全函数依赖有一点不一样,就是 X 的属性集中任一子集可以决定唯一的 Y,则 Y 部分依赖于 X。

    • 例如:学生学号和姓名可以决定唯一的学生,但是学生号也可以决定唯一的学生

  • 传递函数依赖

    • 定义:设 R 为任一给定关系, X Y Z 为其不同的属性子集,若 X —> Y, Y 不决定 X 且 Y —>Z,则有 X —>Z,称为 Z 传递函数依赖于 X

    • 例如:书的出版编号是唯一,版权归出版社所有,所以只能由该出版社出版。所以存在函数依赖:书出版编号—>出版社名,出版社名—>出版社地址,但是出版社名不能决定唯一的出版书编号(除非出版社只出版过一本书,那我没话说?),则有出版社地址传递函数依赖于出版书编号

2.1.3.2、第一范式

每一列都是不可分割的原子数据项(什么意思,每一项都不可分割,像下面的表格就能分割,所以它连第一范式都算不上

图片

2.1.3.3、第二范式

在1NF基础上,非主属性必须完全依赖于主键属性(在1NF基础上消除非主属性对主键属性的部分函数依赖),不能存在部分依赖函数。

如下:分数完全依赖(学号、课名),但是姓名不完全依赖(学号、姓名)

图片

图片

2.1.3.4、第三范式

在2NF的基础上,任何的非主属性不依赖于其他非主属性 (在第二范式基础上消除传递依赖)

注意看第二范式的学生表:存在系主任依赖于系名 (系名---> 系主任),所以不符合第三范式

图片

继续拆分:

图片

ER模型这种建模方法的出发点是整合数据,其目的是将整个企业的数据进行组合和合并,并进行规范处理,减少数据冗余性,保证数据的一致性。这种模型并不适合直接用于分析统计。

2.2、维度建模

数据仓库领域的令一位大师——Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。

事实通常对应业务过程:业务过程可以概括为一个个不可拆分的行为事件,例如电商交易中的下单,取消订单,付款,退单等,都是业务过程。

而维度通常对应业务过程发生时所处的环境:如何人何时何地干了什么事。

下图为一个典型的维度模型,其中位于中心的SalesOrder为事实表,其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表,包括Date(日期),Customer(顾客),Product(产品),Location(地区)等,这些维度表就组成了每个订单发生时所处的环境,即何人、何时、在何地下单了何种产品。从图中可以看出,模型相对清晰、简洁。

图片

维度建模以数据分析作为出发点,为数据分析服务,因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。

三、维度建模理论之事实表

3.1 事实表概述

事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用(维度表外键)以及该业务过程的度量(通常是可累加的数字类型字段)。

3.1.1 事实表特点

事实表通常比较“细长”,即列较少,但行较多,且行的增速快。

3.1.2 事实表分类

事实表有三种类型:分别是事务事实表、周期快照事实表、累积快照事实表,每种事实表都具有不同的特点和适用场景,下面逐个介绍。

3.2、事务型事实表

3.2.1 概述

事务事实表用来记录各业务过程,它保存的是各业务过程的原子操作事件(如查订单、下单),即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度

事务型事实表可用于分析与各业务过程相关的各项统计指标,由于其保存了最细粒度的记录,可以提供最大限度的灵活性,可以支持无法预期的各种细节层次的统计需求

3.2.2 设计流程

设计事务事实表时一般可遵循以下四个步骤:

选择业务过程→声明粒度→确认维度→确认事实

1)选择业务过程

在业务系统中,挑选我们感兴趣的业务过程,业务过程可以概括为一个个不可拆分的行为事件,例如电商交易中的下单,取消订单,付款,退单等,都是业务过程。通常情况下,一个业务过程对应一张事务型事实表。

2)声明粒度

业务过程确定后,需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么,应该尽可能选择最细粒度,以此来应各种细节程度的需求。

典型的粒度声明如下:订单事实表中一行数据表示的是一个订单中的一个商品项。

3)确定维度

确定维度具体是指,确定与每张事务型事实表相关的维度有哪些。

确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。

4)确定事实

此处的“事实”一词,指的是每个业务过程的度量值(通常是可累加的数字类型的值,例如:次数、个数、件数、金额等)。

经过上述四个步骤,事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表,第二步可以确定每张事务型事实表的每行数据是什么,第三步可以确定每张事务型事实表的维度外键,第四步可以确定每张事务型事实表的度量值字段。

3.2.3、不足

事务型事实表可以保存所有业务过程的最细粒度的操作事件,故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求,其逻辑可能会比较复杂(聚合),或者效率会比较低下。例如:

1)存量型指标

例如商品库存,账户余额等。此处以电商中的虚拟货币为例,虚拟货币业务包含的业务过程主要包括获取货币和使用货币,两个业务过程各自对应一张事务型事实表,一张存储所有的获取货币的原子操作事件,另一张存储所有使用货币的原子操作事件。

假定现有一个需求,要求统计截至当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额,故需要对两张事务型事实表进行聚合,且需要区分两者对余额的影响(加或减),另外需要对两张表的全表数据聚合才能得到统计结果。

可以看到,不论是从逻辑上还是效率上考虑,这都不是一个好的方案。

(同一个指标需要聚合多个表的结果)

2)多事务关联统计

例如,现需要统计最近30天,用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表,过滤出最近30天的记录,然后按照订单id对两张事实表进行关联,之后用支付时间减去下单时间,然后再求平均值。

逻辑上虽然并不复杂,但是其效率较低,应为下单事务事实表和支付事务事实表均为大表,大表join大表的操作应尽量避免。

可以看到,在上述两种场景下事务型事实表的表现并不理想。下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。

(需要使用到多个事实表进行关联的时候,由于数据量大,造成效率低下)

3.3、周期型快照事实表

3.3.1 概述

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,主要用于分析一些存量型(例如商品库存,账户余额)或者状态型(空气温度,行驶速度)指标。

对于商品库存、账户余额这些存量型指标,业务系统中通常就会计算并保存最新结果,所以定期同步一份全量数据到数据仓库,构建周期型快照事实表,就能轻松应对此类统计需求,而无需再对事务型事实表中大量的历史记录进行聚合了。

对于空气温度、行驶速度这些状态型指标,由于它们的值往往是连续的,我们无法捕获其变动的原子事务操作,所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样,构建周期型快照事实表。

3.3.2 设计流程

1)确定粒度

周期型快照事实表的粒度可由采样周期和维度描述,故确定采样周期和维度后即可确定粒度。采样周期通常选择每日。

维度可根据统计指标决定,例如指标为统计每个仓库中每种商品的库存,则可确定维度为仓库和商品。

确定完采样周期和维度后,即可确定该表粒度为每日-仓库-商品。

2)确认事实

事实也可根据统计指标决定,例如指标为统计每个仓库中每种商品的库存,则事实为商品库存。

3.3.3 事实类型

此处的事实类型是指度量值的类型,而非事实表的类型。事实(度量值)共分为三类,分别是可加事实,半可加事实和不可加事实。

1)可加事实

可加事实是指可以按照与事实表相关的所有维度进行累加,例如事务型事实表中的事实。

2)半可加事实

半可加事实是指只能按照与事实表相关的一部分维度进行累加,例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例,这张表中的库存事实可以按照仓库或者商品维度进行累加,但是不能按照时间维度进行累加,因为将每天的库存累加起来是没有任何意义的。

3)不可加事实

不可加事实是指完全不具备可加性,例如比率型事实。不可加事实通常需要转化为可加事实,例如比率可转化为分子和分母。

3.4 累积型快照事实表

3.4.1 概述

累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表,如交易流程中的下单、支付、发货、确认收货业务过程。

累积型快照事实表通常具有多个日期字段,每个日期对应业务流程中的一个关键业务过程(里程碑)。

订单id

用户id

下单日期

支付日期

发货日期

确认收货日期

订单金额

支付金额

1001

1234

2020-06-14

2020-06-15

2020-06-16

2020-06-17

1000

1000

累积型快照事实表主要用于分析业务过程(里程碑)之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔,使用累积型快照事实表进行统计,就能避免两个事务事实表的关联操作,从而变得十分简单高效。

3.4.2 设计流程

累积型快照事实表的设计流程同事务型事实表类似,也可采用以下四个步骤,下面重点描述与事务型事实表的不同之处。

选择业务过程→声明粒度→确认维度→确认事实。

1)选择业务过程

选择一个业务流程中需要关联分析的多个关键业务过程,多个业务过程对应一张累积型快照事实表。

2)声明粒度

精确定义每行数据表示的是什么,尽量选择最小粒度。

3)确认维度

选择与各业务过程相关的维度,需要注意的是,每各业务过程均需要一个日期维度。

4)确认事实

选择各业务过程的度量值。

四、维度建模理论之维度表

4.1、维度表概述

维度表是维度建模的基础和灵魂。前文提到,事实表紧紧围绕业务过程进行设计,而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段,维度字段称为维度属性。

4.2、维度表设计步骤

1)确定维度(表)

在设计事实表时,已经确定了与每个事实表相关的维度,理论上每个相关维度均需对应一张维度表。需要注意到,可能存在多个事实表与同一个维度都相关的情况,这种情况需保证维度的唯一性,即只创建一张维度表。另外,如果某些维度表的维度属性很少,例如只有一个**名称,则可不创建该维度表,而把该表的维度属性直接增加到与之相关的事实表中,这个操作称为维度退化

2)确定主维表和相关维表

此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info,spu_info,base_trademark,base_category3,base_category2,base_category1等,其中sku_info就称为商品维度的主维表,其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。

3)确定维度属性

确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择,也可通过进一步加工得到。

确定维度属性时,需要遵循以下要求:

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

维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源,是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。

2)尽量不使用编码,而使用明确的文字说明,一般可以编码和文字共存。

3)尽量沉淀出通用的维度属性

有些维度属性的获取需要进行比较复杂的逻辑处理,例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理,可将这些维度属性沉淀到维度表中。

4.3、维度设计要点

4.3.1 规范化与反规范化

规范化是指使用一系列范式设计数据库的过程,其目的是减少数据冗余,增强数据的一致性。通常情况下,规范化之后,一张表的字段会拆分到多张表。

反规范化是指将多张表的数据冗余到一张表,其目的是减少join操作,提高查询性能。在设计维度表时,如果对其进行规范化,得到的维度模型称为雪花模型,如果对其进行反规范化,得到的模型称为星型模型。

星型模型:基本只有一层维度表

雪花模型:有多层的维度表

图片

星座模型:有多个事实表公用同一个维度表,即多个星型交织在一起。

数据仓库系统的主要目的是用于数据分析和统计,所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型,用户在统计分析的过程中需要大量的关联操作,使用复杂度高,同时查询性能很差,而采用星型模型,则方便、易用且性能好。所以出于易用性和性能的考虑,维度表一般是很不规范化的。

4.3.2 维度变化

维度属性通常不是静态的,而是会随时间变化的,数据仓库的一个重要特点就是反映历史的变化,所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态,通常有以下两种做法,分别是全量快照表和拉链表。

1)全量快照表

离线数据仓库的计算周期通常为每天一次,所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。

优点是简单而有效,开发和维护成本低,且方便理解和使用。

缺点是浪费存储空间,尤其是当数据的变化比例比较低时。

2)拉链表

拉链表的意义就在于能够更加高效的保存维度信息的历史状态。

(1)什么是拉链表

拉链表是针对数据仓库设计中表存储数据的方式而定义的,顾名思义,所谓拉链,就是记录历史。记录一个事物从开始,一直到当前状态的所有变化的信息。(注:拉链表一般包含一个数据有效的起始日期和结束日期,如果结束日期长久有效将会记录为日期的极大值)

图片

(2)为什么要做拉链表

拉链表适合于:数据会发生变化,但是变化频率并不高的维度(即缓慢变化维)。

比如:用户信息会发生变化,但是每天变化的比例不高,如果数据量有一定规模,按照每日全量的方式保存效率很低。比如:1亿用户*365天,每天一份用户信息(每日做全量效率低)。

图片

(3)拉链表的使用场景

在数据仓库的数据模型设计过程中,经常会遇到下面这种表的设计:

    • 有一些表的数据量很大,比如一张用户表,大约10亿条记录,50个字段,这种表,即使使用ORC压缩,单张表的存储也会超过100G,在HDFS使用双备份或者三备份的话就更大一些。

    • 表中的部分字段会被update更新操作,如用户联系方式,产品的描述信息,订单的状态等等。

    • 需要查看某一个时间点或者时间段的历史快照信息,比如,查看某一个订单在历史某一个时间点的状态。

    • 表中的记录变化的比例和频率不是很大,比如,总共有10亿的用户,每天新增和发生变化的有200万左右,变化的比例占的很小。

(4)如何使用拉链表

图片

(5)设计拉链表

在2017-01-01这一天表中的数据是:

注册日期

用户编号

手机号码

2017-01-01

001

111111

2017-01-01

002

222222

2017-01-01

003

333333

2017-01-01

004

444444

在2017-01-02这一天表中的数据是, 用户002和004资料进行了修改,005是新增用户:

注册日期

用户编号

手机号码

备注

2017-01-01

001

111111

(由222222变成233333)

2017-01-01

002

222222

2017-01-01

003

333333

2017-01-01

004

444444

(由444444变成432432)

2017-01-02

005

555555

(2017-01-02新增)

在2017-01-03这一天表中的数据是, 用户004和005资料进行了修改,006是新增用户:

注册日期

用户编号

手机号码

备注

2017-01-01

001

111111

(由222222变成233333)

2017-01-01

002

222222

2017-01-01

003

333333

2017-01-01

004

444444

(由432432变成654321)

2017-01-02

005

555555

(由555555变成115115)

2017-01-03

006

666666

(2017-01-03新增)

如果在数据仓库中设计成历史拉链表保存该表,则会有下面这样一张表,这是最新一天(即2017-01-03)的数据:

注册日期

用户编号

手机号码

t_start_date

t_end_date

2017-01-01

001

111111

2017-01-01

9999-12-31

2017-01-01

002

222222

2017-01-01

2017-01-01

2017-01-01

002

233333

2017-01-02

9999-12-31

2017-01-01

003

333333

2017-01-01

9999-12-31

2017-01-01

004

444444

2017-01-01

2017-01-01

2017-01-01

004

432432

2017-01-02

2017-01-02

2017-01-01

004

654321

2017-01-03

9999-12-31

2017-01-02

005

555555

2017-01-02

2017-01-02

2017-01-02

005

115115

2017-01-03

9999-12-31

2017-01-03

006

666666

2017-01-03

9999-12-31

说明

  • t_start_date表示该条记录的生命周期开始时间,t_end_date表示该条记录的生命周期结束时间。

  • t_end_date = '9999-12-31’表示该条记录目前处于有效状态。

  • 如果查询当前所有有效的记录,则select * from user where t_end_date = ‘9999-12-31’。

  • 如果查询2017-01-02的历史快照,则select * from user where t_start_date <= ‘2017-01-02’ and t_end_date >= ‘2017-01-02’。(此处要好好理解,是拉链表比较重要的一块。)

4.3.3 多值维度

如果事实表中一条记录在某个维度表中有多条记录与之对应,称为多值维度。例如,下单事实表中的一条记录为一个订单,一个订单可能包含多个商品,所会商品维度表中就可能有多条数据与之对应。

针对这种情况,通常采用以下两种方案解决。

第一种:降低事实表的粒度,例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。

第二种:在事实表中采用多字段保存多个维度值,每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。

建议尽量采用第一种方案解决多值维度问题。

4.3.4 多值属性

维表中的某个属性同时有多个值,称之为“多值属性”,例如商品维度的平台属性和销售属性,每个商品均有多个属性值。

针对这种情况,通常有可以采用以下两种方案。

第一种:将多值属性放到一个字段,该字段内容为key1:value1,key2:value2的形式,例如一个手机商品的平台属性值为“品牌:华为,系统:鸿蒙,CPU:麒麟990”。

第二种:将多值属性放到多个字段,每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。

五、数据仓库设计

5.1、为什么要分层

  1. 把复杂问题简单化,将复杂的任务分解成多层来完成,每一层只处理简单任务,方便定位问题。

  2. 减少重复开发,规范数据分层,通过中间层数据,能够减少极大的重复计算,增加一次计算结果的复用性。

  3. 隔离原始数据:不论是数据的异常还是数据的敏感性,使真实数据与统计数据解耦开。

5.2、数据仓库分层规划

优秀可靠的数仓体系,需要良好的数据分层结构。合理的分层,能够使数据体系更加清晰,使复杂问题得以简化。以下是该项目的分层规划。

图片

图片

  1. ODS层:原始数据层,存放原始数据,直接加载原始日志、数据,数据保持原貌不做处理。

  2. DWD层:对ODS层数据进行清洗(去除空值,脏数据,超过极限范围的数据)、维度退化脱敏等。

  3. DWS层:以DWD为基础,按天进行轻度汇总。

  4. DWT层:以DWS为基础,按主题进行汇总。

  5. ADS层:为各种报表提供数据。

  6. DIM层:可以理解为一些字典表、单独存放。

5.2、数据仓库构建流程

以下是构建数据仓库的完整流程。

图片

5.2.1、数据调研

数据调研重点要做两项工作,分别是业务调研和需求分析。这两项工作做的是否充分,直接影响着数据仓库的质量。

1)业务调研

业务调研的主要目标是熟悉业务流程熟悉业务数据

熟悉业务流程要求做到,明确每个业务的具体流程,需要将该业务所包含的每个业务过程一一列举出来。

熟悉业务数据要求做到,将数据(包括埋点日志和业务数据表)与业务过程对应起来,明确每个业务过程会对哪些表的数据产生影响,以及产生什么影响。产生的影响,需要具体到,是新增一条数据,还是修改一条数据,并且需要明确新增的内容或者是修改的逻辑。

下面业务电商中的交易为例进行演示,交易业务涉及到的业务过程有买家下单、买家支付、卖家发货,买家收货,具体流程如下图。

图片

2)需求分析

典型的需求指标如,最近一天各省份手机品类订单总额。

分析需求时,需要明确需求所需的业务过程维度,例如该需求所需的业务过程就是买家下单,所需的维度有日期,省份,商品品类。

3)总结

做完业务分析和需求分析之后,要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求,则需要和业务方进行沟通,例如某个页面需要新增某个行为的埋点。

5.2.2、明确数据域

数据仓库模型设计除横向的分层外,通常也需要根据业务情况进行纵向划分数据域。

划分数据域的意义是便于数据的管理和应用

通常可以根据业务过程或者部门进行划分,本项目根据业务过程进行划分,需要注意的是一个业务过程只能属于一个数据域。

下面是本数仓项目所需的所有业务过程及数据域划分详情。

数据域

业务过程

交易域

加购、下单、取消订单、支付成功、退单、退款成功

流量域

页面浏览、启动应用、动作、曝光、错误

用户域

注册、登录

互动域

收藏、评价

工具域

优惠券领取、优惠券使用(下单)、优惠券使用(支付)

5.2.3、构建业务总线矩阵

业务总线矩阵中包含维度模型所需的所有事实(业务过程)以及维度,以及各业务过程与各维度的关系。矩阵的行是一个个业务过程,矩阵的列是一个个的维度,行列的交点表示业务过程与维度的关系。

图片

一个业务过程对应维度模型中一张事务型事实表,一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是,总线矩阵中通常只包含事务型事实表,另外两种类型的事实表需单独设计。

按照事务型事实表的设计流程,选择业务过程->声明粒度->确认维度->确认事实,得到的最终的业务总线矩阵见以下表格。

图片

后续的DWD层以及DIM层的搭建需参考业务总线矩阵。

5.2.4、明确统计指标

明确统计指标具体的工作是,深入分析需求,构建指标体系。构建指标体系的主要意义就是指标定义标准化。所有指标的定义,都必须遵循同一套标准,这样能有效的避免指标定义存在歧义,指标定义重复等问题。

1)指标体系相关概念

1)原子指标

原子指标基于某一业务过程度量值,是业务定义中不可再拆解的指标,原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论,原子指标包含三要素,分别是业务过程、度量值和聚合逻辑。

例如订单总额就是一个典型的原子指标,其中的业务过程为用户下单、度量值为订单金额,聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念,通常不会对应有实际统计需求与之对应。

2)派生指标

派生指标基于原子指标,其与原子指标的关系如下图所示。

图片

与原子指标不同,派生指标通常会对应实际的统计需求。请从图中的例子中,体会指标定义标准化的含义。

3)衍生指标

衍生指标是在一个或多个派生指标的基础上,通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。

图片

2)指标体系对于数仓建模的意义

通过上述两个具体的案例可以看出,绝大多数的统计需求,都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。

当统计需求足够多时,必然会出现部分统计需求对应的派生指标相同的情况。这种情况下,我们就可以考虑将这些公共的派生指标保存下来,这样做的主要目的就是减少重复计算,提高数据的复用性。

这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计,就可以参考我们根据现有的统计需求整理出的派生指标。

指标体系.xmind

5.2.5、维度模型设计

维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层,维度表存储在DIM层。

5.2.6、汇总模型设计

汇总模型的设计参考上述整理出的指标体系(主要是派生指标)即可。汇总表与派生指标的对应关系是,一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。请思考:汇总表与事实表的对应关系是?

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/134374.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【深度学习】 Python 和 NumPy 系列教程(十):NumPy详解:2、数组操作(索引和切片、形状操作、转置操作、拼接操作)

目录 一、前言 二、实验环境 三、NumPy 0、多维数组对象&#xff08;ndarray&#xff09; 1. 多维数组的属性 1、创建数组 2、数组操作 1. 索引和切片 a. 索引 b. 切片 2. 形状操作 a. 获取数组形状 b. 改变数组形状 c. 展平数组 3. 转置操作 a. 使用.T属性 b…

智慧公厕建设的好处

在现代社会的迅猛发展中&#xff0c;智慧公厕的建设越来越受到重视。通过智慧高效管理和保持公厕整洁&#xff0c;城市形象得以提升&#xff0c;为居民提供更加便捷舒适的生活服务。本文将以智慧公厕源头厂家广州中期科技有限公司&#xff0c;大量精品项目案例&#xff0c;实景…

(手撕)数据结构--->堆

文章内容 目录 一&#xff1a;堆的相关概念与结构 二&#xff1a;堆的代码实现与重要接口代码讲解 让我们一起来学习:一种特殊的数据结构吧&#xff01;&#xff01;&#xff01;&#xff01; 一&#xff1a;堆的相关概念与结构 在前面我们已经简单的学习过了二叉树的链式存储结…

FactoryTalk View Studio

由于项目需要&#xff0c;学习了FactoryTalk View Studio的一些操作&#xff0c;这里记录一下&#xff0c;方便以后查阅&#xff0c;并且随着项目的学习&#xff0c;随时更新。 FactoryTalk View Studio FactoryTalk View Studio 安装新建一个View Site Edition工程在工程中新建…

非常详细的git-flow分支管理流程配置及使用

非常详细的git-flow分支管理流程配置及使用。 git-flow有两个涵义,一个是指软件开发领域的版本管理流程Gitflow。另一个是指git命令工具git flow。 目前业界主流的版本管理流程是Gitflow 和 trunk-based。 Gitflow流行的比较早。但是目前的流行度要低于 trunk-based模式工作…

社区团购商城小程序v18.1开源独立版+前端

新增后台清理缓存功能 修复定位权限 修复无法删除手机端管理员 11月新登录接口修复&#xff01; 修复商家付款到零钱&#xff0c; 修复会员登陆不显示头像&#xff0c; 修复无法修改会员开添加绑定

国内AI语言大模型【文心一言】介绍

一、前言 文心一言是一个知识增强的大语言模型,基于飞桨深度学习平台和文心知识增强大模型,持续从海量数据和大规模知识中融合学习具备知识增强、检索增强和对话增强的技术特色。 最近收到百度旗下产品【文心一言】的产品,抱着试一试的心态体验了一下,整体感觉:还行! 二…

【微信小程序】网络请求

环境&#xff1a;微信小程序开发工具 测试api&#xff08;随机获取猫咪靓照&#xff09;:https://api.thecatapi.com/v1/images/search?limit2 示例&#xff1a; 完整代码 request.wxml <button bind:tap"requestBtn" type"primary">网络请求&l…

TouchGFX之缓存位图

位图缓存是专用RAM缓冲区&#xff0c;应用可将位图保存&#xff08;或缓存&#xff09;在其中。 如果缓存了位图&#xff0c;在绘制位图时&#xff0c;TouchGFX将自动使用RAM缓存作为像素来源。位图缓存在许多情况下十分有用。 从RAM读取数据通常比从闪存读取要快&#xff08;特…

重新认识架构—不只是软件设计

前言 什么是架构&#xff1f; 通常情况下&#xff0c;人们对架构的认知仅限于在软件工程中的定义&#xff1a;架构主要指软件系统的结构设计&#xff0c;比如常见的SOLID准则、DDD架构。一个良好的软件架构可以帮助团队更有效地进行软件开发&#xff0c;降低维护成本&#xff0…

OpenCV之怀旧色、冰冻滤镜、熔铸滤镜

怀旧色 源码&#xff1a; void huaijiu(Mat& src,Mat& dst) {for (int h 0;h < src.rows;h ){uchar *d1 src.ptr<uchar>(h);uchar *d2 dst.ptr<uchar>(h);for (int w 0;w < src.cols;w ){int w3 3*w;int r d1[w3 2];int g d1[w3 1];int …

微信小程序——生命周期详解(代码解读)

✅作者简介&#xff1a;2022年博客新星 第八。热爱国学的Java后端开发者&#xff0c;修心和技术同步精进。 &#x1f34e;个人主页&#xff1a;Java Fans的博客 &#x1f34a;个人信条&#xff1a;不迁怒&#xff0c;不贰过。小知识&#xff0c;大智慧。 &#x1f49e;当前专栏…

网络请求【小程序】

一、get 二、post 1.获取相应数据 Page({/*** 页面的初始数据*/data: { inptValue:, isArr:[]},/*** 生命周期函数--监听页面加载*/onLoad(options) {},onSubmit(){// console.log(this.data.inptValue)//2.后台请求数据wx.request({url: https://tea.qingnian8.com/demoArt/…

c++静态成员变量与静态成员函数

一、静态成员变量 1、说明 1.1、所有对象共享同一份静态变量 1.2、编译阶段分配内存 1.3、类内声明&#xff0c;类外初始化操作 静态成员变量&#xff0c;不属于某个具体的类对象&#xff0c;多有的类对象共享同一份数据 因此静态成员变量有两种方式访问 2、…

java微服务项目整合skywalking链路追踪框架

skywalking官网网址&#xff1a;Apache SkyWalking 目录 1、安装skywalking 2、微服务接入skywalking 3、skywalking数据持久化 1、安装skywalking 下载skywalking&#xff0c;本篇文章使用的skywalking版本是8.5.0 Index of /dist/skywalkinghttps://archive.apache.org/…

RP-母版 流程图 发布和预览 团队项目

母版 创建一个模版&#xff0c;可根据形态不同引用不同母版。若不想母版受页面变化影响&#xff0c;也可以在引用时脱离母版 创建母版&#xff1a; 1) 转换为母版 2&#xff09;在母版页面中添加 母版拖放行为 拖放行为&#xff0c;在母版名称上右键&#xff0c; 、 任意…

MySQL里的查看操作

文章目录 查看当前mysql有谁连接查看数据库或者表 查看当前mysql有谁连接 show processlist;查看数据库或者表 列出所有数据库&#xff1a; show databases;查看正在使用的数据库&#xff08;必须大写&#xff09;&#xff1a; SELECT DATABASE();列出数据库中的表&#xf…

Vulnhub实战-prime1

前言 VulnHub 是一个面向信息安全爱好者和专业人士的虚拟机&#xff08;VM&#xff09;漏洞测试平台。它提供了一系列特制的漏洞测试虚拟机镜像&#xff0c;供用户通过攻击和漏洞利用的练习来提升自己的安全技能。本次&#xff0c;我们本次测试的是prime1。 一、主机发现和端…

写一篇nginx配置指南

nginx.conf配置 找到Nginx的安装目录下的nginx.conf文件&#xff0c;该文件负责Nginx的基础功能配置。 配置文件概述 Nginx的主配置文件(conf/nginx.conf)按以下结构组织&#xff1a; 配置块功能描述全局块与Nginx运行相关的全局设置events块与网络连接有关的设置http块代理…

Android Fragment

基本概念 Fragment是Android3.0后引入的一个新的API&#xff0c;他出现的初衷是为了适应大屏幕的平板电脑&#xff0c; 普通手机开发也会加入这个Fragment&#xff0c; 可以把他看成一个小型的Activity&#xff0c;又称Activity片段&#xff01; 如果一个很大的界面&#xff…