大数据开发工程师-第十二周 综合项目:电商数据仓库

发表于 | 分类于 ， | 浏览 次
字数统计: 6.2k | 阅读时长 ≈ 21

第十二周 综合项目:电商数据仓库之用户数据行为数仓

电商数据仓库效果展示

1
2
3
4
5
大家好，下面我们来学习一个电商行业的数据仓库项目
首先看一下项目效果

本身我们这个数据仓库项目其实是一个纯后台项目，不过为了让大家能够更加直观的感受项目的效果，我们可以基于数据仓库中的数据统计一些指标进行展现。
我们这个项目要讲的重点不是这个大屏，这个大屏只是一个效果，为了让大家感受更加直观一些而已，我们主要讲的是这些指标对应的底层数据是如何在数据仓库中一层一层构建的。

image-20230330172526095

项目的由来

1
2
3
4
5
6
7
8
9
10
11
接下来我们来看一下这个项目的由来，我们为什么要做这个数据仓库项目呢？或者说做这个数据仓库项目有什么意义吗？

在工作中我们经常会遇到这些情况
产品经理过来说，老王啊，你来看一下，为什么这个数据指标在不同的报表中统计的结果不一样呢？
老王听到后，心里拔凉拔凉的，今晚又得加班了，约好的女朋友看电影估计又得泡汤了。

举个例子：针对平台里面的用户下单数据：我们会在客户端记录一份，就是当用户通过网页或者app下单的时候，会触发一个行为，官方名词叫“埋点”，这个埋点对应的其实就是一个接口，当用户通过网页或者app下单的时候，就会触发这个埋点，然后埋点会上报这个数据，最终会把用户下单行为的数据记录下来，这份数据我们就称之为是客户端记录的数据。

同时服务端也会在数据库中维护一份用户的下单数据。
最终在做报表统计的时候：
如果想要按照分钟级别实时计算，做一个用户消费金额的曲线图，我们一般会使用客户端实时上报的数据，用起来比较方便，但是通过客户端埋点上报的数据可能会有一些问题，有可能会丢数据，以及用户在点击下单按钮的时候可能由于网络异常导致下单失败了，但是这条行为数据却发送过来了，以及用户下单之后还可能会退款，所以这里面统计的数据指标会有一些偏差，不过偏差倒不是很大，如果只是想看一下当天用户消费总金额的一个实时趋势，其实这样做是没有什么问题的。但是你要是使用这份数据统计每天用户的消费总金额，那肯定是有问题的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
如果想要按照天来汇总每天用户的消费总金额，这种数据指标对数据的实时性没什么要求，但是对数据的准确度有很高要求，所以一般会使用数据库中的数据，因为数据库是有事务的，并且在统计的时候也可以排除掉用户退款的数据，这样统计出来的才是这一天用户真正的消费总金额。
所以刚才产品经理反馈的问题很大概率是这个原因，当然也有可能是由于计算的口径不一样，因为不同的报表可能是由不同的需求人员提出来的，指标的计算公式也是有所差别的，甚至有的指标是上一任产品经理提出来的，每个人想要统计的指标是有一些区别的，所以在使用数据的时候就会遇到各种各样的问题。

其实，归根结底，就是因为数据不统一，计算流程不统一导致的结果出现偏差。
后来，老王经过一路追踪，发现，原来在统计这个指标的时候，两个报表使用的底层数据不是同一份，所以导致统计的指标有偏差，然后又给产品经理一顿解释，给产品经理解释完又赶紧打电话给女朋友解释，然后就没有然后了。

经过这件事情之后，老王觉得，数据仓库的构建必须提上日程了
通过构建企业级数据仓库，对企业中的所有数据进行整合，为企业各个部门提供统一的，规范的数据出口
这样大家在使用数据的时候不需要每次都到各种地方去找数据，所有人在使用的时候都是基于相同的基础数据，这样计算出来的指标肯定是相同的。

一个完善合理的数据仓库对于企业整体的数据管理是意义重大的，而数据仓库也是整个大数据系统中的重要一环，更高层次的数据分析、数据挖掘等工作都会基于数据仓库进行
如果你的底层数据都没有规划好，那么上层的数据分析以及数据挖掘都是会受影响的。
就像是我们盖房子，如果地基没有打牢，盖出来的房子肯定也是摇摇欲坠。
所以说数据仓库对于一个中大型企业而言是至关重要的。

那话又说回来了，如果你们公司刚起步，产品也是刚上线，这个时候你花大量的时间去搞数据仓库也是没有意义的，这个时候讲究的是快速迭代。

只有说数据规模上来之后，数据仓库才是有意义的，并且也是必不可少的。

数据仓库前置技术

什么是数据仓库

1
2
3
4
咱们前面说了要构建一个数据仓库，那严格意义上来说，到底什么是数据仓库呢？
咱们前面学习过Hive，说Hive其实就是一个数据仓库，可以这样理解，就是把Hive认为是一种技术，通过Hive这种技术可以实现数据仓库的建设。

咱们这个项目中的数据仓库就是使用Hive构建的。
1
2
来看一下针对数据仓库的官方解释：
数据仓库(Data Warehouse)是一个面向主题的、集成的、稳定的且随时间变化的数据集合，用于支持管理人员的决策
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
注意它里面的这几个特性：

面向主题
主题就是类型的意思。
传统数据库主要是为应用程序进行数据处理，未必会按照同一主题存储数据；
数据仓库侧重于数据分析工作，是按照主题存储的。

这一点，类似于传统农贸市场与超市的区别
市场里面，针对一个商贩，他卖的萝卜、白菜这些蔬菜以及水果会在一个摊位上；
而超市里，蔬菜和水果是分开的，并且在蔬菜里面也会进行分类，不同类型的蔬菜放到不同的地方。
也就是说，农贸市场里的菜(数据)是按照商贩(应用程序)去归类(存储)的，而超市里面则是按照蔬菜、水果的类型(同主题)归类的。

集成
传统数据库通常与某些特定的应用相关，数据库之间相互独立。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

稳定
稳定说的是相对稳定
传统数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析使用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

变化
这里的变化说的是反映历史变化
传统数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，它里面记录了企业从过去某一时间点(如开始应用数据仓库的时间)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出分析和预测。
1
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。

数据仓库基础知识

1
2
3
4
在学习数据仓库之前我们先来看一些数据仓库的基础知识
1：事实表、维度表
2：数据库三范式
3：维度建模模型：雪花模型、星型模型

事实表、维度表

1
2
3
4
首先我们来看两个名词：事实表和维度表
什么是事实表呢？
事实表是指保存了大量业务数据的表，或者说保存了一些真实的行为数据的表
例如：销售商品所产生的订单数据

image-20230330173811777

1
2
3
4
5
什么是维度表呢？
首先说一下什么是维度
维度其实指的就是一个对象的属性或者特征，例如：时间维度，地理区域维度，年龄维度
这是维度的概念。
维度表里面存放的其实就是刚才我们所说的那些维度相关的信息。

image-20230330173934481

1
这是事实表和维度表的特点，大家最起码要能区分出来一个表是事实表还是维度表，否则在工作中别人提到这两个概念你还是一脸懵，那就尴尬了。

数据库三范式

1
2
3
4
5
6
7
8
9
接下来我们需要复习一下数据库中的三范式的特性，不知道大家还有没有印象，这个属于数据库相关的知识，如果大家系统的学习过类似于MySQL之类的关系型数据库的话，这块应该是有一些印象的。
其实严格意义上来说，关系型数据库的范式是有多种的
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
巴斯-科德范式(BCNF)
第四范式(4NF)
第五范式(5NF)
不过后面那几种不太常见，数据库设计一般满足第三范式就足够了，所以在这我们就分析一下前三种范式
第一范式(1NF)
1
2
3
4
它的意思是说数据库表的每一列都是不可分割的原子数据项
来看下面这个案例：
这里面存储的是学生信息
但是这里面的地址字段显然是不符合第一范式的，因为这里面的地址信息是可以拆分为省份+城市+街道信息的

image-20230330174354885

1
所以针对这个字段进行拆分，让这个表满足第一范式

image-20230330174431140

第二范式(2NF)
1
2
3
第二范式(2NF)表示在1NF的基础上，数据库表中每一列都和主键相关，不能只和主键的某一部分相关(针对联合主键而言)
也就是说一个表中只能保存一种类型的数据，不可以把多种类型数据保存在同一张表中
来看下面这个案例：

image-20230330174638394

1
2
3
4
这个表里面除了存储的有学生的班级信息，还有学生的考试成绩信息
根据我们刚才的分析，它是满足第一范式的，但是违背了第二范式，数据库表中的每一列并不是都和主键相关
所以我们为了让这个表满足第二范式，可以这样拆分：
拆成两个表，一个表里面保存学生的班级信息，一个表里面保存学生的考试成绩信息

image-20230330175233201

第三范式(3NF)
1
2
3
4
5
6
7
8
9
注意：满足第三范式（3NF）必须先满足第二范式（2NF）。

第三范式(3NF): 要求一个数据库表中不包含已在其它表中包含的非主键字段
就是说，表中的某些字段信息，如果能够被推导出来，就不应该单独的设计一个字段来存放(能尽量外键join就用外键join)。

很多时候，我们为了满足第三范式往往会把一张表拆分成多张表

来看下面这个案例
针对刚才满足了第二范式的表，其实还可以进行拆分

image-20230330175033146

1
2
这样就满足数据库的第三范式了。
我们在这分析这三种范式有什么意义吗？不要着急，往下面看

数据仓库建模方式

ER实体模型
1
2
3
4
数据仓库建模可以使用多种方式
1：ER实体模型，这种模型其实就是满足数据库第三范式的模型，这就是刚才我们为什么要分析数据库中的三范式了。

ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，不过这种方式在实际工作中不推荐使用。
维度建模模型
1
2
3
4
Ralph Kimball提出的数仓理论中，提出了维度建模，将数据仓库中的表划分为事实表和维度表。
基于事实表和维度表进行维度建模。
维度建模通常又分为星型模型和雪花模型，一会我们详细分析这两种维度建模模型。
维度建模是我们在构建数据仓库中常用的方式。
Data Vault模型
1
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。
Anchor模型
1
2
Anchor是对Data Vault模型做了更近一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型。
Data Vault模型和Anchor模型，这两种模型大家知道就行了，很少使用，如果大家感兴趣的话可以到网上查阅相关资料了解一下。

维度建模模型

1
2
3
4
5
6
7
下面详细分析一下维度建模模型

星型模型和雪花模型
星型模型和雪花模型主要区别就是对维度表的拆分，
对于雪花模型，维度表的设计更加规范，一般符合3NF；
而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率
先来看一下星型模型
星型模型

image-20230330180534808

1
2
3
4
5
这里面的中间的订单表是事实表，外面的四个是维度表。
这几个维度表，其实严格意义上来说，只能满足第二范式，是不满足第三范式的。
但是这样的好处是查询效率比较高，在查询的时候不需要关联很多张表。
缺点就是数据有冗余。
使用这个五角星代表星型模型还是比较形象的，因为针对事实表周边的这些维度表，外层就没有其它的表了。
雪花模型
1
接下来看一下雪花模型

image-20230330181059516

1
2
3
4
这个里面订单表是一个事实表，其余的都是维度表。
针对商品维度表外层又拆分出来了一个商品类目的维度表，这样拆分之后其实就满足第三范式了，但是这样就变的复杂了，后期在获取商品维度数据的时候，还需要关联这个商品类目维度表。
这里使用这个雪花代表雪花模型也是比较形象的，事实表周边会有一层维度表，这些维度表外层还可能会有多层维度表
那接下里我们针对这两种模型的优缺点进行一个总结
星型模型 VS 雪花模型
1
2
3
冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间

性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型违反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能比雪花模型高
1
2
那我们在实际工作中一般会选择哪种呢？
在实际工作中我们多采用星型模型，因为数据仓库主要是侧重于做数据分析，对数据的查询性能要求比较高，所以星型模型是比较好的选择，在实际工工作中我们会尽可能的多构建一些宽表，提前把多种有关联的维度整合到一张表中，后期使用时就不需要多表关联了，比较方便，并且性能也高。

数据仓库分层

为什么要分层

1
2
3
4
5
6
7
数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。对数据进行分层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控
详细来讲，主要有下面几个原因：
1. 清晰的数据结构：每一个分层的数据都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
2. 数据血缘追踪：简单来讲可以这样理解，我们最终给业务方呈现的是一个能直接使用的业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围，分层之后就很好定位问题，以及可以清晰的知道它的危害范围。
3. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少重复计算。
4. 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽业务的影响，不必改一次业务就重新接入数据。

数据仓库分层设计

1
那针对我们这里的数据仓库该如何分层呢？

image-20230330182319581

1
2
3
4
5
数据仓库一般会分为4层
1. ODS层：原始数据层，数据源中的数据，采集过来之后，原样保存。
2. DWD层：明细数据层：这一层是对ODS层的数据进行清洗，解决一些数据质量问题和数据的完整度问题。
3. DWS层：这一层是对DWD层的数据进行轻度聚合汇总，生成一系列的中间表，提升公共指标的复用性，减少重复加工，并且构建出来一些宽表，用于提供后续的业务查询。
4. APP层：根据业务需要，由前面三层的数据统计而出的结果(一般会使用数据明细层，数据汇总层的数据)，可以直接提供查询展现，一般会把APP层的数据导出到MySQL中供线上系统使用，提供报表展示、数据监控及其它功能。也有公司把这层称为DM层。虽然名字不一样，但是性质是一样的。
1
2
3
4
5
注意：针对DWD层在对数据进行清洗的时候，一般需要遵循以下原则
1. 数据唯一性校验(通过数据采集工具采集的数据会存在重复的可能性)
2. 数据完整性校验(采集的数据中可能会出现缺失字段的情况，针对缺失字段的数据建议直接丢掉，如果可以确定是哪一列缺失也可以进行补全，可以用同一列上的前一个数据来填补或者同一列上的后一个数据来填补，或者默认值)
3. 数据合法性校验-1(针对数字列中出现了null、或者-之类的异常值，全部替换为一个特殊值，例如0或者-1，这个需要根据具体的业务场景而定)
4. 数据合法性校验-2(针对部分字段需要校验数据的合法性，例如：用户的年龄，不能是负数)

数据仓库命名规范

1
2
3
4
5
6
7
8
我们在使用Hive实现数据仓库的时候该如何体现这些层次？
1. 针对数据仓库的每一层都在Hive中创建一个数据库，数据库的命名包含每一层的标识符
例如：针对ODS层可以在Hive中创建数据库 ods_mall，把同一层的表都放到一个数据库里面，方便管理
2. 针对每一层中的表名，在创建的时候可以使用每一层的标识符开头
例如：针对ODS层，创建的表名为：ods_user，这样方便后期使用，只要看到表名就可以知道这个表示哪一层的了。

针对一些临时表，我们可以在对应的分层中创建表名的时候，以_tmp结尾。
针对一些备份的表，可以在表名后面添加_bak。

典型的数据仓库系统架构

1
下图是一个典型的企业数据仓库系统，通常包含数据源、数据存储与管理、数据的访问三个部分

image-20230330201757040

1
2
3
4
5
6
7
数据源部分负责采集各种日志数据、业务数据，以及一些文档资料，将我们需要的这些数据加载到Hive中，构建数据仓库
数据仓库构建好了以后可以为很多服务提供数据支撑

例如：做数据报表，做OLAP数据分析，以及在做用户画像和数据挖掘的时候都是需要使用到数据仓库中的数据的

在实际工作中，数据仓库分为离线数据仓库和实时数据仓库
我们这个项目主要分析离线数据仓库，因为到现阶段为止我们主要学习了离线计算相关的技术框架。

项目需求分析

1
2
3
4
5
6
通过刚才对一个典型的企业数据仓库系统架构进行分析，我们发现，想要开发一个完整的数据仓库系统，至少需要以下这几个功能模块
1：数据采集平台，这个模块主要负责采集各种数据源的数据
2：数据仓库，这个模块负责数据存储和管理
3：数据报表，这个模块其实就是数据可视化展示了

通过这三个模块可以实现数据采集，构建数据仓库，最后基于数据仓库中的数据实现上层应用，体现数据仓库的价值。

本文标题:大数据开发工程师-第十二周 综合项目:电商数据仓库

文章作者:TTYONG

发布时间:2023年03月30日 - 17:03

最后更新:2023年06月18日 - 16:06

原始链接:http://tianyong.fun/%E5%A4%A7%E6%95%B0%E6%8D%AE%E5%BC%80%E5%8F%91%E5%B7%A5%E7%A8%8B%E5%B8%88-%E7%AC%AC%E5%8D%81%E4%BA%8C%E5%91%A8-%E7%BB%BC%E5%90%88%E9%A1%B9%E7%9B%AE-%E7%94%B5%E5%95%86%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93%E4%B9%8B%E7%94%A8%E6%88%B7%E8%A1%8C%E4%B8%BA%E6%95%B0%E4%BB%93.html

许可协议: 转载请保留原文链接及作者。

多少都是爱
0%