目录
一 数据仓库概述
1.1 什么是数据仓库
数据仓库 (Data Warehouse) 是一个面向主题的 (SubjectOriented)、集成的 (Integrated) 、相对稳定的 (Non-Volatile) 、反映历史变化的 (Time Variant) 数据集合，用于支持管理决策(Decision Making Support) 和信息的全局共享(Global Sharing of Information)。 其主要功能是将组织透过资讯系统之联机事务处理 (OLTP) 经年累月所累积的大量资料， 透过数据仓库理论所特有的资料储存架构，作一有系统的分析整理，以利各种分析方法如联机分析处理 (OLAP) 、数据挖掘 (Data Mining) 之进行，并进而支持如决策支持系统 (DSS) 、主管资讯系统 (EIS) 之创 建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境 变动，帮助建构商业智能 (BI) 。
1.2 数据仓库的作用
整合公司所有业务数据，建立统一的数据中心
产生业务报表，用于作出决策
为网站运营提供运营上的数据支持
可以作为各个业务的数据源，形成业务数据互相反馈的良性循环
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果
开发数据产品，直接或间接地为公司盈利
1.3 数据仓库的特征
1. 数据仓库的数据是面向主题的
2. 数据仓库的数据是集成的
3. 数据仓库的数据是非易失的
4. 数据仓库的数据是随时间不断变化的
1.3.1 面向主题的特征
主题（ Subject ） ：特定的数据分析领域与目标。
主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供应是否及时，以及材料质量状况等。 数据仓库是面向分析、决策人员的主观要求的，不同的用户有不同的要求，同一个用户的要求也会随时 间而经常变化，因此， 数据仓库中的主题有时会因用户主观要求的变化而变化的 。
面向主题划分如下：
数据仓库面向在数据模型中已经定义好的公司的主要主题领域。
典型的主题领域包括顾客、产品、订单和财务 或是其他某项事务或活动。
基本主题：
教育机构：学生、讲师、班主任、课程等
电商行业：运营、流量、价值、商品、市场、风控、销售等
传统行业：供应商、商品、客户、仓库等主题域
主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题 域。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。 主题边界的划分应该按照以下规则来进行定义划分。 首先数据仓库中逻辑模型根据业务划分为多个主题域,主题域下面会涉及具体的实体表,维表以及关系实体,这 些划分可以按照下面规则来进行划分。
a:每个主题域包含一个主要业务概念;
b:每个主题域包含一个主要交易业务概念,用一个或几个核心实体来表述。
c:主题域与主题域之间的核心实体不能重叠,核心实体间的关系实体则可以出现在两个主题域内;
d:每个主题域中包含几个关键的核心实体,且这几个核心实体间具有直接的关联关系。
主题域的另一种定义是：对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主 题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部 分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓 库的设计人员共同完成。1.3.2 集成的特征
集成性是指数据仓库中数据必须是一致的。数据仓库的数据是从原有的分散的多个数据库、数据文
件和数据段中抽取来的，数据来源可能既有内部数据又有外部数据。
数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，因此
数据仓库中的数据必须从多个数据源中获取，这些数据源包括多种类型数据库、文件系统以及
Internet 网上数据等，它们通过数据集成而形成数据仓库中的数据。
集成的方法：
统一： 消除不一致的现象
综合： 对原有数据进行综合和计算
集成需要考虑的问题：
数据格式
计量单位
数据代码含义混乱
数据名称混乱
1.3.3 非易失
数据仓库中的数据是经过抽取而形成的分析型数据，不具有原始性，主要供企业决策分析之用， 执
行的主要是 ‘ 查询 ’ 操作，一般情况下不执行 ‘ 更新 ’ 操作 。同时，一个稳定的数据环境也有利于数据分
析操作和决策的制订。
面向应用的事务数据库需要对数据进行频繁的插入、更新操作，而对于数据仓库中数据的操作 仅限
于数据的初始导入和记录查询 。
1.3.4 随时间不断变化
数据仓库以维的形式对数据进行组织， 时间维是数据仓库中很重要的一个维度 。并且数据仓库中的
数据时间跨度大，从几年甚至到几十年，称为历史数据。
数据仓库中的数据必须以一定时间段为单位进行统一更新。
数据变化方式 :
– 不断增加新的数据内容
– 不断删去旧的数据内容
– 更新与时间有关的综合数据
数据的生命周期与行业、自己本身的需求有关，比如金融业 “ 在设计银行数据保存周期策略时，最常用的经验法则是7 年和 13 个月规则 ”
基础数据区里面通过历史表（拉链表）来保存重要信息的历史数据，一般客户类、账户类等信息要保留7年，交易类流水类信息要保留至少 13 个月以上。除此之外，重要代码、主数据也要通过历史表保存历史。
根据业务决定数据的生命周期，比如电商交易频繁的可能是2 年，保险行业交易比较少的 5 年。太老的 数据对于数据分析没多大作用，你想10 年前的电商交易数据对于现在的电商能有多大帮助，价格、产品、用户都已经完全不同了如果数据仓库是仅用于分析的话（我看好多地方建立的数据仓库仅用于统计分析，对于数据挖掘基本都 没有用），如果有大量的数据挖掘的话，那么数据多些对于结果越精确。（当然，前提是你的历史数据 质量不太差的情况下） 现在存储设备越来越便宜，如果不是数据量很惊人的话，一般是不用删除或导出的，因为导出后是需要管理的。
数据仓库的概念确立之后，有关数据仓库的实施方法、实施路径和架构等问题引发了诸多争议。
1994 年前后，实施数据仓库的公司大都以失败告终，导致数据集市的概念被提出并大范围运用，其代表人物是Ralph Kimball 。
1.4 数据仓库与数据库的区别
1. 着重点不同：
- 数据库着重于数据的业务处理（数据的增删改）、也就是数据的OLTP处理
- 数据仓库着重于数据的分析，通常都是面向某一个行业，领域（查询），也就是数据的OLAP处理
2. 存储结构不同：
- 数据库是面向行式存储。
- 数据仓库是面向列式存储，利于查询和分析. 数据仓库也可以称之为"分析型数据库"
3. 使用的用户不同
- 数据库主要是业务人员，人数相对大。会经常进行读和写操作。每次读和写的数据量都相对来说少。
- 数据仓库主要是管理人员，人数相对少。会经常进行读操作，每次读取的数据量巨大
4. 使用的工具不同
- 数据库主要用的是oracle、mysql、sqlserver等传统关系型数据库
- 数据仓库主要用的是hive、mr、spark、flink
5. 数据的存储位置不同
- 数据库的数据存储到本地文件系统，比如windows、linux、mac
- 数据仓库的数据存储到分布式文件系统，比如hdfs，hbase
6. 响应时间不同
- 数据库的反映时间是非常短的，毫秒级别
- 数据仓库的反映时间较长，秒级别，分钟级别 1.5 OLTP与OLAP的区别
OLAP: (online Analytical Processing,在线分析处理)
主要就是用来针对数据进行分析的，为管理层服务
OLTP: (online transaction Processing,在线事务处理)
主要就是用来快速的进行业务处理。公司内部的所有人，以及能使用客户端的客户
OLAP细分以下种类：
ROLAP 表示基于关系数据库的OLAP实现（Relational OLAP）
MOLAP 表示基于多维数据组织的OLAP实现（Multidimensional OLAP）
HOLAP 表示基于混合数据组织的OLAP实现（Hybrid OLAP）二、数据仓库的架构
三范式的概念：
第一范式：1NF
保证字段的数据不可再分，确保原子性。
比如某一个表中有address字段，里面存储的数据包括省份城市街道，就不满足第一范式
如果想要满足第一范式：应该将address拆成三个字段province,city,street
第二范式：2NF, 前提必须满足第一范式
在一张表中的所有字段都应该和主键字段有直接关系
反例： table1（职工号，姓名，职称，项目号，项目名称） 这个表里有职工信息，还有项目信息 不满足第二范式
上述table1表，应该拆分成如下两张表
职工表(职工号，姓名，职称) 项目表(项目号，项目名称)
第三范式：3NF
需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
反例：table1(订单编号, 订单项目，负责人，业务员，订单数量，客户编号，客户名称，所属公司，联系方式)
存在着联系方式--->客户编号--->订单编号
应该按照下图所示维护两张表
总结： 就是更加细粒度的管理表数据。
1. 优点：数据不冗余
2. 缺点： 表之间存在着大量的join。2.1 两种不同的架构思想简介
2.1.1 bill inmon提出的架构思想
2.1.2 kimball 提出的架构思想
2.2 数据仓库如何分层
数据仓库代表的是一种对数据管理和使用的方式。它是一整套包括建模、ETL、调度在内的完整的理论体系流程，数据仓库在构建过程中通常要分层处理，有以下原因
2.2.1 分层的原因
1. 数据结构清晰
每一层的数据都有自己的作用，
第一层是原始数据，第二层是字段统一格式，统一单位的数据，第三层是微聚合(每天的聚合)，第四层最终指标的一个分析结果存储
2. 方便血缘追踪
当某一张表的数据出了问题，可以向上追述，再次执行一次查询和动态加载。
可以向下追述，对其他什么表产生了影响
3. 减少重复开发
某一层的数据维护好后， 下一层的数据来源只需要从这一层查询和存储就行。可以重复进行。可以做其他的分析。
4. 复杂问题简单化
5. 屏蔽原始数据的异常
数据仓库的数据具有稳定性。某一层的数据不应该实时变化的。如果不分层，原始数据可能会经常发生变量，那么指标结果就会不断的变化。2.2.2 分层的价值
1. 高效的数据组织形式【易维护】
2. 时间价值【高性能】
3. 集成价值【简单化】
4. 历史数据【历史性】2.2.3 如何分层(重点)
数据仓库的常见分层有三层：数据操作层(ODS)、数据仓库层(DW)、数据集市层(DM)、另外有一个维度层(DIM). 实际情况要根据公司的需求而定。
2.2.3.1 ODS层（数据操作层）
存储采集过来的源数据，尽量什么都不做。与源数据保持一致。这一层面的数据还具有鲜明的业务数据库的特征，甚至还具有一定的关系数据库中的 数据范式的组织形式。但是、这一层面的数据却不完全等同于原始数据，可以做一些去噪、去脏、统一字段等（建议什么都不做）
2.2.3.2 dw层
主要是对ods层的数据进行清洗、去重、以主题的形式做宽表处理(表关联、字段的增减、微聚合)。 细分以下几层
1）dwd层(数据仓库明细层)
表关联(对ods的各个表进行关联、或者再连接DIM层的维度)制作宽表，也可以去掉字段、增加字段(time-->year、month、day)。统一字段格式(不同的表的时间，统一格式)。
注意：表关联时，都是根据主题进行关联。2) dw层(数据仓库层)
1. 对dwd层的数据，进行微聚合，这样为上一个DM层做数据支持，提高上一层的效率。
2. 可以选择性的与dim层再次关联。
3. 这层的数据模型一般要根据主题来确定要使用的数据模型，比如星型模型还是雪花模型2.2.3.3 DM层(数据集市)
1. 根据主题做最终的指标查询，数据来源于可能是其他任意层，多数情况是dw层，一般一个部门对应一个数据集市，而一个数据集市中，可以有多个统计结果的表。
2. 该层的作用可以进行数据展示、数据报表、也可以为数据挖掘提供数据支持2.2.3.4 DIM层(维度层)
为整个数据仓库，提供常量值。
比如整个世界的所有国家代码、名称、位置
再有一个国家的省、市、县、区信息
比如时间的维度： 年 月 日 季度 星期
...2.3 数据仓库的开发命名规范
1. 数据仓库的库的命名
数仓层_业务名称 比如: 教育主题：
ods_edu
dwd_edu
电商主题：ods_tele
2. 数据仓库表的命名
- 每种来源的类型代码
01 -> hdfs数据
02 -> mysql数据
03 -> redis数据
04 -> mongodb数据
05 -> tidb数据
- 命名规则：
数仓层_来源代码_业务
比如：
ods_release.ods_01_release 投放数据
ods_release.ods_02_user 注册用户表(业务表：存于MYSQL)
dw_release.dw_customer 目标客户主题表
dm_release.dm_customer_stat 目标客户统计表2.4 数据仓库的两种主流维度模型
2.4.1 星型模型
1. 星型模型是一种多维度的数据关系，
2. 它由一个事实表和一组维度表组成。每个维度表都有一个维度作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。其包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。
简单说：一个事实表周围只有一层维度表。
+86 1001 广东 10010001 广州 区1
+86 1001 广东 10010001 广州 区2
+86 1001 广东 10010001 广州 区3
................................
+86 1002 广西 10010001 广州 区1
+86 1002 广西 10010001 广州 区2
+86 1002 广西 10010001 广州 区3
1001 广东
1002 广西
......
1001 10010001 广州
1001 10010002 深圳
.....
2.4.2 雪花模型
1. 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
2. 雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的"层次"区域，这些被分解的表都连接到主维度表而不是事实表。如图 2，将地域维表又分解为国家，省份，城市等维表。
3. 它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
简单说：一个事实表周围的维度表不止一层。优势是减少数据冗余 
三、名次解释
3.1 维度
1. 观察(审视)数据的角度，比如从城市名、季度、年份、国家名等不同的的角度来分析数据。
2. 维度是多个值的一个集合。
比如城市维度： 深圳、上海、哈尔滨、合肥、长春这些值构成一个维度字段。
3. 维度是一种离散数据： 同一个维度的两个不同的值，没关系，都是独立的。在做数据统计(和、最大、最小、平均、数量)时，都是将相同值的数据聚合起来的。3.2 维度系数(基数)
维度基数（Cardinality）指的是这个维度在数据集中出现不同值的个数。 比如province这个维度，有湖北、广东、湖南、北京等34个值，则该维度的基数就是343.3 度量
1. 度量就是被聚合的统计值，也是聚合运算的结果
2. 度量和刚才说的维度 是数据统计的两个主要概念
3. 度量主要用于分析或者评估，比如对趋势的判断，对业绩或者效果的判定等等。比如在一般的大数据分析 应用里面就有总PV，总UV等度量用于评判一个网站或者APP的活跃度
PV: page viewer 页面访问量
UV: user viewer 用户访问量
select province,city,count(1) 个数,sum(sales) 销售总额,avg(nvl(sales,0))平均销售额 from tablename group by province,city,uid;3.4 指标
指标用于衡量事物发展程度的单位或方法，它还有个IT上常用的名字，也就是度量。。例如，维度“城市”可以关联指标“人口”，其值为具体城市的居民总数
指标： 人数数量，流失量，汇入量， PV(page view, 统计的是一个网站被访问的次数)，UV(统计的是一个网站被多少人访问)，GDP、收入、用户数、利润率、留存率、覆盖率等。很多公司都有自己的KPI指标体系，就是通过几个关键指标来衡量公司业务运营情况的好坏。案例说明
1、企业运营好坏的指标：
1.月常规收入 MRR
2.总客户获取成本 tCAC
3.常规性毛利 RGB
4.毛利回收期 GMPP
5.预计生命周期 eLT
6.生命周期价值 LTV
7.总客户获取成本回报率 rCAC 2、一个网站的指标
维度与指标
虽然维度和指标可以独立使用，但常见的还是相互结合使用。维度和指标的值以及这些值之间的关系，使您的数据具有了意义。为了挖掘尽可能多的深层次信息，维度通常与一个或多个指标关联在一起。 例如，维度“城市”可以与指标“人口”和“面积”相关联。有了这些数据，系统还可以创建“人口密度”等比值指标，带来有关这些城市的更详细的深入信息3.5 事实表
1. 事实上、所有的表，都可以称之为事实表
2. 主要包含了描述特定商业事件的数据，即某些特定商业事件的度量值。
3. 一般情况下，事实表中的数据不允许修改，新的数据只是简单地添加进事实表中。
4. 发生在现实世界中操作型事件，其产生的可度量数值，存储的表统称事实表。例如交易表
事实表：就是经常发生数据增加的表，而且数据增加的量特别大，比如订单表，交易表，各种流水表
特点：事实表的字段除了有维度主键外，剩下的都是度量字段，比如额度，额度总量，平均额度等。
表中的每一条数据，都表示发生了一个事实(发生了事件)
事实表可以再细分：
事实事实表
周期快照事实表
累积快照事实表3.6 ETL
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化 Transfer, 装载Load）的过程，ETL是数据仓库的流水线3.6.1 E
Extract、数据抽取： 指的就是将源数据导入到数据仓库中。
1. 抽取方式：
- 拉取（poll）,指的是数仓主动拉取源数据， 这是最常用的方式
- 推送（push）,指的是源数据方主动把数据存储到数仓里，这种方式不可取，原因是源数据还要单独开发一个推送机制。会影响性能
2. 抽取类型：
- 全量导入: 数据总量小。
- 增量导入: 数据总量大，导入上一次导入后的发生变化的数据。3.6.2 T
Transfor、数据转换：
1. 数据转换是将数据进行重构以及标准化，消除数据的不一致，处理缺失数据，转换最主要的任务就是
数据清洗。
2. 数据清洗是对数据进行重新审查和校验的过程，目的在于删除重复信息，纠正存在的错误，并提供数据一致性。我们说数据仓库的数据源是多个业务系统，各来源的数据存在着差异和和冲突，也就是我们所说的脏数据，按照一定的规则处理脏数据的过程就是数据清洗
3. 一般的数据清洗流程如下：
-- 预处理
-- 建立标准化
-- 去重处理
-- 处理错误值
-- 处理缺失值
-- 格式内容清洗
-- 逻辑错误清洗
-- 修正矛盾内容
-- 非需求数据清洗
-- 关联性验证3.6.3 L
Load、数据装载
1. 预装载： 一些常量表，比如维度表的数据要提前购买，装载到数据仓库中
2. 初始装载：在数据仓库搭建完后，对现有的企业数据一定次导入到数据仓库中
3. 定期装载：日常产生的新数据，进行定时的导入到数据仓库中总结：数据仓库的整个流程其实就是ETL的流程
3.7 数据仓库建模
3.7.1 概念说明
数据仓库建模指的就是建表。
3.7.2 整个流程
业务建模》领域概念建模》逻辑建模》物理建模
1. 业务建模，这部分建模工作，主要包含以下几个部分：
划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
深入了解各个业务部门的内具体业务流程并将其程序化。
提出修改和改进业务部门工作流程的方法并程序化。
数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
2. 领域概念建模，这部分得建模工作，主要包含以下几个部分：
抽取关键业务概念，并将之抽象化。
将业务概念分组，按照业务主线聚合类似的分组概念。
细化分组概念，理清分组概念内的业务流程并抽象化。
理清分组概念之间的关联，形成完整的领域概念模型。
3. 逻辑建模，这部分的建模工作，主要包含以下几个部分：
业务概念实体化，并考虑其具体的属性
事件实体化，并考虑其属性内容
说明实体化，并考虑其属性内容
4. 物理建模，这部分得建模工作，主要包含以下几个部分：
针对特定物理化平台，做出相应的技术调整
针对模型的性能考虑，对特定平台作出相应的调整
针对管理的需要，结合特定的平台，做出相应的调整
生成最后的执行脚本，并完善之。3.7.3 数仓建模的步骤也可以总结如下：
--1. 分析数据源
(1)根据业务确定主题
(2)确定各种数据源：RDBMS、ACCESS、CONTENT
--2:考虑平台和工具的选择: hdfs，hive、hbase、flume、sqoop、datax等
--3: 设计逻辑模型
(1) 设计表模型
(2) 设计数据仓库分层(kill inmon还是kim ball)、选择数据模型(星型模型、雪花模型)
(3) 设计命名规范
--4：实施操作
(1) 建库建表
(2) 装载数据(预装载)
(3) ETL过程(制定采集方案、制定脚本(增量导入、查询、增加分区)
(4) 最终自动化ETL 扩展： 一个项目的基本流程
1. 项目设计报告(多方案)
2. 项目需求分析
3. 项目模块化
4. 开始实施(测试)
5. 项目结束、交接、安装、测试、运维四、案例演示：销售案例
4.1 数据源分析
4.2 业务需求分析(指定指标)
4.3 平台的选择
mysql、hdfs、hive、sqoop、flume、superset、kylin等4.4 设计逻辑模型
1）设置时间维度表、抽象出来地域维度表
2）选择kimball架构体系，选择数据模型(星型模型、雪花模型)
比如，选择雪花模型
3）设计分层名称规范
电商主题：
库名：ods_tel
dwd_tel
dws_tel
dm_tel
dim_tel
表名：
ods_tel.ods_sales_order
...........
dim_tel.dim_product
dim_tel.dim_date
dim_tel.dim_customer
dim_tel.dim_area
.......
dwd_tel.dwd_sales_order
.........
dws_tel.dws_sales_order_day（.....）
......
dm_tel.dm_sales_order_final()4.5 数仓建模实施
4.5.1 平台搭建、采集数据
hdfs,hive,sqoop,flume等4.5.2 数仓的构建
一般选择创建hive表，ods层的数据一般都是textfile，其他层的数据一般都是parquet格式
ods层：
create database if not exists ods_tel;
use ods_tel;
create table if not exists ods_sales_order(
......
)
parititioned by(.....) clustered by() into 4 buckets....
row format delimited
fields teminated by ","
stored as textfile;
其他表如是dim层：
create database if not exists dim_tel;
use dim_tel;
create table if not exists dim_tel.dim_product(
......
)
row format delimited
fields teminated by ","
stored as parquet;
其他表如是dwd层：
create database if not exists dwd_tel;
use dwd_tel;
create table if not exists dwd_tel.dwd_sales_order(
......
)
row format delimited
fields teminated by ","
stored as parquet;
其他表如是dws层：
create database if not exists dws_tel;
use dws_tel;
create table if not exists dws_tel.dws_sales_order_day(
多个维度字段，
day,
多个度量字段，
)
row format delimited
fields teminated by ","
stored as parquet;
其他表如是dm层：
create database if not exists dm_tel;
use dm_tel;
create table if not exists dm_tel.dm_sales_order_final(
多个维度字段，
多个度量字段，
)
row format delimited
fields teminated by ","
stored as parquet;
其他表如是(=-=,元旦假期过的是真的快,一眨眼三天时间就过去了,现在开始慢慢补文章,过几天会发一个完整版的项目文档上来,大家可以提提意见!)
