1.简介

1.1诞生背景

1. 历史数据积存：历史数据使用频率 低，堆积在业务科中，导致性能下降；
2. 企业数据分析需要：各个部门自己建立独立的数据抽取系统，导致数据不一致；

1.2基本概述（Data Warehouse,DW）

1. 由数据仓库之父比尔恩门提出；
2. 数据仓库是一个面向主题的、集成的、非易失的且随着时间变化的数据集合；
3. 主要用于组织积累的历史数据，并使用分析方法（OLAP、数据分析）进行分析整理，进而辅助决策，为管理者、企业系统提供数据支持，构建商业智能；

1.2.1数据仓库的特点

• 面向主题：为数据分析提供服务，根据主题将原始数据聚合在一起；
• 集成：原始数据来源于不同数据源，要整合成最终数据，需要经过抽取、清洗、转化；
• 非易失：保持的数据是一系列的历史快照，不允许被修改，只允许通过工具进行查询、分析；
• 时变性：数仓会定期接、集成新的数据，从而反映出数据的最新变化；

1.2.2数据库VS数据仓库

类型	数据库	数据仓库
概述	数据库面向事业设计，属于OLTP（在线事务处理）系统，主要操作是随机读写；在设计时尽量避免冗余，常采用符合范式规则来设计；	数据库面向主题设计，属于OLAP（在线分析处理）系统，主要操作是批量读写；关注数据整合，以及分析、处理性能；会有意引入冗余，采用符合范式规则来设计；
面向	事务	分析
数据类型	细节、业务
数据特点	当前的、最新的	综合、清洗过的数据
目的	日常操作	历史的、跨时间维护
设计模型	基于ER模型，面向应用	长期信息需求、决策支持
操作	读/写	星形/雪花模型，面向主题
数据模型	GB到TB	>=TB

1.3数据仓库建设方案

	传统数据仓库	大数据数据仓库
概述	由关系型数据组成MPP(大规模并行处理)集群	利用大数据天然的扩展性，完成海量数据的存放 将SQL转化为大数据计算引擎任务，完成数据分析
问题	扩展性有限、热点问题	SQL支持率、事务支持

1.4MPP&分布式架构

1.4.1MPP架构

1. 传统数仓中常见的技术架构，将单机数据库节点组成集群，提升整体处理性能 ；
2. 节点间为非共享架构（share Noting），每个节点都有独立的磁盘存储系统和内存系统；
3. 每台数据节点通过专用网络或者商业网络互相连接，彼此协同计算，作为整体提供服务 ；
4. 设计上有限考虑C一致性，其次考虑A(可用性)，尽量做好P(分区容错性)。

1.4.2MPP架构优点

1. 运算方式精细，延迟低、吞吐低；
2. 适合中等规模的结构化数据处理。

1.4.3MPP架构缺点

1. 架构缺点：存储位置不透明，通过Hash确认数据所在的物理节点，查询任务在所有节点均会执行；
2. 并行计算时，单节点瓶颈会成为整个系统短板，容错性差；
3. 分布式事务的实现会导致扩展性降低。

1.4.4分布式架构

1. 大数据中常见的技术架构、也成为hadoop架构/批处理架构；
2. 各节点实现场地自治（可以单独运行局部应用），数据在集群中全局透明共享；
3. 每台节点通过局域性或广域网相连，节点间的通信开销较大，在运算时致力减少数据移动；
4. 优先考虑的是P（分区容错性），然后是A（可用性），最后再考虑C（一致性）

1.4.5MPP+分布式架构

1. 数据存储采用分布式架构中的公共存储，提高容错性；
2. 上层架构采用MPP，减少运算延迟。

1.4.6常见产品

传统数据仓库

• Oracle RAC
• DB2
• Teradata
• greenplunm

大数据数据仓库

• Hive
• Spark sql
• HBase
• impala
• HAWQ
• TIDB

2.架构

2.1架构图

2.2ETL流程

2.2.1ETL--Extract-Transform-Load

1. 将数据从来源端经过抽取（extract）、交互转化（transform）、加载（load）至目的端的过程；
2. 构建数据仓库的重要一环，用户从数据源抽取所需的数据没经过数据清洗，最终按照月线定义好的数据仓库模型，将数据加载到数据仓库中去；
3. ETL规则的设计和实施约占正回购数据仓库搭建工作量的60%-80%。

2.2.1.1数据抽取（Extraction）

• 抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据；
• 结构化数据一般采用JDBC、数据库日志方式，非/半结构化数据会监听文件变动；

2.2.1.2抽取方式

• 数据抽取方式由全量同步、增量同步两种方式；
• 全量同步会将全部数据进行抽取，一般用于初始化数据转载；
• 增量同步方式会检测数据的变动，抽取发生变动的数据，一般用于数据更新；

2.2.2数据转换（Transformation）

数据转化要经历数据清洗和转化两个过程：

• 数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理；
• 数据转化主要是对数据进行标准化处理，进行字段、数据类型、数据定义的转换；

结构化数据再转化过程中的逻辑较为简单，非/半结构化数据的转化

数据加载（Loading）

将最后处理完的数据导入对应的目标源里

2.2.3ETL过程

结构化数据ETL工具

• Sqoop
• Kettle
• Datastage
• Informatica
• Kafka

非/半结构化数据ETL工具

• Flume
• Logstash

2.3数据积存

2.3.1操作数据层（ODS）

1. 数据与原业务数据保存一致，可以增加字段来进行数据管理（update_time、from、update_type）；
2. 存储的历史数据是只读的，提供业务系统查询使用；
3. 业务系统对历史数据完成修改后，将update_type字段更新为UPDATE,追加回ODS中；

在离线数仓中，业务数据定期通过ETL流程到ODS中，导入方式有全量、增量两种：

• 全量导入：数据第一次导入时，选择此种方式；
• 增量导入：数据非第一次导入，每次只需要导入新增、更改的数据，建议使用外连接&全覆盖方式

2.4数据分析

2.4.1数据明细层（DWD）

1. 数据明细层对ODS的数据进行清洗、标准化、维度退化（把时间、分类、地域这类维度加入表内）
2. 数据仍然满足3NF模型，为数据预算做准备

2.4.2数据汇总层（DWS）

1. 数据汇总层的数据对数据明细层的数据，按照分析主题进行计算汇总，存放便于分析的宽表；
2. 存储模型并非3NF，而是注重数据聚合，复杂查询、处理性能更优的数仓模型，如维度模型；

2.4.3数据应用层（ADS）

1. 数据应用层也被称为数据集市；
2. 存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担；
3. 数据仓库擅长数据分析，直接开放业务查询接口，会加重其负担；
4. 数据应用层（kylin报表决策、HBase并发查询、ElasticSearch搜索检索）

3.建模

3.1基本概念

3.1.1OLTP系统建模方法

1. OLTP（在线事业处理）系统中，主要操作时随机读写；
2. 为了保证数据一致性、减少冗余，常使用关系模型（ER模型）；
3. 在关系模型中，使用三范式规则来减少冗余；

3.1.2OLAP（在线联机分析）

1. OLAP系统，主要操作时复杂分析查询；关注数据整合，以及分析、处理性能；
2. OLAP根据数据存储的方式不同，有分为ROLAP、MOLAP、HOLAP;

OLAP系统分类

1. ROLAP(Relation OLAP):使用关系模型构建，存储系统一般为RDBMS
2. MOLAP(Multidimensional OLAP，多维型OLAP)：预先聚合计算，使用多为数组的形式保存数据结果，加快查询分析时间；
3. HOLAP（hybird PLAP，混合架构的OLAP）:ROLAP和MOLAP两者的集成；如低层时关系型的，高层时多维矩阵型的；查询效率高于ROLAP,低于MOLAP；

3.2ROLAP系统建模方法

典型的数据仓库建模方法有ER模型、维度模型、Data Value、Anchor

ER模型（成熟）

1. 出发点时整合数据，为数据分析决策服务
2. 需要全面了解业务和数据
3. 实施周期长
4. 对建模人员能力要求高

维度建模（互联网）

1. 为分析需求服务，更快完成需求分析
2. 具有较好大规模复杂查询相应性能
3. 最流行的数仓建模经典

Data Value

1. ER模型的衍生
2. 强调数据的历史性、可追溯、原子性
3. 弱化一致性处理和整合
4. 引入范式，应对源系统的扩展性

Anchor

1. data value模型的衍生
2. 初衷为设计一个高度可扩展模型
3. 会带来较多的join操作

3.2.1维度模型

• 维度模型中，表被分为维度表、事实表，维度是对事实的一种组织；
• 维度一般包含分类、时间、地域等
• 唯独模型分为星型模型、雪花模型、星座模型
• 唯独模型建立后，方便对数据进行多维分析 

星型模型

• 标准的星型模型，维度只有一层，分析性能最优

雪花模型

• 雪花模型具有多层维度，比较接近三范式设计，较为灵活

星座模型

• 星座模型基于多个事实表，事实表之间会共享一些维度表；
• 式大型数据仓库中的常态，式业务增长的结果，与模型设计无关；

什么是宽表模型

• 宽表模型式维度模型的衍生，适合join性能不佳的数据仓库产品；
• 宽表模型将维度冗余到事实表中，形成宽表，以此减少join操作；

3.3MOLAP

3.3.1MOLAP系统建模方法

1. MOLAP将数据进行预结算，并将聚合结果存储到CUBE模型中;
2. CUBE模型以多维数组的形式，物化到存储系统中，加快了后续的查询；
3. 生产CUBE需要大量的时间、空间，维度预处理可能会导致数据膨胀；

 常见的MOLAP产品

• Kylin（开源产品代表）
• Druid

3.4多维分析

3.4.1OLAP多维分析

• OLAP主要操作时复杂查询，可以夺标关联，使用count、sum、avg等聚合函数
• OLAP对复杂查询操作做了直观的定义，包括钻取、切片、切块、旋转

3.4.2钻取

• 对维度不同层次的分析，通过改变维度的层次来变换分析的粒度
• 钻取包括上卷（ROLL-UP）、下钻（DRILL-DOWN）
• 上卷（ROLL-UP）,也称为向上钻取，指从低层次到高层次的切换
• 下钻（DRILL-DOWN），指从高层次到低层次的切换

3.4.3切片（slice）、切块（dice）

• 选择某个维度进行分割称为切片；
• 按照多维度进行的切片称为切块；

3.4.4旋转（Pivot）

对维度方向的互换，类似与交换坐标轴上卷（Roll-up）

 4.最佳实践

4.1表的分类

4.1.1维度建模中的表类型

• 事实表
• 维度表
• 事务事实表
• 周期快照事实表
• 累积快照事实表

事实表

• 一般是指现实存在的业务对象，比如用户，商品，商家，销售员等

维度表

• 一般是指对应一些业务状态，代码的解释表。也可以称之为码表
• 通常使用维度对事实表的书籍进行统计、聚合运算

4.1.2事实表的3个分类

事务事实表

• 随着业务不断产生的书籍，一旦产生就不会再变化，如交易流水、操作日志、出库入库记录

周期快照事实表

• 随着业务周期性的推进而变化，完成间隔周期内的度量统计，如年、季度累计
• 使用周期+状态度量的组合，如年累计订单数，年时周期，订单总数是量度

累计快照事实表

• 记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单的状态表；
• 通常由多个时间字段，用于记录生命周期中的关键时间点；
• 只有一条记录，针对次记录不断更新；
• 

实现方式一

• 使用日期分期表，全量书籍记录，每天的分区存储昨天全量数据与当天增量数据合并的结果；
• 数据量大会导致全量表膨胀，存储大量永远不更新的冷数据，对性能影响较大；
• 适用于数据量较少的情况；

实现方式二

• 使用日期分区表，推测数据最长生命周期，存储周期内数据；周期外的冷数据存储到归档表；
• 需要保留多天的分区数据，存储消耗依然很大；

实现方案三

• 使用日期分区表，以业务实体的结束时间分区，每天的分区存放当天结束的数据；设计一个时间非常大的分区，如9999-12-31，存放截止当前未结束的数据；
• 已结束的数据存放到相应分区，存放未结束数据的分区，数据量也不会很大，ETL性能好；
• 无存储浪费，数据全局唯一；
• 业务系统可能无法标识业务实体的结束时间，可以使用其他相关业务系统的结束标志作为次业务系统的结束，也可以使用最长生命周期时间活前端系统的数据归档时间；

4.1.3拉链表

• 拉链表记录每条信息的周末周期，用于保留数据的虽有历史（变更）状态；
• 拉链表将表数据的随机修改方式，变为顺序追加；

4.2ETL策略

全量同步

• 数据初始化装载一定使用全量同步的方式；
• 因为业务、技术原因，使用全量同步的方式做周期数据更新，直接覆盖原有数据即可；

增量同步

• 传统数据整合方案中，大多采用merge方式（update+insert）
• 主流大数据平台不支持update操作，可采用全外链接+数据全量覆盖方式
• 如果担心数据更新出错，可以采用分区方式，每天保存最新的全量版本，保留较短周期；

4.3任务调度

4.3.1为什么需要任务调度

• 解决任务单元之间的依赖关系
• 自动化完成任务的定时计划

4.3.2常见类型

• Shell
• Java程序
• Mapreduce程序
• SQL脚本

4.3.3常见调度工具

• Azkaban
• Oozie

 

5.项目实战

5.1项目背景

• 某电商企业，因数据积存、分析需要，筹划搭建数据仓库，提供数据分析的访问接口；
• 项目一期需要完成数据仓库建设，并完成用户复购率的分析计算，支持业务查询需求；

复购率计算

• 复购率是指在一段时间间隔内，多次重复购买产品的用户，占全部人数的比率；
• 统计各个品类下，品牌月单次复购率和多次复购率；

5.2数据描述

 

 

 

5.3架构设计

5.3.1数据仓库架构图

5.4环境搭建

5.4.1环境说明

操作系统依旧组件版本

• CentOS 7.2
• Hadoop 2.7.7
• Hive1.2.1
• Tez 0.9.1
• MySQL 5.7.28
• Sqoop 1.4.6
• Azkaban 2.5.0
• Presto 0.196

5.4.2集群规划

使用3台虚拟机进行搭建

	Hadoop	Hive&Tez	MySQL	Sqoop	Azkaban	Presto
node01	✔				✔	✔
node02	✔		✔		✔	✔
node03	✔	✔		✔	✔	✔

 5.4.3搭建流程

1. 安装并准备3台CentOS7.2虚拟机，主机名为node01、node02、node03
2. 上传自动化安装脚本automaticDeploy.zip到虚拟机node01中
3. 解压automaticDeploy.zip到/home/Hadoop/目录下
4. 更改frames.txt文件，配置组件的安装节点信息

Downloads – Oracle VM VirtualBoxhttps://www.virtualbox.org/wiki/Downloads

5.5项目开发

整体开发流程

1. 业务数据生成
2. ETL数据导入
3. 创建ODS层，并完成HDFS接入
4. 创建DWD层，并完成ODS层数据接入
5. 创建DWS层，导入DWD层数据
6. 创建ADS层，完成复购率计算
7. 编写脚本，将ADS层的数据导出到MySQL中，供业务查询
8. 使用Azkaban调度器，实现脚本自动化运行