假期数仓项目笔记

数仓项目笔记

sqoop(将数据从传统关系型数据库导出到大数据平台上)

测试Sqoop是否能够成功连接数据库

bin/sqoop list-databases --connect jdbc:mysql://hadoop102:3306/ --username root --password xxxxxx(mysql密码)

将 mysql 中gmall库的user_info表中id,login_name(1<=id<=20)数据导入到HDFS的/test路径

bin/sqoop import \

–connect jdbc:mysql://hadoop102:3306/gmall \

–username root \

–password 000000 \

–query ‘select id,login_name from user_info where id>=1 and id<=20 and $CONDITIONS’ \

(注:如果有需要解析的变量如$max 为防止错误解析需要用单引号)

–target-dir /user_info \

–delete-target-dir (如果输出路径已经存在则先删除)

–fields-terminated-by ‘\t’ \

–num-mappers 2 \

–split-by id

(注: \ 为换行符)

数据的同步策略

1.全量同步:同步完整数据 适用于表数据量不大且每天既有新数据插入又有旧数据修改的场景

2.增量同步:同步新增加的数据 适用于表数据量大，且每天只有新数据插入的场景

3.新增及变化同步:同步新增加的数据和变化的数据,并和数仓中已存在未发生变化的数据进行整合 适用于表数据量大且每天既有新数据插入又有旧数据修改的场景

4.特殊同步:不会发生变化的表,只同步一次

全量同步命令:

bin/sqoop import \

–connect jdbc:mysql://hadoop102:3306/gmall \

–username root \

–password 000000 \

–query ‘select * from user_info where (date_format(create_time,’%Y-%m-%d’)=‘2020-06-15’ or date_format(operate_time,’%Y-%m-%d’)=‘2020-06-15’) and $CONDITIONS’ \

–target-dir /order_info/2020-06-14 \

–delete-target-dir \

–fields-terminated-by ‘\t’ \

–num-mappers 2 \

–split-by id

增量同步命令:

bin/sqoop import \

–connect jdbc:mysql://hadoop102:3306/gmall \

–username root \

–password 000000 \

–query ‘select * from user_info where (date_format(create_time,’%Y-%m-%d’)=‘2020-06-15’ and $CONDITIONS’ \

–target-dir /order_info/2020-06-14 \

–delete-target-dir \

–fields-terminated-by ‘\t’ \

–num-mappers 2 \

–split-by id

获取日期替换2020-06-15

do_date=`date- d ‘-1 day’+%F`

Hive

配置hive

1.将MySQL的JDBC驱动拷贝到Hive的lib目录下

2.配置Hive/conf的hive-site.xml文件

启动hive步骤

1.登录mysql

mysql mysql -uroot -p123456

2.新建hive元数据库

mysql> create database metastore;

mysql> quit;

3.初始化Hive元数据库

[atguigu@hadoop102 conf]$schematool -initSchema -dbType mysql -verbose

hive报错

https://www.cnblogs.com/lfri/p/13099126.html

数仓分层

分层模型

ODS层：存放原始数据 不做处理

DWD层：对OBS层数据清洗(去除空值，脏数据，超出极限范围的数据)、脱敏等。

DIM层：保存维度数据(对业务事实的描述信息)

DWS层：以DWD层为基础，按天对业务事实(下单、支付、退单退款等)进行轻度汇总

DWT层：以DWS层为基础，对最近N天的数据进行累积汇总

ADS层：为各种统计报表提供数据

数仓命名规范

表命名

Ø ODS层命名为ods_表名

Ø DIM层命名为dim_表名

Ø DWD层命名为dwd_表名

Ø DWS层命名为dws_表名

Ø DWT层命名为dwt_表名

Ø ADS层命名为ads_表名

Ø 临时表命名为tmp_表名

脚本命名

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

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

表字段类型

Ø 数量类型为bigint

Ø 金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位

Ø 字符串(名字，描述信息等)类型为string

Ø 主键外键类型为string

Ø 时间戳类型为bigint

范式理论

采用范式可以降低数据冗余

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

完全函数依赖：

通过AB可以得出C，但AB单独得不出C

部分函数依赖：

通过AB可以得出C，通过A或B也能得出C

传递函数依赖：

通过A得到B，通过B得到C，但C得不到A

第一范式：属性不可切割

第二范式：不能存在部分函数依赖

第三范式：不能存在传递函数依赖

关系建模与维度建模

关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单，故查询简单，查询效率较高。

维度表和事实表（重点）

维度表

一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。

维表的特征：

Ø 维表的范围很宽（具有多个属性、列比较多）

Ø 跟事实表相比，行数相对较小：通常< 10万条

Ø 内容相对固定：编码表

事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等）

事实表的特征：

Ø 非常的大

Ø 内容相对的窄：列数较少（主要是外键id和度量值）

Ø 经常发生变化，每天会新增加很多。

1）事务型事实表

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

2）周期型快照事实表

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

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

3）累积型快照事实表**

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

维度模型分类

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

数据仓库建模（绝对重点）

ODS层

1）HDFS用户行为数据

2）HDFS业务数据

3）针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

（1）保持数据原貌不做任何修改，起到备份数据的作用。

（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）

（3）创建分区表，防止后续的全表扫描

DIM层和DWD层

DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：

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

（1）选择业务过程

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

（2）声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

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

支付事实表中一行数据表示的是一个支付记录。

（3**）确定维度**

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。

（4**）确定事实**

此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

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

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√				运费/优惠金额/原始金额/最终金额
订单详情	√	√	√	√	√	√	件数/优惠金额/原始金额/最终金额
支付	√	√	√				支付金额
加购	√	√		√			件数/金额
收藏	√	√		√			次数
评价	√	√		√			次数
退单	√	√	√	√			件数/金额
退款	√	√	√	√			件数/金额
优惠券领用	√	√			√		次数

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

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

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

DWS层与DWT层

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

1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额

2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

​ 那怎么设计能避免重复计算呢？

针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

3）总结：

（１）需要建哪些宽表：以维度为基准。

（２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。

（３）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

ADS层

​ 对电商系统各大主题指标分别进行分析。