一、数仓分层

1.2.1 FLUME日志采集流程

1.2.2 日志的结构

目标数据: 页面数据、事件数据、曝光数据、启动数据、错误数据
页面: 访问时间、停留时间
事件: 应用内一个操作行为
启动:
错误:

1.2.3 买点数据日志结构

日志结构分为两种: 普通页面埋点日志，启动日志

1.3.1 同步策略

全量同步、增量同步、新增及变化同步
增量: mysql中的数据只会增加不会变化
新增及变化同步: 既有新增又有变化

1.4.1 电商常识

SKU[Stock Keeping Unit]: 库存量基本单位
SPU[Standard Product Unit]: 商品信息聚合的最小单位

1.5 电商系统表结构

1.1 为什么要分层

一、数据仓库分层

二、数据库为什么要分层

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

数据集市（Data Market），现在市面上的公司和书籍都对数据集市有不同的概念。
数据集市则是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级的，一般只能为某个局部范围内的管理人员服务。
数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段。

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.1 范式理论[应用于关系建模]

  2.1.1 范式概念

1. 定义

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

1. 优点

采用范式，可以降低数据的冗余性。
为什么要降低数据冗余性？

1. 十几年前，磁盘很贵，为了减少磁盘存储。
2. 以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
3. 一次修改，需要修改多个表，很难保证数据一致性
   1. 缺点

范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

1. 分类

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

2.1.2 函数依赖

1、完全依赖函数:
设X，Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。记做：XF -> Y。
比如通过，(学号，课程) 推出分数 ，但是单独用学号推断不出来分数，那么就可以说：分数完全依赖于(学号，课程) 。
即：通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB。
2、部分函数依赖
假如 Y函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记做：XP -> Y。
比如通过，(学号，课程) 推出姓名，因为其实直接可以通过，学号推出姓名，所以：姓名 部分依赖于 (学号，课程)
即：通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。
3、传递函数依赖
传递函数依赖：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。记做：XT -> Y。
比如：学号 推出 系名 ， 系名 推出 系主任， 但是，系主任推不出学号，系主任主要依赖于系名。这种情况可以说：系主任 传递依赖于 学号
即：通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A。

2.1.3 三范式区分

1、第一范式1NF核心原则就是：属性不可切割
2、第二范式2NF核心原则：不能存在 “部分函数依赖”
3、第三范式 3NF核心原则：不能存在 “传递函数依赖”

2.2 关系建模与维度建模[维度建模是当前的主流]

  关系建模和维度建模是两种数据仓库的建模技术。关系建模由Bill Inmon所倡导，维度建模由Ralph Kimball[**数据仓库工具箱**]所倡导。

2.2.1 关系建模

  关系建模将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。关系模型如图所示，从图中可以看出，较为松散、零碎，物理表数量多。<br />      关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

2.2.2 维度建模

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

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

2.3.1 维度表

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

• 维表的范围很宽（具有多个属性、列比较多）
• 跟事实表相比，行数相对较小：通常< 10万条
• 内容相对固定：编码表 | 日期ID | dayofweek | dayofyear | 季度 | 节假日 | | —- | —- | —- | —- | —- | | 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）累积型快照事实表[]
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

2.4 维度模型分类

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

2.4.1 星型模型

2.4.2 雪花模型

  雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉及多级。

2.5 数据仓库建模[绝对重点]

2.5.1 ODS层

1. HDFS用户行为数据
2. HDFS业务数据
3. 针对HDFS上的用户行为数据和业务数据，我们如何规划处理？
   1. 保持数据原貌不做任何修改，起到备份数据的作用。
   2. 数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
   3. 创建分区表，防止后续的全表扫描

2.5.2 DIM层和DWD层

  DIM层DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。<br />      维度建模一般按照以下四个步骤：<br />**            选择业务过程→声明粒度→确认维度→确认事实**<br />**1、选择业务过程**<br />      在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。<br />**2、声明粒度**<br />      数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。<br />      声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择**最小粒度**，以此来应各种各样的需求。<br />**典型的粒度声明如下：**<br />      订单事实表中一行数据表示的是一个订单中的一个商品项。<br />      支付事实表中一行数据表示的是一个支付记录。<br />**3、确定维度[确定事实表的一类字段是什么]**<br />      维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。<br />      确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。<br />**4、确定事实**<br />      此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。<br />      在DWD层，以**业务过程**为建模驱动，基于每个具体业务过程的特点，构建**最细粒度**的明细层事实表。事实表可做适当的宽表化处理。<br />      事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

  至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。<br />      DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。<br />      DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

2.5.3 DWS层和DWT层

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

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

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

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

2. 总结：

1. 需要建哪些宽表：以维度为基准。
2. 宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
3. DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（１５天、３０天、６０天）的下单次数、下单金额等。

   2.5.4 ADS层

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

   三、数仓环境搭建

   四、数仓搭建 - ODS层

   五、数仓搭建 - DIM层

   六、数仓搭建 - DWD层

   七、数仓搭建 - DWS层

   八、数仓搭建 - DWT层

   九、数仓搭建 - ADS层

   十、全流程调度