大数据项目之电商数据仓库简介

1.数仓分层
1.1为什么要分层

ODS：关系建模
DWD ：
数据清洗，过滤脏数据（去空值，把不符合要求的数据过滤），把数据分类，给某些数据添加必要字段。
维度建模
DWS需要按照主题建模，主题时一个分析问题的角度，圈定了一个分析的范围，计算出这个主题各种指标，而我们的指标主要都是汇总，在dws里面我们只汇总过去一天的数据。得到以天作为粒度的指标。。
DWT ：实际工作中，需要算某个app，过去一天，过去一周，过去一个月，过去一季度，过去一年。。。上线以来的新增用户。
ADS：给领导，给产品经理需要各种统计结果，直接从dws和dwt很快的得到。
1.2数据集市与数据仓库概念

建数仓库有俩种思想，由下至上，由上至下的思想。
数仓命名规范
表命名
1.3ODS层命名为ods_表名
DWD层命名为dwd_dim/fact 表明(dim指的是维度表，fact指的是事实表）
dwd_dim_user dwd_fact_pay ---->dwd_表名
DWS层命名为dws_表名
DWT层名为dwt_表名
ADS层命名为ads_表名
临时表命名为xxxx_tmp,为了得到一些结果临时数据，随时的删除，一般建的是内部表。
用户行为表，以.log为后缀。如果不加就是db
1.4 脚本命名
数据源_to_目标_db/log.sh，命名风格是蛇形风格，单词之间都是小写，单词1_单词2…
用户行为脚本以log；业务数据脚本以db为后缀。
2.数仓理论
2.1范式理论
2.1.1范式概念
定义：
范式可以理解为设计一张数据表的表结构，符合的标准级别。规范和要求
优点
关系型数据库设计时，遵行一定的规范要求，目的在于降低数据的冗余性。
为什么要降低数据冗余性？
1.十几年前，磁盘很贵，为了减少磁盘存储。
2.以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
3.一次修改，需要修改多个表，很难保证数据一致性。
缺点：
范式的缺点时获取数据时，需要通过join拼接出最后的数据。主要是因为这个业务数据主要对单条或者几条数据的随机读写，这样join成本就不会那么高。而我们大数据里面是把过去一天（周，月。。）所有的数据来处理，如果还有大量的join就会导致处理速度非常的慢。。
分类：
目前业界范式有：第一范式（1NF），第二范式（2NF），第三范式（3NF），巴斯-科德范式（BCNF),第四范式（4NF），第五范式（5NF）。
2.1.2函数依赖

2.1.3三范式区分



2.2关系建模与维度建模
当今的大数据处理大致可以分为俩大类：联机事务处理OLTP(on-line transaction processing),联机分析处理OLAP（On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用，主要是基本的，日常事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，二者的差别对比下，下表所示。

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量数据进行汇总
写特性	随机，低延时写入用户的输入	批量导入
使用场景	用户，JavaEE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据模块	GB	TB到PB

2.2.1关系建模

关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散，零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系建模主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

维度建模如图所示，主要应用与OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据，大大减少了join操作，提升查询的执行效率。
关系建模虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这回大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成俩种：事实表和维度表俩种。
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 无
维度表为什么要这么设计？
维度表是看待事实的角度，我们在设计的时候并不知道后续的分析业务有哪些，为了减少关联操作（join），提升性能，就会在一个维度表里面搞很多的字段。
2.3.2事实表
事实表中的每行数据代表了一个业务事件（下单，支付，退款，评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数，个数，件数，金额等），例如，订单事件中的下单金额。
每一个事实表的行为包括：具有可加性的数值型的度量值，与维度相连接的外键，通常具有俩个或者俩个以上的外键，外键之间表示维度之间多对多的关系。
事实表的特征：
非常的大
内容相对的窄，列数较少，具体多少看场景
经常内容发生变化，每天会新增很多
1）事务类型事实表
以每个事务或者事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦书事务被提交，事实表数据被插入，数据就不再进行改变，其更新方式为增量更新。
2）周期型快照事实表
周期型快照事实表中不会保留所有数据（不会保留每条数据的明细），只保留固定时间间隔的数据，例如每天或者每月的销售饿，或每月的账户余额等，中间的变化明细不关心，每天做一个全量。加入购物车是一个典型的周期性快照事实表，我们后续统计的主要是某个商品被加入了购物车多少件，多少人把这个商品加入了购物车，我们并不需要关心用户是怎么样把这个商品加入购物车的。
3）累积性快照事实表
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累计或者存储订单从下订单开始，到订单商品被打包，运输，和签收的各个业务的时间点，数据来跟踪订声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
我们的事实表中有一个收藏表，这个表可以做成事务类型事实表，但是我们设计成积累型快照事实表，这样加大了难度。
小结：
在我们的实际数仓的场景中，很多情况都是汇总操作，我们在汇总的时候，往往会有一个观察这个问题的角度，比方时间（日，周，月，季度，年），地区（省，市，县），用户（性别，年龄区间等），类别等，这些都是维度，如果这些直接关联在事实表周围，需要获取的时候，一次join就能搞定，比较方便。