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_表名

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层

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

4.什么是范式（Normal Form）

1 定义

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

2 优点

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

为什么要降低数据冗余？

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

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

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

3 缺点

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

4 分类

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

5. 函数依赖

1 完全函数依赖

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

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

2 部分函数依赖

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

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

3传递函数依赖

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

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

6.三范式

1 第一范式（1NF）

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

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

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

2 第二范式（2NF）

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

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

3 第三范式

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

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

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

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

一.表的种类及其概念

1.实体表

2.维度表

3.事实表

二.数据同步策略

1.全量同步策略

2.增量同步策略

3.新增及变化策略

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

4.特殊策略

客观世界维度

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

日期维度

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

地区维度

省份表、地区表

数仓业务流程：

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

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

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

前两个flume节点：

从日志服务器采集数据

作为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，多目录