数据仓库总结

1.数据仓库

1.1 什么是数据仓库

数据仓库，英文名为Data Warehouse，简写为DW或DWH。数据仓库，是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

1.2 数据仓库的四个特点

面向主题：数据仓库是按照一定的主题来组织，仅存储与主题相关的数据。主题是指用户在构建数仓时考虑决策时所关注的重点方面，方便以后的数据分析。

集成：数仓的数据来源是任意的，可以是操作型数据库，也可以是网络爬虫，这些数据经过加工与集成，统一成新的数据源。

随时间变化：数仓每天都会从不同数据渠道获取大量数据，关键数据会隐式或显式的基于时间变化。

数据相对稳定：数据进入后一般只进行查询操作，不会进行删改。

1.3 数仓分层

1.ODS层：原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理（同时起到备份的作用）

2.DWD层：明细数据层，每个地方叫法可能不同，结构和粒度与原始表保持一致，DWD层对ODS层数据进行清洗（去除空值、脏数据、超过极限范围的数据（比如金额出现负值））。

可能会用到的ETL：Hive SQL（hql）、MR、Spark sql、Python、kettle（专门做etl,拖拽+sql，比较注重业务逻辑，但外包比较多）

3.DWS层：服务数据层，以DWD为基础，按天进行轻度汇总。比如用户行为宽表，记录了用户一天下单数、评论数等。

4.DWT层：数据主题层，以DWS为基础，按主题进行汇总。比如上面的用户行为宽表是记录了每天的下单数、评论数等，那这里就可以记录用户在今年内下单的总数之类的购买主题，属于某个整体范围。

5.ADS层：数据应用层，为各种统计报表提供数据。可以从其他层去运算。

1.4 数仓为什么要分层

从数据源采集时，经过ETL的过程，然后在数仓中要经过分层，可以比喻成TCPip协议，分成多层，每一层处理一件事。为公司决策，提供数据支持的。

（1）把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题。

（2）减少重复开发：规范数据分层，通过中间层数据能够减少极大的重复计算，增加计算结果的复用性。

（3）隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。比如前面说的ODS层数据更像是备份数据，那么后面的数据层就可以根据需要随意统计数据，其他层发生异常，只要ODS层的数据还在就能取到原始数据，使真实数据与统计数据隔离开。

1.4.1数仓命令规范

表命名：

-ODS层命名为ods_表名

-DWD层命名为dwd_dim/fact_表名（维度表和事实表）

-DWS层命名为dws_表名

-DWT层命名为dwt_表名

-ADS层命名为ads_表名

-临时表命名为xxx_tmp

-用户行为表，以log为后缀

脚本命名：

数据源 _to _目标 _db/log.sh

1.5 数据仓库与数据库的区别

功能	数据仓库	数据库
数据范围	存储历史的、完整的、反应历史变化的数据	当前状态数据
数据变化	可添加、无删除、无变更、反应历史变化	支持频繁的增删改查
应用场景	面向分析、支持战略决策	面向业务流程
设计理论	伪范式、适当冗余	遵照范式（一、二、三范式），避免冗余
处理量	非频繁、大批量、高吞吐、有延迟	频繁、小批次、高并发、低延迟

2.关系建模与维度建模

2.1 关系建模

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

2.2 维度建模

维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

**关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。

**所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

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

2.2.1星型模型

标准的星型模型周围只有一层，即一个事实表周围只有一层维度表与之对应。

2.2.2雪花模型

雪花模型的维度层级比星型模型多，雪花模型比较靠近3NF，但无法完全遵守，因为遵守3NF的性能成本太高。

2.2.3 星座模型

星座模型与前两个模型的区别在于事实表的数量，星座模型中的事实表要多。而且事实表之间也有可能会共享维度表。

2.2.4 模型的选择

首先星座与否与数据和需求有关系，与设计无关，不用抉择。

星型还是雪花，取决于性能优先，还是灵活优先。

实际开发中，不会只选择一种，根据情况灵活组合，甚至并存。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少join就是减少shuffle,性能差别很大。

3.数仓建模

3.1 数仓建模的目的

为什么要进行数据仓库建模？大数据的数仓建模是通过建模的方法更好的组织、存储数据，以便在 性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑

访问性能：能够快速查询所需的数据，减少数据I/O

数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数 据系统中的存储成本和计算成本

使用效率：改善用户应用体验，提高使用数据的效率

数据质量：改善数据统计口径的不一致性，减少数据计算错误 的可能性，提供高质量的、一致的数据访问平台3。

3.2 ODS层

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

数据采用压缩存储，减少磁盘空间；

创建分区表，防止全盘扫描

3.3 DWD层

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

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

3.4 DWS层

统计各个主题对象的当天行为，服务于DWT层的主题宽表，以及一些业务明细数据，应对特殊需求（例如，购买行为，统计商品复购率）。

3.5 DWT层

以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。

3.6 ADS层

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

---

1.什么是范式（Normal Form）？

1.1 定义

按照教材定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。这样的定义太过晦涩，简单点来说，就是一张数据表的表结构所符合的某种设计标准的级别和要求。

1.2 优点

设计关系型数据库，必须遵照一定的准则，目的在于降低数据的冗余。

为什么要降低数据冗余？

为了减少磁盘存储，十几年前，磁盘是十分昂贵的

以前没有分布式系统，多存储数据就得加磁盘

一次修改，需要修改多个表，很难保证数据一致性

1.3 缺点

获取数据时，需要通过多表连接才能得出最后数据。

1.4 分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。一般说来，数据库只需满足第三范式（3NF）就行了。

2. 函数依赖

2.1 完全函数依赖

设X,Y时关系R的两个属性集合，X’是X的真子集，存在 X → Y，每一个X’都有X’!→ Y，则称Y完全依赖于X。记作：

比如通过（学号，课程）退出分数，但是单独用学号无法推出分数，那么可以说：分数完全依赖于（学号，课程）。

2.2 部分函数依赖

设Y依赖于X，但不完全依赖X，则Y部分依赖于X，记作：

比如通过（学号，课程）推出姓名，但也可以直接通过学号推出姓名，所以姓名部分依赖于（学号，课程）。

2.3传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合，存在X→ Y（Y！→ X），Y→ Z,则称Z传递依赖于X。记作

比如：学号推出系名，系名推出系主任，但是系主任推不出学号，系主任主要依赖于系名。这种情况可以说：系主任传递依赖于学号。

3.三范式

3.1 第一范式（1NF）

第一范式的核心要求：属性不能分割。

很明显，上图所示的表的设计师不符合第一范式的，商品列中的数据不是原子数据项，是可以进行分割的，因此对表进行修改，让表符合第一范式，结果如下：

在任何一个关系数据库中，第一范式[1NF]是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。例如在MySQL,Oracle,SQL Server中建表的时候，如果表的设计不符合这个要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的表，一定是符合第一范式的。

3.2 第二范式（2NF）

满足第二范式必须先满足第一范式。第二范式的核心要求：不能存在部分依赖，即确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

以上表就明显存在部分依赖，比如，这张表的主键是（学号，课程），分数确实完全依赖于主键，但是姓名并不完全依赖于主键。所以，我们应当去掉部分依赖。

3.3 第三范式

满足第三范式必须先满足第二范式。第三范式的核心要求：不能存在传递函数依赖。即确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

在下边这张表中，存在传递函数依赖：学号—>系名—>主任，但是系主任推不出学号。

因此这张表可以再次拆分：

---

数据仓库——数据同步策略

一.表的种类及其概念

1.实体表

2.维度表

3.事实表

二.数据同步策略

1.全量同步策略

2.增量同步策略

3.新增及变化策略

4.特殊策略

一.表的种类及其概念

1.实体表

一般是指一个现实中存在的业务对象，实体表它放的数据一定是一条条客观存在的事物数据，比如用户，商家，商品等（某东上的某某人参丸就是一个实体）

2.维度表

一般是指业务中的一些状态，代码的解释表（也称为码表）。维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述。

维度表还可以分为一般维度表和固定维度表。

一般维度表：数据是可以增加以及变化的。比如：商品分类，时间等

固定维度表：数据是固定不变的。比如：性别，订单状态等。

3.事实表

事实表其实质就是通过各种维度和一些指标值得组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。

事实表还可以分为周期型事实表、事务型事实表和累计快照事实表。

事务型事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。由于事实表具有稀疏性质 ，因此只有当天数据才会进入 当天的事实表中，相当于每个分区里面都是每天的数据，不包含之前的数据1。比如：交易流水、操作日志、出入库记录等。

事实表一般围绕着度量来建立，当度量产生的时候，事实记录就生成了。度量可以是销售数量、交易流水值、月末节余等数值。如果同时生成多个度量值的话，我们可以在一个事实表中建立多个事实。当我们的事实表中的事实比较多时，有可能多个事实不同时发生，如果同时生成的几率很小，我们称之为稀疏事实表（Sparse Facts）2。

周期型快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。比如订单表，其中有一个字段，订单状态，这个会周期性变化。 再比如，请假、贷款申请，随着批复状态在周期性变化；销售日快照表、库存日快照表等。

周期快照表没有粒度的概念，取而代之的是周期+状态度量的组合，如历史至今的订单总数，其中历史至今是 一个周期，订单总数是度量。

累计型快照事实表

周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。再比如用户的修改记录信息。

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

	事务型事实	周期快照事实	累积快照事实
时间/时期	离散事务时间点	规律性时间间隔	时间跨度较短的多个时点
粒度	每行代表一个交易事件	每行代表一个时间周期的一个实体	每行代表一个实体的生命周期
事实表加载	新增	新增	新增和修改
事实表更新	不更新	不更新	新事件产生时更新
时间维度	业务日期	时期末	多个业务过程的完成日期
事实	事务事实	累积事实	业务过程事实

二.数据同步策略

1.全量同步策略

每日全量，每天存储一份完整数据，作为一个分区。适用于表数据不大，且每天既有新数据插入，也会有旧数据修改的场景。

例如：编码字典表，品牌表，商品分类表，优惠表，活动表，商品表，加购表，SPU表等。

2.增量同步策略

每天存储一份增量数据，作为一个分区。适用于表数据量大，且每天只有新数据插入的场景。例如：退单表，订单状态表，支付流水表，订单详情表，商品评论表等。

3.新增及变化策略

每日新增及变化，就是存储创建时间和操作时间都是今天的数据。适用场景为表的数据量大，既会有新增，又会有变化。例如用户表、订单表、优惠券领用表等。

4.特殊策略

客观世界维度

没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以只存一份固定值。

日期维度

日期维度可以一次性导入一年或若干年的数据。

地区维度

省份表、地区表。

---

数仓分层：

数仓业务流程：

公共数据：启动日志数据（启动时的数据）

业务数据：事件日志数据（ 用户点击等行为）

埋点：js,获得所有点击动作

前两个flume节点：

1. 从日志服务器采集数据

2. 作为kafka生产者，向kafka传输数据

第3个flume节点：

       1.作为kafka消费者，从kafka获取数据

       2.将获得的数据存入hdfs

Flume:核心概念agent

Agent内部分为3个模块：source、channel、sink

1.source：数据源，一个flume源头。输入 RPC、文件、exec、syslog

2.channel：存储池:消息缓存

3.sink：把数据（event事件）放置到外部的数据介质上。 输出 hdfs、hbase、kafka、Flume、DB

拦截器作用：区分上述两个数据

1.ETL拦截器（轻度清洗）： etl(抽取、转换、加载)，过滤json格式不对、数据不全

2.类型拦截器：分类

flume conf文件编写步骤：

1.先定义三个名字

2.依次写source、channel、sink

3.channel通过名字连接souce、sink

断点重传：TAILDIR，多目录