乐趣区

关于数据仓库:尚硅谷数仓实战之2数仓分层维度建模

@TOC

数仓笔记

数据仓库和数据集市详解:ODS、DW、DWD、DWM、DWS、ADS

尚硅谷数仓实战之 1 我的项目需要及架构设计

尚硅谷数仓实战之 2 数仓分层 + 维度建模

尚硅谷数仓实战之 3 数仓搭建

尚硅谷数据仓库 4.0 视频教程

B 站中转:2021 新版电商数仓 V4.0 丨大数据数据仓库我的项目实战
百度网盘:https://pan.baidu.com/s/1FGUb…,提取码:yyds
阿里云盘:https://www.aliyundrive.com/s…,提取码:335o

第 1 章 数仓分层

1.1 为什么要分层

1.2 数据集市与数据仓库概念

1.3 数仓命名标准

1.3.1 表命名

Ø ODS 层命名为 ods_表名

Ø DIM 层命名为 dim_表名

Ø DWD 层命名为 dwd_表名

Ø DWS 层命名为 dws_表名

Ø DWT 层命名为 dwt_表名

Ø ADS 层命名为 ads_表名

Ø 长期表命名为 tmp_表名

1.3.2 脚本命名

Ø 数据源_to_指标_db/log.sh

Ø 用户行为脚本以 log 为后缀;业务数据脚本以 db 为后缀。

1.3.3 表字段类型

Ø 数量类型为 bigint

Ø 金额类型为 decimal(16, 2),示意:16 位有效数字,其中小数局部 2 位

Ø 字符串 (名字,形容信息等) 类型为 string

Ø 主键外键类型为 string

Ø 工夫戳类型为 bigint

第 2 章 数仓实践

2.1 范式实践

2.1.1 范式概念

1)定义

数据建模必须遵循肯定的规定,在关系建模中,这种规定就是范式。

2)目标

采纳范式,能够升高数据的冗余性。

为什么要升高数据冗余性?

(1)十几年前,磁盘很贵,为了缩小磁盘存储。

(2)以前没有分布式系统,都是单机,只能减少磁盘,磁盘个数也是无限的

(3)一次批改,须要批改多个表,很难保证数据一致性

3)毛病

范式的毛病是获取数据时,须要通过 Join 拼接出最初的数据。

4)分类

目前业界范式有:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯 - 科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

2.1.2 函数依赖

2.1.3 三范式辨别



2.2 关系建模与维度建模

关系建模和维度建模是两种数据仓库的建模技术。关系建模由 Bill Inmon 所提倡,维度建模由 Ralph Kimball 所提倡。

2.2.1 关系建模

关系建模将简单的数据抽象为两个概念——实体和关系,并应用规范化的形式示意进去。关系模型如图所示,从图中能够看出,较为涣散、系统,物理表数量多。

关系模型严格遵循第三范式(3NF),数据冗余水平低,数据的一致性容易失去保障。因为数据分布于泛滥的表中,查问会绝对简单,在大数据的场景下,查问效率绝对较低。

2.2.2 维度建模

维度模型如图所示,从图中能够看出,模型绝对清晰、简洁。

图 维度模型示意图

维度模型以数据分析作为出发点,不遵循三范式,故数据存在肯定的冗余。维度模型面向业务,将业务用事实表和维度表出现进去。表构造简略,故查问简略,查问效率较高。

2.3 维度表和事实表(重点)

2.3.1 维度表

维度表:个别是对事实的形容信息。每一张维表对应事实世界中的一个对象或者概念。例如:用户、商品、日期、地区等。

维表的特色:

Ø 维表的范畴很宽(具备多个属性、列比拟多)

Ø 跟事实表相比,行数绝对较小:通常 < 10 万条

Ø 内容绝对固定:编码表

工夫维度表:

日期 ID day of week day of year 季度 节假日
2020-01-01 2 1 1 除夕
2020-01-02 3 2 1
2020-01-03 4 3 1
2020-01-04 5 4 1
2020-01-05 6 5 1

2.3.2 事实表

事实表中的每行数据代表一个业务事件(下单、领取、退款、评估等)。“事实”这个术语示意的是业务事件的度量值(可统计次数、个数、金额等),例如,2020 年 5 月 21 日,宋宋老师在京东花了 250 块钱买了一瓶海狗人参丸。维度表:工夫、用户、商品、商家。事实表:250 块钱、一瓶

每一个事实表的行包含:具备可加性的数值型的度量值、与维表相连接的外键,通常具备两个和两个以上的外键。

事实表的特色:

Ø 十分的大

Ø 内容绝对的窄:列数较少(次要是外键 id 和度量值)

Ø 常常发生变化,每天会新减少很多。

1)事务型事实表

以每个事务或事件为单位,例如一个销售订单记录,一笔领取记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新形式为增量更新。

2)周期型快照事实表

周期型快照事实表中不会保留所有数据,只保留固定工夫距离的数据,例如每天或者每月的销售额,或每月的账户余额等。

例如购物车,有加减商品,随时都有可能变动,然而咱们更关怀每天完结时这外面有多少商品,不便咱们前期统计分析。

3)累积型快照事实表

累计快照事实表用于跟踪业务事实的变动。例如,数据仓库中可能须要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的工夫点数据来跟踪订单申明周期的停顿状况。当这个业务过程进行时,事实表的记录也要不断更新。

订单 id 用户 id 下单工夫 打包工夫 发货工夫 签收工夫 订单金额
3-8 3-8 3-9 3-10

2.4 维度模型分类

在维度建模的根底上又分为三种模型:星型模型、雪花模型、星座模型。

2.5 数据仓库建模(相对重点)

2.5.1 ODS 层

1)HDFS 用户行为数据

2)HDFS 业务数据

3)针对 HDFS 上的用户行为数据和业务数据,咱们如何布局解决?

(1)保持数据原貌不做任何批改,起到备份数据的作用。

(2)数据采纳压缩,缩小磁盘存储空间(例如:原始数据 100G,能够压缩到 10G 左右)

(3)创立分区表,避免后续的全表扫描

2.5.2 DIM 层和 DWD 层

DIM 层 DWD 层需构建维度模型,个别采纳星型模型,出现的状态个别为星座模型。

维度建模个别依照以下四个步骤:

抉择业务过程→申明粒度→确认维度→确认事实

(1)抉择业务过程

在业务零碎中,筛选咱们感兴趣的业务线,比方下单业务,领取业务,退款业务,物流业务,一条业务线对应一张事实表。

(2)申明粒度

数据粒度指数据仓库的数据中保留数据的细化水平或综合水平的级别。

申明粒度意味着准确定义事实表中的一行数据表示什么,应该尽可能抉择最小粒度,以此来应各种各样的需要。

典型的粒度申明如下:

订单事实表中一行数据表示的是一个订单中的一个商品项。

领取事实表中一行数据表示的是一个领取记录。

(3)确定维度

维度的次要作用是形容业务是事实,次要示意的是“谁,何处,何时”等信息。

确定维度的准则是:后续需要中是否要剖析相干维度的指标。例如,须要统计,什么工夫下的订单多,哪个地区下的订单多,哪个用户下的订单多。须要确定的维度就包含:工夫维度、地区维度、用户维度。

(4)确定事实

此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,能够进行累加),例如订单金额、下单次数等。

在 DWD 层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化解决。

事实表和维度表的关联比拟灵便,然而为了应答更简单的业务需要,能够将能关联上的表尽量关联上。

业务总线矩阵:

工夫 用户 地区 商品 优惠券 流动 度量值
订单 运费 / 优惠金额 / 原始金额 / 最终金额
订单详情 件数 / 优惠金额 / 原始金额 / 最终金额
领取 领取金额
加购 件数 / 金额
珍藏 次数
评估 次数
退单 件数 / 金额
退款 件数 / 金额
优惠券领用 次数

至此,数据仓库的维度建模曾经结束,DWD 层是以业务过程为驱动。

DWS 层、DWT 层和 ADS 层都是以需要为驱动,和维度建模曾经没有关系了。

DWS 和 DWT 都是建宽表,依照主题去建表。主题相当于察看问题的角度。对应着维度表。

2.5.3 DWS 层与 DWT 层

DWS 层和 DWT 层统称宽表层,这两层的设计思维大致相同,通过以下案例进行论述。

1)问题引出:两个需要,统计每个省份订单的个数、统计每个省份订单的总金额

2)解决方法:都是将省份表和订单表进行 join,group by 省份,而后计算。同样数据被计算了两次,实际上相似的场景还会更多。

那怎么设计能防止反复计算呢?

针对上述场景,能够设计一张地区宽表,其主键为地区 ID,字段蕴含为:下单次数、下单金额、领取次数、领取金额等。上述所有指标都对立进行计算,并将后果保留在该宽表中,这样就能无效防止数据的反复计算。

3)总结:

(1)须要建哪些宽表:以维度为基准。

(2)宽表外面的字段:是站在不同维度的角度去看事实表,重点关注事实表聚合后的度量值。

(3)DWS 和 DWT 层的区别:DWS 层寄存的所有主题对象当天的汇总行为,例如每个地区当天的下单次数,下单金额等,DWT 层寄存的是所有主题对象的累积行为,例如每个地区最近7天(15天、30天、60天)的下单次数、下单金额等。

2.5.4 ADS 层


退出移动版